Bonjour,
C'est certain, les modules sont généralement un plus pour faire adopter un outil par les utilisateurs.

Un système qui me parait simple serait de permettre l'appel d'un fichier php modifiable par l'utilisateur et qui pourrait appeler les modules souhaités.

En détail voici une réalisation envisageable :
* Aujourd'hui le fichier category.php se compose "grossièrement" des parties suivantes :

   - Contrôle et initialisation de l'environnement [if ( isset(...))]
   - Définition des variables [$template->assign_block_vars(...)]
   - Affichage du template [$template->parse('category')]

Juste avant l'affichage du template il faudrait faire un include d'un fichier .php customisé par l'utilisateur. Dans le cas général ce fichier reste vide mais si un utilisateur veux ajouter des fonctionnalités à la page category il lui suffit de définir de nouveaux block_vars. Ce que j'ai suggéré  dans un post c'est de l'appeler /template/template_name/category.php ainsi la customisation de la page est liée au template et pas au coeur de pwg. De cette page on peut même appeler des modules.

on obtient donc :
* /category.php  :

   - Contrôle et initialisation de l'environnement [if ( isset(...))]
   - Définition des variables [$template->assign_block_vars(...)]
   - Appel de la customisation de la page [include ('/template/template_name/category.php')]
   - Affichage du template [$template->parse('category')]

* /template/template_name/category.php

   - Définition des variables customisées [$template->assign_block_vars('custom',array)]
   - Appel d'un module [include ('/modules/module_name.php')] 
   - ...

* /modules/module_name.php

   - Définition des variables du module [$template->assign_block_vars('module.module_name',array)]

* /template/template_name/category.tpl

   - Appel de la variable customisée [ {custom.myVar} ]
   - Appel de la variable des modules [ {module.module_name.moduleVar} ]
   - ...

J'espère que je n'ai pas écrit de conneries et que c'est réalisable. Si ça l'est ça ne me parait pas fastidieux pour les développeurs de pwg (juste un appel à un fichier situé dans le répertoire /template) et ça ouvre la porte à tous les délires de développeurs.

A+
MBt

Oui, je conviens bien que l'idée est excellente. Sauf que je n'attacherai pas les plugins dans les templates.
Un plugin se doit d'être disponible sur l'ensemble des templates.
Je conseillerai un répertoire spécifique comme /plugins/ par exemple.

Pour moi: C'est bon, mais je laisse Chris regardez ça.
Il a du taf pour un moment avec toutes ces excellentes idées qui débarquent.   
Il va falloir trouver du temps et le moyer de l'aider. (Pas moi, Chris...). 
8-)

Merci Vincent pour tes encouragement,
mais effectivement, je pense que je ne vais pas pouvoir me tapper tout le boulot,
ou alors on va mettre du temps ;-)

Vu du côté "template", ça m'a l'air pas mal.
Vu du côté "moteur", j'ai un peu les mêmes questions que Pierrick, c'est pourquoi je voulais qu'on prenne la peine d'en parler avant de se lancer.
Je pense que l'on ne va pas couper à gérer des compatibilité de version entre les plugins et PWG.

chrisaga a écrit:

Merci Vincent .

De rien, ce sujet n'était rien à coté de l'autre. Dure! Dure!

chrisaga a écrit:

Je pense que l'on ne va pas couper à gérer des compatibilité de version entre les plugins et PWG.

Je suis d'accord avec ta conclusion.
Je vois une table toute bête (administrable).

Comme ceci (c'est une idée):

CREATE TABLE `pwg_plugcomp` (
`PWG_version` TEXT NOT NULL ,
`cmptblty` BINARY DEFAULT 'false' NOT NULL ,
`plugin_name` VARCHAR( 32 ) NOT NULL ,
PRIMARY KEY ( `plugin_name` ) 
)
) TYPE = MYISAM COMMENT = 'PWG Compatibility with plugins';

Upgrade de PWG: On efface tout... En beta test on valide les plugins compatibles (sur le site uniquement) et chaque plugin chargé insère sa référence compatible 1.6/1.7 (deux lignes dans ce cas). La table n'a pas besoin de la version du plugin, le plugin Resizer 0.2 est compatible 1.6 il insère 1.6...    Resizer 0.3 est compatible 1.7 il insère 1.7... la version de PWG sait lesquels elle peut activer.

rvelices a écrit:

Desavantage: le html rajoute n'est pas toujours compatible avec le template courant. Mais pourquoi pas des templates a l'interieur du plugin ?

C'est d'ailleurs LE problème des plugins. Les développeurs les crééent souvent pour leur besoin perso et en fonction du template qu'ils utilisent pour leur gallerie avant de les partager. Les utilisateurs qui récupèrent un plugin se rendent souvent compte qu'il faut entrer dans le code php pour modifier l'affichage. Lourd!

Question : faut-il allourdir le développement d'un plugin en imposant un système de template ou faut-il encourager la création de plugin au risque que certains développeurs ne pensent pas à la portabilité??
Mon avis : Favoriser la création.

rvelices a écrit:

b. rajout de fonctionalites: example news, download zip, print with shutterfly etc...
- la problematique ici est l'interaction entre noyau, plugin et template et ca ce n'est pas facile car de mon point de vue, idealement le plugin ne devrait pas necessiter la modification du noyau ou du template - c'est tout l'interet du plugin.

Le plugin ne doit pas modifier le noyau c'est certain. Par contre, à mon avis, le template doit être modifié pour prendre en compte (ou non) un plugin.
Pour ne pas toucher au template, il faudrait alors définir des zones dans les templates dans lesquelles les plugins pourront s'insérer sans que le designer du template n'en connaisse l'existance desdits plugins : {Z_MENU_PLUGIN} qui définit un menu dans lequel les plugins pourront ajouter des entrées pour ouvrir des pages particulières (zipDownload par exemple).
Se qui risque de manquer d'ailleurs c'est une page spécifique (plugin.php?page=mon_plugin) équivalente à picture.php ou category.php qui serait appelée pour afficher une fonctionnalité : formulaire de zipDownload qui invite l'utilisateur à uploader un fichier zip dans une catégorie et affiche les images extraites du zip dans la catégorie. De même /admin/plugin.php?page=mon_plugin permettra de configurer un plugin.

Question : Faut-il laisser le soin au designer du template de contrôler même l'intégration des plugins au risque de devoir modifier les tpl à chaque ajout de plugin ou faut-il faciliter la portabilité des templates en proposant aux plugins de s'y intégrer de manière transparente au risque que le designeur ne contrôle plus son template??
Mon avis : Il ne faut pas laisser les développeurs de plugins devenir maître du template, ce n'est pas leur rôle. Le designer doit garder la main.

Mbt

VDigital a écrit:

rvelices a écrit:

Mais pourquoi pas des templates a l'interieur du plugin ?

S'il te plait, Non. Je ne suis vraiment pas pour. Les templates c'est autre chose.
Si le template Truc n'intègre pas Bidule, bein c'est comme ça.
L'auteur de Truc peut fournir son template.
Sinon ça devient trop compliqué, c'est aux auteurs de template de savoir gérer les infos renvoyées par les templates/ou activant les templates.

Je m'explique: le developpeur des plugins peut decider d'avoir ses templates a lui a l'interieur du repertoire plugin. De cette maniere:
- il a le controle sur ses templates independament des templates du noyau.
- pas de probleme d'integration avec les templates orignales
- pas de probleme de sources a mettre a jour et a patcher
- si quelqu'un n'aime pas - facile a savoir qu'est ce qu'il faut modifier ou encore il desactive le plugin