Où mettre mon code: plugin ou functions.php?

Existe-t-il un schéma facile à comprendre pour décider quel type de code appartient à un plugin ou à un thème functions.php?

Il existe de nombreux cas et de nombreux débats sur ce sujet, principalement en raison de certaines idées fausses sur le fonctionnement interne de WordPress. Je demande une réponse basée sur des faits et non sur des opinions.

Il devrait expliquer comment gérer ces points (et probablement plus):

• types de post personnalisés et taxonomies
• formulaires de contact
• codes courts
• widgets personnalisés
• add_theme_support( 'automatic-feed-links' );
• Fonctions de référencement telles que des metaéléments personnalisés
• commutateur de thème

Il y a souvent des avantages et des inconvénients pour les deux côtés. Notre question la plus populaire sur Best Collection of Code pour votre fichier functions.php a reçu beaucoup d'extraits de code sous forme de réponses au moins discutables.
Nous avons besoin de critères qu'un débutant peut comprendre, peut-être une liste de contrôle - avec des raisons.

Voir aussi la question connexe de Chip Bennett sur notre méta-site: Questions demandant spécifiquement une solution "sans plugin"

Connexes: Où est-ce que je place les extraits de code que j'ai trouvés ici ou ailleurs sur le Web?

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.

Un test facile où le code est le mieux placé:

• écrivez le code dans le fichier functions.php
• changer de thème

• la fonctionnalité vous manque-t-elle, le blog ne fonctionne-t-il pas correctement ou reste-t-il des fragments de l'ancien thème (par exemple des codes courts)?

  • oui: le mettre dans un plugin

  • non: laissez-le dans functions.php

Exemples: écrivez un shortcode. Après avoir changé de thème, les codes courts en clair sont conservés dans vos messages. Donc ce sera mieux placé dans un plugin.

Ecrivez une fonction pour lister les derniers commentaires. Après avoir changé de thème, tout va bien car les autres thèmes ont peut-être une fonction équivalente.

Cela dépend vraiment du code et de ce qu'il va faire. Certains codes n’influencent que le style ou le contenu du thème, d’autres modifient les articles de blog.

Je ne pense pas qu'il y ait une réponse facile à cette question, mais je parie que nous pourrions créer un organigramme pour aider à la décision. Voici un aperçu de cet organigramme, qui peut et devrait être développé. Commenter avec des suggestions!

