🌍
Français
@lecden,
Piwigo est un projet collaboratif OpenSource.
L'équipe met à disposition de toutes les bonnes âmes des moyens pour contribuer de près ou de loin au projet Piwigo.
Le gestionnaire d'extension est mis à la disposition de tout ceux qui souhaitent partager leur travail.
L'équipe à bien entendu un droit de regard surtout au niveau législatif au niveau des licences mais après, pour ce qui est de la contribution pure, les contributeurs sont libres de leurs choix.
Bien qu'une extension soit hébergé sur nos serveurs, le maintient et le suivi des extensions n'est pas automatiquement assuré par l'équipe de Piwigo. Il y a beaucoup de contributions qui ne sont plus ou pas suivi car le développeur n'est plus joignable. L'équipe n'a pas pour but de s'occuper des extensions, le CORE demande déjà assez de travail.
Puisque vous parlez de Wordpress, ces derniers ont aussi une plateforme d'échange d'extensions, pour autant, les développeurs de Wordpress ne s’immiscent pas (doit moins je ne le crois pas) dans le suivi des extensions proposées...
Les plateformes d'échanges d'extensions sont misent en place dans le but de regrouper et d'aider à trouver plus facilement une extension à son CMS.
;-)
Je précise que je ne fais pas partie de l'équipe de piwigo... ce que je dis n'engage que moi.
Je suis juste un utilisateur, et j'ai développé un thème ainsi que recemment quelques dérivés.
Et je n'aurais pas forcément fait mon thème avec l'ancien système (template + thème).
D'autant que changer juste du css sur le thème de base piwigo ne m'intéressait pas forcément.
Piwigo ayant énormément de foncitonnalités... c'est très difficile de les intégrer toutes dans une charte graphique différentente, tout en restant cohérent avec le thème.
À partir du moment où l'on ouvre un CMS pour l'agrémenter de plugins ou de thèmes, on se doit un minimum de garder une compatibilité avec la version de base (je ne parle même pas de compatibilité entre plugins...).
Cette rigueur évitera à Piwigo de devenir au fil des versions une usine à gaz qui découragera les intégrateurs et autres développeurs qui ont besoin d'un environnement sain et stable pour s'engager dans un projet basé sur Piwigo.
Après si ce n'est pas la volonté des concepteurs de donner plus d'envergure à Piwigo ou d'en faire un système pérenne, je m'incline sur leur choix. Mais c'est dommage de ne pas poser les bonnes bases dès maintenant si c'était le cas.
lecden a écrit:
Or je constate qu'en changeant de thème, on peut perdre des boutons favoris, caddie, etc qui viennent de plugins piwigo affichés normalement sur le thême par defaut de piwigo mais pas nécessairement sur tous les autres thèmes.
Oui parce que la notion de thème piwigo englobe ce que tu appelles template + thème.
Ce que personnellement, je trouve assez favorable par rapport à la notion template / thème qui existait avant dans piwigo (et qui était assez délicate du point de vue du développeur du thème).
lecden a écrit:
Pour ce qui est de la notion de theme fils theme pere, je trouve cela assez risqué d'un point de vue maintenance. Un fork de template + theme serait plus approprié dans ce cas là.
C'est aussi beaucoup plus compliqué à gérer.
Si le système est trop rigide (obligation de garder toutes les fonctionnalités, compatibilité avec les différents plugins etc...) ça découragera certainement le développement de thèmes...
lecden a écrit:
PS : un retour vers le classique http://www.csszengarden.com/ pourra illustrer ces quelques propos
Merci pour le lien, j'avais perdu l'adresse.
Pour le reste, on va réfléchir.
Suggestion à propos des thèmes....
Un thème est dans le jargon informatique une version graphique d'un template, ce dernier définissant l'achitecture graphique d'un site. Nous pouvons donc avoir différents affichages (couleurs, polices, taille) d'un même template mais sans que celà affecte les différents modules et bouton/icones qui sont définis dans le template d'origine. Or je constate qu'en changeant de thème, on peut perdre des boutons favoris, caddie, etc qui viennent de plugins piwigo affichés normalement sur le thême par defaut de piwigo mais pas nécessairement sur tous les autres thèmes.
Cette perte de fonctionnalités n'est pas acceptable et va a contresens d'une architecture 3 tiers (présentation, fonctionnalités, données)
Le développement des thèmes et surtout l'acceptation par l'équipe piwigo de leur ajout dans la banque des themes devrait imposer de respecter l'affichage des fonctions par défaut, plus des zones d'affichage des plugins additionnels avec la possibilité de rendre l'affichage optionnel des ces fonctionnalités dans la partie configuration du thème ...si la finalité d'un thème était justement d'être allégée sur certaines fonctionnalités mais SANS PERTE par rapport à la version de base.
Pour ce qui est de la notion de theme fils theme pere, je trouve cela assez risqué d'un point de vue maintenance. Un fork de template + theme serait plus approprié dans ce cas là.
Wordpress, Gallery, Joomla ont tous un template de base clairement architecturé, versionné et donc pérenne qui permet à la communauté des "templaters" de proposer leur création tout en assurant une compatibilité fonctionnelle.
A vos claviers !
;-)
PS : un retour vers le classique http://www.csszengarden.com/ pourra illustrer ces quelques propos
Ok je commence à voir...
Oui, mais cela se complique un peu quand le thème devient un thème parent.
Ca devient un peu compliqué pour moi ... :-(
Ce que j'ai retenu c'est que mes anciens templates-extensions vont finir dans le sous-répertoire /template et comme ça j'ai mon_theme_a_moi lol
Gotcha a écrit:
Tu veux dire pour les templates-extensions donc ?
non.
dans le fichier themes/mon_theme_a_moi/template/monfichier.tpl je peux avoir besoin de connaitre le nom du thème.
or, le nom du theme ce n'est pas forcément "mon_theme_a_moi", un theme pouvant être dérivé d'un autre theme.
grum a écrit:
mathiasm a écrit:
Je viens de relire la page du wiki.
Je ne comprends pas l'intérêt de coder le nom du dossier qui contient le thème dans themeconf.inc.php, puisque celui-ci est dans le dossier qu'il référence ?
Ne peut-on pas supprimer cette référence ? Cela limite les risque d'erreur, non ? Ou alors c'est un garde-fou pour éviter les renommages intempestifs ?tu l'utilise dans les templates. c'est une information bien pratique car le template lui n'est pas forcément dans le même répertoire que le thème.
Tu veux dire pour les templates-extensions donc ?
grum a écrit:
mathiasm a écrit:
Je viens de relire la page du wiki.
Je ne comprends pas l'intérêt de coder le nom du dossier qui contient le thème dans themeconf.inc.php, puisque celui-ci est dans le dossier qu'il référence ?
Ne peut-on pas supprimer cette référence ? Cela limite les risque d'erreur, non ? Ou alors c'est un garde-fou pour éviter les renommages intempestifs ?tu l'utilise dans les templates. c'est une information bien pratique car le template lui n'est pas forcément dans le même répertoire que le thème.
Merci pour l'éclaircissement.
mathiasm a écrit:
Je viens de relire la page du wiki.
Je ne comprends pas l'intérêt de coder le nom du dossier qui contient le thème dans themeconf.inc.php, puisque celui-ci est dans le dossier qu'il référence ?
Ne peut-on pas supprimer cette référence ? Cela limite les risque d'erreur, non ? Ou alors c'est un garde-fou pour éviter les renommages intempestifs ?
tu l'utilise dans les templates. c'est une information bien pratique car le template lui n'est pas forcément dans le même répertoire que le thème.
Je viens de relire la page du wiki.
Je ne comprends pas l'intérêt de coder le nom du dossier qui contient le thème dans themeconf.inc.php, puisque celui-ci est dans le dossier qu'il référence ?
Ne peut-on pas supprimer cette référence ? Cela limite les risque d'erreur, non ? Ou alors c'est un garde-fou pour éviter les renommages intempestifs ?
Merci VDigital !