SPIP 1.9

* *

This article sets out the principal features of version 1.9 that have been introduced since the last stable version (SPIP 1.8.3) [1].

1. Public site

New standard templates

The templates have been redesigned, and now follow the W3C standards and accessibility guidelines more closely. The navigation interface has been rearranged, and the style sheets have been simplified, to make customising your site easier.

These templates have inclusions: three for the navigation menu by section, the header and the footer (which are repeated on each page) and two others for forums and petitions signatures.

SPIP’s forms have also been redesigned. For better accessibility, each form field has an associated <label>, and the various elements are more rigorously gathered in “logical building blocks” thanks to the dedicated tags <fieldset> and <legend>. Moreover, the forms render easily using CSS: Don’t my forms look smart!.

Advanced syndication

The syndication feed templates (backend) are now in RSS 2.0 format. A site configuration option makes it possible to specify whether you want to output all the contents of your articles in these RSS feeds, or only a summary. The syndication also includes information on the section in which the article is placed as well as the article’s keywords and associated documents (podcasting). When your SPIP site syndicates another site having such an enriched flow, it can also analyse this data. See the article La syndication de contenus (translation pending).

Additional document formats

SVG (Scalable Vector Graphics) format, now rendered as a valid file type by FireFox and Opera, is now allowed as a file type that you can insert in article’s text (via the shortcut <emb1>). The uploading of this format which embeds Javascript, is protected in the following way:

• if uploaded by an editor, SPIP purges the document of any Javascript code and any reference to a Javascript file;
• if uploaded by an administrator, SPIP accepts the document as is.

Other new formats are also supported: Abiword (abw), Blender (blend), Video Flash (flv), truetype fonts (ttf), as well as all “open document” formats (OpenOffice.org).

Page URLs

The files article.php3 etc., which were installed in the site root and used to call the article (for example) template, are not necessary anymore and have been removed.

