J’ai d’abord erré sur Overblog avec toutes les limitations d’un tel service puis sur Typepad avec un lot tout aussi conséquent de limites puis j’ai découvert WordPress un peu plus de deux ans après. Depuis, je me demande comment font les autres systèmes pour exister…

WordPress est beau, simple, souple, rapide et stable. Il a tout ce que l’on peut attendre d’un système informatique avec les problèmes en moins.

Je suis passé en version 3.2.1 en début de semaine de manière complètement transparente. Je n’ai eu aucun problème lors de la migration qui s’est faite en quelques secondes. Imaginez un upgrade de Windows en un clic? Bref, c’est juste hallucinant ce qu’ils sont parvenus à faire avec cette plateforme.

Le public comme les professionnels de l’internet ne s’y sont d’ailleurs pas trompés puisque WordPress est, et de loin, la plateforme la plus répandue sur le web avec plus de 15% des sites qui tournent sous WordPress.

Si vous n’y connaissez rien à l’informatique et vous souhaitez monter un site, optez pour WordPress, vous apprendrez le web en douceur et sans douleur. Longue vie à WordPress!

Aujourd’hui, lorsque l’on veut créer un blog, que l’on s’y connaisse ou pas en informatique, WordPress est le choix qui s’impose. Facile à installer, facile à utiliser, facile à faire évoluer, WordPress, c’est le couteau suisse du site web couplé à un moteur de Ferrari pilotable sans permis! Donc pour les blogs, il n’y a plus de débat depuis bien longtemps. WordPress est loin, très loin devant et les rares alternatives ont sombré dans l’oubli.

Donc la vraie question est plutôt de savoir si WordPress est une bonne idée pour faire un site web corporate. Selon moi, la réponse est oui. Plusieurs arguments plaident en faveur de WordPress. Tout d’abord le nombre de themes et de plugins disponibles : des dizaines de milliers rendant les possibilités quasiment infinies. Ensuite, il y a l’importance de la communauté. Sur WordPress, quand vous avez un problème ou un souhait, il y a 95% de chances pour qu’une autre personne ait rencontré le même problème ou eu la même idée et du coup, on trouve presque toujours une réponse à ses besoins. Enfin, il y a la robustesse. WordPress, c’est du très solide. Je ne vois pas trop de moteur de CMS en mesure de soutenir la comparaison avec WordPress. Bref, WordPress, c’est le number one et c’est pas prêt de changer!

WordPress est d’ailleurs tellement populaire qu’un certain nombre de poids lourds du monde des technologies s’y intéressent de très près. Il y a d’abord Microsoft qui a migré tous les blogs sur la plateforme Myspace sur WordPress il y a quelques mois. On peut aisément imaginer l’intérêt pour un Microsoft de mettre la main un jour sur WordPress. Google aussi pourrait être interessé, sa plateforme Blogger n’étant pas un succès technique digne des autres applis de l’entreprise.

Côté futur, WordPress commence un peu à se heurter aux difficultés liées à sa popularité. Le core team d’Automattic est assez restreint. Du coup, les nouvelles versions prennent régulièrement du retard, ce qu’au passage, je ne critique pas, le contraire serait étonnant vu la quantité de travail. Au niveau fonctionnalités, WordPress couvre 99% des fonctionnalités imaginables pour un blog et il faut donc songer à le faire évoluer pour répondre à des besoins plus larges. Ceci passera inéluctablement par l’intégration dans le core de plugins essentiels comme le plugin de cache ou certaines fonctions SEO ou encore de backup.

Bref, WordPress a un avenir prometteur, s’il parvient à négocier correctement le virage de la professionnalisation afin de lui ouvrir toujours plus de sites souvent jusque là confinés à des CMS fait maison.

Il est donc probable que beaucoup de plugins vont avoir de gros problèmes à fonctionner après le passage en 2.8.1, notamment pour ceux qui utilisent des redirections et des fichiers de traitement.

Pour rendre les plugins compatibles, voici la solution. Il faut dans la fonction qui ajoute les menus enregistrer vos pages tierces via la ligne suivante :

$_registered_pages[get_plugin_page_hookname('<plugin_dir>/<plugin_filename>.php','')] = true;

Bien entendu, n’oubliez pas de déclarer au début de la fonction la variable globale $_registered_pages sinon cela ne risque pas de fonctionner.

J’ai utilisé cette solution avec succès pour rendre WATS compatible avec WP 2.8.1.

Au niveau de l’admin, il n’y a pas de grands changements et c’est très bien comme ça car l’interface d’admin a déjà atteint un niveau d’ergonomie proche de la perfection. Au niveau des fonctionnalités essentielles : une nouvelle interface de gestion des widgets, l’installation des themes depuis l’admin (comme pour les plugins), optimisation du chargement des scripts dans l’admin, etc… Vous pouvez voir ici la liste des nouveautés. Il y a plus de 180 nouvelles features et 790 fixes, joli boulot!

