WordPress Custom Post Types Débat - Functions.php ou des plugins?

Comme beaucoup d'entre vous le savent, Syed Balkhi a assisté à WordCamp Raleigh en 2012. La semaine dernière, l'un de ses tweets a suscité un vif débat. Dans cet article, notre fondateur, Syed Balkhi, discutera de la question de savoir si les types de messages personnalisés WordPress appartiennent au fichier functions.php ou aux plug-ins. 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 - wpbeg.in/vcXr7j #wcraleigh

- WordPress Débutant (@wpbeginner) 4 novembre 2012

Après le tweet, beaucoup de personnes réputées de la communauté WordPress sont intervenues. Vous pouvez voir la conversation en entier ici. Curtis McHale a fait un pas en avant et a développé le sujet dans son nouveau billet de blog.

La conversation de Twitter a soulevé quelques points intéressants.

Résumé des arguments

Argument des plugins: L'utilisateur aura toujours les données même s'il change de thème. Cela n’est peut-être pas aussi joli, mais ça restera là.

Functions.php Argument: Les données sans conception ne seraient pas pertinentes. Cela déroutera encore plus les utilisateurs.

De quel côté es-tu plus d'accord? Clairement les deux côtés ont leurs problèmes, mais qui est le moindre de deux maux?

Voici pourquoi nous croyons que les types de publication personnalisés devraient TOUJOURS vivre dans un plugin spécifique au site ou dans 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. Après avoir changé nos thèmes à quelques reprises, nous comprenons bien cette déclaration. Les publications, pages, liens, pièces jointes et révisions sont tous les types de publication intégrés à WordPress. En plus de cela, nous avons des types d'articles tels que Livres, Témoignages, Offres, etc. Maintenant, pouvez-vous imaginer si nous changeons de thème et faisons disparaître tout cela? Sûrement, nous ne voudrions pas que cela se produise.

Avec 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: le temps et la centralisation. Tant que nous aurons toutes les données nécessaires, tout ce que nous aurions à faire dans le futur est de changer le style. Nous n'aurons pas à nous soucier de copier et coller les fonctions d'un fichier à un autre à chaque fois. Que faire si vous souhaitez répliquer la fonctionnalité? Il suffit de prendre le plugin et de le déposer sur votre nouveau site. Changer le style, et vous avez terminé.

Règles et standards

Lorsque vous utilisez TOUJOURS le mot, comme 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 cas spéciaux dans lesquels les règles sont pliées et les normes enfreintes, mais cela ne signifie pas que nous devrions nous en débarrasser complètement..

Il existe des tonnes de types d'articles génériques qui nécessitent le plus souvent le même ensemble de champs méta supplémentaires. Quelques exemples qui me viennent à l’esprit sont les suivants: Citations, Livres, Recettes, Témoignages, Portfolio, etc..

Compte tenu du grand nombre de thèmes de photographies et de portefeuilles disponibles sur le marché libre et commercial, il n’a pratiquement aucun sens de demander à l’utilisateur de saisir à nouveau toutes ses informations de type de publication personnalisée à chaque changement de thème. Regardons un exemple de scénario:

Photographe - L’utilisateur configure un WordPress doté d’une fonctionnalité de blog (CPT par défaut). Il souhaite ajouter un portfolio de son travail (nécessite un Portfolio CPT). Il veut montrer des témoignages de clients (nécessite un CPT de témoignage). Toutes ces informations vont sûrement survivre au-delà d’un thème. Un an plus tard, l'utilisateur souhaite modifier l'apparence de son site et le réactualiser. Trouve un nouveau thème qui a toutes les fonctions similaires. Au moment où il change de thème, BOOM. Toutes les données précédentes qu'il a entrées ont disparu. Il existe un menu appelé Portfolio et un menu appelé Témoignages, mais aucune des données n’y figure. L'utilisateur pense "HOLY CRAP, j'ai perdu tout mon contenu". Crée une nouvelle question de support dans le forum. Envoie des emails à des sites comme WPBeginner, etc. S'ils ne reçoivent pas de bonne réponse, ils devront ressaisir toutes les données. Ceci est une expérience utilisateur de merde.

Alors, comment pouvons-nous résoudre 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 quelque temps en créant un plugin de portefeuille de base. Est-ce que ça va être la solution parfaite pour tout le monde? NON, mais ce sera pour la majorité.

Comme Justin le demande dans son message, quels champs standard devraient être inclus dans le plugin portfolio (en référence à post meta). 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 être fait via un plugin? Une fois que cela deviendra un standard, les auteurs d'autres thèmes commenceront à s'y adapter.

Par exemple, nous constatons une augmentation de la prise en charge de styles pour Gravity Forms dans les cadres de thèmes WordPress tels que Genesis et d’autres. Pourquoi? Parce qu'ils comprennent que leurs utilisateurs l'utilisent.

Certains thèmes WordPress robustes sont fournis avec des fonctionnalités qui, à notre avis, devraient être des plugins. Thèmes Job Board, thèmes de suivi des problèmes, thème des annonces classées, thèmes de l'immobilier, etc. Ils doivent tous être alimentés par un plugin de base. Cela se passe déjà avec WooCommerce. WooThemes a publié de nombreux thèmes qui prennent en charge le style pour le plugin. D'autres sociétés thématiques 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 tout est tombé en place. C’est le thème du changement d’expérience que nous devons rechercher.

Pourquoi ne pas faire la même chose avec Portfolio, Témoignages et autres types de publication génériques personnalisés? Est-ce parce que c'est trop simple? Le commerce électronique est-il une plus grosse bête à conquérir? Il est clair que le commerce électronique comporte beaucoup trop de champs par rapport aux autres, il devrait donc être beaucoup plus facile pour ces types de publication génériques. Il s’agit simplement de faire un effort conscient pour améliorer les choses.

Jetez un coup d'œil au plugin ReciPress. Il crée une metabox personnalisée avec des champs de recette et l'attache avec des posts. Cependant, il est possible de l'associer à des types de publication personnalisés. Toute personne utilisant ce plugin peut changer de thème sans avoir à passer par de tels tracas.

Ce serait bien de voir des thèmes comme AgentPress être alimentés par un plugin de base centralisé. Il serait bon de voir que la transition de thèmes changeants devient plus facile. Par exemple, si un utilisateur passe d'un thème de photographie à un autre, il ne devrait pas y avoir de chaos. Des erreurs mineures peuvent se produire, mais au moins dans l'ensemble, les choses vont marcher.

Vous pouvez toujours donner des exemples de types de publication super personnalisés créés pour une utilisation client unique, mais c'est l'exception et non la règle..

Que pensez-vous de ce sujet? Où le code de types de messages personnalisés doit-il résider? Dans le fichier functions.php ou dans les plugins?