Modifying SPIP to your own needs
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 [1] and all functions are systematically callable [2],
- 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.