Catégorie : WP : trucs, astuces

Dans cette catégorie, quelques notes et astuces sur le codage et les sources de WordPress

WP 4.4-alpha: taxonomy.php fait des petits !! [Màj]

La taxinomie est à la base des catégories, mots-clés (étiquettes) et autres classements dans WordPress (comme language avec la trilogie xili-language). Depuis WP 2.3, tous les éléments clés se trouvaient dans le fichier wp-includes/taxonomy.php . La version WP 4.4 annonce un grand changement. Le developpeur va chercher les informations dans 3 fichiers

<?php
/**
 * Core Taxonomy API
 *
 * @package WordPress
 * @subpackage Taxonomy
 * @since 2.3.0
 */

/** Core taxonomy functionality */
require_once( ABSPATH . WPINC . '/taxonomy-functions.php' );

/** WP_Term class */
require_once( ABSPATH . WPINC . '/class-wp-term.php' );

/** WP_Tax_Query class */
require_once( ABSPATH . WPINC . '/class-wp-tax-query.php' );

avec notamment la nouvelle classe wp-term qui renforce l’objet précédent décrivant les termes avec méthode…

A cela s’ajoute la nouvelle table termmeta qui va être très utile pour compléter la description d’un tag par exemple.

Il est encore trop tôt pour tirer les conséquences mais xili-language va continuer de tirer partie de ces nouvelles classes, functions et tables.

Pour le moment, xili-language fonctionne toujours 😉

Justin Tadlock vient de publier un article très complet pour les développeurs.

A suivre encore (de très près)…

une fonction souvent oubliée : is_active_widget()

is_active_widget() est une fonction souvent oubliée des développeurs qui insèrent de manière non sélective des éléments (js, css) dand le header de la page sans qu’un des widgets soient présents sur la page affichée.
Cette fonction est pourtant une bonne façon de remédier à ce défaut.

* @global array $wp_registered_widgets
 *
 * @param string $callback      Optional, Widget callback to check.
 * @param int    $widget_id     Optional, but needed for checking. Widget ID.
 * @param string $id_base       Optional, the base ID of a widget created by extending WP_Widget.
 * @param bool   $skip_inactive Optional, whether to check in 'wp_inactive_widgets'.
 * @return string|false False if widget is not active or id of sidebar in which the widget is active.
 */
