Je commencerais par cette question: la fonctionnalité est-elle liée à la présentation du contenu ou à la génération / gestion du contenu, du site ou de l'identité de l'utilisateur?
Si la fonctionnalité n'est pas spécifiquement liée à la présentation du contenu , elle se trouve directement dans Plugin Territory. Cette liste est longue:
- Modification des filtres WP principaux (
wp_headcontenu, tels que liens canoniques, générateur et autres méta HTML, etc.)
- Site Favicon
- Shortcodes post-contenu
- Poster des liens de partage
- Scripts de pied de page Google Analytics (et similaires)
- Outils de référencement / contrôles
- etc.
Si la fonctionnalité est liée à la présentation du contenu , il est un candidat pour être inclus dans le thème. À ce stade, je reviendrais au critère de changement de thème de @ Raf912 : manqueriez-vous à la fonctionnalité lorsque vous changez de thème ? Si la réponse à cette question est non , alors la fonctionnalité appartient au thème. Quelques exemples:
- Suppression / substitution du noyau WP Gallery Gallery CSS
- Filtrage de la longueur des extraits postaux, du texte "en savoir plus", etc.
- Tout ce qui est implémenté via
add_theme_support()(je suppose que celui-ci devrait être évident)
- CSS personnalisé
Normalement, ces deux questions fourniront une ligne de différenciation assez claire. Cependant, il y a des exceptions.
Types de messages personnalisés
Les types de publication personnalisés, par exemple, sont un hybride unique en ce qui concerne la génération et la présentation du contenu, étant donné le fonctionnement de la hiérarchie des modèles pour les pages d'index d'archive et les pages de publication uniques . L'aspect de génération de contenu des CPT les placerait normalement dans Plugin Territory; Toutefois, les plug-ins ne peuvent pas définir de pages de modèle qui correspondent de manière inhérente à la conception, à la mise en page et au style d'un thème donné (en particulier si le CPT affiche un affichage autre que le titre / contenu / méta habituel, ou s'il est associé à des taxonomies personnalisées).
À long terme, la solution à cette disparité, à mon humble avis, consiste à adopter une convention / consensus standard pour la définition des CPT pour des types de contenu donnés (listes immobilières, événements du calendrier, produits de commerce électronique, entrées de livres / médiathèques, etc. .) De cette façon, le contenu généré par l'utilisateur resterait portable entre les thèmes qui implémentent la définition standard / conventionnelle d'un CPT donné, tandis que les développeurs de thèmes conservent la possibilité de définir le design / la présentation / le style de ce CPT dans les fichiers de modèle de thème.
Liens de médias sociaux
De même, je dirais normalement que les liens de profils de médias sociaux, qui deviennent presque omniprésents dans les thèmes actuels, sont des territoires de plugins, car ils n’ont rien à voir avec la présentation du contenu. La meilleure solution serait que ces profils soient définis quelque part dans le noyau; Cependant, il n’existe actuellement aucun moyen standard / consensus de définir ces liens. Sont-ils mieux définis au niveau de la configuration du site ou par utilisateur? Si par utilisateur, la méta de l'utilisateur est exposée dans le modèle? etc.
Là encore, à long terme, la solution à cette disparité est que le noyau définisse le lieu où ces liens sont définis ou que la communauté des développeurs de thèmes développe son propre consensus. En attendant, il n’ya vraiment rien pour cela que de les garder définis dans chaque thème.