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 ?

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 :

Contrairement à WordPress 3.0, la version 3.1 se doit d’avoir un temps de développement court, les évolutions envisagées seront donc rapides, et il n’y aura pas de gros projets intégrés.

L’objectif de date pour la sortie finale de WordPress 3.1 est prévu pour mi-décembre 2010.

Cette version va avant tout privilégier les évolutions sur l’interface, la qualité et les performances du code et il n’y aura pas de modification sur le schéma. L’avis de l’équipe est de réserver les évolutions majeures pour WordPress 3.2, et ainsi produire un code de qualité en PHP5.

Donc première chose à retenir : pas de modification de schéma et pas de nouvelles API importantes.

Ce que ne contiendra pas WordPress 3.1

La refonte des médias. Une mise à jour importante du gestionnaire des médias a été envisagée par l’équipe de dev, c’est aussi l’une des demandes les plus récurrentes de la communauté. Il ne changera pas pour la simple et bonne raison que le code en question est assez tordu et qu’il serait regrettable de développer quelque chose en PHP4 alors que WordPress 3.2 sera compatible PHP5 uniquement.

De plus, c’est un chantier qui demandera du temps, qui imposera des modifications sur le schéma de la base de données et sur l’interface utilisateur. De fait, c’est un chantier couteux en temps.

Pour WordPress 3.1, la seule évolution possible sur le gestionnaire de médias sera l’envoi de fichiers HTML.

L’autre point important qui ne sera pas modifié dans WordPress 3.1 concernant la gestion de widgets. En effet, le filtrage des widgets par vue article/page/catégorie ne pourra être travaillé que dans WordPress 3.2.

En attendant, les plugins proposent des solutions appréciables.

Les fonctionnalités probables de WordPress 3.1

1. Des évolutions prévues sur l’API de taxonomie afin d’effectuer des requêtes avancées. WordPress 3.0 avec les custom types et les custom taxonomies a radicalement changé la façon de penser un site WordPress. L’API des taxonomies évolue logiquement pour répondre à toutes les attentes.

2. Une refonte importante des rôles/permissions est demandée par certains membres de l’équipe WordPress, pour la version 3.1, une première version de l’API sera proposée avec des fonctions permettant de travailler plus facilement sur les utilisateurs. À l’heure actuelle, les requêtes SQL « maison » priment encore dans ce domaine.

3. Une nouvelle fonctionnalité est également envisagée, il s’agit des liens internes. Autrement dit, la possibilité de créer des relations entre les contenus de WordPress. Il s’agit de la principale évolution à mes yeux de WP 3.1 !

Il fut un temps où seuls les articles relatifs permettaient de créer des liens entre les contenus, désormais il existe plusieurs plugins permettant de créer manuellement des liens entre le contenu (comme mon plugin Relation Post Types). Cette fonctionnalité est en vive discussion sur le trac.

4. Les pages de l’administration vont être largement AJAXifié avec quelques modifications mineures d’interface. La modération des commentaires sera également revue.

5. La barre d’administration avec menu déroulant. Très utile pour les plateformes de sites, buddypress, la barre d’administration semblable à WordPress.com fera probablement son apparition. Mais comme tout le monde n’est pas d’accord, la fonctionnalité restera peut-être sur la forme d’un plugin. (le plugin de Viper007Bond gère cela très bien pour le moment.)

6. Quelques simplifications et nettoyages de l’interface à travers toute l’application, et principalement le multi-site. Des pistes de recherche pour l’élaboration d’un tableau de bord personnel à la place du tableau de bord générale sont menées par Ryan. Ces modifications pourront être publiées dans WordPress 3.2 selon le planning.

7. Quelques corrections à prévoir sur l’API des custom post types.

8. Modification de l’interface de la gestion de thèmes par la version de WordPress.com. Cette dernière est plus efficace, plus légère, supporte la recherche, etc. C’est une étape indispensable pour les personnes ayant un WordPress MS avec beaucoup de thèmes.

9. Les templates de pages pour les articles. Afin de pouvoir supporter des modèles comme les pages)

10. La fonctionnalité QuickPress sera disponible à travers une fonction afin de pouvoir afficher facilement un formulaire sur le thème utilisateur.

Le planning

La date de publication ne devrait pas dépasser le 15 décembre pour ne pas interférer avec les vacances.

• 9 septembre : Confirmation du planning
• 15 octobre : feature freeze, pas de nouvelles fonctionnalités ajoutés dans le code
• 1er novembre : primary code freeze, fin de grands changements dans le code PHP
• 15 novembre :période de béta, plus d’amélioration, uniquement de la correction de bugs.
• 1 décembre : string freeze, traduction !
• 15 décembre : publication de WordPress 3.1

