PHP 7.2 : comment remplacer la DEPRECATED create_function pour passer une variable dans add_action() ?

create_function est maintenant obsolète avec PHP 7.2. Comment le réécrire avec une fonction anonyme pour passer une variable dans add_action() à la fin d’une fonction calculant cette var? Dans ce cas, l’action ‘admin_notices’ affiche un message lorsque le thème est activé.

Remplacer

add_action( 'admin_notices', create_function( '', 'echo "' . addcslashes( $msg, '"' ) . '";' ) );

par

add_action(
    'admin_notices',
    function() use ( &$msg ) {
       echo $msg;
    }
);

Noter que la variable est passé en référence ( &$msg ) dans function.
Voir dans le fichier functions.php de ce thème dans GitHub ( line 148 ).

Faites en bonne usage !

WordCamp 2018 à Lille

Ce vendredi 7 décembre 2018 : premier wordcamp sur les terres des Hauts de France. A l’évidence cela discutera ferme sur Gutenberg et les bouleversements occasionnés (ainsi que l’immense travail pour les développeurs d’extension. L’occasion sera aussi ouverte pour discuter autour des extensions multilingues et surtout les spécifications de base de description des langues et de leurs attributs.

Taxinomie et Objet WP_term

xili-tidy-tags

Mémo pour faire la synthèse de l’approche originale du modèle de données utilisé dans xili-tidy-tags créé en 2019 (WP 2.3) et toujours opérant dans WP 4.8 Evans en 2017 !

de la naissance des idées

En 2009, lors de la construction progressive de l’extension multilingue xili-language basée sur la taxonomie (WP 2.3), s’est posé la question : comment gérer les mots-clés (étiquettes, post-tag) et leur traduction ? A l’analyse, il est paru évident que d’une langue à l’autre, il n’y a pas de lien bi-univoque entre un mot et sa traduction (et inversement). En élargissant la réflexion, il est apparu aussi que des mots pouvaient être regroupés selon un ensemble sémantique (marque / trademark) – pas traduisible. Des noms, des couleurs. Et que donc l’extension ne concernait pas uniquement les sites bi ou multilingues. D’où la mise au point une extension indépendante dénommée xili-tidy-tags. Comme l’ont fait certains sites, ils ont pu créer des nuages selon des thématiques sémantiques. A noter que cette approche taxinomique permet à un mot clé d’appartenir à plusieurs ensembles (donc d’apparaître dans plusieurs nuages).

Sur le plan technique et selon les possibilités et contraintes présentes dans WP, le choix s’est porté pour lier la taxinomie à un groupe de termes. Cela va donc demander de créer des requêtes spécifiques (puisque non liées à un objet autre de type post ou custom post type). De même, il ne sera pas possible d’utiliser les tax_queries telles qu’elles furent définies lors de l’évolution de WP.

Puis sont apparus les taxonomies type mots-clés mais spécifiques comme celles présentes dans bbPress (topic-tag). S’est donc posé aussi le problème de la réalisation notamment dans l’interface admin, une ou plusieurs extensions ? En fait, le choix s’est porté sur le mode d’une instantiation avec donc un interface dédié à chaque taxonomie. A titre d’exemple pour les développeurs, la gestion des “topic-tag” se met en place quand bbPress est détecté. Avec quelques lignes de code, une nouvelle instantiation peut-être mise en place si une taxonomie est ajoutée (custom taxonomy).

un peu technique

Les échanges via le tracs WordPress ne sont pas toujours aisés mais il y a été fait allusion à la colonne de la table term_group (“alias”). versus l’approche taxinomique. En fait, xili-tidy-tags a besoin des deux notamment dans un contexte multilingue. La taxinomie language des mots clés les groupe par langue et la colonne de la table “term_group” permet de passer d’une langue à l’autre pour un mot-clé.

A suivre…