Comment remplacer la fonction enfichable dans le thème?
Toute la documentation que j'ai rencontrée traite de la redéfinition de la fonction plug-in via votre plug-in.
Et si vous développiez des thèmes à la place?
Mon functions.php nécessite un autre fichier qui remplace la fonction get_user_by(), définie dans pluggable.php.
Si j'omets l'appel if( function_exists() ), l'erreur "Impossible de redéclarer ...".
Si j'inclus l'appel if( function exists() ), aucune erreur ne se produit, mais bien entendu, ma fonction est alors ignorée, car la version enfichable existe.
D'après l'article génial de Dominic sur l'ordre de démarrage de WordPress , il est clair que pluggable.php est chargé avant le functions.php de votre thème et ainsi de suite, ce qui explique l'erreur.
La question est donc de savoir comment tirer parti de cette architecture plug-in de Nice à partir d'un thème, sans avoir recours à 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 font les plugins. 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 de 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 sont simplement pas / composants réutilisables - ils ne s'appliqueront jamais à un autre client, ils ne seront jamais placés sous GPL et ouverts. ne doivent 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 plug-ins. Le thème est installé, peut-être un thème enfant de Twenty Eleven, peut-être même un autonome, ses appels functions.php dans un chargement de bateaux inclut, chacun gérant 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 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 plugins en conjonction avec ce type de développement de thème hautement personnalisé when le plugin 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 de base pour un scénario unique, je me tourne vers les crochets d'action, les crochets de filtre et j'aimerais pouvoir également compter sur des fonctions enfichables pour l'utilisateur et l'authentification.
Si vous construisez cela 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'ancrage (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 dans sunrise.php. Ou même quelque chose (une constante ou non) dans wp-config.php.
Je préférerais ajouter des points d’accès aux fonctions connectables plutôt qu’il est plus facile de les remplacer. Il est peu probable que nous ayons une autre fonction enfichable: ils sont antérieurs aux points d'ancrage et je n'ai presque jamais vu une situation où ils auraient un avantage par rapport à un bon point d'ancrage ancien.
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 plug-in. Gardons-le 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 sur plugins_loaded. (Il suffit de déplacer pluggable.php plus bas dans wp-settings.php et je parie que la moitié du noyau casserait - ou à tout le moins, le personnalisateur le ferait.)
Enfin, il y a l'idée inévitable qu'un thème puisse inclure un fichier séparé tel que pluggable.php que nous pourrions charger dès que nous chargeons des plugins, 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 crochet setup_theme, vous pouvez remplacer le thème chargé 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: http://core.trac.wordpress.org/ticket/2479#comment: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" pose problème, il suffit de créer un lien symbolique dans le répertoire du thème vers la liste déroulante mu-plugins afin qu'il s'affiche lors de la recherche dans le répertoire du thème.
Je ne vois pas comment y parvenir, trop tôt dans la séquence de chargement.
La solution la plus proche de sane consisterait à ajouter l'inclusion personnalisée à wp-config.php (par code ou en demandant à l'utilisateur de), mais une comparaison avec ce plugin de regroupement aurait probablement plus de sens.