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.

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 ?

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 !

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.

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

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.

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 !)

Malheureusement, WordPress ne permet pas la désactivation des fonctionnalités non utilisées, c’est regrettable à plusieurs points. Le premier, c’est les performances, charger en mémoire des lignes de code non utilisé peut s’apparenter à un gâchis de ressources. Le deuxième point, c’est la présence de menus inutiles dans la console d’administration. Cet aspect peut être corrigé via des plugins permettant  la personnalisation la console d’administration, ces derniers proposent de choisir précisément les fonctionnalités que l’on souhaite afficher ou masquer.

Mais revenons à drupal…

Lorsque je discute avec des clients, des développeurs, on me dit, WordPress ce n’est pas vraiment un CMS, Drupal oui !

C’est vrai et faux, en fait techniquement parlant, ces 2 outils sont des CMS. WordPress est un CMS orienté gestion de contenu personnelle (plutôt blog), tandis que Drupal est un CMS « non orienté ». Autrement dit, Drupal est extrêmement générique et on le ressent bien à l’installation. (Comme l’on dit plusieurs blogueurs de la communauté WP, WordPress est beaucoup plus packagé que Drupal, plus « ready to use »).

Cette orientation, publication personnelle/blog, est donc à la fois la plus grande force et faiblesse de WordPress.

Force, car cela lui attire la sympathie d’un très grand nombre de webmestres, développeurs et surtout des utilisateurs. Faiblesse, car comme beaucoup d’outils de masse, on le considère à tort comme un outil d’entrée de gamme peu adapté au monde professionnel et à un usage CMS. Et pourtant…

J’ai installé un drupal en local, et j’ai comparé les modules par défaut de drupal avec ceux de WordPress. Vous trouverez dans un premier le tableau comparatif, puis mon analyse.

Comme vous pouvez le constater, mis à part 1-2 fonctionnalités mineures qui n’ont pas d’alternative complète sous WordPress, la totalité des fonctionnalités des modules intégrés dans Drupal possède une alternative ou plusieurs alternatives. Parfois nativement, parfois sous la forme de plugins de la communauté !

Lorsque la fonctionnalité est native, elle possède le même niveau de qualité que sa concurrente drupal. Lorsqu’il s’agit d’un plugin, c’est variable. Certains plugins de la communauté sont bien plus évolués que leurs concurrents par défaut de drupal (mais des plugins drupal peuvent équilibrer la balance), tandis que dans certains cas, c’est l’inverse.

Je conclurai en 3 points.

1. WordPress n’a rien à envier aux modules de base de Drupal. La communauté très active remplit parfaitement son rôle en réalisant des plugins de qualité similaire.

2. Le programme de plugins « officiel » de WordPress.org va permettre de constituer une base de plugins sûrs, vérifiés et mis à jour régulièrement. Ces plugins deviendront l’équivalent des modules de drupal.

3. Drupal possède une longueur d’avance concernant la possibilité de créer nativement des types de contenus à la volée. (je ne parle pas de CCK, mais des types de contenus), WordPress supporte depuis très longtemps ce genre d’ajout via des plugins, mais rien de  très propre. La version 3.0 ajoutera une API complète permettant d’ajouter autant de types de contenu que souhaité.

Dans un prochain article, je vous parlerai de Views/CCK et WordPress !

PS: J’ai sûrement oublié certaines fonctionnalités, je pense par exemple aux permissions, je me suis contenté des modules de base pour le moment, mais si vous voyez des fonctionnalités de bases qui n’existe pas dans WordPress, dites-le-moi, j’essaierai de trouver l’alternative si elle existe !

En fait, le bug se caractérise par la perte des catégories/mots clefs ou bien une "confusion" dans la taxonomie de WordPress. Vous éditez un mot clef avec l'ID 199 et ce dernier disparait au profit de la catégorie avec l'ID 8.

Étrange n'est ce pas !

Pourtant en base de données rien n'est perdu, c'est juste que la fonctionnalité globale catégories de WordPress Mu fout le bordel dans la table term_taxonomy.