Alors, lorsque j’ai appris le lancement de VaultPress, je me suis dit dans un premier temps : chouette un plugin améliorant la sécurité de WordPress, mais après avoir lu et visionner la vidéo de présentation, j’ai compris qu’il ne s’agissait que d’un plugin de backup automatique des données, alors effectivement on peut se poser la question de l’intérêt de ce service pour les personnes ayant un serveur dédié, mais sur un mutualisé milieu/haut de gamme et/ou pour un blog sensible le service peut s’avérer intéressant.

J’ai donc décidé de postuler à l’inscription de la béta, une première fois pour mon blog perso, sans réussite. Et une seconde fois, pour le site WordPress Francophone, et bingo, 5 jours après je reçois la fameuse invitation permettant de s’inscrire au service !

Lors de l’inscription au service, on vous propose 3 niveaux de service, le basique qui comprend toutes les fonctionnalités de backup, le niveau premium qui offre du support technique en plus et enfin un niveau entreprise disponible après contact pour des services plus personnalisés, audit du code, etc. Le service basique est facturé 15$/mois, tandis que le service premium est facturé 40€/mois.

Dans le cadre de WordPress Francophone, j’ai choisi l’abonnement à 15$/mois afin de tester à moindre coût le service.

Le plugin

Une fois payé, on vous propose de télécharger une extension à installer sur le blog WordPress de votre choix. Une fois, le plugin installé et activé, un menu VaulPress apparait dans le menu de la console d’administration et permet de voir l’avancement de la sauvegarde du blog sur les serveurs de VaultPress.

Le backup se fait en arrière-plan, il n’est pas nécessaire de se connecter à WordPress ou de laisser une fenêtre du navigateur pour que le transfert se fasse. Le transfert initial est assez long, tout dépendra du nombre d’articles et de commentaires, mais surtout tout dépendra de la quantité de pièces jointes.

Dans le cadre de WordPress Francophone, j’ai activé le plugin le soir à 21h, le lendemain tous les fichiers avaient été synchronisés.

Une fois les fichiers complètement synchronisés, on peut observer un tableau de bord VaultPress qui nous affiche les informations principales, nombres d’articles, commentaires, termes, révisions, médias, etc. On peut également trouver le nombre de copies du blog. (ici 40)

Le service

Maintenant que nous avons passé en revue les pages du plugin sur l’admin WordPress, nous allons voir les fonctionnalités du site VaultPress.com. La page de connexion, bien que stylé VaultPress nous rappelle que WordPress n’est jamais très loin…

Pour se connecter à VaultPress, il faut posséder un compte WordPress.com, ce dernier vous sera demandé lors de l’inscription initiale, vous devez alors saisir vos identifiants WordPress.com.
Une fois connecté, on tombe sur un tableau de bord qui contient tous les sites protégés par VaultPress, ici il n’y a que WordPress Francophone.

Le statut affiche la dernière mise à jour de la base WordPress avec VaultPress, ici on peut voir qu’il s’agit du plugin du compteur de vues utilisées sur WordPress Francophones. Le menu propose de voir l’intégralité des backups de votre site, le log d’activité des sauvegardes ainsi qu’un formulaire de contact.

La page « Backups » nous propose de compacter, d’archiver et de télécharger l’ensemble des fichiers et la base de données de WordPress pour chaque backup réalisé. Ainsi, il est possible de télécharger n’importe quel backup de votre blog, l’intérêt majeur, c’est qu’en cas de pertes de données sur votre serveur, vous pouvez récupérer les fichiers à toutes les dates, et surtout les dernières données grâce à la synchronisation en temps réel.

La page « logs » retrace toutes les modifications apportées sur votre installation WordPress, ajout d’un article, d’un commentaire, d’un méta via un plugin, etc. bref tout est enregistré !

Conclusion

La conclusion est difficile. Le service est efficace et fonctionne très bien sur un serveur mutualisé comme Infomaniak. Pour les personnes possédant un dédié, un backup automatique et incrémentiel de la base de données et des fichiers sur 2 lieux de stockage me paraissent largement suffisant…

Alors, je ne sais pas trop… Pour qui ?

Les personnes ayant de « gros blogs » sont bien souvent sur des serveurs dédiés et/ou infogérés, dans un tel cas la backup serveur me parait suffisante…
Les personnes sur des hébergements mutualisés seront-elles prêtes à mettre de l’argent pour un service de backup ? Au prix proposé, on n’est pas loin d’un serveur virtualisé de base…

