xili-language version 2.16.3 : quelques corrections et des préparations pour 2.17

Huit jours après la précédente, la mise de maintenance 2.16.3 corrige quelques messages (php notice) apparaissant dans de rares circonstances.
La liste des widgets s’enrichit d’un widget pour l’affichage correcte du dénombrement des catégories selon la sous-sélection liée à la langue courante. L’affichage des nombres a nécessité un nouveau ‘walker’ et de cache associé. Ce widget doit être (pour le moment) enregistré par l’auteur du thème. Bien sûr, comme il s’agit d’un nouveau widget dénommé ©xili Categories, vous devez l’activer via le menu Apparance/Widgets (et donc supprimer celui que vous aviez installé précédemment Categories widget) 😉
exemple de code à ajouter dans functions.php

Le widget “Archives” (qui donne les archives selon un tri mensuel) lui aussi affiche des mois corrects selon la langue s’il y a des archives. Pour vider le cache précédent, il est conseillé d’ajouter un article.

Mise à jour de maintenance pour la trilogie xili-language !

Les trois extensions pour gérer un site multilingue ont été mises à jour :

  • xili-language : version 2.16.2 (corrige une alerte si les catégories sont affichées en mode “dropdown” )
  • xili-tidy-tags : version 1.10.1 (nettoyage du code source en cours)
  • xili-dictionary : version 2.10.1 (ajout de la possibilité de gérer les fichiers po/mo dans le dossier WP_LANG_DIR – wp-content/languages)

C’est l’occasion aussi pour parler la nouvelle présentation des statistiques dans l’entrepôt des extensions qui est bien commentée dans cet article de Brian. J’en profite pour signaler ce qui n’a pas été vu : les stats “Active Versions” sont fausses et mal triées si notamment le deuxième indice de la version contient au moins 2 chiffres. Une déclaration de bug #912 a été ouvert sur le tracs ! MAJ : La correction a été effectuée en 24h 😉 Le tri est maintenant correct !

Merci aux contributeurs européens de cette semaine : Emmanuel, Gabriel,…

xtt Active Versions
Active Versions de xili-tidy-tags

La trilogie xili-language mise à jour pour WordPress 4.1 “Dinah”

La sortie de WordPress 4.1 “Dinah” a été l’occasion depuis quelques semaines de revoir l’ensemble des extensions liées à la création d’un site multilingue avec xili-language (v.2.16.0), xili-tidy-tags (v1.10.0) et xili-dictionary (2.10.0) et de créer (comme exemple) le thème enfant multilingue TwentyFiften-xili et son site de démonstration.

Les modifications les plus importantes sont pour :

  • xili-language
    la prise en compte des fichiers .mo qui sont déposés dans le dossier wp-content/languages/themes s’il n’y a pas de fichiers .mo dans le dossier du thème lui-même.
  • xili-tidy-tags
    la correction d’une modification des assignations de langue quand on créait des groupes (alias) de mots-clés de même sens dans des langues différentes.
  • xili-dictionary
    Faciliter la récupération des termes liés aux commentaires (inclus dans le fichier wp-includes/comment-template.php) et rendre plus aisée donc leur traduction. En effet, WordPress, qui est de base traduisible mais pas multilingue, lie ces textes liés au formulaire de commentaires à la langue du tableau de bord uniquement et non au thème (qui a son propre textdomain).

Les améliorations du noyau (core) de WordPress ont été prises en compte (requête complexe). La réalisation du thème enfant TwentyFifteen-xili donne l’occasion de présenter un exemple avec différents astuces.

M.
2014-12-19

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.

xili-language 2.15.2 : mise à jour pour WP 4.0

xili-language version 2.15.2 mise en ligne ce soir est avant tout une mise à jour technique pour WordPress 4.0 tout en restant compatible avec la version précédente (disparition de la constante WPLANG).
Les tests ont été réalisés sur différents sites, par exemple celui-ci avant et après la mise à jour 4.0.
Sur un site vierge 4.0, vide de tout article, xili-language a été installée, trois langues activées et l’import xml d’un autre site multilingue s’est passé sans encombre. Un article sera publié prochainement car, exporter-importer un site web à langues multiples demande quelques précautions.
Le forum bbPress peut comme précédemment être actif en plusieurs langues…
M.

xili-language v. 2.15.1: La possibilité pour le développeur de déclarer ses drapeaux

