Types de messages personnalisés vs formats de messages: preuve de l'avenir - l'un est-il moins "prêt pour le futur" qu'un autre?

Question

Je suis confronté à la directive suivante pour un travail de sous-traitance.

Type de publication vs Format de publication

Évitez les types de messages personnalisés et adoptez les formats de messages! Les formats de publication sont pris en charge par le noyau WordPress et sont déjà activés dans le thème de démarrage. Vous pouvez attribuer des styles, une mise en forme et des fonctions uniques aux formats de publication. Si le client change de thème à l'avenir, WordPress reconnaîtra toujours les formats que vous avez appelés tant qu'ils sont activés dans la feuille de fonctions du prochain thème.

Les types de publication doivent être enregistrés dans le fichier de fonctions de votre thème et ne seront pas aussi facilement transférables au moment de l'activation d'un nouveau thème. Dans la plupart des cas, un format de publication dédié utilisant des champs personnalisés, des images en vedette et de nombreuses autres fonctions déjà disponibles dans le noyau de WordPress permet de répondre à la nécessité de créer une publication avec plusieurs valeurs et fonctions de clé.

Utilisez votre meilleur jugement! "

Bien que je comprenne le problème et que, lors de la création d’un site Web planifiant de changer de thème en un rien de temps, ces formats peuvent être très utiles - j’ai du mal à les comprendre.

Le site Web contient des pages et un flux d’API externe pour ce qui serait probablement normalement des "publications". Ensuite, quelques sections parcourent des sujets tels que les FAQ et les éléments de menu alimentaire.

J'ai actuellement un type de message personnalisé pour la FAQ et les éléments du menu Aliments. Il est peu probable que les 'posts' soient utilisés, mais je les réserve pour un éventuel 'blog' ou 'news'.

Ce qui semble être suggéré, c'est que je choisisse juste un format ... comme "à part" puis l'utilise comme FAQ - et ensuite peut-être - prenne "citation" et l'utilise pour les éléments de menu. Ensuite, toutes les données seraient sous "messages", ce qui est suggéré pour être plus favorable à l'avenir.

Je ne veux pas être un imbécile et aller à contre-courant ... mais cela semble beaucoup moins intuitif. Le client devra aller à "posts", puis toutes les questions de la FAQ et du menu seront mélangées. Ensuite, s'il y a une section Nouvelles plus tard ... ce seront les Nouvelles, les FAQ et les éléments de menu. Le client oubliera probablement de vérifier les formats et sera confus - et devra appeler mon entrepreneur pour obtenir de l'aide.

Si vous comparez ces 2 phrases (une de chaque cas)

"Si le client change de thème à l'avenir, WordPress reconnaîtra toujours les formats {post} que vous avez appelés tant qu'ils sont activés dans la feuille de fonctions du thème suivant."

et

Les types d'articles doivent être enregistrés dans le fichier de fonctions de votre thème et ne seront pas aussi facilement transférables le moment venu pour l'activation d'un nouveau thème.

... alors quelle est vraiment la différence. De toute façon, un petit bloc de code doit être inclus - ou aucun d'entre eux ne fonctionnera.

Il est plus probable que ces données soient agrégées dans un cadre JS dans les années à venir plutôt qu'un autre thème WordPress ~, auquel cas les données sont beaucoup plus confuses à mes yeux. Je préférerais le type de message personnalisé lorsque j'utilise WP-API pour, par exemple, une application Ember.

Les types de post personnalisés en tant que tels n'ont pas leur place dans les "flux" en dehors de ce site. Si je voulais des FAQ dans un flux - j'ai peut-être utilisé le format de publication 'à part' et une catégorie.

Si le site est construit avec beaucoup de champs personnalisés avancés - et est divisé en tonnes de partiels - et construit avec un stylet et des composants de tondeuse concaténés, ainsi que des fonctions spéciales, je ne le vois pas vraiment dans le monde des sites qui ne sont que "thème - interchangeable" de toute façon. S'assurer qu'un petit bloc de code pour enregistrer le type de message personnalisé est le moindre des soucis. (Il convient de noter qu'en général, je n'ai pas utilisé WordPress avec des thèmes à l'esprit - et uniquement à partir de zéro pour des sites très personnalisés. Je n'ai jamais utilisé de widget, etc. - de sorte que je peux ignorer les pratiques courantes).