Mon avis est partagé sur l’intérêt d’un tel service… et vous ? pour qui ? quel contexte ?

Mais les taxonomies ne sont pas nécessairement suffisantes dans un usage pro pour monter un site avec de nombreuses relations. Parfois, on souhaite relier 2 types de contenu ensemble, par exemple sur un site contenant des petites annonces, on voudra avoir la possibilité de lier des articles d’actualités à des petites annonces. Ainsi, on pourra facilement afficher des blocs de contenus liés sur le thème.

Pour y parvenir, j’ai développé le plugin : Relation Post Types

Relation Post Types - Réglages

Ce dernier offre la possibilité de choisir dans la console d’administration quelles liaisons voulez vous mettre en place. Par exemple, si vous avez des petites annonces et des articles à relier, vous pouvez choisir d’afficher un bloc « articles » sur la page d’édition des petites annonces, et inversement vous pouvez afficher le bloc « petites annonces » sur la page d’édition des articles. Ainsi, vous pouvez créer des relations dans les 2 sens.

Boite de sélection dans la page de rédaction

On peut même pousser le bouchon le plus loin et créer des relations entre contenus d’un même type de données, par exemple relier une petite annonce à d’autres petites annonces. Cela peut être utile pour générer du contenu relatif, mais manuellement.

Le plugin est disponible en téléchargement sur WP.org, dans le référentiel de plugins. Le plugin est réservé à un public de développeur ou d’utilisateurs avertis, il n’existe pas de fonctions prêtes à l’emploi à utiliser dans le thème, il vous faudra coupler les fonctions du plugin et WP_Query.

N’hésitez pas à me contacter pour tout bug ou évolution allant dans le sens du plugin.

Le premier, c’est qu’il ne se trouve pas dans le référentiel officiel des plugins, ce qui rend handicapantes les mises à jour et son installation. Son deuxième défaut, c’est les problèmes liés au déplacement d’un blog.

Dans de nombreux cas, on développe un blog WordPress avec une adresse de développement et lorsqu’on souhaite migrer, tout se passe bien sauf pour le plugin Cforms, pour 3 raisons :

1. Il enregistre le chemin complet vers le plugin dans un fichier PHP
2. Il enregistre l’adresse du blog dans un fichier JavaScript
3. Il enregistre l’adresse du blog et de destination des fichiers dans une option de WordPress.

L’inconvénient est que lorsqu’on change d’adresse du blog, Cforms conserve les réglages du blog où il a été installé, chose très gênante, car cela implique la modification des 2 fichiers et un bidouillage dans la base de données pour corriger le plugin.

Pour me simplifier la vie, j’ai développé un petit plugin qui permet l’édition depuis la console d’administration de ces différentes informations. Le plugin se présente de la façon suivant :

Le plugin est disponible sur le référentiel de WordPress.org et répond au doux nom de « Advanced Edit Cforms » (j’essaie d’être explicite !)

Cette nouvelle version est pleinement compatible avec WordPress 2.8 et 2.9. Elle n’est pas contre plus du tout compatible avec les versions antérieures, pour 2 raisons, alléger l’extension et ne pas faire semblant d’avoir des évolutions pour les anciennes versions de WordPress alors qu’en fait le code utilisé par les anciennes versions n’était plus mis à jour !

Cette version apporte quelques nouveautés dont :

• Compatibilité à 100% avec l’API taxonomie de WP2.8/2.9
• Utilisation de la nouvelle API des Widgets
• Amélioration du code en vue d’avoir 0 notice PHP (à 99%)
• Correction sur les méthodes de cache WordPress
• Correction avec le bug de la fausse activation. (rien ne se passer)
• Compatibilité à 100% avec PHP4
• Ajout d’un sélecteur de taxonomie pour l’édition de masse (permets de catégoriser massivement)
• Réaménagement de la page « Gestion des tags »
• Nouveau script pour l’auto-complétion, utilisation de l’AJAX pour de meilleures performances
• Correction d’un bug avec les articles très longs et la suggestion de tags de Yahoo/Tag The Net
• Ajout de 3 connecteurs pour la suggestion : OpenCalais, Alchemy et Zemanta
• Correction de l’importateur fourni avec l’extension
• Externalisation du tableau d’options de l’admin pour diminuer la consommation mémoire

Certains d’entre vous ont remarqué que j’avais fermé le projet Google Code, c’est assez simple. L’outil est, je trouve, très mal foutu pour le chef du projet. Les visiteurs peuvent commenter toutes les pages, et les demandes de supports et retours arrivent de partout à la fois.

De plus, la gestion de tickets est difficile à gérer pour une seule personne, un trac est beaucoup plus lisible à ce niveau.

