API

Pour modifier le fonctionnement d’un logiciel, il n’y a guère que deux méthodes :
 utiliser le paramétrage proposé d’origine par le logiciel (voir la Configuration initiale),
 modifier le code du programme !

 Notion d’API

Une API est une interface définie (sous forme d’une liste de fonctions ou points d’entrée), facilitant la reprise de fonctionnalités natives du programme d’origine (ici, du core de SPIP), dans vos propres programmes (ici, les pages de squelettes d’affichage de la table externe, assurant aussi l’insertion des données lues dans la table correspondante de SPIP).

Toutes les fonctions de SPIP (qui est écrit en PHP) sont à priori utilisables dans vos programmes, sauf que :
 la plupart des fonctions disponibles pré-supposent un environnement d’exécution (avec des fonctions dépendantes déjà accessibles),
 les fonctions de controle sont les points émergés d’un lacis de fonctions du source,
 toutes ces fonctions sont susceptibles d’évolution (changement de paramètres, de fonctionnement, voire disparition) selon les besoins des développeurs,

SPIP a choisi de résoudre ces difficultés en inscrivant divers moyens d’extensions, et vous allez voir, il y a beaucoup de solutions...

 Les divers niveaux d’API SPIP

Passons en revue tous ces moyens d’extension :

1. Déjà, par rapport aux squelettes de la dist, la surcharge de squelettes offre un espace d’extensions ./squelettes/ incomparablement plus simple, tout en restant dans un cadre hyper-sécurisé.
2. Des instructions du langage SPIP dans les squelettes permettent déja certaines programmations et calculs (#SET, #GET, #ENV,...)
3. De même la personnalisation de l’espace privé par des squelettes (à modifier dans ./squelettes/prive/) offre une nouvelle gamme de modifications.
4. La création (et l’appel dans l’interface) de nouvelles pages, voire de nouveaux objets éditoriaux par la Fabrique, apporte encore une nouvelle dimension aux extensions.
5. Ces facilités s’articulent souvent sur la généralisation du modèle de formulaires CVT, avec même l’automatisme des formulaires configurer_... qui positionne une architecture relativement simple de création d’écrans d’interaction...
6. Le système de plugins propose alors un cadre de conception des extensions, apte à supporter les mises-à-jour automatisées
7. La plupart des fonctions de haut niveau de SPIP (écrites en PHP) sont surchargeables, en recodant des fonctions en source PHP, à enregistrer dans les fichiers mes_options et mes_fonctions
8. La structure des autorisations dans SPIP permet aussi un contrôle complémentaire
9. Les systèmes de variantes de squelettes, ou les squelettes contrôlés par mots-clés, proposent d’autres voies de compléments
10. et si cela ne suffit pas, vous avez accès
    au PHP dans les squelettes (par des filtres, ou -peu recommandé- par du source ecrit..)
    à la programmation PHP directe (au sein de plugins)...

 Surcharge directe

La méthode la plus directe -mais pas forcement la plus facile à réaliser, et surtout à pérenniser- c’est de modifier le code source.. sauf que, il n’est plus possible d’utiliser les mises-à-jour simplement : celles-ci écraseraient les personnalisations du code !
 Depuis longtemps, la programmation objet a popularisé le concept de surcharge [1], directement repris pour la surcharge des squelettes : les squelettes de Squelettes de la "dist" stockés dans un répertoire ./squelettes-dist peut être masqués et remplacés par leurs homonymes dans le répertoire ./squelettes !
 Un système analogue est mis en place pour Surcharger des fonctions :