xili-language v. 2.15.0 a introduit la fonction add_theme_support ( 'custom_xili_flag') pour ouvrir l’utilisation de drapeaux présents dans la bibliothèque Médias.
En ajoutant le paramètre array ($args), xili-language v. 2.15.1 ajoute un moyen de déclarer des drapeaux présents par défaut dans le dossier du thème. Une façon élégante de proposer des images/drapeaux adaptés au design et au graphisme du thème. Dès lors plus besoin de mettre ces éléments dans la bibliothèque Médias sauf si le webmestre veut introduire les siennes.

Exemple de code à mettre dans une function appelée par un add_action ‘after_setup_theme‘ (priority set to 12)

%2$s est utilisé dans ‘path’ parce que les png sont dans le theme enfant pour cette exemple. Ici, faute de test, on suppose que tous les png sont présents. (%1$s pointe sur le thème parent)

Pour présenter divers exemples, twenty fourteen-xili est géré exceptionnellement dans l’extension xili-language elle-même en n’utilisant que la liste des langues disponibles et en testant la présence de png dont le nom est basé sur le slug (fr_fr.png…). La dernière version de twenty thirteen-xili utilise une autre approche.

A suivre.

xili-language v. 2.15: une option pour gérer les drapeaux du sélecteur de langue !

xili-language version 2.15 introduit des nouvelles options pour webmestres et développeurs de thèmes.

Même si l’usage de drapeaux pour sélectionner une langue a ses limites (*), xili-language v. 2.15 ajoute une option qui facilite l’ajout des drapeaux car jusqu’à maintenant, il fallait utiliser la CSS pour substituer l’image choisie au nom de la langue.

(*) une même langue est souvent pratiquée dans plusieurs pays!

Quelques exemples sont livrés dans les thèmes enfant des 5 thèmes de base livrés avec WP (comme twenty fourteen xili qui est ici même en démo). Pour cette option introduite dans la v2.15, une nouvelle version de ces thèmes enfant est mise en ligne.

Grâce aux outils disponibles dans le noyau WordPress et leur intégration dans xili-language, on dispose maintenant :

  • une façon facile d’ajouter une image (drapeau) pour une langue,
  • une façon facile d’assigner une image (drapeau) à une langue,
  • un nouvel interface dans le menu Apparence pour ajuster les paramètres,
  • et un processus automatique pour générer les lignes CSS dans le header de la page HTML.

Les développeurs vont trouver:

  • un nouveau add_theme_support() dénommé ‘custom_xili_flag’,
  • des nouveaux filtres pour personnaliser leurs thèmes,
  • un nouveau shortcode pour pointer le drapeau d’une langue donnée (SRC).

Quelques copies d’écran : Extrait de la liste des médias – une image est affectée comme flag (drapeau) (la seconde comme header image)

flag example
exemple de drapeau (flag)

L’extrait ci-dessous montre l’option principale (drapeau ou nom), une liste des drapeaux téléchargés et disponibles dans la bibliothèque média et quelques lignes très techniques pour affiner les réglages de la CSS. Pour les 5 thèmes de base (comme 2014), des valeurs par défaut sont proposées:

xili-language flag settings
Réglages des drapeaux (flag) xili-language

Avantages:

  • le choix des images drapeaux est libre (et modifiable), pas nécessaire de prédefinir un nom ou un type de fichier identique (jpg, png, …)
  • L’extension choisit la bonne image qui a été téléchargée et assignée à la langue cible.
  • En utilisant les filtres ad’hoc, les développeurs peuvent régler les lignes de style par défaut. Voir le thème responsible-xili comme exemple.

Inconvénients:

  • encore plus de lignes de code dans les sources de l’extension !

Une nouvelle extension pour gérer l’attachement des médias : xili re/un-attach media

Cette huitième extension déposée sur le dépôt WordPress s’appelle xili re/un-attach media.
Elle résulte d’un agacement à propos de l’obligation de supprimer le media pour le détacher d’un article et l’impossibilité de faire un ré-attachement.
Après une recherche sur les extensions existantes et examen de leurs sources soit anciens, soit non construit en mode objet (Davidn.de), soit trop complexes, le défi est lancé : faire une extension a minima en OOP, sécurisée (nonce), documentée en ligne (Onglet Aide, Pointeur/PostIt) avec réutilisation maximum des composants disponibles dans WordPress notamment le javascript media.

Les deux nouvelles actions sont disponibles sur la liste

mais aussi dans une “metabox” dans l’écran pour gérer un média.

Etat des attachements en mode single edit
Etat des attachements en mode single edit

Elle est testée pour WP 3.8.3+ et aussi 4.0-alpha…

Lien vers le dépot Github [Github by dev.xiligroup].

xili-re-un-attach-media est sur le dépot WP plugin repository.

un site internet multilingue avec WordPress et xili-language