Archives par mot-clé : filter

Mode d'emploi

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.

Mode d'emploi

Plugin JetPack: what about with class Featured_Content from theme TwentyFourteen ?

Laisser un commentaire

Plugin JetPack has a strange behavior with class Featured_content of TwentyFourteen theme and child theme like here TwentyFourteen-xili!

Feedback after investigations

In TwentyFourteen, in sub-folder inc file featured-content.php contains class Featured_Content. It is possible to copy (and modify) inside child theme (as done in TwentyFourteen-xili to include sub-selection and cache according current language). As here in frontpage, only featured posts in a language are displayed. Because functions from functions.php are fired before those of parent theme: no problem, modified class has priority!

All is working well until JetPack will be installed… no sub-selection 🙁
By tracing, the modified class is not used
In JetPack settings, no way to disable (not load) Featured_Content Class, only a class with same name loaded before is possible !
How to force to download the child theme Featured_Content Class ?

In sources below (theme-tools.php – extrait ci-dessous) : no filter, only test with class_exists

// Featured Content has an internal check for theme support in the constructor.
// This could already be defined by Twenty Fourteen if it's loaded first.
// Be sure to not load this on the plugin page in case another plugin is activating
// with the same class name in an attempt to override Jetpack's Featured_Content
if ( ! class_exists( 'Featured_Content' ) && 'plugins.php' !== $GLOBALS['pagenow'] ) { 
    require_once( JETPACK__PLUGIN_DIR . 'modules/theme-tools/featured-content.php' );
}

Only possible solution, creating a plugin with a filter before the time where JetPack load the modules (plugins_loaded – priority 100).

Remember it is impossible to add filters “plugins_loaded” inside functions.php of a theme. It is too late according timeline of wp_settings.

The code below show that featured-content.php file will be required before JetPack requires its modules:

function xili_jetpack_disable_featured () {

    if ( ! class_exists( 'Featured_Content' ) && 'plugins.php' !== $GLOBALS['pagenow'] ) {
        if ( file_exists( get_stylesheet_directory() . '/inc/featured-content.php' ) ) {
            require get_stylesheet_directory() . '/inc/featured-content.php'; // this one will disable others
        }
    }
}

if ( class_exists ( 'jetpack' ) ) { // inited by init filter but without modules (priority 100 in jetpack)
    
    add_action( 'plugins_loaded', 'xili_jetpack_disable_featured', 17 ); // after XL and XTT

}

This example code lines are easy to insert in a very simple plugin.
For multilingual context, these lines (with options) are now inside xili-language (v 2.11.1+). Here, you will see in real time that TwentyFourteen-xili multilingual recovers his behavior and sub-select featured posts in frontpage.

M.