Here With Me

Blog personnel et technique, Blog technique et personnel, Blog avant tout.

18 septembre 2011
par Amaury
1 Commentaire

Quelques outils CLI pour WordPress

Je continue mon expérimentation de Github en partageant sur un dépôt 2 scripts pour WordPress.

https://github.com/herewithme/wordpress-cli-tools

Ces 2 scripts peuvent être exécuter en mode CLI, c’est-à-dire en ligne de commande, ils permettent de régénérer les miniatures de WordPress, et de modifier l’ensemble des liens vers les images de WordPress vers leur page attachment associé.

Par ailleurs, je vais progressivement passer tous les plugins open-source que je propose vers Github à la place des dépôts SVN/Redmine. En espérant que cela augmente le nombre de feedbacks et de patchs associés.

18 septembre 2011
par Amaury
6 Commentaires

Les primaires citoyennes (socialistes) d’un point de vue CMS

Jeudi 15 septembre se déroulait le premier show TV consacré à la primaire citoyenne organisée par le PS.  Cela m’a rappelait les primaires républicaines aux États-Unis, et je me suis posé la même question que les blogueurs outre-atlantique, quels sont les outils utilisés par chacun des candidats pour réaliser le site web !

Et le grand gagnant de cette primaire est Drupal.

Sur les 6 candidats, 3 ont choisi Drupal, 2 WordPress et seul Manuel Valls a fait le choix de SPIP.

Drupal ou WordPress pour un site politique ?

Bien entendu les candidats n’ont jamais entendu parler du mot CMS, ce sont donc les agences web chargées de réaliser les sites web de cette compagne qui sont responsable de ces choix.

Personnellement, je ne suis pas du tout étonné de voir Drupal remporté cette primaire, cela représente tout à fait l’état du marché des CMS open-source en France, Drupal leader, WordPress outsider, SPIP en déclin.

Pourtant lorsque l’on regarde les fonctionnalités en place sur chacun des sites, on se rend bien compte que WordPress répond parfaitement à ces besoins et que l’utilisation de Drupal est un choix discutable, car même s’il reste un outil très performant dans bien des domaines, WordPress le surpasse largement au niveau de l’ergonomie et la facilité d’utilisation/de formation.

Or lorsque l’on réalise un site pour un candidat d’une compagne politique, on sait pertinemment que le site a une durée de vie limitée et que la facilité d’utilisation est primordiale pour fluidifier les publications par l’équipe de communication. Le choix de WordPress est de fait ultra légitime.

Les blogs des candidats

Pour l’anecdote, 2 candidats disposent d’un blog à temps plein en dehors des périodes électorales, Arnaud Montebourg et Manuel Valls, et ces derniers utilisent bien entendu WordPress.

15 août 2011
par Amaury
22 Commentaires

Gros nettoyage en vue dans le référentiel de plugins de WordPress.org !

Matt vient d’annoncer, dans l’une de ses fameuses conférences « State of the Word », que toutes les extensions n’ayant pas été mises à jour lors des 2 dernières années seront masquées du référentiel.

Les raisons à ce changement sont multiples, Matt évoque des problèmes de conception, de sécurité, de compatibilité de ces plugins avec la version courante de WordPress. Je trouve qu’il a entièrement raison, le référentiel est devenu un véritable champ de ruine de plugins fait à un moment T et jamais mis à jour.

C’est d’ailleurs pour cette raison que je demande toujours à mes clients de faire valider les plugins qu’il souhaite rajouter à leur installation une fois un projet terminé. Cela permet d’éviter d’installer des plugins vieux comme le monde.

Par ailleurs, je trouve que le référentiel des plugins fait preuve d’un grand laxisme comparé à celui des thèmes. Je pense que les plugins devraient passer un stresstest afin d’être publiés sur le référentiel.

Je pense aux tests suivants :

  • Internationalisation du code
  • Sécurisation du code avec les API de WP
  • Pas de notice avec la constante WP_DEBUG à true
  • Plugin développé en anglais uniquement