Pour éviter d'avoir ce problème à l'édition, je vous donne un correctif très rapide : créer un fichier fix-bug-cat.php dans le dossier mu-plugins de votre installation WordPress Mu.

Et insérez-y le code suivant :

<?php
remove_filter ( 'term_id_filter', 'global_terms' );
?>

En désactivant le filtre fautif, vous vous évitez ce bug ennuyant... Pour ceux que ça intéresse, j'ai créé un ticket sur le trac à ce sujet pour probablement une correction définitive d'ici WordPress 3.0 !

Ici, je vais vous montrer avec 2 bouts de code, comment on peut générer automatiquement une barre de sidebar pour chaque page de votre blog/site sous WordPress, sans oublier une sidebar par défaut pour le reste du blog et les pages n'ayant aucun widget spécifique !

Étape 1 : Enregistrement automatique des nouvelles sidebars

Ici, on procède en 2 étapes,dans un premier temps on enregistre la sidebar par défaut, puis on récupère la liste complète des pages disponibles de votre blog via la fonction get_pages() et on fait une boucle dessus pour enregistrer chaque sidebar.

<?php
if ( function_exists('register_sidebar') ) {
 // Default sidebar
 register_sidebar(array(
 'id' => "sidebar-default",
 'name' => 'Sidebar par défaut',
 'before_widget' => '<li id="%1$s">',
 'after_widget' => '</div></li>',
 'before_title' => '<h2>',
 'after_title' => '</h2><div>',
 ));
 // One sidebar by page
 $_pages = get_pages();
 foreach( (array) $_pages as $_page ) {
 register_sidebar(array(
 'id' => "sidebar-$_page->ID",
 'name' => esc_html($_page->post_title),
 'before_widget' => '<li id="%1$s">',
 'after_widget' => '</div></li>',
 'before_title' => '<h2>',
 'after_title' => '</h2><div>',
 ));
 }
 unset($_pages, $_page);
 wp_reset_query();
}
?>

Étape 2 : Appel de la sidebar depuis votre thème

(Code généralement à placer dans le fichier sidebar.php de votre thème)

Ici il ne faut pas oublier d'ajouter la variable globale $wp_query, grâce à cette dernière nous récupérons l'ID de l'objet actuellement chargé, et je vérifie que je suis bien sur une page et que la sidebar est utilisée. (autrement dit qu'elle contient au moins un widget). Si ça n'est pas le cas, je charge la sidebar par défaut.

<?php
global $wp_query;
if ( function_exists('dynamic_sidebar') ) {
 if ( is_page() && is_active_sidebar( 'sidebar-' . $wp_query->queried_object_id ) ) {
 dynamic_sidebar( 'sidebar-' . $wp_query->queried_object_id );
 }  else {
 dynamic_sidebar( 'sidebar-default' );
 }
}
?>

Vous pouvez retrouver l'intégralité du code depuis cette page pastebin

J'ai donc cherché une solution sur le net, et sur le groupe de support de MailPress, je suis tombé sur un sujet traitant du problème, et la réponse d'André m'a fait sourire :)

ask viper and cform dev to stop spreading their code all over all admin pages ! ?

En fait, il a en partie raison... Les plugins en questions, Viper Video Quicktags, Cforms et bien d'autres, ajoutent sans trop se soucier leur bouton à l'éditeur visuel de WordPress, et ils ne font pas du tout attention sur quelle page est chargé l'éditeur et encore moins par quel plugin... Mais ils n'ont pas tort... Lorsque j'ajoute le plugin Viper Video Quicktags, je souhaite ajouter les boutons des services vidéos... Et si je déporte l'éditeur visuel sur une page du site, je souhaite également avoir ses boutons...

En fait, le fautif à mes yeux est WordPress, les filtres offrent des superbes possibilités d'extensibilité, mais le nombre d'incompatibilités entre les extensions est en croissance exponentielle... Ici, l'éditeur visuel devrait pouvoir être appelé avec ou sans les filtres. (WordPress le propose déjà pour la fonction get_posts/query_posts)