Au niveau du développement des plugins, comme jQuery est passé en V1.3, un certain nombre de plugins vont devoir être mis à jour pour faire évoluer l’ancienne notation avec un sélecteur @, celui-ci n’étant plus pris en compte en 1.3. Il y a également quelques changements apparemment dans la gestion des taxonomies. J’ai corrigé les quelques problèmes apparus dans mon système de gestion de tickets suite à cet upgrade. J’espère donc être en mesure de le publier sous peu.

Seul problème rencontré, il existe depuis quelques versions de WordPress ce que l’on appelle la page « attachment » qui est un post vide contenant juste l’attachement en question (photo, vidéo, etc…). Si vous avez dans vos posts, une image avec le même nom que le post, la redirection n’aura pas lieu correctement après la migration

Voici un exemple concret : j’ai un post « toto » dans la catégorie titi avec une photo intitulée « toto.jpg ». Vous pouvez accéder à la photo via /titi/toto/toto/ avant la migration. Après la migration, vous pourrez toujours accéder à la photo via titi/toto/ et donc l’utilisateur suivant l’ancienne URL ne sera pas redirigé vers /toto/ qui est la nouvelle URL.

Il existe un certain nombre de plugins fonctionnant plus ou moins bien pour gérer automatiquement les redirections 301 de l’ancienne structure vers la nouvelle :

• Dean permalink migration : gère correctement le cas décrit ci-dessus mais casse les liens de feed et de trackback;
• Permalink redirect : permet de gérer plusieurs structures antérieures apparemment mais ne gère pas le cas décrit ci-dessus.

Comme aucune solution automatique ne fonctionnait à 100%, je me suis tourné vers l’indispensable plugin redirection et j’ai créé manuellement les redirections. Cela peut sembler fastidieux mais en réalité, cela ne prend que 10 minutes. Il suffit de créer un fichier .csv avec cette tête :

/categorie1/(.*)/,/$1/,301

/categorie2/(.*)/,/$1/,301

Ensuite vous l’importez via le panneau d’admin du plugin et ça roule! Ainsi, la redirection est forcée et on n’arrive plus sur la page de l’attachement. Bon au final, j’ai quand même passé la journée là dessus à cause de cette histoire d’attachement. En effet, il m’a fallu des heures avant de trouver le dénominateur commun à tous ces posts qui n’étaient pas redirigés correctement. Mais bon voilà maintenant, ça marche! Si vous voyez des problèmes, n’hésitez pas à me les signaler.

Edit du 12/04/2009 :

Il faut aussi deux redirections « do nothing » avant celles des catégories comme suit :

/category/(.*)/

/tag/(.*)/

Si vous n’insérez pas ces redirections « do nothing », vous risquez d’avoir des matches avec vos redirections de notes et des redirections non souhaitées (notamment pour les subpages de catégories et de tags).

Je mets ce plugin donc à disposition de tous même si je pense qu’il aura une audience très limitée. Si vous l’utilisez, n’hésitez pas à me laisser un petit commentaire, cela fait toujours plaisir!

Si vous rencontrez un problème avec ce plugin, laissez moi un commentaire ou envoyer un mail via le formulaire de contact.

Voici le lien de téléchargement.

Le problème, c’est que c’est assez peu documenté. Cependant, si vous voulez passer des tableaux du client au server ou du server au client dans le cadre d’une application web javascript avec un server php, vous allez avoir du mal à vous en passer.

Je vais donc vous donner quelques pistes côté client et côté server pour vous familiariser avec le JSON et éviter les pièges dans lesquels je suis tombé et où j’ai perdu de nombreuses heures avant de comprendre ce qui se passait car forcément, debugger de l’ajax côté php, c’est pas très facile.

Alors commençons par la voie client vers server. Imaginons que notre utilisateur remplit une table qu’il va poster en ajax pour traitement par le server. Tout d’abord, il faut « jsonifier » le tableau (néologisme pour indiquer que l’on encode la table en format json). Pour cela, c’est très simple, on fait un petit appel à la fonction JSON.stringify avec comme paramètre l’id de notre tableau. Il nous retourne le tableau stringifié! La page de Wikipedia sur le JSON vous donne une idée du format en question. En gros, c’est du style {« key »: »value », »key »: »valeur »} avec des imbrications possibles si vous utilisez un tableau multidimensionnel. On envoie ensuite la table en ajax avec un post au server qui la récupère et là ouvrez en grand vos yeux, j’ai passé trois heures avant de comprendre ce qui se passait, il faut appliquer un stripslashes sur le tableau côté server sinon le json_decode vous renvoit un tableau vide! Voici le bout de code :

  $tableau = json_decode(stripslashes($_POST[tableau]));

Voilà, maintenant, vous savez comment récupérer le tableau, il est alors formaté correctement pour être exploité par le server.