Cela permettrait d’augmenter sensiblement le niveau de qualité des plugins sur le CMS WordPress.

Au 15 aout 2011, le référentiel compte 15 741 plugins, je pense qu’une fois cette amputation réalisée le nombre de plugins WordPress passera sous la barre des 10 000 plugins. Et je pense que si un stresstest était mis en place, alors on descendrait à 5000 plugins, des chiffres plus raisonnables non ?

14 août 2011
par Amaury
10 Commentaires

N’appelez jamais une taxinomie de WordPress « type »

C’est dommage, mais l’API des taxinomies de WordPress ne possède pas de liste de mots clefs interdits lors de l’enregistrement. De fait, il est tout à fait possible d’appeler une taxinomie « page », « post », « category ». Parfois, cela pète dès l’enregistrement de la taxinomie, alors on change rapidement le nom sans perdre de temps. Parfois, c’est beaucoup plus vicieux et il faut passer beaucoup de temps à debugger pour trouver l’origine.

C’est justement le cas du mot « type », il ne faut JAMAIS l’enregistrer comme nom de taxinomie pour la simple et bonne raison que cela va faire bugger le gestionnaire de médias de WordPress. Une fois la taxinomie, ce dernier ne retournera aucun média dans la liste affichée dans les lightbox. En effet, le gestionnaire utilise le mot clef « type » pour différencier les vidéos/images/sons/documents. WordPress intercepte également ce mot clef pour limiter les résultats de la WP_Query qui récupère les médias à ceux classer dans la taxinomie « type », pour le terme « image », etc.

Conclusion, n’hésitez pas à choisir des noms de taxinomies assez longs pour éviter les effets de bords !

9 août 2011
par Amaury
6 Commentaires

Simplifier l’usage de la console d’administration avec les custom post types de WordPress

Avec l’apparition des types de contenus personnalisés (custom post types /CPT), les consoles d’administration de WordPress ont vu fleurir des tonnes de menus en plus dans la console d’administration. Si bien qu’un site web, un peu complexe, utilise désormais 4 à 5 CPT.

Généralement, les développeurs se contentent de leur attribuer l’icône par défaut de WordPress, ou mieux il laisse le champ complètement vide pour ne proposer aucune icône pour ces types de contenus. Il faut dire que trouver une icône, la redimensionner, proposer une version active/inactive, c’est beaucoup de boulot !

Mais ce que l’on oublie c’est que les icônes ne sont pas uniquement là pour décorer, elles permettent de mémoriser rapidement l’emplacement des fonctionnalités dans l’administration.

Voici un petit exemple entre 2 menus de la console d’administration de WordPress. Si l’on met de côté les différences graphiques liées à WordPress 3.2, on constate :

  • À gauche, il s’agit du menu classique de WordPress, l’ordre n’est quasiment pas changé, les types de contenus n’ont pas d’icônes.
  • À droite, chaque type de contenu possède une icône distinctive et l’ordre est complètement personnalisé. Des séparateurs sont présents afin de grouper les éléments du menu.

Les différences entre ces 2 menus ne portent que sur des détails, mais c’est précisément ces détails qui  différencient une console d’administration compréhensible et pleinement intégrée dans l’esprit du CMS à une administration fouillis.

Pour arriver à un tel résultat, peu ou pas de développement sont nécessaires.

La première chose à faire est de trouver des icônes, je vous recommande l’énorme pack d’icônes  »Fugue » de Randy Jensen, elles sont déjà formatées pour les types de contenus de WordPress.

Une fois que vous avez sélectionné vos icônes, il suffit d’ajouter le code proposé sur ce même site pour ajouter les règles CSS nécessaires dans WordPress. Si vos types de contenus sont intégrés dans votre thème, placez le code des icônes également dans le thème, sinon faites un plugin.

Pour modifier l’ordre du menu, et grouper les éléments selon le besoin du client, je vous recommande l’utilisation du plugin Admin Menu Editor, il est disponible sur le référentiel officiel et permet de configurer le menu en glisser-déposer.

Plugin Admin Menu Editor

