Tous les articles par adminxili

tag grouping

xili-tidy-tags 1.9 ajoute des fonctionnalités de groupe des mots-clés selon leur sens

Dans les versions précédentes, on pouvait faire des nuages de mots clés selon leur sémantique ou leur langue mais il était difficile de relier par exemple “rouge”, “red”, “rot” et passer d’une liste de posts selon la langue du mot-clé et sa traduction dans une autre langue. En utilisant les fonctions de groupage (alias) des taxinomies du noyau de WP, c’est maintenant possible depuis la version 1.9. Des template tags sont utilisables pour lister les membres d’un groupe et les liens associés comme ici sous le titre de la page listant les articles liés au mot-clé “editor”.

Les nouveaux groupes “multilingues” de mots-clés ayant le même sens mais pas la même langue ne contiennent souvent pas plus de mots-clés que le nombre de langues utilisés dans le site.

100253 downloads September 19th, 2013

Plus de 100 000 téléchargements pour xili-language…

Lors de la surveillance des forums utilisateur de l’extension xili-language ce W.E, la barre des 100 000 est passée. Ce qui confirme, sur la base des pics lors des mises à jour que 3 à 4000 sites mettent à jour régulièrement leur version. C’est un encouragement à continuer même si le contexte des extensions (libres ou payantes) pour rendre WP multilingue est très concurrentiel.
Le principal souci aujourd’hui est l’absence d’esprit contributif pour participer à la documentation, les forums etc… Et si cela ne pose aucune difficulté à répondre à une première question posée (via le formulaire de support ou le forum), il n’est pas possible d’aller plus loin pour former, assister, développer des personnalisations (il y a des centaines de milliers de thèmes plus ou moins bien codés) sans une contribution (ou une facturation pour les professionnels)… En somme le code mis en ligne est gratuit mais pas les services ! Merci aux partenaires fidèles de tous les continents…
Parce que les bibliothèques intégrées à WP offrent de plus en plus de possibilité d’intégration avec un modèle de données plus fin, les prochaines versions de la trilogie xili-language continueront de progresser tout en donnant beaucoup de liberté aux webmestres codeurs…

A++

M.

xilitidy new logo

xili-tidy-tags version 1.8.6 dispo avec en sus un exemple de nuage en “popup”…

La sortie de cette version de xili-tidy-tags est liée à celle de WP 3.6 de l’été.
L’ajout majeur est un exemple de “template tag” – xili_tidy_tags_dropdown – qui permet d’afficher un nuage sous forme de “popup” ou “dropdown”. C’est en fait une solution compacte mais un peu bancale car pour que la liste “select” redirige vers la page regroupant les articles liés à cette page, il faut combiner du javascript (ici on a retenu du jQuery).

Le code se situe après la ligne 1009 du source du plugin. Bien sûr un minimun de connaissance en wp php est nécessaire.

C’est aussi un exemple pour récupérer les infos d’un nuage de tags récupérés en tableau.

Cet article sera prochainement complété.

M.

Le thème enfant multilingue de 2013 est disponible au téléchargement !

Comme la version finale de WP en 3.6 est sortie, le thème multilingue enfant de 2013 est téléchargeable ici.

Après sa mise en place via ftp dans le sous-dossier thèmes à côté du thème parent twentythirteen, il suffit de l’activer dans Apparence pour ajouter les fonctions multilingues si l’extension xili-language est elle-même active.

Ce thème enfant est avant tout une base “pédagogique” avec l’activation d’une classe puissante pour créer l’interface de réglage des éléments du thème.

Bon travail.

M.

Les filtres/actions clés au démarrage de WP [réservé développeurs]

[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…)