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

81

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

Il existe plusieurs cas et de nombreux débats sur ce sujet, principalement parce qu’il existe des 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 convient d’expliquer comment gérer ces points (et probablement plus):

  • types de post personnalisés et taxonomies
  • formulaires de contact
  • shortcodes
  • widgets personnalisés
  • add_theme_support( 'automatic-feed-links' );
  • Fonctions de référencement telles que la meta elements personnalisée
  • commutateur de thème

Il y a souvent des avantages et des inconvénients pour les deux parties. Notre question la plus populaire meilleure collection de code pour vos fonctions. Le fichier php contient de nombreux extraits de code constituant des 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 également la question connexe de Chip Bennett sur notre méta-site: Questions demandant spécifiquement une solution" sans plugin "

En relation: Où puis-je placer les extraits de code que j'ai trouvés ici ou ailleurs sur le Web?

    
posée fuxia 18.11.2012 - 11:51
la source

6 réponses

66

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

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

  • Modification des filtres WP principaux ( wp_head content, tels que liens canoniques, générateur et autres méta HTML, etc.
  • Favicon de site
  • Codes courts de post-contenu
  • Publier des liens de partage
  • Scripts de pied de page Google Analytics (et similaires)
  • Outils / contrôles de référencement
  • etc.

Si la fonctionnalité est liée à la présentation du contenu , il s'agit d'un candidat à inclure dans le thème. À ce stade, je reviendrais au critère de changement de thème de @ Raf912 : manqueriez-vous cette fonctionnalité lorsque vous changez de thème? Si la réponse à cette question est non , la fonctionnalité appartient au thème. Quelques exemples:

  • Supprimer / remplacer le noyau CSS de la galerie WP
  • Filtrage de la longueur des extraits après publication, du texte "en savoir plus", etc.
  • Tout élément 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 publication personnalisés

Les types de publications personnalisées, par exemple, sont un peu hybrides 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 types à publication unique archiver les pages d'index et les pages à publication unique . 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 de calendrier, produits de commerce électronique, bibliothèque / médiathèque). entrées, 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 vers les réseaux sociaux

De même, je dirais normalement que les liens de profil de médias sociaux, devenus 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 / consensuel 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.

    
réponse donnée Chip Bennett 19.11.2012 - 13:53
la source
46

Un test simple 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 des fragments de l'ancien thème (par exemple, des codes courts) sont-ils conservés?

    • 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. Ce sera donc mieux placé dans un plugin.

Ecrivez une fonction pour lister les derniers commentaires. Après avoir changé de thème, tout va bien car l’autre thème a 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.

    
réponse donnée Ralf912 18.11.2012 - 13:26
la source
16

Je ne pense pas que la réponse à cette question soit facile, mais je parie que nous pourrions créer un organigramme facilitant la prise de décision. Voici un aperçu de cet organigramme, qui peut et devrait être développé. Commentez 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 modifications majeures des fonctionnalités?
      • Oui - Le code en question est-il spécifique à cette conception actuelle ?
        • Oui: functions.php
        • Non: plugin
      • Non (cela change souvent ou à la fantaisie) - 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
        • 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: Si le client A voyait ou activait le plug-in que vous avez écrit pour les clients B, C et D, serait-il mauvais ou peu professionnel? (par exemple, cela pourrait casser le site ou causer des fonctionnalités indésirables)
              • Oui: functions.php
              • Non: plugin
            • Non: Probablement un plugin
      • Non (hébergé par un service tel que VIP qui n'autorise pas les plugins): utilisez functions.php
Quelques autres pensées que je ne savais pas comment s'intégrer ici:
  • 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 cette fonctionnalité dans le fichier functions.php du thème parent.
  • Les répertoires de plug-ins des grandes installations multisites pouvant rapidement devenir indisciplinés, il est 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.
réponse donnée Matthew Boynes 08.12.2012 - 18:23
la source
5

À partir d'ici Thèmes VS Plugins

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

Vous pouvez également créer un plug-in spécifique à un 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, plugin sauf si vous ê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');

enlace

  1. Ajouter un nouveau type de publication personnalisée - Code
  2. Ajouter de nouveaux champs aux utilisateurs - Code supérieur
  3. Ajouter de nouveaux widgets - Code
  4. Ajouter des liens permanents personnalisés - Paramètres de lien permanent WordPress
réponse donnée Brad Dalton 04.02.2014 - 22:00
la source
3

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 en train de travailler sur des sites wordpress avec des délais limites, vous constaterez que le temps presse vraiment.

Plus souvent qu'autrement, en particulier pour les débutants, il est beaucoup plus rapide et simple d'ajouter simplement tout 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 devez sérieusement envisager de procéder comme suit :

  1. Construire un squelette de plugin

Ceci 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 à créer une liste complète de plug-ins à réutiliser dans d'autres projets si nécessaire, ce qui vous fera gagner beaucoup de temps à long terme.
  • Vous pouvez les rendre accessibles au public si vous souhaitez une visibilité supplémentaire

Vous pouvez désormais créer vos projets correctement et mener plus rapidement vos projets futurs.

  1. Créer un squelette de thème

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

  • Une feuille de style 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 destinés aux utilisateurs est beaucoup plus rapide.

Si vous procédez comme indiqué ci-dessus, vous pourrez 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 vite 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.

    
réponse donnée Privateer 28.01.2015 - 02:17
la source
2

La réponse simple est la suivante.

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, 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, installez un plugin.

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

    
réponse donnée CO4 Computing 26.10.2015 - 06:28
la source

Lire d'autres questions sur les étiquettes