A noter qu’il existe une version pro de ce plugin, elle permet de réaliser des exports/imports de la configuration du plugin.

22 février 2011
par Amaury
5 Commentaires

Désactiver rapidement les 2 taxonomies par défaut des articles de WordPress

Dans WordPress, il n’existe pas de fonction pour désenregistrer des taxonomies, alors pour désactiver les taxonomies par défaut, il faut modifier directement le tableau de taxonomie de WordPress.

Ce qui donne le code suivant à insérer dans le fichier functions.php de son thème, ou bien dans son plugin.

<?php
add_action('init', 'remove_default_taxos', 2 );
function remove_default_taxos() {
global $wp_taxonomies;
unset($wp_taxonomies['category'], $wp_taxonomies['post_tag']);
}
?>

WordPress gère très bien la désactivation des taxonomies par défaut, et les différentes fonctionnalités propres aux catégories et aux tags sont proprement désactivées dans la console d’administration, comme dans les vues listes ou édition.

15 février 2011
par Amaury
31 Commentaires

Simple Punctual Translation, un plugin pour proposer ponctuellement des traductions sur votre site

À BeAPI, il nous arrive fréquemment que l’on nous demande de réaliser des sites multilingues.
Parfois, il s’agit de traduire l’intégralité du site, mais bien souvent il s’agit surtout de traduire les pages statiques de WordPress, ou certains articles très populaires.

Face à ce besoin plutôt basique, il n’existe pas de solution magique sur WordPress…

Les solutions existantes

Pour faire court, on peut utiliser comme plugin :

  1. WPml
  2. Qtranslate
  3. Global Translator

WPML

Ce plugin est le plus complet pour gérer les sites multilingues sous WordPress.
Il propose de traduire tout : contenus, taxos, menus, widgets. Il permet aussi une traduction de son site par des personnes extérieures, bref.

Il fait plein de choses. Le problème se résume en 3 points :

  1. On ne peut pas désactiver la traduction sur les articles WP
  2. Le code source est imbuvable, pourri et j’en passe. (il m’est arrivé de désactiver des fonctions PHP complètes, le plugin fonctionnait mieux…)
  3. Il vient récemment de passer en mode payant

De fait, à l’agence dès que l’on peut, on s’en passe bien volontiers !

Qtranslate

Alternative qui a l’avantage de proposer moins de fonctionnalités que WPML, mais avec une interface sympathique bien qu’imposant une contrainte en nombre de langues.
(Chaque langue étant affiché dans la même page d’édition que le contenu initial, avec un basculement via des onglets)

Mon principal reproche concerne l’architecture du plugin, tout stocker dans les mêmes champs, et insérer des balises XML pour différencier les langues n’est pas une méthodologie viable.
Par exemple, impossible de désactiver le plugin sans afficher tout le contenu en 3 triples. (si votre site possède 3 langues)

Global Translator

La traduction « low-cost » qui consiste à proposer une version traduite par les soins de Google, Babel Fish, Promt ou FreeTranslations de tout son site. Bien entendu le résultat est catastrophique la majorité du temps, et il n’est pas possible de proposer sa traduction. Bref, une solution pas exploitable en entreprise, mais qui très utile dans le cadre d’un blog personnel pour générer du trafic international. (mais non qualifié)

Notre solution : Simple Punctual Translation

Avec l’équipe de développement de BeAPI, on s’est mis en mode réflexion, on a imaginé toutes les fonctionnalités que l’on peut attendre d’un plugin open-source, l’architecture que l’on pourrait créer, l’impact sur les développements. Bon, je ne vous cache pas qu’on s’est bien aidé de Drupal pour lister toutes les fonctionnalités multilingues à prévoir.

Et puis face à un chantier aussi grand, on s’est dit qu’on ferait bien de commencer par une solution allégée de plugin multilingue. On a listé le besoin de base rencontré à l’agence, soit traduire certains types de contenus de WordPress et on a commencé le développement de Simple Punctual Translation.

Comme son nom l’indique, ce plugin permet de faire des traductions ponctuelles sur son site WordPress, ponctuel dans le sens nous n’allons traduire que certaines pages du site.

