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

Aucun problème, Wordpress a tout prévu! En effet, il dispose d’une table dans la base données dédiée aux options du blog et des plugins. Vous pouvez donc tout à fait l’utiliser pour y insérer des options supplémentaires. Là où toute la puissance de Wordpress se révèle, c’est qu’il vous fournit une surcouche pour faire tout le travail d’interfaçage avec la base de données grâce à trois fonctions get_option, add_option et update_option. La première permet de récupérer la valeur d’une option, la seconde permet d’ajouter une option et la troisième permet de mettre à jour la valeur d’une option.

Comme un exemple vaut mieux qu’un long discours, voici un bout de code montrant ces trois fonctions en action :

$myplugin_settings = array();
function my_plugin_load_settings()
{
global $myplugin_settings;

$myplugin_settings = get_option('myplugin');
}

Pour décrire rapidement ce qui se passe dans cette fonction, on imagine qu’elle est appelée à l’initialisation du plugin. On va appliquer des valeurs par défaut aux options. On teste si les options existent. Si elles n’existent pas, on les ajoute, sinon on les met à jour. Ensuite, on initialise notre variable globale avec les valeurs précédemment insérées.

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

Il en existe des centaines dans Wordpress, très exactement 800 dans la version 2.7.

Ce site fournit une base de données des hooks avec leur fonctionnalité exacte. C’est donc une mine d’or pour le développeur de plugins wordpress.

On distingue principalement deux types de hooks : les hooks d’action et les hooks de filtrage. Pour faire simple, prenons un exemple de chaque cas. Lorsque le plugin se charge, on va utiliser un hook d’action pour appeler la fonction d’initialisation. Le hook d’action est un simple appel de fonction qui va avoir lieu lorsqu’un événement système précis a lieu. En revanche, lorsque l’on souhaite modifier le contenu d’une note, on va utiliser un hook de filtrage. Les hooks de filtrage s’appliquent plus à des flux de données que le système va analyser et modifier selon vos directives.

Pour ajouter un hook d’action, voici la syntaxe :
add_action('plugins_loaded', 'my_init_function');

Ici my_init_function sera appellée à chaque fois que le plugin sera chargé.

Pour ajouter un hook de filtrage, voici la syntaxe :
add_filter('the_content', 'my_filtering_function');

Ici my_filtering_function sera appellée à chaque fois que le contenu d’une note sera généré (lu dans la database puis passé à travers le filtre pour ensuite être affiché suivant le theme).

Voici un bout de code montrant ce que pourrait être le contenu de my_filtering_function :

define("MYFILTER_REGEXP", "/\[myfilter\]/");
function my_filtering_function($content)
{
return (preg_replace_callback(MYFILTER_REGEXP, 'my_plugin_write_content', $content));
}

Dans cet exemple, à chaque fois que Wordpress va générer le contenu, il va appeler my_filtering_function en lui passant en paramètre le contenu. Dans ma fonction, je dois retourner à Wordpress le contenu filtré. Je mets donc en place un filtrage grâce à la fonction php preg_replace_callback qui va faire un match sur le pattern défini plus haut (MYFILTER_REGEXP). A chaque fois que le contenu d’une note ou d’une page contiendra mon pattern, la fonction my_plugin_write_content sera appelée. Je pourrais alors modifier et manipuler le contenu selon mes souhaits et le retourner modifié à Wordpress. Voilà comment fonctionnent les filtres.

Comme il y a 800 hooks, je ne vais pas tous les détailler ici, cela serait un travail de romain. Aussi, je vous recommande d’aller voir dans la base de données pour y trouver celui qui répond à votre besoin.

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