Mais quid de l’autre sens? Et bien c’est à peu près pareil. On commence par encoder notre tableau avec json_encode et on le balance au client avec un echo. Voici le bout de code :

$result = array('success' => "TRUE", 'erreur' => "Tout va bien!");
echo json_encode($result);


Puis on récupère dans la fonction de résultat du call Ajax le tableau jsonifié avec un eval comme suit :

var tableau = eval('(' + ajaxres + ')');


Et voilà, vous savez à présent comment échanger des données complexes entre le client et le server en Ajax grâce au JSON! Dernier point, pour utiliser la fonction stringify, je vous recommande de télécharger le script json2.js.

Retour au sommaire du dossier sur l’écriture d’un plugin wordpress

Lorsque l’on soumet un formulaire (form submit en post ou get), il y a une interaction avec le server qui va parser et exploiter les données que vous lui envoyez. Le problème est que cela doit se faire suivant une séquence bien précise avec un certain nombre de contrôles. Si un utilisateur parvient à soumettre ses données directement en outrepassant ces contrôles, il y a un risque pour le système car il peut alors soumettre n’importe quoi ou profiter de privilèges dont il ne dispose pas.

Le nonce field permet d’empêcher cela. Toute soumission directe sera bloquée grâce à ce système.

Comment est ce que cela fonctionne techniquement? Le système vous fournit une clé lors du chargement du formulaire. Vous allez soumettre au système votre formulaire rempli. Celui-ci va alors vérifier que la clé fournie est bien celle qu’il récupère dans le formulaire soumis. Si ce n’est pas le cas, cela veut dire que vous n’avez pas soumis vos données via le formulaire qu’il vous a fourni et donc il rejette la soumission!

Vous trouverez sur wikipedia un joli schéma qui explique tout ça très bien.

Concrètement, pour implémenter cette protection au niveau des formulaires de votre plugin, il faut procéder de la manière suivante :

1/ Entre les balises <form></form> vous insérez le code suivant :

<form action= »" method= »post »>
<?php wp_nonce_field(‘myplugin-nonce-form1′); ?></form>

2/ Au niveau de la fonction de retour du formulaire où vous avez le $_POST, vous faites le check sur le nonce :

if (isset($_POST['submit']))
check_admin_referer(‘myplugin-nonce-form1′)

Si vous voulez vérifier que le mécanisme fonctionne bien, insérez juste le code de la seconde partie (le check). Comme vous n’aurez pas inséré le nonce dans le formulaire, la clé ne sera pas soumise et WordPress rejettera la soumission.

Si on soulève le capôt, voici ce que wordpress va insérer dans le code HTML de la page contenant le formulaire :

<input id= »_wpnonce » name= »_wpnonce » type= »hidden » value= »71fd0b1cc7″ /><input name= »_wp_http_referer » type= »hidden » value= »page.php » />

Il soumet donc un champ caché et en test ensuite la valeur. Le hacker pourra toujours essayer de reproduire ça, il n’a aucune chance d’y parvenir sachant que la clé change à chaque passage.

Retour au sommaire du dossier sur l’écriture d’un plugin wordpress

On commence par supprimer le lien vers le menu dans la barre des menus en faisant un unset sur l’index correspondant dans la variable globale menu. Par exemple, pour bloquer l’accès à la modification du profil, je fais :

unset($menu[50]);

Pour savoir quel $menu[x] il faut unsetter, il faut regarder dans le fichier menu.php dans le répertoire wp-admin. Cette action aura pour effet de supprimer l’icône dans le menu d’admin.

Ce n’est pas suffisant car l’accès direct à la page est toujours possible pour celui qui en connaît l’url. Mais aucun problème, là encore, j’ai la solution! On faire un check sur la page en cours de chargement et si c’est une page pour laquelle on ne souhaite pas donner accès à l’utilisateur, on le redirige vers une autre page à laquelle on lui donne accès sinon, bonjour la boucle de redirection.

Voici le bout de code pour faire la manipulation. Ici je bloque l’accès à l’édition du profil pour les utilisateurs de niveau 0 et je les redirige vers le dashboard de l’admin :


$requesteduri = $_SERVER['REQUEST_URI'];
$destinationpage = get_option('siteurl') . '/wp-admin/index.php';
$position = strpos($requesteduri, '/wp-admin/profile.php');

if (($position != 0) && ($current_user->user_level == 0))
wp_safe_redirect($destinationpage);

Donc pour résumer, pour bloquer l’accès à une page dans l’admin :

1/ on supprime l’entrée dans le menu;

2/ on met en place une redirection pour empêcher l’accès direct.

Ces deux actions doivent être réalisées assez tôt dans le chargement de la page. Il faut donc faire un hook sur l’action plugins_loaded par exemple, ça fonctionnera bien comme ça.

Retour au sommaire du dossier sur l’écriture d’un plugin wordpress