Here With Me

Le blog technique d'Amaury Balmer qui parle de technologies open-source, mais surtout de WordPress !

14 septembre 2012
par Amaury
18 Commentaires

Tester rapidement et efficacement un hébergement pour WordPress : phpwpinfo()

À chaque nouveau projet à BeAPI c’est la même chose, on conçoit un nouveau site, on le développe, on le teste, et puis vient le moment fatidique où il faut le mettre en ligne.

Généralement, nos clients travaillent avec un prestataire « infogérant » ou leur DSI et c’est là que les complications arrivent.

Il faut dans un premier temps fournir les prérequis nécessaires à WordPress, et ensuite il faut vérifier que ces prestataires aient bien faire leur job.(chose qui arrive assez rarement !)

Il faut alors parcourir de façon méthodique le PHPinfo() et les variables MySQL afin de s’assurer que tout est correctement configuré !

Pour ma part, je vérifie plus de 50 points différents qui touchent les sujets suivants :

  • Configuration Apache
  • Modules Apache
  • Configuration PHP
  • Extensions PHP
  • Configuration de MySQL
  • Envoi d’emails

Ayant constaté le côté méthodique et répétitif de la chose, j’ai décidé de faire un script PHP dédié à ces tests. Il s’appelle donc phpwpinfo, c’est open-source et sur Github.

Aperçu de phpwpinfo

Aperçu de phpwpinfo

Le test couvre beaucoup plus de points que les 2 prérequis de base de WordPress (Version 5.2 de PHP et 5.0 de MySQL)

Il permet globalement de s’assurer que WordPress va bien tourner, en ayant mis toutes les chances de son côté, en ce qui concerne les optimisations PHP, MySQL et HTTP.

C’est un projet libre, je ne pense pas avoir couvert tous les tests possibles, c’est pourquoi j’attends avec impatience les premiers « pull request » dans Github afin de parfaire l’outil.

Bon test !

13 mai 2012
par Amaury
19 Commentaires

Benchmarks WordPress 3.3 et 3.4 : Impact de la traduction sur les performances

Configuration

  • Dotdeb PHP 5.3, Apache 2.2 & MySQL 5.5
  • No extra PHP extension/Apache module
  • APC opcode cache, no static cache, no deflate
  • French/American English versions of WordPress
  • TwenyEleven WordPress theme

Zero tuning on conf file, only default configuration from APT installation.

Benchmarks

J’utilise le logiciel SIEGE pour effectuer des benchmarks rapides
siege -b -c 100 -r 10 http://mywebsitebenchark.com

Le benchmark appelle le site internet http://mywebsitebenchark.com, en éxécutant 100 connexions simultanées, le test est lancé 10 fois à la suite.


Profiling

Profiling de l’application via XHprof avec le cache opcode APC, pour les versions françaises « FR », anglaises natives « US », et françaises avec le plugin 001 Prime Strategy Translate Accelerator « FR_Plugin »




Conclusion

Ces quelques tests ont tendance à montrer 2 choses :

  1. Le mécanisme d’internationalisation de WordPress coûte cher en CPU et en mémoire. Un WordPress français est presque 2.5 fois plus lent qu’un WordPress en langue native
  2. La segmentation des fichiers PO à venir dans WordPress 3.4 améliore légèrement la situation mais sans être révolutionnaire. On économise 3mo lors de l’exécution de WordPress. WordPress 3.4 FR est environ 35% plus rapide que WordPress 3.3 FR.

Par ailleurs, le plugin 001 Prime Strategy Translate Accelerator propose un concept intéressant en ajoutant la traduction de WordPress dans le cache user de APC. C’est donc un moyen innovant et intelligent pour améliorer les performances sans hacker le core de WordPress.

Le seul défaut que je trouve à ce plugin, c’est qu’il fait appel directement aux fonctions de APC, au lieu d’utiliser le cache objet de WordPress, ce qui lui permettrait d’être compatible avec un grand nombre de technologies (Xcache, Memcache, etc.)

Le cache objet de la traduction est peut être un concept à proposer dans le core, avis aux amateurs de patch :)

Dernière précision : WordPress 3.4 US est aussi rapide que WordPress 3.3 US out of the box.

18 septembre 2011
par Amaury
5 Commentaires

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
7 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
23 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
11 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
7 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.