[NOTE : les exemples sont ici basés sur jetpack v2.3. La version jetpack 2.4+ a revu l’ensemble de l’initialisation selon des règles décrites ici.]

Ce qu’il faut savoir à propos de l’addition de filtres par une extension (plugin) ou via le fichier functions.php du thème actif.
Le cas particulier des filtres présents dans wp-settings.php

La ligne des temps

La suite logique de la mise en place des composants jusqu’à la délivrance de la page visiteur ou auteur (administrateur) telle que visible dans le wp-settings.

• mise en place des dropins et des mu-plugins (#157) (mu = must use).

• mise en place des fichiers des extensions ( #196 ) qui semble se faire dans le sens alphabétique. Deux situations : soit seuls les éléments sont installés et le filtre (action) est mis en queue (ce filtre pourra alors permettre le moment venu l’instantiation de la classe du plugin) – soit déjà des initialisations, instanciations sont lancées (elles ne sont dès lors plus filtrables au préalable par d’autres plugins).

196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212

// Load active plugins.
foreach ( wp_get_active_and_valid_plugins() as $plugin )
	include_once( $plugin );
unset( $plugin );
 
// Load pluggable functions.
require( ABSPATH . WPINC . '/pluggable.php' );
require( ABSPATH . WPINC . '/pluggable-deprecated.php' );
 
// Set internal encoding.
wp_set_internal_encoding();
 
// Run wp_cache_postload() if object cache is enabled and the function exists.
if ( WP_CACHE && function_exists( 'wp_cache_postload' ) )
	wp_cache_postload();
 
do_action( 'plugins_loaded' );

Pourquoi il est important de définir la priorité du filtre dans la queue afin de maîtriser les effets désirés ?

Par défaut, la priorité d’un filtre est ajoutée au niveau 10. C’est donc sa position sur la ligne des temps de l’adjonction qui va déterminer sa place. Cela n’est donc pas parfait, on ne peut pas toujours se fier à l’ordre alphabétique du nom de l’extension. D’où la nécessité de définir précisément, en déclarant des priorités successives, par exemple que XILI-LANGUAGE sera lancée avant XTT et XD car ces deux dernières ne fonctionnent que dans l’environnement multilingue préalablement créé par XILI-LANGUAGE.

Exemple de JetPack et de bbPress pour le maîtrise du language côté admin:

Comme on le lit dans wp-settings.php, la réalisation (do_action) plugins_loaded (#209) se fait avant que les informations sur l’utilisateur connecté soient connues. Celle des filtres init (#306) est par contre activée alors que WP connait les rôles du visiteur ou de l’administrateur.

580
581
582
583
584
585

// line 4580 et suivantes
add_action( 'init', array( 'Jetpack', 'init' ) );
add_action( 'plugins_loaded', array( 'Jetpack', 'load_modules' ), 100 );
add_filter( 'jetpack_static_url', array( 'Jetpack', 'staticize_subdomain' ) );
 
Jetpack_Sync::sync_options( __FILE__, 'widget_twitter' );

La réalisation (do_action) plugins_loaded (#209) précède celle de init (#306). Mais en sus, ce qui pose problème, dans le cas de jetpack la fonction qui appelle Twitter ( Jetpack_Sync::sync_options( FILE, ‘widget_twitter’ ); ) instancie la classe lors de l’include de jetpack… c’est donc redondant – le filtre init n’a donc pas de raison d’être puisque la fonction twitter a instancé la classe dès l’include du fichier jetpack.php … Une mise à plat s’impose.

Chaque chose en son temps et au bon moment… une bonne architecture n’est pas automatique. Il faut donc bien séparer ce qui tient de l’infrastructure (inclusion des fichiers de l’extension), de sa modification par les extensions activées (filtre plugins_loaded) et de sa personnalisation selon la personne connectée et des rôles qui lui sont attribués (filtre init) ; pour ces deux filtres cités, bien assigner les priorités.

A propos des fonctions et objets ajoutées dans functions.php du thème.

286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317

$GLOBALS['wp_locale'] = new WP_Locale();
 
// Load the functions for the active theme, for both parent and child theme if applicable.
if ( ! defined( 'WP_INSTALLING' ) || 'wp-activate.php' === $pagenow ) {
	if ( TEMPLATEPATH !== STYLESHEETPATH && file_exists( STYLESHEETPATH . '/functions.php' ) )
		include( STYLESHEETPATH . '/functions.php' );
	if ( file_exists( TEMPLATEPATH . '/functions.php' ) )
		include( TEMPLATEPATH . '/functions.php' );
}
 
do_action( 'after_setup_theme' );
 
// Set up current user.
$wp->init();
 
/**
 * Most of WP is loaded at this stage, and the user is authenticated. WP continues
 * to load on the init hook that follows (e.g. widgets), and many plugins instantiate
 * themselves on it for all sorts of reasons (e.g. they need a user, a taxonomy, etc.).
 *
 * If you wish to plug an action once WP is loaded, use the wp_loaded hook below.
 */
do_action( 'init' );
 
// Check site status
if ( is_multisite() ) {
	if ( true !== ( $file = ms_site_check() ) ) {
		require( $file );
		die();
	}
	unset($file);
}

Ce fichier est inclus après la génération des rôles et la mise en place des locales. Le fichier du thème enfant est inséré avant celui du thème parent. (# 287) – Ensuite intervient la réalisation (do_action) after_setup_theme (#294) qui précède celle de init (#306). Cas particulier si thème enfant : comme le fonctions.php du thème enfant est activé avant celui du thème parent. L’adjontion du filtre/action after_setup_theme doit se faire en position 11. Les fonctions de ce filtre recouvront alors celle du thème parent.

On peut donc dans le thème adapter certaines actions ou filtres générés au préalable par les extensions. Cela ne sera donc actif que si le thème est affecté au site (thème courant). Pour ce qui concerne les filtres du wp-settings, on voit que seul les filtres ‘init’ peuvent être modifiés (changement de la fonction associée ou de sa priorité via remove_filter suivi d’un add_filter avec de nouveaux paramètres,…)

(à suivre… patience…)