Comment remplacer la fonction enfichable dans le thème?

Toute la documentation que j'ai rencontrée traite de la substitution de la fonction enfichable via votre plugin.

Et si vous faites plutôt du développement de thème?

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

Si j'omets l' if( function_exists() )appel, j'obtiens l'erreur "Impossible de redéclarer ...".

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

Sur la base de l'impressionnant post de Dominic sur l'ordre de démarrage de WordPress , il est clair qu'il pluggable.phpest chargé avant votre thème functions.phpet ainsi de suite, ce qui explique l'erreur.

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

Notes supplémentaires : Il semble donc que l'argument est que les thèmes ne devraient pas essayer de faire ce que font les plugins. Mais cet argument a plus de quatre ans (selon le numéro de Trac à 4 chiffres). Je serais ravi d'entendre certains frappeurs lourds si cette philosophie s'applique toujours, compte tenu de la topologie complexe du paysage de développement de thème d'aujourd'hui. J'aimerais croire que nous avons évolué depuis.

Contexte : Je développe une solution CMS unique pour un client, avec beaucoup de 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 tout simplement 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 sont les plus certainement pas à distribuer / installer sur d'autres déploiements WordPress. Au mieux, il y aura quelques bonnes pratiques que je vais exploiter sur de futurs projets, mais ce sera strictement un travail de référence / copier-coller.

Pour moi, cela ne ressemble pas à un cas d'utilisation de plugins. Le thème est installé, peut-être un thème enfant de Twenty Eleven, peut-être un autonome, ses fonctions.php appelle dans une cargaison d'includes, chacune manipulant 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 inclusions. Je ne veux pas que des fichiers de thème avec des dépendances sur certains plugins ou autres soient activés, etc. Cela n'a tout simplement pas de sens de créer de la complexité dans le système. Bien sûr, je peux le mettre dans le dossier des plugins à utiliser, mais cela ressemble toujours à un hack - en ce moment, tout ce qui a à voir avec les personnalisations faites pour 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 également.

Ne vous méprenez pas. J'adore les plugins et je les utilise et les écris. Et j'utilise des plugins conjointement avec ce type de développement de thème hautement personnalisé lorsque le plugin est tiers 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 de base pour un scénario unique, je me tourne vers les crochets d'action, les crochets de filtre et j'aimerais pouvoir compter sur des fonctions enfichables pour le côté utilisateur et l'authentification.

Si vous construisez cela pour un seul client, vous devez absolument en profiter mu-plugins.

Il y a beaucoup de choses dans WordPress que vous ne pouvez pas faire functions.php. Les fonctions enfichables en font partie, mais plus évident, un certain nombre de crochets (actions et filtres) se déclenchent auparavant functions.php. Dans certains cas, ces hooks se déclenchent même avant les plugins réguliers, ce qui nécessite alors que vous utilisiez mu-pluginsun plugin activé par le réseau. Dans d'autres cas encore, même un plugin mu est trop tard. Vous avez peut-être besoin de quelque chose sunrise.php. Ou même quelque chose (une constante ou autre) dans wp-config.php.

Je préfère ajouter des crochets aux fonctions enfichables, plutôt que de les remplacer plus facilement. Il est peu probable que nous ayons à nouveau une autre fonction enfichable - ils sont antérieurs aux crochets et je n'ai presque jamais vu de situation où ils ont un avantage sur un bon crochet à l'ancienne (à la mode?).

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 arriver. Cela casserait beaucoup de choses. D'innombrables thèmes appellent des fonctions dans le corps de functions.phpcela, ce qui entraînerait une erreur fatale s'ils pluggable.phpn'avaient pas déjà été chargés, comme current_user_can()ou wp_create_nonce(). Ils échoueraient tous. Et cela casserait également les plugins, qui pourraient normalement commencer à appeler ces fonctions plugins_loaded. (Il suffit de pluggable.phpdescendre plus bas wp-settings.phpet je parie que la moitié du cœur se briserait - ou tout au moins, le personnalisateur le ferait.)

Enfin, il y a l'idée inévitable qu'un thème pourrait inclure un fichier séparé comme pluggable.phpcelui que nous pourrions charger dès que nous chargeons les plugins, et donc pourrait remplacer les fonctions enfichables. En plus d'être une mauvaise idée (voir les quatre premiers paragraphes de ce commentaire), il ne serait toujours pas compatible, car jusqu'au setup_themecrochet, on pourrait remplacer le thème à charger en filtrant les valeurs de feuille de style et de modèle.

Malheureusement, cela n'est tout simplement 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 affiché ici: http://core.trac.wordpress.org/ticket/2479#comment:5 )

Dans le cadre d'un projet ponctuel, il est tout à fait approprié de déposer du code indispensable dans mu-plugins. Si "tout avoir en un seul endroit" est un problème, créez simplement un lien symbolique dans le mu-pluginsrépertoire du thème vers le menu déroulant, afin qu'il apparaisse lors de la recherche dans le répertoire du thème.

Je ne peux pas penser à un moyen d'y parvenir, trop tôt dans la séquence de chargement.

La solution la plus proche de la logique serait d'ajouter une inclusion personnalisée à wp-config.php(par code ou en demandant à l'utilisateur), mais la comparer à ce plugin de regroupement aurait probablement plus de sens.