Comme beaucoup d'entre vous le savent, la semaine dernière, Syed Balkhi a assisté au WordCamp Raleigh 2012. Lors de l'événement, l'un de ses tweets a déclenché tout un débat. Dans cet article, notre fondateur Syed Balkhi débattra de la question de savoir si les types de publication personnalisés WordPress appartiennent au fichier function.php ou aux plugins. Vous trouverez ci-dessous un tweet qui a lancé ce débat :
N'ajoutez pas de types de publication personnalisés dans Functions.php -> Vous devez TOUJOURS utiliser un plugin spécifique au site - http://t.co/bebYXq2F #wcraleigh
- WordPress Débutant (@wpbeginner) 4 novembre 2012
Après le tweet, de nombreuses personnes réputées de la communauté WordPress sont intervenues. Vous pouvez voir la conversation complète ici. Curtis McHale est allé encore plus loin et a développé le sujet dans son nouveau billet de blog.
La conversation sur Twitter a soulevé quelques points intéressants.
Argument des plugins : L'utilisateur aura toujours les données même s'il change de thème. Ce n’est peut-être pas aussi joli, mais ça restera là.
Functions.php Argument : Les données sans conception ne seraient pas pertinentes. Cela confondra encore plus les utilisateurs.
Avec quel côté êtes-vous le plus d’accord ? De toute évidence, les deux côtés ont leurs problèmes, mais lequel est le moindre des deux maux ?
Voici pourquoi nous pensons que les types de publication personnalisés devraient TOUJOURS résider dans un plugin spécifique au site ou dans un plugin complètement distinct.
Les types de publication personnalisés sont des données. Dans la plupart des cas, vos données survivront à la conception actuelle. Après avoir changé de thème à plusieurs reprises, nous comprenons clairement cette affirmation. Les publications, pages, liens, pièces jointes et révisions sont tous des types de publications intégrés à WordPress. En plus de cela, nous avons des types de publications tels que des livres, des témoignages, des offres, etc. Maintenant, pourriez-vous imaginer si nous changeons de thème et que tout cela disparaisse ? Nous ne voudrions sûrement pas que cela se produise.
Avoir 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 réellement ? Le secret tient en deux mots : temps et centralisation. Tant que nous disposons de toutes les données nécessaires, il ne nous restera plus qu’à changer le style à l’avenir. Nous n’aurons pas à nous soucier de copier et coller les fonctions d’un fichier à un autre à chaque fois. Et si vous souhaitez répliquer la fonctionnalité ? Prenez simplement le plugin et déposez-le dans votre nouveau site. Changez le style et vous avez terminé.
Lorsque vous utilisez le mot TOUJOURS comme nous l’avons fait dans notre tweet, cela peut signifier à la fois une règle et des normes. Les règles et les normes sont conçues pour la majorité. Il y aura toujours des cas particuliers dans lesquels les règles sont contournées et les normes ne sont pas respectées, mais cela ne signifie pas que nous devons complètement nous débarrasser des normes.
Il existe des tonnes de types de publications génériques qui nécessitent pour la plupart le même ensemble de champs méta supplémentaires. Voici quelques exemples qui me viennent à l’esprit : citations, livres, recettes, témoignages, portfolio, etc.
Compte tenu du grand nombre de thèmes de photographie et de portfolio disponibles sur le marché gratuit et commercial, cela n'a presque aucun sens d'obliger l'utilisateur à saisir à nouveau toutes ses informations de type de publication personnalisées à chaque fois qu'il change de thème. Jetons un coup d'œil à un exemple de scénario :
Photographe - L'utilisateur configure un WordPress doté d'une fonctionnalité de blog (CPT « post » par défaut). Il souhaite ajouter un portfolio de son travail (nécessite un Portfolio CPT). Il souhaite afficher des témoignages de clients (nécessite un CPT de témoignage). Toutes ces informations vivront sûrement au-delà d’une conception thématique. Un an plus tard, l’utilisateur souhaite changer le look de son site et lui apporter un rafraîchissement. Trouve un nouveau thème doté de toutes les fonctions similaires. Au moment où il change de thème, BOUM. Toutes les données précédentes qu'il a saisies ont disparu. Il existe un menu appelé Portfolio et un menu appelé Témoignages, mais aucune donnée n'y est. L’utilisateur pense « MERDE, j’ai perdu tout mon contenu ». Crée une nouvelle question d'assistance dans le forum. 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 merdique.
Alors, comment pouvons-nous résoudre ce problème ?
Nous créons une nouvelle base standard. Justin Tadlock a déjà commencé à travailler sur ce problème il y a quelque temps en créant un plugin de portefeuille de base. Est-ce que ce sera la solution parfaite pour tout le monde ? NON, mais ce sera pour la majorité.
Comme Justin le demande dans son article, quels champs standard doivent être inclus dans le plugin de portefeuille (en référence à la méta 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 et coller la même chose encore et encore d’un thème à un autre alors que cela peut se faire via un plugin ? Une fois que cela deviendra un standard, d’autres auteurs de thèmes commenceront à s’y adapter.
Par exemple, nous constatons une augmentation de la prise en charge du style pour Gravity Forms dans les frameworks de thèmes WordPress comme Genesis et autres. Pourquoi? Parce qu'ils comprennent que leurs utilisateurs l'utilisent.
Il existe des thèmes WordPress robustes dotés de fonctionnalités qui, selon nous, devraient être des plugins. Thèmes Job Board, thèmes de suivi des problèmes, thèmes de petites annonces, thèmes immobiliers, etc. Ils doivent tous être alimentés par un plugin de base. Cela se produit déjà avec WooCommerce. WooThemes a publié de nombreux thèmes dotés d'une prise en charge de style intégrée pour le plugin. D'autres sociétés de thèmes ont promis de publier également des thèmes de commerce électronique basés sur WooCommerce. Vous pouvez passer d’un thème à l’autre et conserver tous vos produits tels quels. C’est presque comme si le thème avait changé, mais tout s’est mis en place. C’est l’expérience de changement de thème que nous devons rechercher.
Pourquoi ne pas faire la même chose avec Portfolio, Témoignages et autres types de publications génériques personnalisées ? Est-ce parce que c’est trop simple alors que le commerce électronique est une plus grosse bête à conquérir ? De toute évidence, le commerce électronique comporte beaucoup trop de champs par rapport aux autres, cela devrait donc être beaucoup plus simple 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 métabox personnalisée avec des champs de recette et la joint aux publications. Cependant, il est possible de le joindre avec des types de publications personnalisés. Toute personne utilisant ce plugin peut changer de thème sans avoir à subir de tels tracas.
Ce serait bien de voir des thèmes comme AgentPress être alimentés par un plugin de base centralisé. Ce serait formidable de voir la transition des thèmes changeants devenir plus facile. Par exemple, si un utilisateur passe d’un thème de photographie à un autre, cela ne devrait pas être le chaos. Des erreurs mineures peuvent survenir, mais au moins dans l’ensemble, les choses fonctionneront.
Vous pouvez toujours donner des exemples de types de publication super personnalisés créés pour une utilisation client unique, mais ce n'est pas la règle, mais c'est l'exception.
Que pensez-vous de ce sujet ? Où doit résider le code des types de publication personnalisés ? Dans le fichier function.php ou dans les plugins ?