De ce fait, j’ai déplacé le support sur une installation redmine que j’utilise désormais pour publier mes extensions et mini-extensions pour WordPress.

Enfin, beaucoup de personnes m’ont attesté que la version 1.6.x de Simple Tags fonctionnait bien avec WordPress 2.8, et bien il se trouve que non. Elle fonctionnait à peu près, sur certaines installations déjà en place, rien d’apparent. Mais sur une installation from scratch, il y avait de nombreux problèmes, l’ajout des tags sur les pages ne fonctionnait pas par exemple, etc.

Ces stages rémunérés par Google, permettent à des projets comme WordPress de travailler sur des sujets bien précis, comme les performances, la documentation ou encore la recherche dans WordPress !

Ce projet est pour l’heure disponible sous forme de plugin « Search API » bien qu’il soit, à mon avis, très rapidement intégré dans le cœur de WordPress…

Le plugin est totalement modulable, il peut fonctionner avec différents algorithmes, par défaut il y a la recherche MySQL (via FullText), mais il est possible d’utiliser d’autres modules comme Google Custom Search, Sphynx Search.

Le plugin permet un tri des résultats par pertinence, date ou alphabétique. Il y a également possibilité d’afficher un formulaire de recherche avancé, avec un tri possible sur les auteurs, les catégories, les mots clefs, etc.

Une version optimisée et compatible est en préparation… patience ;)

For english users : a new version of Simple Tags for WordPress 2.8 is in preparation and will be release soon !

Eh oui… Entre WordPress 2.3 et WordPress 2.7, l’API des widgets n’a pas bougé d’un pouce alors que l’ergonomie et l’apparence ont complètement changé… L’une des problématiques les plus courantes était dans le cadre de thèmes avec un grand nombre de sidebars… Et oui à part 2-3 Widgets (comme le texte) qui proposaient l’ajout multiple, on était vite coincé…

Par exemple, dans WordPress 2.7, il est impossible de placer un widget « catégories » sur 2 sidebars en même temps… Frustrant lorsqu’on souhaite gérer des sidebars différentes selon la vue (tags, archives, catégories…) où l’on se trouve !

Pour remédier à cela, il fallait créer des widgets multiples, autrement dit que l’on peut ajouter plusieurs fois, la problématique étant que peu d’extensions proposées ce fonctionnement, car plus compliqué à développer.

WP-Polls

C’est le cas par exemple de WP-Polls 2.40, une extension permettant de gérer des sondages, qui par défaut ne possède qu’un seul widget. Cela peut poser problème si vous souhaitez afficher 2 sondages sur 2 sidebars différentes.

Pour mes besoins pros, j’ai dû adapté cette extension afin de la rendre compatible multi widget, et ainsi pouvoir placer autant de sondages que le client souhaitait sur ces sidebars. Je mets par la même occasion à disposition le widget en téléchargement ci-dessous :

WP Polls Widget Multi v2.40 (à renommer en .php et placer dans le dossier « wp-content/plugins »)

Et voici un petit apercu de 4 widget « Poll » en place avec encore la possibilité d’en ajouter :

La version multi widget de l'extension WP-Polls

La difficulté de WordPress 2.7, c’est que l’API pour faire du multi widget est très rudimentaire et de ce fait pas évident à manipuler pour les développeurs d’extensions non confirmés…

Petite comparaison :

• Mon widget multi de WP-Polls (WP 2.7) fait 240 lignes. (dispo ci-dessus)
• Le même widget (quasiment) fait par l’auteur de WP-Polls avec l’API 2.8 ne fait plus que 75 lignes.

Évidemment lorsque l’API est optimisée, c’est tout de suite plus simple et plus rapide de créer du multi widget ;)

Contrairement à l’ancienne API qui n’était composée que de fonctions PHP classiques, la nouvelle API va faire plaisir au puriste PHP ! Et oui pour la première fois (ou presque), nous devrons étendre une classe existante de WordPress pour ajouter nos widgets, hop petit exemple :

class WP_Widget_Polls extends WP_Widget {

Sur ce rythme on ne pourra bientôt plus critiquer WordPress pour la qualité de son code ;) Bien entendu, tout cela reste compatible PHP4 ! (ce qui n’est pas un cadeau pour les développeurs de WP)

Je ne détaille pas plus ici l’utilisation de la nouvelle API des widgets, j’en reparlerai avec un cas pratique lors de la sortie de WP 2.8. Pour info, la discussion relative à la nouvelle API est disponible sur le trac de WP.

L’un d’entre eux était:

Comment insérer toutes les images de son blog dans un article, mais avec de la pagination !

