Archives par mot-clé : action

WP-Settings en action : attention à ne pas filtrer n’importe comment !

Version 2014–12–08

Une première relecture en prévision du MeetUp du 9 décembre à Lyon.

Pour suivre, il suffit d’avoir un éditeur de texte et lire les fichiers du kit WordPress (ici version 4.1)

Contexte

Le fichier wp-settings.php est lancé à la fin de wp-config.php

wp-config.php est lancé par wp-load.php qui lui même arrive après la succession index.php, wp-blog-header.php et avant template-loader.php qui contient l’importante action do_action( ‘template_redirect’ ); en ligne #12

Lecture ligne par ligne, les étapes clés

Imprimé, le fichier wp-settings.php tient sur six pages ou 375 lignes (WordPress Version 4.1). Dans les deux premières pages (#156), il déclare les constantes et met en place les fichiers (et classes) indispensables notamment ceux qui sont dans le dossier “wp-includes”. Ensuite, si l’installation est multisite, sont mis en place les extensions obligatoires (mu) puis les fichiers des extensions (sans qu’elles à ce stade activée – si elles sont bien écrites #212)

Les “do_action” majeurs

ligne #237 : premier “do_action” nommé “plugins_loaded”

Puis déclaration des GLOBALS dont la fameuse $wp_query

deuxième “do_action” nommé “setup_theme”

puis mise en place de l’internationalisation

Mise en place des fichiers fonctions.php (theme enfant avant theme parent) du thème courant.

troisième “do_action” nommé “after_theme_setup”

L’utilisateur courant est déclaré (donc connu). Souvent on en profite pour activer et enregistrer des fonctionnalités du thème actif.

quatrième “do_action” nommé “init”

C’est le fourre-tout mais qui mérite mieux si l’on veut mieux séquencer les activations

cinquième et dernier “do_action” nommé “wp_loaded” à la fin où tout est en place et où les ajax peuvent être lancés. (#374)

avant la requête (loop)

Le lancement de la requête se situe dans le fichier wp-blog-header et juste avant le template-loader (bien sûr si on veut afficher le thème). La fonction wp() est en fait la fonction main de la classe WP qui contient le do_action_ref_array( ‘wp’, array( &$this ) );

après la requête (juste avant la boucle / loop )

Sous réserve que l’on veuille afficher le thème, le do_action( ‘template_redirect’ ); en ligne #12 est la première action une fois la query effectué (en dehors des actions et filtres de la classe WP_Query elle-même).

Les éléments clés pour les développeurs d’extensions

De cette lecture rapide de wp_settings, on retire qu’il faut choisir dans une extension les bons filtres et au bon moment. Dans des versions précédentes de JetPack, certaines actions étaient faites trop tôt et interdisaient toute filtrage possible par une extension.

versant utilisateur – visiteur (frontend)

La réalisation de l’extension xili-language pour afficher un site multilingue avec une traduction correcte des termes du cadre du thème permet de préparer le chargement des bons fichiers .mo une fois bien connu ce qui doit être affiché (un single, une liste,…) et la langue qui doit être utilisée en concordance avec les contenus (c’est le filtre ‘wp’ dans la classe WP. Cette connaissance du bon filtre (action) au bon moment se substitue aux tâtonnements du début où on utilisait un filtre comme dans une autre extension sans avoir analysé sa position.

versant administrateur auteur (backend)

Quand on se connecte sur la partie admin, le trajet est un peu différent, il indique qu’on est côté admin (WP_ADMIN à true) mais passe toujours par wp-config.php donc par wp-settings.php etc…

La première action importante sera do_action( ‘admin_init’ ); en ligne #127 du fichier /wp-admin/admin.php. C’est là que par exemple on va définir à la volée la langue courante de l’administrateur qui veut en changer sans changer celle de base qu’il a défini dans son profil.

En guise de conclusion transitoire

“le source, le source, le source” comme me disait Amaury rencontré au 2e BarCamp à Paris est en effet, le plus important à explorer avant et pendant le développement d’une extension ou d’un thème. L’utilisation de la fonction “error_log” avec des drapeaux permet aussi de valider les découvertes et d’afficher l’existence ou des valeurs visibles sur la console au fil du démarrage de WP jusqu’à son affichage.