• Ce code doit-il être hébergé sur une installation de WordPress sur un seul site?
  • Oui - Le thème du site ne change-t-il qu'avec les nouvelles conceptions et les changements de fonctionnalités?
    • Oui - Le code en question est-il spécifique à cette conception actuelle ?
      • Oui: functions.php
      • Non: plugin
    • Non (ça change souvent ou à volonté) - Plugin
  • Non (Multisite) - Vous hébergez l'installation multisite OU s'agit-il d'une solution multisite hébergée qui autorise les plug-ins?
    • Oui: la fonctionnalité en question est-elle spécifique à ce site ou peut-elle / devrait-elle être utilisée par d'autres sites du réseau?
      • Spécifique à ce site: functions.php
      • Partagé sur plusieurs sites - Voulez-vous le forcer sur tous les sites?
        • Oui: plugin, stocké dans le répertoire mu-plugins ou activé par le réseau
        • Non: s'agit-il d'un réseau de sites non liés ? (par exemple différents clients)
          • Oui: Serait-ce mauvais ou non professionnel si le client A voyait ou activait le plug-in que vous aviez écrit pour les clients B, C et D? (par exemple, cela pourrait casser le site ou causer une fonctionnalité indésirable)
            • Oui: functions.php
            • Non: plugin
          • Non: probablement plugin
    • Non (hébergé par un service tel que VIP qui n'autorise pas les plugins): utilisez functions.php

• Thèmes parents - parfois avec des fonctionnalités partagées, il serait préférable de créer un thème parent et de placer ces fonctionnalités dans le fichier functions.php du thème parent.
• Les répertoires de plug-ins des installations multisites de grande taille peuvent rapidement devenir indisciplinés. Il serait donc préférable de dupliquer les fonctionnalités partagées utilisées par un faible pourcentage de sites (par exemple, moins de 1%) dans des fichiers functions.php.

À partir d'ici Thèmes VS Plugins

Ajoutez du code personnalisé à un thème enfant afin que, lorsque vous mettez à jour le thème parent, votre code personnalisé ne soit pas perdu.

Vous pouvez également créer un plugin spécifique au site contenant tout votre code personnalisé.

En ce qui concerne l'écriture de code par rapport aux plugins, vous pouvez utiliser des plugins pour et les fonctions. Cependant, pour la plupart des choses que vous voulez, le codage manuel est le meilleur, car il est plus facile de le modifier, sauf dans certains cas comme des boîtes à méta où vous pouvez envisager êtes un développeur de thèmes.

 function modify_contact_methods($profile_fields) {

// Add new fields
$profile_fields['twitter'] = 'Twitter Username';
$profile_fields['facebook'] = 'Facebook URL';
$profile_fields['gplus'] = 'Google+ URL';

return $profile_fields;
}
add_filter('user_contactmethods', 'modify_contact_methods');

http://codex.wordpress.org/Plugin_API/Filter_Reference/user_contactmethods

1. Ajouter un nouveau type de message personnalisé - Code
2. Ajouter de nouveaux champs aux utilisateurs - Code ci-dessus
3. Ajouter de nouveaux widgets - Code
4. Ajouter des permaliens personnalisés - Paramètres de WordPress Permalink

Je sais que c'est un cheval mort et que Chip l'a à peu près couvert, mais je voulais ajouter quelques réflexions.

Si vous réalisez une programmation vivante et que vous vous retrouvez à travailler sur des sites wordpress dans des délais, vous constaterez que cela revient vraiment au temps.

Le plus souvent, en particulier pour les débutants, il est beaucoup plus rapide et simple d'ajouter simplement ce dont vous avez besoin dans un thème et de le qualifier de fait.

Cela étant dit, si vous travaillez sur Wordpress de manière semi-régulière, vous devriez sérieusement envisager les mesures suivantes :

1. Construire un squelette de plugin

Cela devrait gérer tout ce que vous aurez habituellement besoin de faire avec un plugin, y compris l'activation, la désactivation, la mise à jour de version, la construction de panneaux d'administrateur et la désinstallation.

Si vous prenez le temps de le faire, vous trouverez:

• Il ne faut plus beaucoup de temps supplémentaire pour ajouter des fonctionnalités via des plugins
• Vous pouvez commencer à construire une liste complète de plug-ins à réutiliser sur d'autres projets, en vous faisant gagner beaucoup de temps à long terme.
• Vous pouvez les rendre accessibles au public si vous voulez une visibilité supplémentaire

Vous pouvez maintenant construire les choses correctement et faire les projets futurs plus rapidement.

2. Construire un squelette de thème

Cela devrait gérer tout ce qui est généralement nécessaire dans un thème:

• Une feuille de style principale contenant les styles que vous utilisez couramment (réinitialisations, etc.)
• Un fichier index.php approprié, gérant tout ce dont vous avez besoin pour n'importe quel modèle
• Un fichier functions.php - vous ne l'utiliserez pas autant, mais il vous sera utile.

Une fois que cela est fait, créez un squelette de thème enfant qui utilise votre thème principal.

• Ajoutez la feuille de style en faisant référence à votre thème parent.
• Ajouter le fichier functions.php

Une fois ces deux opérations terminées, la création de nouveaux sites pour les utilisateurs devient beaucoup plus rapide.

Si vous faites ce qui précède, vous pouvez alors travailler sur les éléments suivants:

• Passez votre nouveau temps libre à vous familiariser avec PHP, WordPress, JavaScript, CSS et / ou mySQL ... plus vous en apprendrez sur ceux-ci, plus vous obtiendrez des résultats concrets.
• Mettez à jour vos squelettes de plug-ins, de thèmes et de thèmes enfants lorsque vous trouvez des améliorations à apporter. Aussi bon que vous soyez, si vous continuez à apprendre, vous constaterez des améliorations à apporter.

Et, si vous faites tout ce qui précède , vous constaterez que la réponse de Chip ne sera alors pas seulement idéale, elle deviendra optimale.

La réponse simple est ceci ..

Le code dépend-il de l'une des fonctionnalités intégrées à un thème spécifique? Si oui, alors mettez un thème.

Voulez-vous que ce code soit transférable entre sites et entre thèmes? Si oui, alors mettez dans un plugin.

Si la réponse est non à la fois ci-dessus, puis imaginez le site 5 ans dans le futur, quand il est temps pour une refonte. La fonction du code que vous écrivez est-elle quelque chose qui survivra à la prochaine mise à jour de la conception? Si oui, mettez un plugin.

De plus, si vous n'utilisez pas de thèmes enfants et que vous envisagez de mettre à jour le thème, je vous suggérerais également d'utiliser un plugin.