La structure des fichiers
Je pense que ça change pas mal de choses sur la façon dont le code est structuré aujourd'hui. Chaque fonctionnalité est composée d'un à quatre morceaux : le code exécutable (PHP), les fichiers de ressource (ex. chaînes dans plusieurs langues, templates), les fichiers statiques (ex. CSS et JS) et les fichiers de sortie (ex. logs et images uploadées). Chacune de ces trois parties est placée dans un dossier à part parce que ça permet de les héberger avec des règles différentes sur le serveur web : les fichiers PHP doivent être exécutables tandis que tout le reste ne l'est pas, les fichiers statiques doivent être accessibles par HTTP tandis que les fichiers de ressource ne devraient pas l'être, etc. L'arborescence ressemble aujourd'hui à ça :yaronet/ resource/ src/ static/ storage/
Si on envisage des plugins pour yAronet, il faudrait pouvoir les distribuer sous la forme d'archives autonomes qu'il suffit de décompresser quelque part pour que ça fonctionne. S'il faut mettre des fichiers par-ci et des fichiers par-là, ça devient rapidement compliqué de s'y retrouver et d'ajouter/supprimer des plugins sans oublier d'en déployer la moitié ou de nettoyer des fichiers inutiles.
Mais du coup ça veut dire que le site doit pouvoir servir des fichiers statiques depuis plusieurs endroits, exécuter du code PHP stocké dans plusieurs dossiers, etc. L'arborescence deviendrait quelque chose comme ça :
yaronet/ plugin1/ resource/ src/ static/ storage/ plugin2/ ...
Il faudrait déterminer comment rendre ça possible sans que tout le dossier ne soit accessible par HTTP. Peut-être que faire proxy via le code PHP y compris pour les fichiers statiques pourrait être une option, mais ça reste assez dommage : un serveur HTTP est bien plus performant pour cette tâche, et peut utiliser plein de techniques auxquelles PHP n'a pas accès (cache & co).
Les hooks
Plus simple à expliquer : pour s'interfacer dans le site il faudra un système de hook qui permettrait d'intercaler facilement des morceaux de code. Même chose au niveau des templates, où on voudrait pouvoir ajouter ou modifier des élément visuels dans les pages existantes. Il faut trouver un bon compromis entre proposer suffisamment de points d'ancrage pour que ça reste permissif sans que le code n'en souffre trop.Pour l'intégration visuelles, une solution alternative serait de dire "il n'y a aucune possibilité d'insérer du code dans les pages, toutes les modifications doivent se faire en post-processing à l'aide de code JS". Mais d'une part ça va un peu à l'encontre d'un des choix du site de fonctionner correctement même sans JS, d'autre part ça repousse le problème un peu plus loin et ça risque d'être très difficile de maintenir une rétro-compatibilité avec ce genre de solution, donc je ne pense pas que ce soit une bonne idée.
Est-ce que vous avez d'autres choses en tête ?