L’architecture retenue pour le développement est en pleine cohérence avec WordPress 3.0, nous avons créé un type de contenu traduction, et nous avons créé une taxonomie pour les langues du site. Nous avons personnalisé la console d’administration de WordPress pour proposer les fonctionnalités de traduction, un peu d’AJAX pour rendre l’interface pratique. Enfin, nous avons créé un widget affichant les langues disponibles pour le contenu actuellement chargé. Un rôle traducteur est automatiquement créé avec le plugin, il permet à un utilisateur de ce rôle d’uniquement pouvoir créer et gérer des traductions.

Les fonctionnalités utilisateurs se résume en la possibilité de switcher entre une et plusieurs langues sur la vue single d’un contenu. Ainsi, une page peut être traduite en X langues.

Le plugin propose les réglages suivants :

  • Insertion automatique des langues disponibles à la fin d’article
  • Réécriture des URLs soit via un paramètre « lang » dans l’adresse ou via un préfixe en début d’adresse :
    • http://www.herewithme.fr/contenu/?lang=de
    • ou http://www.herewithme.fr/de/contenu
  • Activation des traductions sur les post types de son choix
  • 2 modes pour le mécanisme de traduction, que je détaillerai ci-dessous.

Bien entendu, le plugin est disponible via le référentiel des extensions WordPress.

Moteurs de traduction

Pour ce plugin, nous n’avons pas voulu imposer une architecture définie pour le moteur de traduction, alors nous avons proposé un mode automatique ou manuel.

Mode automatique

Le mode automatique est plutôt destiné au grand public, car aucune modification n’est nécessaire dans le code source. Le principe est le suivant, lorsqu’on navigue sur la version allemande d’une page, WordPress récupère les données originales de la page, et notre plugin vient automatiquement injecté le contenu allemand de 3 champs, le titre, le contenu et l’extrait.

Cela veut dire que la version allemande en mode automatique conservera, si votre thème l’affiche, la date de publication, les commentaires, l’auteur, les tags et les catégories de l’article original.

Ce mode suffit largement à un usage basique du plugin de traduction, sur des types de contenu natifs, il est compatible à 99% sur les installations WordPress existantes.

Mode manuel

Ce second mode est nettement plus puissant que le premier. Le mode manuel ne modifie aucune donnée de la requête initiale de WordPress, si aucune modification n’est portée sur le thème, votre contenu ne sera même pas traduit ! Pour switcher de langue, nous nous sommes inspirés des fonctions de WordPress Mu permettant des switcher de blogs, soit switch_to_blog() et restore_current_blog().

Et nous avons créé 2 fonctions switch_to_language() et restore_original_language().

La première fonction switch_to_language() permet de basculer le contenu dans la version traduite, tandis que la deuxième fonction permet de restaurer la langue originale du contenu.

Exemple :

<?php
the_title(); // Title in English
switch_to_language();
 the_title(); // Title in French
restore_original_language();
the_title(); // Title in English
?>

Ce couple de fonctions permet aux développeurs d’être extrêmement précis sur les champs à traduire. Ce mode à mon sens, doit être largement privilégié, car il est propre, il n’interagit pas avec la requête initiale de WordPress. Néanmoins, il y a quelques défauts comme :

  • Le titre HTML de la page n’est pas traduit
  • Les plugins de fil d’ariane ne prennent pas en compte la traduction

Ce sont principalement des défauts concernant l’aspect SEO, et effectivement sur cette première version du plugin nous n’avons travaillé que l’aspect fonctionnel. Nous comptons sur les retours de la communauté pour améliorer le plugin…

Le mot de la fin

N’hésitez pas à tester ce plugin et nous faire vos retours sur le site redmine du projet.

Dernière précision, ce plugin a été développé sur WordPress 3.1, mode WP_Debug activé, il est rétro-compatible 3.0.

Pour conclure, il n’est pas compatible PHP4. (en fait je n’en sais rien, mais pour tout vous dire, je m’en fous royalement)

Le plugin est image :