Je me demande si j'aurais dû simplement inclure 12 scripts dans la tête et écrire le fichier css sans préprocesseur? Mais cela semble simplement impoli ... et ne faciliterait pas le transfert vers un autre thème ...

Dans quels cas chaque style de fractionnement des données de site respectif serait-il plus évolutif? Existe-t-il vraiment une chance que les types de message personnalisés disparaissent? Je pensais que les formats de publication n'étaient qu'un bonus pour le microblogging - et que la plupart des gens étaient vraiment mécontents de l'avoir fait.

Je sais que c'est à la limite de l'opinion, mais ce n'est vraiment pas pour moi. Je veux faire ce qu'il y a de mieux - mais il m'est vraiment difficile de croire qu'un choix non systématique d'un sous-format de micro-blogage conviendrait mieux.

Les utilisateurs finaux sont souvent occupés et ont besoin d'une interface utilisateur claire. Les types de messages personnalisés sont clairement gagnants ici. - Mais je ne rend pas service à mon client en "Utilisant mon meilleur jugement" - et passer aux types de publication personnalisés par rapport aux formats de publication?

Veuillez donner des cas d'utilisation objectifs pour chaque chemin.

Voici quelques réflexions sur le sujet:

http://wptavern.com/why-arent-post-formats-in-wordpress-more-popular

https://managewp.com/wordpress-post-formats-blogging

Dans IRC et d'autres endroits, je reçois presque 100% ~ "Si vous créez des FAQ, ce ne sont pas des publications et doivent être des types de publication personnalisés." J'obtiens "N'utilisez pas les formats pour cela" ~ mais peu de preuves que l'un est plus convivial que l'autre.

Prenez cet URL pretend API, par exemple, de l’apparence de chacun:

http://somewebsite.com/cms/wp-json/wp/v2/faqs
contre
http://somewebsite.com/cms/wp-json/wp/v2/posts?format=aside&category=faq

Ma tentative pour décrire le 2:

Les formats de publicationpermettent de styliser la publication dans certains scénarios et de micro-blogger lorsque vous souhaitez définir différentes catégorisations de publications dans un flux.
Les types de publication personnaliséssont destinés à des groupes de données qui ne sont pas des publications.

MAIS - est-ce que la preuve est ou non moins future ... et si post-format est - le post-format est-il tellement meilleur - que je devrais renoncer à une interface intuitive pour l'utilisateur? - Si c'est le cas, je ferai ce qui est juste.

Type de publication vs Format de publication

[1]~~Les formats de publication sont pris en charge par le noyau WordPress~~, [2]~~et sont déjà activés dans le thème de démarrage.~~ [3]~~Vous pouvez attribuer des styles, une mise en forme et des fonctions uniques aux formats de publication.~~ ~~Si le client change de thème à l'avenir, WordPress reconnaîtra toujours les formats que vous avez appelés tant qu'ils sont activés dans la feuille de fonctions du prochain thème.~~

[4]~~Les types d'articles doivent être enregistrés dans le fichier de fonctions de votre thème et ne seront pas aussi facilement transférables le moment venu pour l'activation d'un nouveau thème.~~ [5]Dans la plupart des cas, il est possible de créer un message avec plusieurs valeurs et fonctions de clé grâce à un format de message dédié qui utilise des champs personnalisés, des images en vedette, [1] ~~et tant d'autres fonctions déjà disponibles via WordPress.~~

Utilisez votre meilleur jugement! "

Ils sont tous deux pris en charge dans WP core.
Tout le monde n'utilisera pas le thème de départ
Les deux peuvent être coiffés et personnalisés de la même manière.
Les deux doivent être enregistrés dans le fichier de fonctions
Besoins peut être satisfait par les formats postérieurs, vrai - mais rien ne prouve qu'il soit idéal

Toutes ces déclarations semblent annuler chaque partie de la discussion.

La seule réserve que j'ai pu trouver:

À partir de la documentation: https://codex.wordpress.org/Post_Types

