Comme beaucoup d'entre vous le savent, la semaine dernière, Syed Balkhi a assisté à WordCamp Raleigh 2012. Pendant l'événement, l'un de ses tweets a suscité un vif débat. Dans cet article, notre fondateur Syed Balkhi débattra si les types de publication personnalisés WordPress doivent figurer dans le fichier functions.php ou dans des plugins. Ci-dessous, un tweet qui a lancé ce débat :
N'ajoutez pas de types de publication personnalisés dans functions.php -> Vous devriez TOUJOURS utiliser un plugin spécifique au site – http://t.co/bebYXq2F #wcraleigh
— WordPress Beginner (@wpbeginner) 4 novembre 2012
Après le tweet, de nombreuses personnalités respectées de la communauté WordPress ont réagi. Vous pouvez voir la conversation complète ici. Curtis McHale est allé plus loin et a développé le sujet dans son nouveau billet de blog.
La conversation sur Twitter a soulevé d'excellents points.
Résumé des arguments
Argument des plugins : L'utilisateur aura toujours les données même s'il change de thème. Cela ne sera peut-être pas aussi joli, mais cela restera là.
Argument Functions.php : Les données sans design seraient sans pertinence. Cela confondrait encore plus les utilisateurs.
De quel côté êtes-vous le plus d'accord ? Clairement, les deux camps ont leurs problèmes, mais lequel est le moindre mal ?
Voici pourquoi nous pensons que les types de publication personnalisés devraient TOUJOURS résider dans un plugin spécifique au site ou un plugin séparé.
Longue vie aux données
Les types de publication personnalisés sont des données. Dans la plupart des cas, vos données survivront à la conception actuelle. Ayant changé nos thèmes plusieurs fois, nous comprenons clairement cette affirmation. Les articles, les pages, les liens, les pièces jointes et les révisions sont tous des types d'articles intégrés à WordPress. En plus de cela, nous avons des types d'articles comme Livres, Témoignages, Offres, etc. Pouvez-vous imaginer si nous changions de thème et que tout cela disparaissait ? Sûrement, nous ne voudrions pas que cela se produise.
Ayant des développeurs dans notre équipe, cela ne devrait pas avoir beaucoup d'importance. Étant donné que tous nos thèmes sont conçus sur mesure par notre équipe, quelle différence cela fait-il vraiment ? Le secret réside dans deux mots : temps et centralisation. Tant que nous aurons toutes les données nécessaires, tout ce que nous aurons à faire à l'avenir sera de changer le style. Nous n'aurons pas à nous soucier de copier-coller les fonctions d'un fichier à un autre à chaque fois. Et si vous voulez reproduire la fonctionnalité ? Prenez simplement le plugin et déposez-le sur votre nouveau site. Changez le style, et c'est fait.
Règles et normes
Lorsque vous utilisez le mot TOUJOURS comme nous l'avons fait dans notre tweet, cela peut signifier à la fois règle et normes. Les règles et les normes sont faites pour la majorité. Il y aura toujours des scénarios de cas particuliers où les règles sont assouplies et les normes enfreintes, mais cela ne signifie pas que nous devrions abandonner les normes.
Il existe des tonnes de types d'articles génériques qui nécessitent la plupart du temps le même ensemble de champs de métadonnées supplémentaires. Parmi les exemples qui viennent à l'esprit, on peut citer : Citations, Livres, Recettes, Témoignages, Portfolios, etc.
Compte tenu du grand nombre de thèmes de photographie et de portfolio disponibles sur le marché gratuit et commercial, il est presque inutile de faire retaper à l'utilisateur toutes les informations de son type de publication personnalisé à chaque changement de thème. Examinons un scénario d'exemple :
Photographe – L'utilisateur a configuré un WordPress qui possède une fonctionnalité de blog (CPT « post » par défaut). Il souhaite ajouter un portfolio de son travail (nécessite un CPT Portfolio). Il veut afficher des témoignages clients (nécessite un CPT Témoignage). Toutes ces informations survivront certainement à la conception d'un thème. Un an plus tard, l'utilisateur souhaite changer l'apparence de son site et lui donner un coup de jeune. Il trouve un nouveau thème qui possède toutes les fonctions similaires. Au moment où il change de thème, BOUM. Toutes les données précédentes qu'il avait saisies ont disparu. Il y a un menu appelé Portfolio, et un menu appelé Témoignages, mais aucune des données n'est là. L'utilisateur pense « SA MÈRE, j'ai perdu tout mon contenu ». Il crée une nouvelle question de support sur le forum. Il envoie des e-mails à des sites comme WPBeginner, etc. S'ils ne reçoivent pas de bonne réponse, ils devront ressaisir toutes les données. C'est une expérience utilisateur nulle.
Alors, comment résolvons-nous ce problème ?
Solution possible ?
Nous créons une nouvelle base standard. Justin Tadlock a déjà commencé à travailler sur ce problème il y a un moment en créant un plugin de portfolio de base. Sera-ce la solution parfaite pour tout le monde ? NON, mais ce le sera pour la majorité.
Comme le demande Justin dans son article, quels champs standard devraient être inclus dans le plugin de portfolio (en se référant aux métadonnées de publication). Ce type de conversation doit avoir lieu entre les développeurs qui créent des fonctionnalités similaires dans leurs thèmes. Pourquoi copier-coller la même chose encore et encore d'un thème à l'autre quand cela peut être fait via un plugin ? Une fois que cela deviendra une norme, les autres auteurs de thèmes commenceront à s'y adapter.
Par exemple, nous constatons une augmentation du support de style pour Gravity Forms dans les frameworks de thèmes WordPress comme Genesis et d'autres. Pourquoi ? Parce qu'ils comprennent que leurs utilisateurs l'utilisent.
Il existe des thèmes WordPress robustes qui sont dotés de fonctionnalités que nous pensons devraient être des plugins. Thèmes de tableaux d'offres d'emploi, thèmes de suivi des problèmes, thèmes d'annonces classées, thèmes immobiliers, etc. Ils devraient tous être alimentés par un plugin de base. Cela se produit déjà avec WooCommerce. WooThemes a publié de nombreux thèmes qui prennent en charge le style intégré du plugin. D'autres sociétés de thèmes ont également promis de publier des thèmes de commerce électronique basés sur WooCommerce. Vous pouvez passer d'un thème à un autre et conserver tous vos produits tels quels. C'est presque comme si le thème avait changé mais que tout s'était mis en place. C'est l'expérience de changement de thème que nous devons viser.
Pourquoi ne pas faire la même chose avec Portfolio, Témoignages et d'autres types de publications personnalisées génériques ? Est-ce parce que c'est trop simple par rapport au commerce électronique, qui est une bête plus grande à conquérir ? Clairement, le commerce électronique a beaucoup trop de champs par rapport aux autres, il devrait donc être beaucoup plus facile pour ces types de publications génériques. Il s'agit simplement de faire un effort conscient pour améliorer les choses.
Jetez un œil au plugin ReciPress. Il crée une boîte de métadonnées personnalisée avec des champs de recettes et les attache aux publications. Cependant, il est possible de les attacher à des types de publications personnalisées. Quiconque utilise ce plugin peut changer de thème sans avoir à passer par un tel tracas.
Il serait agréable de voir des thèmes comme AgentPress alimentés par un plugin de base centralisé. Il serait formidable de voir la transition du changement de thèmes devenir plus facile. Par exemple, si un utilisateur passe d'un thème de photographie à un autre, ce ne devrait pas être le chaos. Des erreurs mineures pourraient se produire, mais au moins dans l'ensemble, les choses fonctionneront.
Vous pouvez toujours donner des exemples de types de publications super personnalisés créés pour une utilisation client unique, mais c'est l'exception, pas la règle.
Que pensez-vous de ce sujet ? Où devrait résider le code des types de publications personnalisées ? Dans le fichier functions.php ou dans des plugins ?
Yazmin
Ayant perdu mes CPT à de nombreuses reprises en changeant de thème, je trouve frustrant de devoir configurer la même fonctionnalité encore et encore dans functions.php.
Je préfère de loin la voie du plugin et c'est la méthode que j'utiliserai désormais pour mes projets professionnels également.
Joshua Jarvis
J'ai exactement le même problème avec un thème immobilier. Les « annonces » étaient toutes des types personnalisés dans un thème qui est maintenant obsolète. Lorsque j'ai mis à jour le thème, j'ai perdu tout le contenu personnalisé des articles, et maintenant je dois trouver un moyen de tout transférer. J'ai des options, mais si c'était un plugin, cela n'aurait pas été nécessaire.
Personnel éditorial
Extrêmement désolé pour votre désagrément. C'est pourquoi nous avons écrit cet article, car nous savons que cela rend la vie de l'utilisateur final plus difficile.
Admin
Hugh H. Sands
« Nous n'aurons pas à nous soucier de copier-coller les fonctions d'un fichier à l'autre à chaque fois. »
Je n'arrive pas à imaginer quelqu'un écrire du code pour un CPT dans functions.php alors qu'il est si facile de l'isoler avec des includes
Ce débat tourne le plus souvent autour des données par rapport au design et je me demande, étant assez nouveau sur WP, qu’en est-il des performances ? Les plugins imposent-ils une surcharge ?
Personnel éditorial
Cet article devrait répondre à votre question sur les plugins et les performances :
https://www.wpbeginner.com/opinion/how-many-wordpress-plugins-should-you-install-on-your-site/
Admin
Hugh Sands
Merci pour le lien, vraiment utile !
Kelvin Alfonso
J’ai toujours inclus les CPT via un fichier séparé dans le functions.php mais je pense que je vais passer à la solution des plugins. Merci !
Sudhakar
Je suis débutant et je n’ai aucune expertise pour commenter en faveur ou contre un plugin ou le functions.php. Mais je me demande si je veux opter pour la solution functions.php et le faire sous un thème enfant, quel est le problème alors ? Pourquoi ai-je besoin de l’avoir dans un plugin, mon thème enfant ne me sauverait-il pas des futures mises à jour et modifications de thèmes ?
Personnel éditorial
Votre thème enfant vous sauverait des futures mises à jour de thème. Cependant, il ne vous sauverait PAS si vous changez de thème. Parce que vous changez le thème enfant si vous changez le thème actif.
Admin
Pat Ramsey
Je suis partisan de la solution plugin pour les types de publication personnalisés et les taxonomies. La mention par l’auteur d’un plugin spécifique au site est la façon dont je procède. Je place tous les types de publication personnalisés, les taxonomies personnalisées et les metaboxes dans ce plugin, adapté à l’objectif du site. Finalement, le thème du site changera mais les données perdurent et sont toujours facilement accessibles.
shawn
Si les développeurs continuent d’ignorer le fait que séparer les « données » du « design » est nécessaire pour créer des applications modulaires, et peu importe où les données sont placées, la réutilisation de ces données / ce code sera toujours un problème.
Il semble y avoir une perception chez certains membres de la communauté WP, pour une raison ou une autre, que l'on ne peut accéder aux données dans l'écosystème WordPress que si elles sont encapsulées dans un plugin. Nous continuons donc à voir des discussions comme celle-ci qui contribuent au « grand débat plugin vs thème ».
Il faut se concentrer sur l'évolution du système de plugins archaïque de WordPress, pour créer des bibliothèques basées sur des modèles de conception modulaires qui séparent le code / les données de la conception. Des bibliothèques qui peuvent être utilisées dans les thèmes et les plugins...
Des débats comme ceux-ci sont inutiles à l'ère post-PHP4 de WP !!! (re-post)
Mark Simchock
Re: « Comme Justin le demande dans son article, quels champs standard devraient être inclus dans le plugin portfolio (en référence aux métadonnées de publication). Ce type de conversation doit avoir lieu entre les développeurs qui créent des fonctionnalités similaires dans leurs thèmes. »
Moi ? Je préférerais un plugin bien documenté et conçu pour être amélioré plutôt qu'une approche « fermée », universelle et difficile à utiliser (ce code).
Mon point est, peut-être est-il possible de dire : « Je n'essaie pas de plaire à tout le monde. Voici mon plugin de base. Voici comment le personnaliser. Il est conçu pour être personnalisé. » et de s'arrêter là. Quoi que vous fassiez, il est difficile d'anticiper tous les cas d'utilisation, tous les besoins. Alors pourquoi s'en préoccuper ? Pourquoi ne pas l'aborder comme un framework (en quelque sorte) et laisser le développeur dans le besoin le personnaliser au besoin ?
Justin Tadlock
C'est effectivement le plan. Je construis une base extrêmement petite et facilement personnalisable. Mais j'aimerais savoir quels champs, le cas échéant, devraient être standard.
Kevin Maines
Faute de frappe :
« En considérant que toutes nos équipes sont conçues sur mesure par notre équipe »
Personnel éditorial
Fixed it. Thanks for catching that
Admin
Affan Ruslan
Je crois que cela devrait être sur un plugin.
Au cas où l'utilisateur n'aurait pas besoin des données à l'avenir, il peut toujours convertir le type de publication personnalisé en type de publication « normal ». Il existe des plugins pour cela, recherchez dans le répertoire et vous en trouverez au moins un.
Christophe Debruel
Je me fiche de ce que les gens disent. Les types de publication personnalisés vont dans un plugin. Un thème peut facilement être modifié pour s'adapter au type de publication personnalisé dans le frontend. Je trouve plus logique de styliser le thème pour le CTP que d'avoir des thèmes différents avec le même code CTP.
Ingo
« Pods Framework » pourrait également être une bonne solution de plugin. Pour CPT, CT et CF.
http://wordpress.org/extend/plugins/pods/
Personnel éditorial
Oui, Pods est génial.
Admin
Elliott Richmond
Plugin pour moi. Au moins pour un client non technique, bien que le thème ne fonctionne pas correctement, il deviendra évident qu'il y a un problème et cela les incitera à faire appel à un développeur.
Kailas Mahajan
Tout dépend du projet...
Si l'on gère un projet qui nécessite de changer de thème après une certaine période... on peut utiliser un plugin.
ou si le projet s'en tient à un seul thème.. on peut aller avec function.php
Ross W
Tout le monde parle de la façon dont les données doivent être stylisées par le thème, et des exemples où c'est le cas et où les données et le thème peuvent être séparés.
Ce que je ne vois pas, c'est quelqu'un qui parle de cas où un thème dépend de la disponibilité de certaines données spécifiques. Disons que vous avez un thème qui a une carte des pays et des données spécifiques à certains pays, et que, sans cette carte et ces données, le thème perd une partie de ses fonctionnalités clés.
Oui, vous pourriez toujours faire cela avec les données dans un plugin, mais est-il raisonnable qu'un thème suppose que certaines données existent ? Est-il raisonnable de supposer que le plugin qui crée les types de données est installé et activé ? (Questions sincères… discutons-en !)
Et si mon client, légèrement non technique, voulait créer une copie du site avec son « thème ». Il active le thème sur une nouvelle installation de Wordpress pour découvrir qu'une grande partie du contenu est manquante ou cassée ? Il pensait que le thème contenait tout ce dont il avait besoin pour que son site ait l'air bien ?
Je vois des utilisations pour les deux approches. Pour la plupart de mes travaux clients, je mets en place des CPT, des meta-boxes et quelques fonctions pour en simplifier l'accès, dans des fichiers de bibliothèque et je les inclus. Cela permet de garder tout le « matériel » dont mon thème a besoin pour fonctionner dans un seul paquet, tout en permettant de déplacer facilement les CPT vers un nouveau thème si je le souhaite.
Bien sûr, si un CPT semble pouvoir être utilisé sur plusieurs thèmes et n'est pas SO spécifiquement qu'il ne s'applique qu'aux données d'un seul client, alors vous le transformez en un plugin qui peut être déployé à volonté.
Je ne pense pas qu'il y ait une relation simple et univoque entre les données et les thèmes. Ce n'est pas toujours le cas que « j'ai des données qui ont besoin de style »... parfois « mon style a besoin de données ».
Des réflexions à ce sujet ?
Andres Hermosilla
Je suis tout à fait d'accord sur le fait qu'il y a un avantage à avoir un package « complet ». Souvent, il y a des fonctionnalités très spécifiques à un thème qui sont mieux intégrées directement (par exemple, P2 d'Auttomatic) plutôt qu'installées comme thème et plugin de thème.
Konstantin Kovshenin
Plugins. Point final.
Curtis McHale
Votre référence à AgentPress est l'une des raisons pour lesquelles je suis à 100 % pour les CPT dans les plugins. J'ai eu affaire à des thèmes comme celui-ci et il est très difficile de les styliser correctement à moins de supprimer la fonction personnalisée du thème. Mon client et moi avons passé 20 heures à mettre le code à un point où nous pouvions réellement travailler dessus.
Birgit
ma meilleure et ma solution préférée et recommandée est le TOOLBOX très flexible : http://wordpress.org/extend/plugins/toolbox/
Personnel éditorial
Bonne idée. J'aimerais pouvoir comprendre ce que la capture d'écran montrait sans télécharger le plugin.
-Syed
Admin
Birgit
The plugin is a “toolbox” for code snippets, that you do normally in your functions.php.
But with a theme update, custom code in the theme’s function.php might get lost.
So I use within my network installation this plugin, activated it network-wide and then the plugin comes with “modules”, that you can access for example by FTP.
You can create modules as much as you like – I have one for each of my blogs within this network. In this modules (= just .php files, let’s say just like site-specific plugins) you can add all the code, that you normally put in your theme’s function.php.
Then at the options page of the plugin you can activate in each blog, which module you would like to load and whether to load it only for frontend or only for backend or for both.
So I only need to have 1 plugin to serve all blogs with individual code snippets, that normally go to their functions.php – and can decide, where to load these modules.
uff, hope this is understandable, because my English is not the best
Peut-être que cela vous aidera à le lire : http://tinyurl.com/bf5dflt
Personnel éditorial
Brigit, I did translate the WP.org page as well. I understood what the plugin was intended for. However the screenshots were in German, and google is not smart enough to translate images just yet. Same issue is with the link you posted
Sara
Je préfère toujours les plugins au fichier functions.php pour tout ce qui « casserait » matériellement sur le front-end ou perdrait des données si le thème était changé. C'est précisément pour les raisons que vous citez, et je pense aussi qu'il est dingue pour ceux d'entre nous qui ne sont pas vraiment des programmeurs PHP d'essayer de dépanner les conflits quand il faut commenter des choses dans le fichier functions.php pour isoler un problème.
matt
ok, alors quel plugin CPT recommandez-vous ?
Personnel éditorial
L'idée est que vous devriez enregistrer les CPT dans un plugin spécifique au site. Il n'y a pas encore de plugin spécifique. Mais on lance juste l'idée de créer un plugin de base pour les types de publication génériques.
Admin
Muhammad Waqas
Je suis plus convaincu par l'utilisation de fonctions locales. mais dans ce cas, je pense que les plugins peuvent être plus fiables. Par exemple, si vous commencez à utiliser wp avec un framework spécifique. Dans la plupart des cas, il est possible que vous deveniez un esclave pendant longtemps, à moins que vous n'engagiez un professionnel wp pour vous aider à vous échapper de ce framework sans perdre vos paramètres et vos données. D'un autre côté, les plugins peuvent fonctionner avec presque tous les thèmes.
Quand j'ai commencé à travailler avec wp, je préférais les frameworks aux plugins. La réalité est que les développeurs de plugins considèrent les débutants et les personnes moins instruites lors du développement de quelque chose. Je crois personnellement que la plupart des utilisateurs de wp préfèrent les modifications manuelles du code plutôt que de dépendre de plugins pour les fonctions principales des sites. à long terme, les plugins ne sont pas fiables. Je le ressens..