Mais trêve de bavardage, pour corriger l'incompatibilité, j'ai développé un petit plugin qui corrige la situation pour les 2 plugins (cforms, viper vidéo quicktags), et de la sorte pas besoin de modifier/désactiver l'un ou l'autre des plugins...

<?php
/*
Plugin Name: MailPress Fix TinyMCE
Plugin URI: http://www.herewithme.fr
Description: Fix TinyMCE for MailPress with Viper Video Quicktags and Cforms
Author: Amaury Balmer
Version: 0.1
Author URI: http://www.herewithme.fr
*/
add_action( 'init', 'fixTinyMCE_MailPress', 999 );
function fixTinyMCE_MailPress() {
 if ( !isset($_GET['page']) && $_GET['page'] != 'mailpress_write' ) {
 return false;
 }
 // Viper video quicktags
 global $VipersVideoQuicktags;
 remove_filter( 'tiny_mce_version', array(&$VipersVideoQuicktags, 'tiny_mce_version') );
 remove_filter( 'mce_external_plugins', array(&$VipersVideoQuicktags, 'mce_external_plugins') );
 remove_action( 'edit_form_advanced', array(&$VipersVideoQuicktags, 'AddQuicktagsAndFunctions') );
 remove_action( 'edit_page_form', array(&$VipersVideoQuicktags, 'AddQuicktagsAndFunctions') );
 if ( 1 == $VipersVideoQuicktags->settings['tinymceline'] )
 remove_filter( 'mce_buttons', array(&$VipersVideoQuicktags, 'mce_buttons') );
 else
 remove_filter( 'mce_buttons_' . $VipersVideoQuicktags->settings['tinymceline'], array(&$VipersVideoQuicktags, 'mce_buttons') );
 // Cforms
 remove_filter( 'mce_external_plugins', 'cforms_plugin');
 remove_filter( 'mce_buttons', 'cforms_button');
 return true;
}
?>

Le fichier est également disponible au téléchargement ici.

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 !

En réalité, la source du problème vient de WordPress 2.7, cette nouvelle version a apporté une nouvelle API pour les commentaires, dont la fonctionnalité de pagination. Cette dernière est très pratique lorsqu’on a plus de 1000 commentaires de moyenne sur chaque article… ( ex: Bords de Pistes )

Prenons l’exemple de l’article « Top Chrono » que Lionel a rédigé, le lien de l’article est le suivant:

• http://www.bordsdepistes.com/2009/03/21/top-chrono/

Vu qu’il y a 10 pages de commentaires, nous nous retrouvons avec 10 liens pour le même article:

• http://www.bordsdepistes.com/2009/03/21/top-chrono/comment-page-1/
• …
• http://www.bordsdepistes.com/2009/03/21/top-chrono/comment-page-10/

10 pages où le titre, la description et le contenu sont les mêmes !

Autrement dit, nativement WordPress, qui est pourtant très bien optimisé pour le référencement, créé du duplicate content avec cette fonctionnalité. Un débat a eu lieu sur le mailing de WordPress, et plusieurs hypothèses ont été envisagé, petit résumé de la situation.

Les balises HTML méta

Une première solution aurai été d’ajouter une balise méta « no index, follow » à la page. Bien que cette méthode règle le problème du duplicate content, l’inconvénient est que Google ne référence pas le contenu de tous les commentaires et de ce fait, c’est potentiellement un moins bon positionnement dans Google vu que moins de contenu est référencé !

Utilisation de jQuery

Une autre idée aurait été d’utiliser jQuery pour faire la pagination, avec le plugin Tabs par exemple. L’intérêt est que fonctionnellement on obtient bien une pagination. Cependant, cette technique est peu ou pas accessible, il oblige le chargement de jQuery dans les thèmes WordPress et surtout il force à écrire la totalité des commentaires dans le code HTML. Lorsqu’on a plus de 1800 commentaires, cela peut vite devenir contraignant !

En pratique

Pour résoudre ce problème de façon concrète, j’ai trouvé 2 solutions. Les deux sont d’ailleurs compatibles et fonctionnent mieux ensemble.

