Comment redéfinir la fonction pluggable dans le thème?

10

Toute la documentation que j'ai rencontrée traite de la redéfinition de la fonction plug-in via votre plugin.

Et si vous développiez un thème à la place?

Mon functions.php nécessite un autre fichier qui remplace la fonction get_user_by() , définie dans pluggable.php .

Si j'oublie l'appel de if( function_exists() ) , j'obtiens le message d'erreur "Impossible de redéclarer ...".

Si j'inclus l'appel if( function exists() ) , aucune erreur ne se produit, mais bien sûr, ma fonction est alors ignorée, car la version enfichable existe.

D'après le superbe post de Dominic sur la commande de démarrage de WordPress , il est clair que pluggable.php est chargé avant le functions.php de votre thème, etc., ce qui explique l'erreur.

La question est donc de savoir comment tirer parti de cette belle architecture enfichable dans un thème, sans recourir à l'écriture de plug-ins qui doivent ensuite être regroupés ou installés avec le thème?

Notes complémentaires : il apparaît donc que l'argument est que les thèmes ne devraient pas essayer de faire ce que les plugins font. Mais cet argument date de plus de quatre ans (selon le numéro de trac à 4 chiffres). J'aimerais beaucoup entendre de gros frappeurs si cette philosophie s'applique toujours, compte tenu de la topologie complexe du paysage de développement de thèmes actuel. J'aimerais croire que nous avons évolué depuis.

Contexte : je développe une solution CMS unique pour un client, avec de nombreuses métadonnées personnalisées, la personnalisation du back-end Admin, le processus de connexion / authentification, les travaux. Et bien sûr, il y a le composant de conception - c'est là que la partie thème entre en jeu. Le fait est que ce ne sont pas des composants réutilisables - ils ne s'appliqueront jamais à un autre client, ils ne seront jamais placés sous GPL et open source, et ils ne doivent certainement pas être distribués / installés sur d’autres déploiements WordPress. Au mieux, il existe certaines meilleures pratiques que je vais utiliser pour les projets futurs, mais ce sera strictement un travail de référence / copier-coller.

Cela ne me semble pas être un cas d'utilisation de plugins. Le thème est installé, peut-être un thème enfant de Twenty Eleven, peut-être même un autonome, ses fonctions functions.php sont placées dans un bateau comprenant des éléments, chacun traitant un aspect différent du CMS en question. Ensuite, les fichiers de modèle de thème utilisent des "balises de modèle" personnalisées définies dans les inclus. Je ne veux pas que des fichiers de thèmes avec des dépendances sur un plugin ou un autre soient activés, etc. Cela n'a aucun sens de créer de la complexité dans le système. Bien sûr, je peux le mettre dans le dossier des plugins à utiliser absolument, mais cela ressemble toujours à un hack - pour le moment, tout ce qui concerne les personnalisations apportées à ce projet est contenu dans wp-content/themes/my-theme/ . Je ne veux pas non plus avoir à envisager de rechercher des éléments dans certains dossiers de plugins.

Ne vous méprenez pas. J'aime les plugins et je les utilise et les écris. Et j’utilise des plug-ins conjointement avec ce type de développement de thème hautement personnalisé lorsque le plug-in est une tierce partie et représente les meilleures pratiques bien au-delà de ce que je pourrais éventuellement déployer dans un délai raisonnable. Mais lorsque je dois modifier les fonctionnalités principales d'un scénario ponctuel, je me tourne vers les crochets d'action, les crochets de filtre et j'aimerais pouvoir utiliser des fonctions enfichables pour l'utilisateur et l'authentification.

    
posée Tom Auger 20.06.2012 - 20:27

3 réponses

10

Si vous le construisez pour un seul client, vous devez absolument tirer parti de mu-plugins .

Il y a beaucoup de choses dans WordPress que vous ne pouvez pas faire dans functions.php . Les fonctions enfichables en font partie, mais il est plus évident qu'un certain nombre de points d'accroche (actions et filtres) se déclenchent avant functions.php . Dans certains cas, ces hooks se déclenchent même avant les plugins ordinaires, ce qui vous oblige ensuite à utiliser mu-plugins ou un plugin activé par le réseau. Dans d'autres cas encore, même un plug-in mu est trop tard. Peut-être avez-vous besoin de quelque chose en sunrise.php . Ou même quelque chose (une constante ou non) dans wp-config.php .

Je préférerais ajouter des points d’accroché aux fonctions connectables, plutôt que de faciliter leur remplacement. Il est peu probable que nous ayons à nouveau une autre fonction enfichable: ils sont antérieurs aux points d'ancrage et je n'ai presque jamais vu une situation où ils seraient avantagés par rapport à un bon point d'ancrage traditionnel.

Je suis toujours d’accord, six ans plus tard, avec Andy Skelton - "Il existe de nombreuses différences entre le fichier de fonctions d’un thème et un plugin. Continuons ainsi."

Cela mis à part, un changement comme celui-ci ne pourrait jamais se produire. Cela casserait beaucoup de choses. D'innombrables thèmes appellent des fonctions dans le corps de functions.php qui entraîneraient une erreur fatale si pluggable.php n'avait pas déjà été chargé - comme current_user_can() ou wp_create_nonce() . Ils échoueraient tous. Et cela casserait les plugins, qui pourraient normalement commencer à appeler ces fonctions le plugins_loaded . (Il suffit de déplacer pluggable.php plus bas dans wp-settings.php et je parie que la moitié des ressources essentielles se briseraient ou, à tout le moins, le personnalisateur le ferait.)

Enfin, il est inévitable qu'un thème puisse inclure un fichier distinct, tel que pluggable.php , que nous pourrions charger dès que nous chargeons des plug-ins, et donc remplacer les fonctions pouvant être connectées. Mis à part le fait que ce soit une mauvaise idée (voir les quatre premiers paragraphes de ce commentaire), il ne serait toujours pas compatible, car jusqu’au% hook, on pourrait remplacer le thème à charger en filtrant les valeurs de la feuille de style et du modèle.

Malheureusement, cela n’est pas tenable compte tenu de l’architecture de WordPress. La bonne chose est qu'il existe d'innombrables (meilleures) façons de le faire.

(Initialement posté ici: enlace )

    
réponse donnée Andrew Nacin 20.06.2012 - 22:19
5

Dans le contexte d'un projet ponctuel, il est absolument approprié de supprimer le code d'utilisation obligatoire dans mu-plugins . Si "avoir tout à la fois" est un problème, créez simplement un lien symbolique dans le répertoire du thème vers le menu déroulant mu-plugins , afin qu'il apparaisse lors de la recherche dans le répertoire du thème.

    
réponse donnée Mark Jaquith 20.06.2012 - 22:12
0

Je ne vois pas comment y parvenir, trop tôt dans la séquence de chargement.

La solution la plus proche de la solution saine consisterait à ajouter l'inclusion personnalisée à wp-config.php (par code ou à demander à l'utilisateur), mais une comparaison avec ce plugin de regroupement aurait probablement plus de sens.

    
réponse donnée Rarst 20.06.2012 - 20:52

Lire d'autres questions sur les étiquettes