Un mot sur les types de publication personnalisés en tant que plug-in Afin d'éviter de casser un site sur le changement de thème, essayez de définir les types de publication personnalisés en tant que plug-in ou, mieux, en tant que plug-in à utiliser impérativement. De cette façon, vous ne forcerez pas les utilisateurs à utiliser un certain thème.

"Doit utiliser des plugins" https://codex.wordpress.org/Must_Use_Plugins

Pieter Goosen · Accepted Answer

Ressenti comme un marathon, totalement essoufflé après avoir lu votre question.

Comme pour ce type de questions, il n’ya vraiment pas de bonne ou de mauvaise réponse car la plupart d’entre elles reposent sur des opinions et non sur des faits. Il y a peu de points ici que nous pouvons discuter concrètement

POINT 1

Les types de message doivent être enregistrés dans le fichier de fonctions de votre thème et ne seront pas aussi facilement transférables au moment d'activer un nouveau thème.

Totalement taureau malheureusement. Les types de messages personnalisés et les taxonomies personnalisées devraient jamais être enregistrés dans un thème, il devrait toujours aller dans le plugin. En règle générale, si quelque chose donne une fonctionnalité au site et non au thème (comme c'est le cas ici), il devrait être inséré dans un plugin. Il y a eu quelques articles sur ce sujet, utilisez le site pour rechercher des informations supplémentaires. En bref, les types d'articles et les taxonomies personnalisés devraient toujours être disponibles même après un changement de thème s'il était correctement enregistré à partir d'un plugin

POINT 2

Évitez les types de messages personnalisés et adoptez les formats de messages! Les formats de publication sont pris en charge par le noyau WordPress et sont déjà activés dans le thème de démarrage

Les types de messages personnalisés et les formats de messages sont tous deux pris en charge par Core. Dans les deux cas, ils doivent être enregistrés/ajoutés avant de pouvoir être utilisés. Donc, ce point est totalement excessif et ne devrait même pas être discutable. Oui, les formats de publication font déjà partie du thème de démarrage, mais qu'en est-il du thème X lorsque vous passez au thème X?.

POINT 3

Les types de post personnalisés en tant que tels n'ont pas leur place dans les "flux" en dehors de ce site.

Vrai et faux. C’est l’une des raisons pour lesquelles je préfère les types de publication personnalisés, mais ne discutons pas d’opinion. Par défaut, les types de publication personnalisés sont exclus de la requête principale, sauf sur les pages d'archive de taxonomie et de type de publication. Cela vous donne beaucoup plus de contrôle quand, où et comment utiliser les types de publication personnalisés. Ajouter des types de publication personnalisés aux flux, pages d'accueil, pages d'archives, etc. est aussi simple que d'ajouter une simple action pre_get_posts avec les conditions souhaitées; vous pouvez également le faire dans le même plugin que celui utilisé pour enregistrer votre type de publication.

En dehors de cela, vous avez beaucoup de fonctionnalités supplémentaires que vous pouvez utiliser pour manipuler votre type de publication et comment il sera utilisé sur votre site en ajustant simplement les valeurs aux paramètres de register_post_type() lorsque vous enregistrez le type de publication.

POINT 4

Je me demande si j'aurais dû simplement inclure 12 scripts dans la tête et écrire le fichier css sans préprocesseur?

Ne fais jamais ça. Utilisez toujours le crochet wp_register_scripts pour ajouter des scipts et des styles à l’en-tête et au pied de page si nécessaire, ne les codez jamais directement dans la tête (ou le pied de page). De plus, je ne suis jamais un grand partisan de la manipulation de fonctionnalités impotantes avec des langages et des plates-formes côté client. Le problème est que tout ce qui repose sur des fonctions basées sur le client peut être manipulé par l'utilisateur final. La compatibilité entre navigateurs est également toujours un problème. Utilisez uniquement JS et CSS pour manipuler la valeur faciale d'un site (look and feel), ne le laissez jamais contrôler le fonctionnement d'un site. Utilisez des langages côté serveur comme PHP pour contrôler cela.

POINT 5

Existe-t-il vraiment une chance que les types de message personnalisés disparaissent?

Il y a 0% de chances que les types et/ou formats de publication personnalisés soient un jour supprimés du noyau. Juste comme un point supplémentaire, register_post_type() est utilisé pour enregistrer les types de publication par défaut post et page et register_taxonomy() est utilisé pour enregistrer les taxonomies par défaut category, post_tag, post_format et link_category.

Il est très très rare que quelque chose soit retiré du noyau, une dépréciation se produit régulièrement, mais cette suppression n’est presque jamais. Prenons, par exemple, les paramètres toujours utilisés judicieusement caller_get_posts et showposts. Ceux-ci ne devraient plus être utilisés à partir de la version 3.0, mais les gens l'utilisent toujours. (active le débogage et vous obtiendrez une notification claire sur ce). Imaginez que les développeurs principaux suppriment cela du noyau.

Wordpress Core est assez concentré sur la compatibilité ascendante (spécialement si une fonctionnalité nécessite une mise à niveau énorme et change de façon spectaculaire ou si une fonctionnalité est dépréciée), ce qui est un avantage considérable pour les non développeurs. En tant que développeur, les avis sont ajoutés aux fonctions/arguments amortis/etc, c’est pourquoi il est always advicable pour permettre le débogage lors du développement.

Pour revenir au point d'origine, vous n'avez pas à craindre que des types de publication personnalisés ou des formats de publication ne soient jamais supprimés du noyau.

POINT 6

Je pensais que les formats de publication n'étaient qu'un bonus pour le microblogging - et que la plupart des gens étaient vraiment mécontents de l'avoir fait.

En bref, les formats de publication ne sont qu'un bonus, un Nice-à-avoir. Ce point peut être débattu encore et encore, ainsi que son utilité réelle. Cela dépend vraiment des préférences personnelles, que cela soit utile ou non pour votre projet. Personnellement, je ne suis pas un très grand fan des formats de publication. Je préfère toujours un type d'article personnalisé ou une taxonomie personnalisée, en fonction des exigences du projet, au-dessus des formats d'article. Vous avez beaucoup plus de contrôle avec les types de publication personnalisés et les taxonomies personnalisées qu'avec les formats de publication.

Un gros problème avec les formats de publication est le fait que standard est not un format de publication. Il s’agit simplement d’une solution de rechange déplorable pour les publications auxquelles aucun format n’a été attribué. Modifier une boucle donnée est désordonné si vous devez supprimer ou uniquement interroger les publications sans format de publication.

POINT 7

Les formats de publication sont utilisés pour styliser la publication dans certains scénarios et pour le micro-blogging lorsque vous souhaitez définir différentes catégorisations de publications dans un flux.

Correct est la plupart de ce qui a été dit. Le format de publication ne doit pas nécessairement être réservé au microblogging. Vous pouvez utilisez des formats de publication ou de très grands projets en fonction des besoins exacts du projet. Mais encore une fois, votre utilisation dépend de votre projet et de vos préférences personnelles.

Les types de publication personnalisés sont destinés à des groupes de données qui ne sont pas des publications.

Pas vrai. Oui, ce sont des groupes de données dans un sens, car les types de publication personnalisés sont utilisés pour le faire, mais il est incorrect de dire qu’ils ne sont pas des publications. Les pages sont également des publications, de même que les publications normales et toutes les publications de type publication personnalisée. Ils sont tous traités exactement de la même manière, la seule différence réelle est la hiérarchie. Les publications de type publication non hiérarchique (comme dans le type de publication post) ne peuvent pas avoir de publication enfant alors que les types de publication hiérarchiques (comme pour la publication dans le type de publication page) peuvent avoir des posts pour enfants

CONCLUSION

Les types de messages personnalisés (et les taxonomies personnalisées) et les formats de messages sont ici pour rester. Que ce soit à utiliser dépend du projet en cours et de ce avec quoi vous êtes à l'aise. Cela nécessite une planification minutieuse à l’avance. Il est également très important de savoir comment et où vous devriez enregistrer/ajouter des fonctionnalités pour conserver la compatibilité et la facilité d’utilisation lorsque les thèmes changent, etc.

Ce que j'ai donné est juste un directive de base et doit être traité comme tel. Je ne peux pas entrer dans beaucoup plus de détails car cela nécessitera un livre. Il y a vraiment beaucoup d'informations sur le site et hors site que vous devriez vérifier.

Bonne chance pour votre projet