Le contenu de l’article

En remplaçant le contenu de l’article par l’extrait et un lien vers le lien de l’article, on retombe dans le schéma classique d’une page listant des articles comme peuvent l’être les catégories ou les tags.

De cette façon, Google ne considère plus le contenu comme du duplicate content et les commentaires sont bien référencés tout en étant liés à l’article avec le permalien et l’extrait !

Pour faire cette modification, vous pouvez utiliser l’extension de Austin Matzko soit en utilisant son extension, soit en faisant un copier/coller de sa fonction directement dans le fichier functions.php de votre thème.

Le titre de la page

Malheureusement, la première méthode ne règle pas complètement le problème, le titre de la page HTML reste toujours le même sur chaque page de commentaires et cela gene Google. C’est là où rentre en jeu l’idée de Christian Schenk d’ajouter un suffixe au titre des pages de commentaires. L’astuce qu’il donne permet d’ajouter un suffixe à ces pages si vous utilisez l’extension All In One SEO Pack.

Pour y parvenir, il suffit de copier les 2 fonctions qu’il propose dans le fichier functions.php de son thème et de modifier le code de All In One SEO Pack pour permettre aux filtres de fonctionner.

On remarquera que la méthode n’est pas trop propre vu qu’on est obligé de hacker le plugin et comme c’est le genre de plugin qui est mis à jour toutes les 2 semaines, cela deviendra très rapidement pénalisant.

Mon extension : Simple SEO for Paged Comments

Afin de faciliter la résolution de ce petit problème, j’ai créé une petite extension qui utilise les 2 techniques données précédemment. A la différence près que le titre des pages de commentaires se verra ajouter un suffixe, et ceux sans nécessairement utiliser All In One SEO Pack (et encore moins le hacker). Théoriquement ma technique doit fonctionner avec tous les plugins SEO de la communauté.

Vous pouvez trouver la fiche de l’extension sur mon blog et prochainement sur WordPress.org.

Sources

Un peu de lecture en anglais ;)

• Paginated comments with WordPress 2.7 and the Copyblogger theme
• Paged Comments and the SEO Problem: A Solution

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.

Le problème de Tidy, c’est que généralement l’extension n’est pas activée sur les hébergements mutualisés !

Je suis tombé cet après-midi, en faisant des recherches pour une preg nettoyant le code HTML de MS Word, sur une alternative à Tidy écrit entièrement en PHP, j’ai nommé « htmLawed« . Comme le souligne l’auteur du script, les performances sont certes moins bonnes, mais on gagne en compatibilité vu que le script ne nécessite que PHP 4 !

Le script s’intègre d’ailleurs assez facilement avec WordPress, et il semble possible de remplacer le filtre KSES de WP sans trop de modifications. D’ailleurs, d’après ce que j’ai pu voir sur les forums de support de WordPress.org, un paquet de personnes milite pour le remplacement la vieillissante classe Kses par htmlLawed… On verra ;)

Pour ma part, j’ai rencontré quelques soucis avec les accents et l’encodage UTF-8, donc je reste prudent avec l’usage de htmlLawed !
Des personnes ont déjà essayé ?

Pour voir la bête, il suffit d’aller sur la page de l’auteur :
http://www.frequency-decoder.com/2009/02/03/unobtrusive-date-picker-widget-v4

Dommage que le script ne soit pas fait via jQuery, il aurait probablement été plus light, néanmoins il fonctionne sans librairie, ce qui est déjà très sympa en soit !

Je sais déjà où je vais l’utiliser ;)

La ligne à ajouter est la suivante :

$wp_local_package = 'fr_FR';

Elle permet de préciser la langue utilisée pour les mises à jour. Une fois le fichier modifié, vous devrez voir la notification disparaitre lors de la prochaine vérification de version de WordPress !

Si vous ne souhaitez ou ne pouvez pas faire la modification, n'oubliez pas qu'il est possible de masquer les mises à jour, pour cela il faut se rendre sur la page "Outils - Mettre à jour".