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
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 , 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  and all functions are systematically callable ,
- 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.