Phing pour gestionnaire de plugin

Bonjour,

est-ce que Phing serait une bonne solution pour la base d'un gestionnaire de plugins ?

J'attends par là :
- lancer l'extraction du .zip
- le déploiement des fichiers dans l'arborescence du site
- gestion des dépendances (inter-module)

Je bataille depuis plusieurs jours à trouver une solution pas trop old school pour faire ceci. J'ai aussi pensé à faire avec PEAR mais bon ça complique. Le but étant d'installer / désinstaller les plugins un peu comme le fait Wordpress.

Auriez-vous d'autres solutions à me conseiller ?

Merci aux personnes qui prendront la peine de m'aider :calim2:

Moi je vois ça un peu comme un usine à gaz.
Dans ma boite, on est en train de passer à phing pour le déploiement de nos applications, et l'une d'entre elle gère des extensions.
Mais on n'utilise pas phing pour cela (notamment parce que comme WordPress, on a une interface web de gestion des plugins).

Phing ne me semble pas le plus simple (mais pas impossible). Enfin si Pear ne te convient pas, pour moi Phing ne sera pas meilleur pour cela.

As tu regardé les archives PHAR ? Un seul fichier contient tous tes scripts, en restant exécutable. C'est en natif en 5.3, sous forme d'extension avant.

Concernant la création de package Pear à partir de Phing, il y a ceci :
http://phing.info/docs/guide/stable/...earPackageTask

Phing est un outil de build, pas un gestionnaire de plug-in.

Il y'a une différence.

Tu peux utiliser phing pour publier plusieurs releases d'une application PHP avec des plug-ins préinstallés (par exemple, package minimum, plug-in conseillé ...).

Tu ne peux pas utiliser phing pour permettre à un utilisateur d'installer un plug-in (ou alors ça sera une très grosse usine à gaz).

D'après ce que j'ai compris, tu souhaites un système de plug-ins applicatifs. C'est à dire ces plug-ins viendraient enrichir ton application (le cas de wordpress).

PEAR est utilisés pour installer des extensions qui viennent enrichir PHP sur un serveur. Ca ne semble pas cadrer avec tes besoins.

Comme tu l'as souligné, Wordpress propose un système d'upload et d'installation, de même pour Joomla. Tu peux regarder de leur coté comment c'est codé.

J'ai regardé du coté du Zend Frameworks qui propose un système de plug-in en natif mais pas le coté installation que tu recherches.

Fabien

Merci pour vos réponses !

@max-mag : oui j'ai regardé du coté de .phar, je vais l'employer pour le package du plugin. :)

La difficulté que je rencontre c'est la gestion des dépendances, surtout au niveau des versions du noyau lui même.
Par exemple tel plugin compatible avec telle version du noyau. Niveau conceptuel je bloque sec.
Pour le déploiement je me dis qu'à la limite chaque plugin contient une sorte de fichier build.xml (ou un array en php) qui indique le chemin pour le déploiement.
Enfin je ne sais pas trop ce n'est pas évident surtout que si après je dois revoir tous les plugins à cause d'un changement de méthode ça va être pénible et long.

@Phelim : le système de plugin de Zend me semble plus être un système de classe "pluggable" dans une application dev avec Zend.
Concernant PEAR, Symfony l'utilise je me disais que ça serait peut être un début de solution mais bon au bout du compte je ne pense pas.

Je suis en train de regarder wordpress pour voir comment c'est fichu, par contre je ne caresse pas trop l'idée de mettre tous les plugins dans un dossier spécifique, je préfère déployer direct (image dans dossier img, css dans dossier css, le forum dans le dossier forum, ...).

Si vous avez des idées je suis preneur !

Concernant les dépendances, voici dans les grandes lignes notre système :

• Téléchargement du plugin zippé via une interface web
• Extraction
• lecture du fichier xml

Ce fichier xml contient la version minimale du core, la licence etc ...
Si la licence ou la version ne collent pas, l'installation échoue.
Je pense que l'on peut imaginer vérifier les dépendances avec ce système.
Par contre, s'il faut résoudre les dépendances, c'est autre chose ...

Ok merci, ça confirme un peu ce que je comptais faire (donc ça rassure).

Mis à part pour le fichier XML j'hésite entre : XML, INI, array PHP

Pour nous, le xml a été évident.
Les extensions pouvant être développée par des tiers, on a limité au maximum php, donc pas de paramétrage vis un tableau php. Mais c'est le plus souple et le plus performant.

Un fichier ini n'était pas assez souple, un fichier xml oui. Je veux dire par là que l'on peut au final avoir une structure plus claire et hiérarchisée qu'avec un ini.

Mais tout dépends de ce qu'il y a à configurer. Par ailleurs on utilise des ini par simplicité.

Ok. Effectivement avec un peu de recul le fichier.ini ne sera pas très pratique, le array PHP peut nécessiter des passerelles si un plugin est développé en Flash par exemple, reste XML.

Citation:

---

Mais tout dépends de ce qu'il y a à configurer.

---

Bonne question !
La base de la config étant le basique "nom, description, chemin, dépendance, auteur". Je pense que je vais partir sur du XML ça sera plus évolutif si il y a d'autres config particulières à ajouter plus tard, surtout si c'est en profondeur.

Merci pour ton aide :)