Objectifs
Le premier objectif de la maquette SPIPRemix est de faire la démonstration qu’il est possible d’intégrer composer dans le développement de SPIP et des applications qu’on peut en faire sans remettre en question les principes techniques et fonctionnels historiques de SPIP, tels que la gestion de ses plugins via SVP, l’organisation des fichiers, ses principes de chargement de fonction, etc.
De SPIP3.0 à SPIP3.2, proposer des chantiers permettant aux utilisateurs de rester dans leur version actuel en passant par la "méthode composer" pour les mises à jour.
Ceci afin d’effectuer les transitions suivantes :
- Passer le code de SPIP et des plugins "core" à GIT,
- Fournir un mode opératoire pour les développeurs de contributions sur la zone pour organiser leur code de sorte que leurs plugins SPIP puissent être installés avec composer, et migrent vers une plate-forme GIT à leur rythme,
- Faciliter la fourniture de "distributions" basées sur SPIP,
- Se passer de smart_paquets pour générer des Zips,
- Unifier les méthodes d’installation et de mise à jour en un seul principe, que ce soit via le web (spip_loadper.php et le plugin SVP) que par ftp ou ssh,
- Permettre qu’à terme il soit possible d’isoler les fonctions de SPIP sous forme de composants spécialisés ou transitoires, tant pour les fonctionnalités (CMS) que pour les aspects techniques tels que la journalisation, l’accès à des référentiels de type SQL ou autres, la transformation des contenus, le compilateur lui-même, etc.
Cible
La maquette SPIPRemix se propose de simuler la mise à disposition d’une version SPIP3.3 entièrement gérée par Composer pour son installation/mise à jour.
Limites
- PHP5.3+,
- Les seuls plugins requis pour qu’une application soit opérationnelle seront traités.
- Le plugin SVP et spip_loader.php ne sont pas traités.
Chantiers
- Transitions de la gestion de source,
- Dépôt Composer,
- Séparation du code de SPIP en composants.
Scenarii possibles
Il y a plusieurs manières d’arriver à l’objectif selon l’ordre dans lesquelles on traite les briques technologiques.
Plan A
Le plan A ci-dessous a vocation à fournir un dépôt Composer aussi vite que possible. Pour cela, il nécessite l’aménagement des dépôts SVN officiel de SPIP et de la ZONE (pour le répertoire _core_) et la configuration d’un ou plusieurs serveurs web Apache.
Ainsi, il est possible de décider la migration vers GIT plus tard et de rendre cette transition indolore puisque Composer y aidera.
Donc, dans l’ordre :
- Réarrangement des dépôts Subversion de SPIP et de la Zone (répertoire
_core_), - Associer ces dépôts à un serveur http+ssl,
- Mettre en œuvre le Dépôt Composer,
- Séparer SPIP en composants,
- Mettre en œuvre les outils d’assistance à migration pour les utilisateurs,
- Migrer SPIP et les plugins "core" sur un serveur git.
- Arrêter le dépôt SVN de SPIP, supprimer le répertoire
_core_de la Zone, - Arrêter smart_paquets,
- Modifier le plugin SVP et spip_loader.php en conséquence.
Nous n’avons pas mis en œuvre ce scénario à cause des difficultés rencontrées pour la mise en place de la pile SVN+APACHE+DAV_SVN chez notre hébergeur.
Plan B
Le Plan B, que nous avons utilisé pour SPIPRemix, privilégie la migration de SVN vers GIT.
- Réarrangement des dépôts Subversion de SPIP et de la Zone (répertoire
_core_, - Migrer SPIP et les plugins "core" sur un serveur git,
- Mettre en œuvre le Dépôt Composer,
- Séparer SPIP en composants,
- Mettre en œuvre les outils d’assistance à migration pour les utilisateurs,
- Arrêter le dépôt SVN de SPIP, supprimer le répertoire
_core_de la Zone. - Arrêter smart_paquets,
- Modifier le plugin SVP et spip_loader.php en conséquence.
Hors périmètre
- autoloading, et autres PSRs,
- gestion de la configuration (
paquet.xml), - organisation des fichiers d’une application web basée sur SPIP,
- intégration de composants tiers via Composer,
- gestion des "assets" à savoir traductions, ressources "statiques" (css, js, images),
- historique des dépôts subversion officiels.