Sans pagination, c’est très simple. Il suffit d’utiliser la fonction get_posts() pour récupérer les images.

D’ailleurs petite précision, pour ne récupérer que les attachements de type « image », il faut préciser le paramètre :

‘post_mime_type’ => ‘image’

Pour gérer la pagination, j’ai choisi d’utiliser la pagination internet de WordPress, celle permise avec les marqueurs « nextpage ». Pour la galerie, j’utiliserai la même. Pour cela, j’ai été obligé de créer une petite extension permettant l’insertion d’un shortcode.

Voila le mode d’exécution :

1. Je récupère l’article juste après la requête SQL de WordPress.
2. Je force l’application du shortcode dans le contenu de l’article récupéré.
3. Je récupère les images
4. Je fais une boucle pour imprimer les images et tous les X images, j’imprime le marqueur « nextpage »

Ainsi, WordPress lors de l’affichage propose la pagination des articles. Pour cela, il ne faut pas oublier la fonction wp_list_pages() dans les fichiers single.php ou page.php (selon le cas article ou page).

Le shortcode permet de paramétrer, la taille des images, le nombre d’images par page et optionnellement l’ID d’un article parent. Tout cela est décortiqué dans le code de l’extension.

Vous pouvez retrouver cette extension depuis mon trac de plugins open-source, plus précisément dans le dossier Simple All Pictures.
Pour télécharger le fichier, allez en bas de la page,  et sous l’intitulé « Download in other formats: », sélectionnez le format que vous voulez.

Pour le but du code tout est dit dans le titre ou presque… le code qui va bien suit!

<?php
// ID de la catégorie
$category_id = 3;
// On récupérer les ID des articles
$post_ids = get_objects_in_term( $category_id, 'category' );
// On récupérer les ID des tags liés à ces articles
$tag_ids = wp_get_object_terms( (array) $post_ids, 'post_tag', array('fields' => 'ids') );
// On passe le tableau des tags dans une chaine de caractère séparé de ","
$tag_param = '';
if ( ! empty($tag_ids) ) {
$tag_param = 'exclude=' . implode(',', (array) $tag_ids );
}
// On utilise Simple Tags - Nuage de tags
st_tag_cloud('number=100&'.$tag_param);
?>

Ce mec, c’est moi… Pour l’anecdote momo360modena, c’est le pseudonyme de mes jeunes années…

J’ai donc proposé il y a très peu de temps un énorme ticket pour passer les fonctions Mu sous les nouvelles fonctions de la classe WPDB, pour des raisons de lisibilités et de performances. Le patch contient également la proposition de déplacer tous les hooks par défaut de WordPress Mu dans un fichier, comme le fait WordPress.

J’espère que tout le patch sera retenu… ça m’a pris deux bonnes heures cette histoire…

Passons maintenant à la suite de ma todo:

• Manage Sites : La possibilité de gérer les sites sous WordPress Mu
• Clean DB : Effacer la table inutile, et rétaper wp_sitecategories
• Manage Global Terms : Permettre l’édition, même basique de la table des globals terms.
• Hardcoded $table_prefix : Permettre l’utilisation d’autre chose que wp_ comme préfixe de table (inutile mais c’est pour la beauté du geste)
• Localize Installer : Avoir un installeur localisé :) pour me faciliter la vie lors des mises à jour !
• Split mu-functions : Séparer les fonctions mu-functions par thématiques…
• Localize Users : Offrir la possibilité à chaque utilisateur de lancer la traduction de son choix. Actuellement ce choix est fait au niveau de l’admin.
• Mu Plugins : Reproduire la page des plugins pour les mu-plugins…

Conclusion derrière ces noms de codes, rien d’extraordinaire… juste les fonctionnalités qui manquent à mon gout à WordPress Mu.

Avant de me lancer dans le développement de ces patchs, je vais probablement discuter avec Donncha, pour voir de son côté si tout ça peut être intégré… En fait la grande difficulté d’un projet comme WordPress Mu, c’est de délimiter les fonctionnalités qui doivent être inclus dans le core et celles qui doivent rester en tant que mu-plugins…

Si de votre coté, vous avez des idées de fonctionnalités manquantes, je suis preneur ;) (le premier qui me répond le domaine mapping, je l’envoi chiez, ca existe déjà en mu-plugins…)

1. Comme plateforme de blog public (ex: Unblog.fr)
2. Comme plateforme pour les réseaux de blogs de gros bloggeurs ou collectifs.

Dans le cas numéro 2, bien qu’il soit possible de désactiver les inscriptions publiques, vos visiteurs pourront toujours tomber sur la page d’inscription. Typiquement lors d’une erreur dans l’URL !

