[ar] [ast] [bg] [br] [ca] [co] [cpf] [cs] [da] [de] [en] [eo] [es] [eu] [fa] [fon] [fr] [gl] [id] [it] [ja] [lb] [nl] [oc] [pl] [pt] [ro] [ru] [sk] [sv] [tr] [uk] [vi] [zh] Espace de traduction


The search engine

August 2010

All the versions of this article:

SPIP includes its own search engine which is deactivated by default. When activated by an administrator on the configuration page, this engine is used to perform searches over the various types of data stored in the database: articles, sections, news items, keywords and authors.. Since SPIP 1.7.1, the forum discussion threads and petitions signatures have also been indexed.

The general principle

There are generally two major methods for implementing a search engine. The first is to quite stupidly search through the existing data storage systems (HTML files, database... depending on the type of site). This method is very slow since the type of storage that you generally have available was not envisaged for this type of purpose.

The second method, which has been adopted by SPIP (and also by all the professional search engines), is to establish a storage method specific to the requirements of searching. For example, the score for each word in an article can be directly stored so that it can be easily accessed again, and to obtain a total search score with simple addition. The advantage here is that the search is very fast; almost as fast as any other page calculation we might make. The inconvenience is that it requires a construction phase for the said information storage; this is the step known as indexing. Indexing has a cost in terms of resources (process time and disk space), and also introduces slight delays in time between the addition or modification of content and that addition or modification being reflected in the search engine’s results. On the other hand, in the case of SPIP, we are obliged to use PHP and MySQL like we do for the rest of the software, which does not help us deliver a high performance search engine, not only in terms of speed, but also in terms of relevancy of various other enhancements (indexing documents external to the site, creation of semantic fields enabling more finely tuned searches, etc.).

The advantage of the internal engine, however, is that it makes it possible to manage the display of the search results using the same methods (templates) as for the rest of the SPIP pages, and to do so within the same visual environment.


The indexing is accomplished during visits to the public site. In order to avoid accumulation of indexing tasks and page calculations that would lead to time outs on particularly slow servers, SPIP waits until a page is displayed by using the cache [1].

Indexing treats the various text data fields of a given content type one by one: for example, for an article, the standfirst, the description, the title, the text... For each text data field, the score for each word is calculated simply by counting the number of occurrences. For this purpose, words of three characters or less are ignored (they are in most cases insignificant and entail the creation of an unwieldy database); on the other hand, any accented characters are transliterated (converted into their non-accented equivalents) in order to avoid problems linked with character sets and also to make it possible to perform searches using the non-accented version of keywords.

Finally, the scores for each word are accumulated in a weighted version between the various text data fields for the indexed content. The weighting makes it possible, for example, to assign a greater weight to keywords that occur in the title of an article than is assigned to the same words in the body text or in the post-scriptum...

The indexing functions can be studied within the ecrire/inc_index.php3 file. To better visualise the dynamic indexing of the site, you can open the ecrire/data/spip.log file, or perhaps view the ecrire/admin_index.php3 page (note: this page, still rather experimental, is not delivered with all versions of SPIP and exists only in French. It has been withdrawn from [SPIP 1.9] and is now available from the recherche_etendue plugin with several other index management functions).

In version [SPIP 1.6], some important changes were applied to the behaviour of the engine:
-  better behaviour in a multilingual environment;
-  the underscore is no longer considered as a word separator but as an alphabetic character (useful for computer-related documentation);
-  any words of two letters (or more) that only contain upper-case characters are considered as abbreviations or acronyms and will be indexed, which eliminates one of the major drawbacks with restricting indexing to words of more than 3 letters (G8, USA, VAT, UN are now all indexed).

The search

The search simply operates by separating the search text into distinct words; the same filter is applied as during indexing: deletion of words of three letter or less (except acronyms) and transliteration of accented characters.

For each content being searched, the score of the various words is then retrieved and added in order to obtain a total score. Finally, the results are generally displayed in decreasing score order ({par points}{inverse}), i.e. in decreasing order of relevancy (but which remains at the discretion of whoever codes the templates to format the results).



On a modern server that is not overloaded, indexing a long piece of text (several tens of thousands of characters) will take between one or two seconds: the wait is almost imperceptible compared with the delays of transferring data over the network. Short contents are indexed quasi-instantaneously. Of course, these claims need to be tempered depending on the size of the site. A truly enormous site risks seeing indexing times extend a bit; to put this in perspective, note that a site like Le Courrier des Balkans contains some 3800 published articles as at the time of writing, and more than 7500 forum messages, none of which have caused SPIP’s search engine to show any signs of weakness at all.

In addition, statistically speaking, we can assume that each piece of content will approximately be indexed only one time: taking consideration of the fact that there are generally many more visits to a site than there are content updates, the server overhead experienced will appear to be quite negligible overall.


Indexing quality is lower than the professional search engines. Since PHP is overall a rather slow language, the phase of extracting words had to be simplified as much as possible so that the indexing time remained at a strict minimum. As a result, the indexing data includes some "waste", i.e. text fragments that do not actually correspond to "real" words but which have been indexed as such (these are often technical contents like file names or sections with terrible punctuation). Using the example of uZine, where we observe approximately 2% of such "waste", we are still left with the impression that these data are quite negligible in quantity, and that they are quite unlikely to be found as positive hits during any search.

SPIP searching does not offer any boolean operators, with an implicit operator working more-or-less like a logical "OR". Nonetheless, since SPIP 1.7.1, the articles found will display in an order which privileges results containing more accurately spelled words as per the search criteria. As such a search for "the hand sign" will highlight articles containing the words "hand" and "sign" will in advance of articles which only contain "handsome" and "signalling" - those articles will still appear in the results list, just further down the ranks.

Disk space

MySQL not being specially designed for storing index data, use of the search engine tends to make the database eat up a lot of the available disk space. To provide a little more precision on this topic, we can say that a given text content generates index data of a size roughly between the size of that content itself and double the size of that same content. So if we extrapolate the data that is not indexed (the forums for example), then indexing will approximately double or triple the space occupied by the database. This can be painful if you don’t have a large disk space quota available to you.

If you ever do deactivate the search engine in an effort to save disk space, do not forget to then erase all of the indexing data (on the database backup/restore page) to ensure that the disk space occupied by those data really is freed up again.


[1So if you have set all of the $delais variables to zero, or if your site is never actually visited (like a test site), then indexing will never actually take place.

Show the template of this page Site powered by SPIP | Translation area | Private area