Why write a plugin?

Modifying SPIP to your own needs prior to 1.9

The templates, tags, loops and filters

SPIP can be customised in many different ways. The primary requirements for customisation are quickly dealt with by using templates, which are basically HTML files supplemented with SPIP code, and which are stored in a prioritised hierarchy of directories.

We can similarly construct our own templates by relying on standard elements such as tags and loops, elements which we can also create and customise as we so choose.

When required, we can transform the display of a tag by using custom filters, functions coded in PHP in a file named mes_fonctions.php.

However, it may also happen that our requirements go beyond the traditional framework of a SPIP site, such as publishing articles on the Internet in a collaborative fashion amongst the site editors. So it may sometimes become necessary to lightly or significantly alter SPIP’s behaviour in order to add new editorial elements, to link them to each other and other components, and to manage them through an interface that has been customised or rendered more ergonomic for the user.

Modifying the core of SPIP

To achieve such customisations, it was necessary to enter a complex process of rewriting many of the kernel files, i.e. modifying SPIP’s standard distributed code. Of course, this is a perfectly legitimate approach [1], but which makes adhering to upgrades to SPIP itself a painful and difficult task indeed.

Modifying SPIP to your own needs post 1.9

Since version 1.9, SPIP has implemented a formal structure to enable modification and extension of the system in a manner which remains harmonious with the core code. The principle followed is that of "grafting" all manner of improvements and modifications on top of it (and removing such grafts when we want to without touching any code in our original core SPIP system). The possibilities are then so wide that the question becomes one of how to facilitate the installation, both on an individual implementation as well as a public distribution point of view, of all these types of customisations.

Technically, the introduction of the plugin mechanism opens up the following possibilities:
-  all files in the kernel can be overloaded [2] and all functions are systematically callable [3],
-  an application interface (API) is maintained through the definition of a large number of entry points (pipelines) built into the code.

Plugins are typically required for four different scenarios:

-  Functions and options: creating your first plugin, migrating and making your functions and options portable for both your own use and that of others.

-  The pipelines: injecting, when you activate the plugin, some code into the SPIP kernel and significantly altering its default behaviour.

-  Modifying the native files: absent any suitable pipeline, you can modify sections of the SPIP code without actually having to interfere with the kernel files themselves.

-  Rewrite your own code: inventing your own scripts which you can "graft on to the side" of the standard SPIP engine.

If none of these goals is your current concern, then you probably need not bother with the pages that follow :) However, you might still be very interested in what is available to you from the myriad of freely distributed plugins.


[1We remind the reader that SPIP is licensed under the GPL, which grants complete freedoms to use the code as one wishes, to examine how it works and modify it freely to one’s own needs, and to redistribute both the original and any modifications one might have made.

[2Overloading a file consists of instituting repeated read attempts of a nominated file so that it takes the the one assigned the highest (and most recently changed) priority. Schematically speaking, if you overload a file which has a value of "Good morning" with another file that has a value of "Good evening", then the screen will display "Good evening" and not "Good morning".

[3You can call any previously existing function from any file, so long as you have included at the start of your file a reference to the file that contains the function that you wish to use. This is particularly powerful, since the SPIP designers have implemented a plethora of functions offering standardised processing that you have no need to reprogramme yourself. As examples, there are lire_fichier (which reads a file), ecrire_fichier (which writes to a file), preg_files (which searches for a file), all of the SQL query commands and dozens of other functions which are simplified as much as possible using procedures contained with the SPIP source code. See the documentation of the code to find out more about them.

There is a substantial list of available plugins now (which are completely open if you wish to review the constituent code)

Author Mark Published : Updated : 26/10/12

Translations : català, corsu, English, Español, français, italiano, Nederlands