Therefore, these files do not appear in the default URLs anymore (the default URLs are now called "urls page" and are of the form /spip.php?article12 (for the article number 12) or /spip.php?page=plan (for the site map! template plan.html).

Please note:

• an htaccess.txt file is provided to enable visitors (and search engines) who use the old addresses to be redirected to the right pages. For the majority of hosts, renaming this file to .htaccess (invisible file) will be sufficient to activate it and is recommended. This file can also be used for the management of the page URLs ("clean URLs", etc).
• if migrating or upgrading, if you leave the old files article.php3 etc. in the root, they will continue to function thanks to the dummy file inc-public.php3 - but note that this will not be possible in the next version of SPIP.
• the control of the cache age (variable $delais) is now taken care of by the tag #CACHE which fits directly in the template to set the refreshing delay (however, the variable $delais still function if it is present in your old .php3 files).

To choose another mode of URL management it is still possible to modify the variable

$type_urls

in the file ecrire/mes_options.php.

php or php3 files?

All .php3 files have been renamed .php, but the old names are still supported by SPIP, with the result that your customised files (mes_fonctions.php3, ecrire/inc_connect.php3 or ecrire/mes_options.php3) are still taken into account.

This will not be the case with SPIP 2.0: you should rename these three files as soon as possible.

Compatibility: SPIP requires a version of php higher than 4.0.8, and is compatible with version 5.x. Its compatibility with MySQL 4 and 5 has been re-examined and improved.

Graphic filters

An important collection of new filters makes it possible to apply graphic treatments to the images.

They require the presence of the GD2 library on the server.

Some filters deal with colours (to render in black and white, in sepia, to darken, lighten...), others rotate, blur, mirror, apply degrees of transparency or a transparency mask etc.

An article Traitement automatisé des images (translation pending) covers these new graphic treatment filters.

The filter |couleur_extraire extracts a colour from an image (logo, attached documents...) to apply this colour to other elements of the page (blocks of colours, CSS style, typographical image, etc). One can thus automate variations of colours between the various pages of the site, while preserving graphic coherence.

A series of filters makes it possible to modify the extracted colour (lighten, darken, etc.) to create a complete palette of colours. An article presents the use of these filters on image colours.

In the same way, the filter |image_typo creates typographical images, i.e. images representing the text via a font available on the server, guaranteeing a uniform display in all the browsers without the need to use their propre fonts. An article describes the complete use of the filter image_typo. In addition to GD2, this filter requires the presence of Freetype on the server (it is generally installed with GD2).

Improvements in image thumbnail creation

In the site configuration, under the “Advanced Functions” tag, it is highly recommended to select the GD2 option (if it is available on the server). The compression carried out with this method is now much more accurate, and it preserves the transparent zones of GIF and PNG images.

The filter |reduire_image becomes |image_reduire (to keep the consistency with all the image processing filters now beginning with |image_). The old name is still available for now.

A new filter, |image_reduire_par reduces the dimensions of an image by a certain factor (for example: |image_reduire_par{2} reduces the dimensions of the image by two).

New tags

• #CACHE. The old variable $delais (delay before the cache is refreshed) can now be set in the templates themselves with the tag #CACHE{duree} (note: one can use here, as before, an expression of the style 24*3600). This new tag has an additional option to also produce an HTTP header indicating to the browser that the page will not change for a specified period of time.
• #HTTP_HEADER allows you to define HTTP headers, for example #HTTP_HEADER{Content-Type: text/css}. IMPORTANT: using this tag will cause SPIP to remove the administration buttons: this replaces the old variable $flag_preserver, which will be abandoned from SPIP 2.0.
• #CHEMIN{fichier} (improves #DOSSIER_SQUELETTE). #CHEMIN{xxx} will give the complete path to the file xxx, whether it is in the root, in the default templates folder dist/ or in your templates folder squelettes/ etc.
• #DESCRIPTIF_SITE_SPIP returns, as its name suggests, the site description that has been entered in the general site configuration. Useful for meta tags.
• Modification of #LOGO_SITE_SPIP from now on, this is different from the default section logo (rubon0.jpg), #LOGO_SITE_SPIP now returns the site’s logo (siteon0.jpg). The site’s logo is added, like the title and the description of the site, in the general site configuration.
• Syndicated sites: the new tags #SOURCE and #URL_SOURCE display the name and the address respectively of the original source of the syndicated content. In the syndicated contents, the tag #TAGS displays in the form of microformats the links to the attached documents, the keywords and the heading.
  For more details see the article syndication of contents.
• the technical tag #CONFIG displays the value of a configuration variable stored in the table spip_meta
• very technical also, #EVAL{} will evaluate the PHP expression between brackets. Thus, #EVAL{2*7} gives 14, #EVAL{_DIR_IMG_PACK} will give the path of the folder ecrire/img_pack/ (this tag should be used with caution)
• A simplified syntax is now available for the INCLUDE (SPIP tag INCLURE) where one specifies nothing but the name of the template to be included, in the form <INCLURE {fond=template2} {id_article}>. (Note: it has not yet been decided if this syntax will lead in the long term to an "internal" storage of the fragment thus included in the current page.)
• as far as security is concerned, it is from now on possible to completely remove the safety filters on a tag by applying a double star (example: [(#TEXTE**)] allows you to compile php inserted in an article - if you leave this option as is in a template you expose your site to serious security problems).
• the tags with arguments, i.e. followed bya pair of brackets, benefit from a simplified syntax , the parantheses and brackets are no longer mandatory: one can thus write
  #EXPOSE{rouge} instead of
  [(#EXPOSE{rouge})].

Automatic loop pagination

A generic system of pagination of the results of a loop is integrated: it uses the criterion {pagination} (which can take as argument the number of elements to be posted on a page: {pagination 5}) and the tags #PAGINATION and #ANCRE_PAGINATION. The default templates are full of examples of pagination (see the article documenting the pagination system). Note: this system is not compatible with this contrib’.

Criteria

• The criterion {inverse} can take any tag as a parameter to dynamically vary the sorting direction. It is possible to write: <BOUCLE_exemple(ARTICLES){par #ENV{sorting}}{inverse #ENV{sortdirection}}>, which allows to set the sorting direction (&sortdirection=1 ou &sortdirection=0) and the column to sort (&sorting=titre or &sorting=date, etc.) in the URL.

• There is now a possibility to make a criterion conditional by adding a question mark at the end ({lang?}).

• the criterion {xxx IN 1,2,3} accepts a table of values passed by the URL (see definition of the criterion IN).

Better cache management

The cached file does not only depend on the URL of the page, but also on the domain name, the value of $dossier_squelettes (where your templates are stored) as well as the value of a named aggregate variable $marqueur, which can be set freely. That allows, for example, to change a template "on the fly" while benefitting from the cache (visitor customisation, functionality "var_skel"...).

Also, the cached file is no longer compressed if it is small (< 16 Kb) to gain a bit more efficiency for templates with many (small) inclusions.

Language and characters

• SPIP selects by default the “universal” character set utf-8. There is a button, in the private area, to convert your site to this character set (this is not mandatory).

To ease this conversion, if your templates include accentuated characters, they will be converted (at the time of page recalculation) in the character set specified for the site.

• A new language was added: Bosnian.
• A filter |direction_css makes it possible “mirror” a CSS file for languages written from right to left. If the stylesheet to be mirrored is called style.css, this filter uses (if the current language is written from right to left) an optional stylesheet style_rtl.css; if this one does not exist, it automatically creates an RTL stylesheet by replacing all the occurrences of left by right and vice versa (and stores it in the IMG/cache-css/ folder). It generally applies to a tag #CHEMIN : [(#CHEMIN{style.css}|direction_css)].

2. Private area and administration

Introduction of AJAX

The private area integrates, in an experimental way (as certain functionality is not active in MSIE), AJAX navigation elements (or rather AJAH, as HTML elements are directly created by the server). These allow a richer navigation without reloading the whole page. These navigation forms are intended, primarily, for larger sites (containing inclusions of many sections and articles).

Starting from a certain number of sections, the drop-down menu allowing you to select in which sections the current element is (for example an article) is replaced by a small navigator in four columns showing the structure of the site:

This small menu, in addition to giving better navigation in the structure of the site, has its own search engine.

The lists of elements (in particular of articles) benefit from AJAX in two manners:

• when there are many elements, the pagination of 10 by 10 (articles 1 to 10, then 11 to 20, etc.) is displayed without reloading the page completely, only the list is reloaded; the small button "More" (+) at the top right makes it possible to display the complete list, also without reloading the whole page;
• on the articles, when the site is multilingual, the "microphon" marking the multilingualism changes the list display to a mode making it possible to follow the state of the translations.

Speed of display

Page loading in the private area was very slow using Internet Explorer 6; a specific code has been developed for this browser, increasing the loading speed to match other browsers. However, this should not dissuade you from using FireFox!

In addition, page compression has been disabled in the private area to allow faster final rendering.

Revision of the status of "restricted administrators"

This status suffered from some inconsistencies and has been entirely re-examined. To benefit fully from its new options, it is recomended that this status applies only to first level sections, though its application to other levels remains possible.

Restricted administrators can now manage the forums in their sections, download documents by ftp from the upload/login directory, make an XML backup of their sections (saved in this same directory), and follow the site statistics. On the home page of the private area, a menu at the top right provides direct links to the sections they manage, and symmetrically the home page of a section shows in a similar menu a list of the restricted administrators of that section.

Conversely, other previous options for restricted administrators of a section (creation of keywords, creating a user account, emptying the cache) are not available to them anymore, so that the site administrators have full control over the evolution of the site (to avoid quasi-identical keywords, and to be able to approve the new editors).

Improvement of the backup system

The backup system, importing/exporting SQL tables to XML now includes external tables. It is also more robust for possible interruptions of the backup process when the database is bulky, and shows the progression of the backup more accurately.

The restoration process is also quicker, and is more robust when restoring backup files of old versions of SPIP. It is now possible to directly restore an XML backup that has been done via phpMyadmin.

Improvement of indexing (for the search engine)

The code has been rewritten to take into account any declared table which includes a field idx: SPIP can thus index additional tables, and normally search them via loops and the criterion {recherche}.

The weights of the various fields in the indexing of the words can be defined.

The various index tables have been merged into one.

Improvement of statistics

A finer analysis of the inbound links allows a more accurate calculation, and it is no longer necessary to establish a connection to the database for each visit, which should reduce considerably the load on the server.

In addition, the publication of a referrer also shows a thumbnail of the home page of that site (for most of those sites). By default, the source of these labels is Thumbshots.org. It is possible to modify the site providing the thumbnails, with one or the other of the following generating sites (in the file ecrire/mes_options.php):

$source_vignettes = "http://open.thumbshots.org/image.pxf?url=http://"; 
$source_vignettes = "http://msnsearch.srv.girafa.com/srv/i?s=MSNSEARCH&r=http://"; 
$source_vignettes = "http://pthumbnails.alexa.com/image_server.cgi?id=www.monsite.net&size=small&url=http://";

3. The programming interface

Note: this is a technical part and is of interest if you develop extensions or want specific installations of SPIP

Rewriting of the code continues, with the intent of offering in the long term a standardised programming interface. Information in this section is provided in order to make it possible for the various SPIP extensions (in particular the thousands of contributions available on SPIP-Contrib) to be able to function with SPIP 1.9, even under a shared installation. Note: this information does not guarantee the presence of such functionality in future versions of SPIP, where the programming interface will be entirely reviewed.

Reorganisation of the files and folders

As indicated above, and already undertaken with SPIP 1.8, the files extension .php3 have disappeared, confirming that PHP3 is no longer compatible. This renaming, necessary to avoid ambiguity, has been accompanied by a complete reorganisation of the directories.

The root directory no longer contains the templates and stylesheet files. These are now in the directory dist, which is essential and cannot be removed.

The root no longer contains scripts like spip.php, and its alias index.php (internal adjustment makes it possible to put ./ in place of spip.php in the URL: define('_SPIP_SCRIPT', '') but by default it is define('_SPIP_SCRIPT', 'spip.php') as we cannot be absolutely certain that only the root of the site will call this script (there could be a simple index.html with a home page).

Other scripts have been moved to sub-directories of the directory ecrire/ and are distributed as follows:

• exec/ = > scripts which produce the pages in the private area;
• action/ = > scripts which modify the database without building a page to be returned to the client (for example a change of status of an article with the small floating bullets);
• base/ = > the functions which drive the database;
• inc/ = > libraries of functions used by SPIP.

Override of standard files

Thanks to the reorganisation above, it is possible to change SPIP’s behaviour in the private area without modifying its source and therefore add your own customisation without breaking future updates.

Any script s in the private area is now called by a URL of the form ecrire/?exec=s..... SPIP will then look for each directory appearing in the constant SPIP_PATH whether there is a file exec/s.php. The first file found will be loaded, and should define the function exec_s, which will then be called. As a last resort, SPIP will load the standard file ecrire/exec/s.php which contains the definition of the function exec_s_dist to be executed.

This behaviour is also provided by the functions action_a_dist defined in the files action/a.php.

You can also override the standard libraries, which are loaded by the function include_spip or include_ecrire (which is deprecated but continues to function). When calling include_spip('inc/name') SPIP will seek a file with that name in a sub-directory inc of the directories in SPIP_PATH which will be loaded instead of the standard file.

You will see that this interface also makes it possible to add scripts and libraries to SPIP, without ever modifying the source.

Calling scripts through a function, rather than directly, also has the advantage of forcing consistent naming of the aggregate variables, which has advantages for security.

This work has two important benefits: the integration of a system of plugins, and the possibility of distributed sources of SPIP between several sites.

Plugins

Introduction of a system of plugins; a new sub-menu appears in the “Configuration” menu when a folder named plugins/ is detected in the root of the site. You can then activate the plugins installed in this folder one by one. For more information, see the article Installing plugins.

Many plugins are in preparation; their development is taking place primarily on the SPIP Zonehttp://zone.spip.org/trac/spip-zone..., and their documentation will be on the site SPIP Contrib.

Distributed sources

An important rewriting of all the SPIP code means that it is possible for the same distribution to serve several sites at the same time without the need to replicate the source. This functionality can be deployed by one user having several sites on a host (with several MySQL accounts or even with only one, thanks to table prefixes) or by the host willing to offer a simple preconfigured SPIP installation to all users (to optimize disc usage).

Such an installation does not prevent each user customising SPIP, thanks to the override system described in the previous section of this article. Howerver, it requires that the host allows certain directives (Alias or RewriteRule) in the htaccess file of its configuration, or that he configures this directly in his httpd.conf file (VirtualHost directive).

Automatic detection of tables SQL and joints

In a template containing the loop BOUCLE_a(xxx), the table xxx can be any SQL table registered in your server. SPIP will query the SQL server to find the description of the table. This will allow the compiler to process the template and interpret all the tags #NAME as a SQL column <span class="base64" title="PGNvZGUgY2xhc3M9J3NwaXBfY29kZSBzcGlwX2NvZGVfaW5saW5lJyBkaXI9J2x0cic+eHh4PC9jb2RlPg=="></span>.name if it exists. These columns will also be valid as loop criterions.

In a template containing a loop table table1 ... tableN), the tables 1 to N will be taken as candidate for a join between columns of the same name. More examples will be provided in the documentation soon.

Other improvements

• If the revisions tracking is activated, it is now possible to revert to an earlier version of an article.
• The shortcut bar is now available in Safari.

Installation and update

spip_loader: for the automatic installation of SPIP 1.9, a new spip_loader.php has been set up (/spip-dev/INSTALL/). Once installed on the server, it directly downloads the same zip file as for a manual installation and extracts the files. Other innovations relating to spip_loader: it is now multilingual, and it is very easy to publish it so that it installs the latest development version (SVN) instead of the stable version.

For an update from a previous version of SPIP, you can copy all the files of SPIP 1.9 over your existing installation as before. Nevertheless, taking into account the fundamental reorganization of the files, you will obtain a not very satisfactory mixture of old and new scripts.

It is thus advised, after updating the database, to carry out a backup dump.xml.gz and then carry out a new installation in which you will copy your directory IMG and your templates and proceed then with the restoration of your file dump.xml.gz. A thorough documentation is given in this article: article 3472.

* *

All the innovations will be gradually integrated into the reference pages of the documentation. More detailed articles are being prepared and translated on the most technical points.

In a general way we need assistance to improve the documentation of SPIP: do not hesitate to take part in the drafting, the proof reading, the correction, the translation or the organization of this documentation.

Lastly, a big thank-you to all those who contributed to this new version by reporting problems or by suggesting ideas (on the lists or on trac) on code, images, or documentation, by supporting users, and, at all times ... by doing this with feelings.