Le visiteur aura alors droit à une superbe page d’inscription aussi inutile que moche.

Pour éviter cette page, il y a 2 alternatives:

1. Hacker le code de WordPress MU
2. Créer une petite extension pour WPmu afin de rediriger automatiquement l’utilisateur.

Je vais bien évidemment utiliser la méthode 2 qui a l’avantage de simplifier les mises à jour.

Pour cela, nous allons créer un petit fichier mu-redirect.php dans le dossier wp-content/mu-plugins/

Et nous allons y placer le code suivant:

<?php
add_action('signup_header', 'redirect_home');
function redirect_home() {
	global $current_site;
	wp_redirect( "http://{$current_site->domain}{$current_site->path}" );
	exit();
}
?>

Très simplement cette fonction va rediriger le visiteur vers la page d’accueil de votre plateforme. Vous pouvez également diriger vos visiteurs sur une adresse ou page spécifique… selon vos besoins !

Le code de cette extension est également disponible sous pastebin.

Bon blogging !

J'ai mis le plugin sur le service de code pastbin.

A noter que cette méthode est radicale ! Elle s'applique pour tous les utilisateurs. (Sauf les commentaires) Vous pouvez également personnaliser le filtre de Kses avec le plugin HTML Purified.

WordPress, comme tout logiciel informatique, est de plus en plus soumis a des attaques diverses et variées... Pour contrer ce genre de désagrément, WP utilise plusieurs mécanismes:

• Gestion des droits
• Un nouvel algorithme de cryptage des mots de passe pour WordPress 2.5
• La gestion de "nonce" permettant de vérifier la provenance lors d'une action dans l'administration.

La grande nouveauté de cette version 2.5, c'est l'ajout d'une méthode permettant de protéger rapidement et efficacement les requêtes SQL d'une technique très remployées, j'ai nommé les injections SQL.

Avant WordPress 2.5, c'était un peu l'anarchie. En effet, chaque plugin dispose de son propre mécanisme de protection, plus ou moins efficace et plus ou moins testé...

Afin de remettre les choses a plats, les développeurs ont ajouté la méthode "prepare" à la classe d'accès a la base de données "wpdb".

Cette méthode bouscule les habitudes sur plusieurs aspects, pour bien comprendre le fonctionnement, je vais décortiquer une requête SQL de WordPress avec l'ancienne et la nouvelle méthode !

Ancienne méthode

Dans cet exemple, je vais prendre la requête SQL utilise lors de l'insertion d'un article dans la base de donnes. Cette requête permet de vérifier que l'identifiant de l'article (ou slug) est bien unique, le cas échéant WP rajoutera un suffixe mais peu importe... Le sens de la requête n'a aucun intérêt dans cette démonstration !

Voici la requête:

$post_name_check = $wpdb->get_var("SELECT post_name FROM $wpdb->posts WHERE post_name = '$post_name' AND post_type = '$post_type' AND ID != '$post_ID' AND post_parent = '$post_parent' LIMIT 1");

Note: vous pouvez trouver la requête dans le fichier "wp-includes/post.php", à la ligne 701.

Comme vous pouvez le constater, la requête fait appel à 4 variables dynamiques:

• $post_name
• $post_type
• $post_ID
• $post_parent

Ces variables sont des sources potentielles d'injections SQL... Pour être sûr de leur contenu, il est impératif de les sécuriser une par une... Cela implique plus de code... et surtout un code répétitif à souhait qui perd en lisibilité !

La nouvelle méthode !

Voici la même requête sous WP 2.5:

$post_name_check = $wpdb->get_var($wpdb->prepare("SELECT post_name FROM $wpdb->posts WHERE post_name = %s AND post_type = %s AND ID != %d AND post_parent = %d LIMIT 1", $post_name, $post_type, $post_ID, $post_parent));

Note: vous pouvez trouver la requête dans le fichier "wp-includes/post.php", à la ligne 1267.

Que remarquons-nous ?

1. Avant d'effectuer la requête SQL (méthode "get_var"), nous utilisons la méthode "prepare"
2. Nous n'avons plus de variables directement dans la requête SQL
3. La méthode "prepare" fonctionne de la même façon que les fonctions PHP "sprintf" ou "printf" (chaînes formatées)
4. Le nombre de paramètre de la méthode "prepare" est infini.
5. Le code de la requête SQL est plus lisible

Comment ça marche ?

Dans le code de la requête SQL, à la place des variables PHP, nous plaçons des marqueurs. Ces marqueurs débutent toujours par un pourcentage.

