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

Question

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

Il y a sont plusieurs cas et plusieurs 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 les éléments meta 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 Meilleure collection de code pour votre fichier functions.php a obtenu 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 mets les extraits de code que j'ai trouvés ici ou ailleurs sur le Web?

Chip Bennett · Accepted Answer

Je commencerais par cette question: La fonctionnalité est-elle liée à présentation du contenu ou à génération/gestion du contenu, du site ou de l'identité de l'utilisateur?

Si la fonctionnalité n'est pas liée spécifiquement à présentation du contenu _, elle se trouve directement dans Plugin Territory. Cette liste est longue:

Modification des principaux filtres WP (contenu wp_head, 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 à présentation du contenu, alors il s’agit d’un candidat à inclure dans le thème. À ce stade, je reviendrais à critère de changement de thème de @ Raf912 : la fonctionnalité vous manquerait-elle lorsque vous changeriez de thème? Si la réponse à cette question est non, alors la fonctionnalité appartient dans le thème, quelques exemples:

Supprimer/ignorer le WP core Galerie 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 le type de publication unique pages d'index d'archive et pages de publication uniques . L’aspect générateur de contenu des CPT les place normalement dans Plugin Territory; toutefois, les plugins ne peuvent pas définir de pages de modèle qui s’intègrent de manière inhérente dans la conception/la présentation/le style d’un thème donné (en particulier si le CPT affiche des affichages autres que les titres/contenus/contenus habituels). Meta, ou a des taxonomies personnalisées associé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, devenus presque omniprésents dans les thèmes actuels, sont des plugins de territoire, car ils n’ont rien à voir avec 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.

Encore une fois, à 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.

Ralf912 · Answer

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.

Matthew Boynes · Answer

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 mono-site de WordPress?
- Oui - Le thème du site ne change-t-il qu'avec les nouvelles conceptions et modifications majeures des fonctionnalités?
  - Oui - Le code en question spécifique à la conception actuelle ?
    - Oui: functions.php
    - Non: plugin
  - Non (ça change souvent ou à volonté) - Plugin
- Non (Multisite) - Vous hébergez l'installation multisite OR est-ce une solution multisite hébergée qui autorise les plug-ins?
  - Oui: la fonctionnalité en question 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
    - Partage 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 des fonctionnalités indésirables)
        
        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, <1%) dans les fichiers functions.php.

Brad Dalton · Answer

À 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 et de 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

Privateer · Answer

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 travaillez sur des sites wordpress dans des délais impartis, vous constaterez que le temps presse.

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 dit, si vous travaillez sur Wordpress de manière semi-régulière, vous devriez sérieusement envisager de procéder comme suit :

Construit un squelette de plugin

Cela devrait gérer tout ce que vous devez habituellement 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.

Construit 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.

CO4 Computing · Answer

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 dans lequel 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.