function is_active_widget($callback = false, $widget_id = false, $id_base = false, $skip_inactive = true) {

 

S’il y a plusieurs possibles widgets d’un même type ($id_base) on peut faire un premier test :

if ( is_active_widget( false, false, 'xili_language_widgets') ) {
		//
		$insert_style = array();
		$styletext = array();
		if ( $widgets_xll = get_option( 'widget_xili_language_widgets' ) ) {
			foreach ( $widgets_xll as $key => $one_xll ) {
				if ( isset( $one_xll['flagstyle'] ) && in_array( $one_xll['flagstyle'],  array ('flagstyle', 'flagstyletext' ) ) ) {
					$insert_style[] = $key;

et ensuite si c’est nécessaire on peut affiner :

function xili_language_widgets_head_test ( $key,  $styletext ) {
	$widget_uid = 'xili_language_widgets-' . $key;
	$name = is_active_widget( false, $widget_uid, 'xili_language_widgets');
	if ( $name ) {
		printf('<!--- Xili-language list widget ID %s in %s -->', $key, $name ); // only active and visible in sidebar with $name
		$style_lines = '<style type="text/css">';

Ce 2e extrait est utilisé dans xili-language pour insérer si et seulement si un réglage de l’instance d’un widget le nécessite !

NOTE :

le premier paramètre est par défaut à false et reste un mystère (probablement lié à la compatibilité de version de WP) car il est testé comme un string alors qu’il s’agit d’un tableau contenant un objet et un string ?!?

A suivre

Le Customizer et le paramètre ‘show_in_nav_menus’ et les CPT et CT

Nouveau avec WordPress 4.3:
Au moment d’enregistrer une nouvelle taxonomie (custom taxonomy) ou un nouveau type de post (custom post type)

Si vous ne voulez pas voir des éléments inattendus dans la liste des items ajoutables du nouveau personnalisateur de menus dans la page (Apparence / Personnaliser) ‘theme customizer’ le paramètre show_in_nav_menus doit être réglé false !
Cette liste apparaît dans la 2e colonne quand dans le Theme Customizer un menu est sélectionné !
Le paramètre show_ui mis à false ne suffit pas !

Champ de thème : à la mode avec la page personnalisation

On connait les champs personnalisés attachés à chaque article, ils sont stockés dans la table wp_postmeta.
La nouvelle mode concernant l’utilisation de la page “personnalisation” (customize) du menu du thème actif fait renaître l’utilisation du tableau “Theme_mods” résultat de l’appel à la fonction get_theme_mods.
Plus directement, on peut accéder à un élément du tableau du thème actif avec les deux fonctions get_theme_mod et set_theme_mod (voir includes/theme.php de WP). Ce tableau est stocké dans la ligne theme_mods_twentyfifteen de la table wp_options ici pour le thème twentyfifteen.

Un thème comme zerif-lite utilise de nombreux champs de ce type à saisir par le webmestre pour, par exemple ajouter des champs dans un header ou d’une page d’accueil multi paragraphe. Le fichier inc/customizer.php contient une (grande) liste de ces champs ajoutés pour personnaliser le site.

get_theme_mod est une fonction qui permet de rendre une valeur par défaut si rien ne pré-existe dans la base.

Cette fonction est aussi filtrable. Si le champ est de type “string” nommé “sous-titre” et si on veut le traduire, on peut utiliser le filtre du nom “theme_mod-sous-titre“.

Si un thème utilise ces functions directement sans une fonction GETTEXT dans le thème, ce filtre sera utile pour faire de la traduction/adaptation dans un contexte multilingue. Via des fichers xml ou une détection adaptée, des gestionnaires de dictionnaire pour préparer les traductions iront détecter ces valeurs afin de préparer les fichiers de langue (.mo, .po).

M.

Etiquette remplace mot-clé

Sans crier gare, dans la traduction française de tag est passée de mot-clé à étiquette ! Est-ce bien ? En tout cas, cela ajoute de la précision à la façon de classer les articles ? Et cela précise le modèle de données : en effet, on range des articles dans des rayons (catégorie) et sur chacun on peut ajouter des étiquettes (marque, couleurs, composants…).
Pour le contexte multilingue, cela conforte aussi les choix faits dans la trilogie xili-language depuis 2009. Les grands rangements se basent sur les catégories (les rayons) où peuvent coexister des articles de langues différentes et les étiquettes (ex mots-clés) sont traduisibles ou non mais groupables par langue ou groupe sémantique (trademark,…) C’est l’objet de l’extension xili-tidy-tags.
NB : xili-language ne clone pas les catégories selon la langue mais en traduit l’intitulé et la description selon le contexte…

Multisite et taxonomie nouvelle ajoutée… quid ?

Dans WordPress multisite (network) – version 4.2.2 – avec la fonction dans le site n°3

switch_to_blog( 2 );

a-t-on vraiment basculé vers l’autre site n°2 pour lancer une requête (new WP_Query ( $query ) ;) incluant une nouvelle taxonomie (ici ‘domain’) ?

// extrait
'tax_query'   => array(
'relation' => 'AND',
	array(
	'field'    => 'term_id',
		'taxonomy' => 'category',
		'terms'    => array ('publication', 'evenement'),
		'operator' => 'IN'
	),
array(
	'field'    => 'slug',
	'taxonomy' => 'domain',
	'terms'    =>  array( 'aerien', 'sous-marin'),
	'operator' => 'IN'
	)
)

en fait, non, car la construction de $query a besoin de la déclaration de la taxonomie dans le site n°3 où est le code.
Comment s’en sortir ?
Il ne faut pas activer ‘en réseau’ l’extension qui déclare cette nouvelle taxonomie mais site par site et dans l’extension (qui crée la taxonomie) il faut prévoir de masquer celle-ci dans les sites où elle n’est pas utile
'show_ui' => ($current_blog->blog_id == 2 ) ? true :false,

En procédant de la sorte, on corrige les carences de switch_to_blog( 2 ); et il est donc possible sur le site n°3 d’afficher des listes résultant de requêtes complexes sur les données du site n°2.

thème enfant : after mais pas trop tôt !

add_action( 'after_setup_theme', 'twentyfifteen_xilidev_setup', 11 ); // called after parent

Petit retour sur le fichier functions.php d’un thème enfant (child thème) et le moment où il est mis en place (voir wp_settings en action) :

Le fichier functions.php du thème enfant est mis en place avant celui du parent, cela permet donc de remplacer des fonctions proposées par le parent et de les personnaliser dans le thème enfant. C’est ainsi qu’on voir ce type de lignes dans un thème parent bien écrit comme ceux fournis avec les versions de WordPress :

if ( ! function_exists( 'twentyfifteen_fonts_url' ) ) :
/**
 * Register Google fonts for Twenty Fifteen.
 *
 * @since Twenty Fifteen 1.0
 *
 * @return string Google fonts URL for the theme.
 */
function twentyfifteen_fonts_url() {

Revenons à l’action after_setup_theme qui par défaut à une priorité de niveau 10. Pourquoi la mettre à 11 ? Comme celle du parent est à dix (10), elle sera appelée en premier et celle du thème sera appelée ensuite. Le contenu de l’action du parent sera complété par quelques ajouts dans le contenu de l’enfant. Pas nécessaire de tout réécrire.
Cela permet par exemple d’annuler un filtre proposé par le parent comme dans cet exemple pour twentyfifteen in github

remove_filter( 'walker_nav_menu_start_el', 'twentyfifteen_nav_description');

Pour ce qui veulent continuer à en parler : rendez-vous au WordCamp Lyon ce 5 juin 2015.

esc_html avec add_query_arg : attention mais pas trop

En préparant et testant la nouvelle version 1.0 de xili-re-un-attach media, la redirection ne fonctionnait plus comme dans l’avant-dernière version. Pourquoi ?

Parce qu’aveuglément “pour la sécurité” selon les recommandations récentes de WordPress ! la fonction esc_html avait été ajoutée pour créer les liens de redirection utilisant add_query_arg…

ce qui donne : 

... post.php?post=274&action=edit&message=1

et non 

... post.php?post=274&action=edit&message=1

or la function wp_redirect() ne redirigait pas à la bonne page…

donc pas de esc_html quand on a un bon contrôle du lien notamment au sein du code !

M.