• %s pour une chaîne de caractère
• %d pour un nombre entier
• La suite des marqueurs sur php.net.

A ce moment de l'article, pour ceux qui ont tout compris, vous vous dites: "Quelles différences avec l'ancienne méthode, les marqueurs ont les mêmes inconvénients que les variables PHP..." et "Pourquoi faire une méthode prepare alors qu'il existe déjà la fonction PHP sprintf..."

C'est précisément ici que la méthode agit... Contrairement à la fonction sprintf, qui ne fait que remplacer bêtement les variables.

La méthode "prepare" passe par une étape intermédiaire, la sécurisation des variables:

1. Suppression des quotes simples et doubles de la requête
2. Ajout des guillemets entre les variables PHP pour respecter la syntaxe SQL
3. Utilisation de la méthode "escape" pour protéger les variables des injections SQL

Conclusion

Vous l'aurez bien compris... L'intérêt majeur de cette fonction est de gagner du temps lors de la création des requêtes SQL ! (tout en les sécurisant)

Grâce à son fonctionnement "à la printf", le code de vos extensions gagnera en lisibilité, en légèreté, et la sécurité sera assurée...

Il ne reste plus qu'à attendre les nouvelles versions de vos extensions préférées pour WordPress 2.5 !

(Extensions = Plugins, préparez vous mentalement... C'est la nouvelle traduction française dans WordPress 2.5)

TinyMCE passe en version 3.x

Cette nouvelle version de l’éditeur visuel apporte plusieurs choses

• Compatibilité à 100% avec Safari 3
• Cœur de l’éditeur complètement réécrit, optimisé et plus léger
• API revu et corrigé, beaucoup plus flexible pour les plugins
• Le code produit est beaucoup plus sémantique et respecte les standards web du W3C.

Elle corrige également un grand nombre de bugs. Le site de l’éditeur : Moxiecode Systems AB pour davantage d’informations.

jQuery passe en version 1.2.x et se généralise

Depuis la version 2.1, l’équipe de WordPress migre progressivement tous les JavaScripts de WordPress sous la librairie jQuery. Cette dernière passe par la même occasion à la version 1.2.x (plus performante et plus légère).

jQuery est désormais utilisé pour:

• Les alertes de manipulation dans les listes d’articles, de pages.
• Les alertes WordPress avec dégradés
• Enfin jQuery remplace Prototype dans la page de rédaction (page plus rapide !)

Les librairies Prototype et script.aculo.us sont également mise à jour, respectivement aux versions 1.6.0 et 1.8.0.

Cela permettra probablement à la console d’administration d’être un peu plus légère pour les navigateurs web !

L’API XML-RPC évolue…

Quelques nouveautés… et des corrections !

• Ajout d’une méthode pour la suppression des catégories, récupération du nombre de commentaires
• Support des champs personnalisés
• L’API AtomPub peut désormais être découvrable automatiquement via les clients tels que Windows Live Writer, etc.
• Support des différents statuts de publication des articles
• L’API est extensible grâce aux filtres et actions des plugins WordPress
• Les articles programmés dans le futur avec Windows Live Writer fonctionnent correctement
• Etc.

Vous trouverez le détail des modifications sur le trac de WordPress.

Une nouvelle méthode pour sécuriser les requêtes SQL $wpdb->prepare !

Et pour en savoir plus… il faudra lire le prochain article entièrement consacré à cette nouvelle méthode :)

Edit: Lire Faire des requêtes sécurisées sous WordPress 2.5 ! Utilisation de la méthode $wpdb->prepare !

En effet, une fois le login passé, le logiciel part dans une boucle infinie ! Et l'admin est inaccessible... Pas terrible pour blogger...

Pour résoudre ce petit bug, nous allons éditer le fichier admin.php se situant à la racine de b2evolution.

Et à la ligne 22, nous allons remplacer

if( ! empty( $_SERVER['PATH_INFO'] ) && $_SERVER['PATH_INFO'] != $_SERVER['PHP_SELF'] ) // the "!= PHP_SELF" check seems needed by IIS..

Par

if( ! empty( $_SERVER['PATH_INFO'] ) && $_SERVER['PATH_INFO'] != $_SERVER['PHP_SELF'] && 1 == 0 ) // the "!= PHP_SELF" check seems needed by IIS..

Avec cette petite modification, la condition n'est jamais remplie, l'administration fonctionne mais les anciennes url du type "/admin/plugins.php" ne seront plus rediriger vers "/admin.php".

Pour note, la variable PATH_INFO est différente de PHP_SELF, raison pour laquelle la condition est remplie et cela fait tout foirer :)

Mon diagnostic s'arrête la... faute de temps !

En effet, j’ai eu l’occasion de tester différents caches (et "optimiseur") OPCode avec une grosse installation de WordPress :

• APC (plugin WordPress)
• eAccelerator (plugin WordPress)
• XCache (plugin WordPress)
• Memcached (plugin WordPress)

Note: Les plugins permettent à WordPress d’utiliser les caches des utilitaires en lieu et place du système de fichiers (bien plus lent)

Alors, non il n’y aura aucun bench à l’appui de mon discours, juste un retour d’expérience…

APC, XCache et eAccelerator possèdent tous les 3 un point commun. Ceux sont des extensions pour PHP. De ce fait, leur installation est très simple, une ligne en plus dans le fichier php.ini et tout fonctionne ! (ou presque)

A contrario, Memcached n’est pas spécifique à PHP, il peut être utilisé par n’importe quel type de langages… C’est une technologie de cache générique. De ce fait, il est nécessaire d’installer un service sur votre serveur, et une extension à PHP. Autre différence, Memcached n’optimise pas le traitement PHP, il ne fait que de la mise en cache.

Revenons à des choses plus générales…

A quoi sert à ces outils ? A réduire la charge serveur non ?

Donc pour réduire la charge serveur, il faut optimiser l’exécution de PHP pour que ce dernier passe moins de temps sur chaque traitement.

Chose que font a merveille APC, eAccelerator et Xcache avec leur optimisation et cache interne.

Cool ? Non pas vraiment…

Ces outils ont tendance à être plus gourmand en consommation processeur, du coup, le traitement est optimise, plus court probablement, mais la consommation CPU de votre serveur augmente… Donc votre serveur est plus lent…

L’effet recherché n’est pas la…

Que faire alors ?

Que faire alors ?

Et bah contrairement à nos 3 gugusses, Memcached ne gère que la mise en cache, et il le fait très bien, et il le fait surtout de manière économique pour le processeur… Du coup, l’utilisation de Memcached est bien plus efficace.

Alors maintenant, la charge du serveur a baissée… mais les pages mettent toujours 2 secondes pour s’afficher, vu que le code PHP de WordPress n’est pas optimisé…

Un casse tête ? Pas vraiment…

eAccelerator et Memcached fonctionne très bien à 2…

• eAccelerator optimise le code PHP
• Memcached met en cache les résultats et diverses variables PHP

Et voila le duo gagnant, vos page sont rapides, et la charge de votre serveur est correcte…

Quelques chiffres… sur une journée (24h):

• eAccelerator seul :  0.8 (consommation CPU moyenne)
• Memcached seul : 0.6
• eAccelerator + Memcached  : 0.4

Le choix coule de source…

Maintenant quelques ressources

Un tutorial pour installer une version récente de Memcached sur une Debian Etch

Il existe un plugin WordPress pour memcache, mais ce dernier utilise une classe d’émulation à la place de l’extension PHP. Cela va s’en dire que les performances sont moindres… vu que le code PHP est plus lent que l’extension en C…

Je mets donc à disposition une classe de cache exploitant l’extension PECL:Memcache et Memcached pour WordPress !

Cette classe est théoriquement compatible avec WPmu, mais je n’ai pas encore testé.

Ryan, un des développeurs de WP, donne quelques infos sur sa version de memcache.

Et contrairement à lui, la méthodologie pour ajouter vos serveurs Memcached à mon plugin est la suivante:

$memcached_servers[] = array( ‘host’ => ’127.0.0.1′, ‘port’ => 11211, ‘persistant’ => true );

C’est un point que je n’aborde pas, mais Memcached peut être répandu sur des clusters de serveurs… c’est la méthode WordPress.com !

Dernier point

Je base cet article sur mon expérience de différents serveurs, 3 différents. Le raisonnement est vérifié sur ces 3 serveurs.

Si vous avez d’autres techniques… je suis preneur :)

Contrairement à d’autres plugins, All In One SEO Pack pour ne pas le citer, j’ai regroupé toutes les corrections sur une seule mise à jour dans le but de vous éviter 30 mises à jour en 2 semaines ;)

Pour les plus passionnés, vous trouverez le changelog sur le site de WordPress.org, en anglais bien sûr !

Le téléchargement se déroule comme toujours sur le site de WordPress.org ! Plus précisément sur la fiche de Simple Tags.

Comme d’habitude, merci pour vos nombreux retours !

Edit: Une version 1.3.2, et 1.3.3 ont vu le jour, la version 1.3.2 mettant juste à jour le fichier de langue japonaise, tandis que la version 1.3.3 corrige un petit bug lors de la recherche dans l’édition de masse.