Il existe cependant une méthode alternative reposant sur Subversion (SVN). C’est la méthode idéale pour tout développeur WordPress ou gestionnaire de blogs. C’est celle que j’emploie depuis la version 2.6 grâce notamment à la constante WP_CONTENT.

Explications et application concrète.

Avant toute chose, sachez que ce tutorial est optimisé pour les personnes qui versionnent entièrement leur projet. Il n’est pas question ici d’avoir une arborescence libre et de procéder à des checkout un peu partout. C’est possible mais pas du plus grand intérêt.

L’avantage évident ici est de pouvoir déployer son blog n’importe où en un rien de temps.

Structure des fichiers

Installer WordPress en tant que dépendance SVN revient à mélanger 2 techniques :

• Installer WordPress dans son propre répertoire
  
• Installer WordPress proprement depuis SVN

Je suis pénible donc je n’ai pas spécialement envie de modifier un fichier core ou autre chose que wp-config.php. Tout le contraire de ce qu’indique la première méthode.

La seconde explication m’a toutefois posé légèrement problème puisqu’un peu brutale et posant soucis chez OVH.

Celles et ceux qui voient la capture d’écran ci-dessus peuvent constater que tout WordPress a été déplacé dans un sous-répertoire wordpress au même niveau que wp-content.
On ne garde à la racine que le fichier .htaccess et wp-config.php.

Sur le répertoire racine, j’ai appliqué ces propriétés pour WordPress 2.7 :

• svn:ignore :
  

  wp-config.php

• svn:externals :
  

  wordpress http://svn.automattic.com/wordpress/branches/2.7

Je ne versionne volontairement pas le fichier wp-config.php car c’est le seul fichier susceptible de changer d’une instance à une autre. Je le récupère depuis wordpress/wp-config-sample.php et je le personnalise selon mes besoins.
Et puis versionner des mots de passe … qui y tient ?

Configuration

Après cette restructuration, on aura toutefois besoin de configurer 2-3 bricoles. Vraiment rien de méchant promis.

Le .htaccess

Voici ma configuration. Elle peut être aisément déportée dans votre déclaration de Virtual Host pour des raisons de performance. Sur un serveur mutualisé vous n’avez en général pas accès à ce dernier type de configuration.

<IfModule mod_rewrite.c>
Options -Multiviews -Indexes +FollowSymlinks
RewriteEngine On
RewriteBase /
# Moving to dependency
RewriteRule ^(index.php|wp-[a-z0-9-]+\.php|xmlrpc.php)?$ wordpress/$1 [L]
RewriteRule ^(wp-admin|wp-includes)/(.*)$ wordpress/$1/$2 [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . wordpress/index.php [L]
</IfModule>
# BEGIN WordPress
# END WordPress

Ce fichier est très inspiré de la configuration SVN proposée sur le Codex WordPress. Seulement voilà, cette renvoie tout sur index.php … et omet ainsi tous les accès aux fichiers situés à la racine, avec entre autre :

• wp-cron.php
• wp-link-opml.php
• wp-trackback.php
• xmlrpc.php

Je vous fais grâce des contrôleurs de flux (Atom, RSS & cie) et des appels en directs à index.php effectués par certains plugins.

Donc non on ne peut pas vraiment se passer de ces fichiers. D’où ces 2 règles :

• RewriteRule ^(index.php|wp-[a-z0-9-]+\.php|xmlrpc.php)?$ wordpress/$1 [L]
  

  On capte tous les fichiers PHP (les contrôleurs) originellement situés à la racine de WordPress.

• RewriteRule ^(wp-admin|wp-includes)/(.*)$ wordpress/$1/$2 [QSA,L]

  Et là c’est pour le confort de conserver les adresses initiales … mais aussi pour éviter de modifier un bout de paramétrage dans l’admin. Le jour où vous décidez de rebasculer à l’ancien système, ça se fera sans douleur

Enfin, pourquoi avoir poussé les commentaires WordPress vers le bas ? Tout simplement pour éviter que nos règles personnalisées soient écrasées par WordPress lors d’une mise à jour des permaliens. Nos règles primeront toujours ainsi.

Le fichier wp-config.php

Dans le fichier wp-config.php, nous n’allons rien modifier. Nous allons juste ajouter forcer 2 paramètres. Ils indiqueront à WordPress où se trouve le véritable répertoire wp-content (renommable mais je ne jouerai pas avec).

Le blog

Bon j’ai menti un peu toute à l’heure en indiquant qu’on ne toucherait qu’à wp-config.php. Cependant la modification est on ne peut plus mineure et ne concerne que l’upload de medias.

En effet si on ne touche pas à l’emplacement des fichiers envoyés, WordPress considère qu’ils sont uploadés dans wordpress/wp-content/uploads. C’est fort gênant mais heureusement, en préfixant le chemin par ../ ou en tapant un chemin absolu tout rentrera dans l’ordre.

À noter qu’il s’agit du seul paramétrage hors d’un fichier. Si j’avais pu m’en passer je l’aurais fait.

Dépendance SVN pour la traduction

C’est en tombant sur un autre article traitant de svn:externals pour WordPress que j’ai été interpelé sur la prise en charge des langues via SVN également.
Le système n’est pas parfait puisqu’on ne peut gérer qu’une seule langue par ce biais là. Ça ne conviendra donc pas aux blogs multilingues.

La technique consiste à transformer wp-content/languages en svn:externals.
Ça donnerait ceci pour la version française de WordPress 2.7, au niveau du svn:externals du répertoire wp-content :

languages http://svn.automattic.com/wordpress-i18n/fr_FR/branches/2.7/messages/

Simple et efficace mais ça reste encore de la bricole.

Cas particulier : plugins et i18n

Je vous expose le problème mais malheureusement vous ne pourrez pas y faire grand chose. Par contre ami développeurs, pour rendre votre code de plugin 100% portable, merci de prendre note

Le chargement des traductions s’effectue à l’aide de la fonction load_plugin_textdomain(). Elle prenait seulement 2 paramètres jusqu’à l’arrivée de WordPress 2.6. Ça n’a pas été crié sur les toits mais elle prend désormais 3 … et c’est du 3ème argument qu’il faut utiliser désormais :

1. $domain : l’espace de nom des traduction (inchangé)
2. $abs_rel_path : chemin relatif par rapport à l’emplacement de WordPress (déprécié, on y mettait PLUGINDIR.'/'.dirname(plugin_basename(__FILE__)) en général)
3. $plugin_rel_path :  chemin relatif par rapport à l’emplacement des plugins (c’est qui nous intéresse ; dirname(plugin_basename(__FILE__)) nous suffira désormais)

Vous trouverez un exemple sur le Codex, du côté de l’internationalisation des plugins.
Un exemple de code pérenne :

load_plugin_textdomain('votreplugin', dirname(plugin_basename(__FILE__)), dirname(plugin_basename(__FILE__)));

Et si jamais vous utilisez votre plugin en lien symbolique ça ne fonctionnera pas … mais on s’éloigne du sujet

Et pour WordPress Mu ?

Je ne m’attarderai pas dessus mais les manipulations sont sensiblement les mêmes. Je n’ai pas encore eu l’occasion d’essayer mais j’ose imaginer qu’il n’y a pas tant de différences que ça

Conclusion

Le jour où vous souhaitez migrer vers une autre version majeure de WordPress, c’est simple : il suffit de changer les externals vers le tag adéquat.

Pourquoi ne pas utiliser le trunk directement me demanderez-vous ? Le trunk de WordPress est plutôt instable puisque c’est là que se construit la prochaine version de manière systématique. L’utilisation des branches permet de bénéficier des correctifs sans avoir à modifier le moindre external.
Si vous avez un grand besoin de stabilité, alors utilisez les tags qui sont en principe figés.

On remarquera aussi que malgré son âge, WordPress commence à peine à proposer des solutions d’industrialisation.
Les liens symboliques sont en effet très mal gérés. Tentez d’utiliser un seul répertoire source pour plusieurs blogs avec des liens symboliques et tout s’effondre.

La preuve en est aussi avec le manque de ressources disponibles sur le Web et traitant ce sujet. Ça m’étonnerait d’être le premier à vouloir déployer du WordPress via SVN.
Les choses s’améliorent mais pour le côté code is poetry, on en est encore loin.

J’ai publié il y a quelques jours la version 1.2 du plugin Amazon Widgets Shortcodes. Cette version suit plusieurs autres publications plus intimistes, à des fins de tests grandeur nature. Ce fût en tous cas suffisant pour commencer à attirer l’attention de traducteurs.

Concrètement, ce plugin facilite la monétisation des blogs WordPress en évitant de copier du HTML fourni par Amazon. Les widgets Amazon s’intègrent du coup par le biais de petits raccourcis textuels, les shortcodes.

Présentation et explications sur la conception du plugin.

Widgets Amazon

Amazon fournit des widgets au travers de son programme Partenaires (également nommé Associates dans le reste du monde). Ces widgets permettent d’intégrer des fonctionnalités sympathiques sur son propre site ou blog à partir d’un code HTML généré par leur interface.

La liste des widgets et des fonctionnalités est assez importante :

• lien produit (avec ou sans image)
• widget carrousel (présentation de produits dans un carrousel d’images)
• widget slideshow (présentation de produits sur une bande déroulante)
• widget envies cadeaux
• liens textuels
• liens aperçu produit
• liens contextuels
• etc.

Les widgets se créent en ligne et au final, leur code HTML nous est gentiement proposé.

Premier constat : le code fourni par Amazon a beau être fonctionnel, c’est quand même un sacré bazar. Pour peu que l’on bascule de l’éditeur Visuel à l’éditeur HTML de WordPress, le code est nettoyé par endroit le rendant quasi inutilisable.

Second constat, copier ce code dans l’éditeur visuel de WordPress (TinyMCE) est passablement horrible avec parfois jusqu’à 10 lignes de HTML illisible.

Enfin, côté maintenance c’est pas gagné : si Amazon change le code HTML des éléments sans assurer de rétrocompatibilité (ce que je ne leur souhaite pas), les widgets déjà insérés seraient rendus inopérants.

Arborescence du code d'Amazon Widgets Shortcodes

Les objectifs fixés et avoués du plugin Amazon Widgets Shortcodes

Toujours désireux d’utiliser les widgets Amazon et sentant que ça pouvait être pratique, je me suis dit que c’était l’occasion rêvée de produire un plugin utile, bien conçu et fiable.

En développant ce plugin, je me devais d’atteindre ces objectifs :

• le rendre internationalisable (i18n)
• le proposer en 2 langues minimum (français et anglais)
• permettre son exploitation facilement et sans se prendre la tête (KISS)
• fournir une documentation d’utilisation appropriée
• rendre l’évolution du code aussi souple que possible

Stratégie de développement

Maintenant que j’avais les idées, il fallait les mettre en place. Voici comment j’avais envisagé les étapes du développement :

1. support d’1 seul widget Amazon
2. augmentation du nombre de widgets Amazon supportés
3. stabilisation de l’API et internationalisation
4. configuration intégrale depuis l’admin WordPress
5. intégration des widgets depuis l’éditeur HTML WordPress (TinyMCE)
6. intégration du copier/coller de code HTML Amazon
7. support intégral des widgets
8. améliorations pratiques et ergonomiques
9. utilisation en tant que widgets dans les thèmes WordPress
10. gestion intégrée des widgets (Amazon ne fournissant aucune API à ce niveau)

Cette progression permet de créer petit à petit l’application, de la rendre modulaire et extensible. L’ajout et le support de nouveaux widgets ne doit pas remettre en cause l’architecture du plugin.

Code JavaScript d'Amazon Widgets Shortcodes

Ce à quoi il faut penser en développant un plugin

Développer un plugin c’est bien. Il faut cependant toujours avoir en tête qu’il ne sera pas installé que sur son propre blog. Ça doit être le leitmotiv qui accompagne toute nouvelle idée afin de prévoir les installations et mises à jour.

Voici 5 points clés pour développer un bon plugin :

1. penser utilisateur avant tout (c’est lui qui doit savoir l’utiliser, pas ses développeurs)
2. penser que le développement pourra se faire en équipe (clarté du code, documentation)
3. penser que le plugin pourra être utilisé dans plusieurs langues (i18n)
4. penser aux scénarios de mise à jour (base de données, tests fonctionnels/unitaires)
5. penser que ce plugin n’est pas le seul sur le blog (optimisation, nommage)

Intégration d’un widget Amazon par copier/coller

C’est le serpent qui se mord la queue diraient certains.
Et pourtant, c’est la meilleure fonctionnalité qu’on puisse apporter. Tout le monde n’étant pas technicien, les utilisateurs lambda apprécieront de pouvoir simplement se débarrasser de leur code HTML Amazon pour le convertir sur leur blog.

Simple comme bonjour !

Conclusion

Le développement d’un plugin WordPress est relativement aisé. Certaines parties de la documentation sont quelque peu obscures, notamment celle qui touche l’éditeur HTML et son internationalisation. Il m’a fallu m’inspirer d’autres plugins mais aussi comprendre que WordPress 2.5 mettait en cache la configuration de TinyMCE dans un fichier.

L’autre partie ardue fût le plugin TinyMCE : la documentation est toujours partagée entre la version 2 et la version 3 et là encore, la meilleure documentation reste le code source d’origine. Je saluerai au passage le gros effort de lisibilité que leur équipe a apporté. On en prendrait presque du plaisir à le lire

Quoiqu’il en soit, le plugin WordPress Amazon Widgets Shortcodes est bel et bien prêt à être utilisé par le grand public. Le minimum vital est là. Le confort aussi.

Dans le billet ENES : Open Source ? j’expliquais les bases du renouveau du projet. Renouveau important car aux yeux du « public », et même aux notres, on en reste sur une impression de stagnation. Pendant que jeandubois s’occupe de la partie développement et matériel, je refonds le site Web. Bientôt à mi-parcours et à moins d’un mois de son relancement, que retenir ?

Petit rappel pour celles et ceux qui ont eu la flemme de suivre le lien ci-dessus : ENES est initialement un projet de conservation de jeux NES, ceux qui ne l’étaient pas encore. On élargit notre vocation désormais en proposant une plateforme matérielle d’extraction de données (de cartouches de jeu) ainsi que les logiciels nécessaire à l’extraction. En clair, avec un peu de connaissances, on peut aussi bien dumper de la Super NES comme de la Neo Geo (en théorie).

Le nouveau site d’ENES sera bien plus axé communication : de notre côté il sera plus facile de rédiger des brèves et d’en générer des exports RSS (format de fichier adapté à l’actualité car il peut être « interprété » par de nombreux navigateurs, des lecteurs de news et même des sites Web.
L’avantage pour les visiteurs et autres personnes intéressées par le projet c’est que l’actualité du groupe ira directement à eux : pas besoin de passer n-fois sur le site pour repérer des mises à jour; une actualisation du fil RSS suffit pour lister les dernières entrées. Comble du bonheur, ces fils sont disponibles en français et en anglais.

Bilinguisme

Oui tiens d’ailleurs, dans mon dernier billet sur ENES je parlais d’utiliser un blog pour l’actualité. Ben en fait non pour la simple et bonne raison qu’apparemment, avoir un même article en 2 langues différentes c’est impossible. Soit les blogs sont monolingues soit ils faut écrire 2 articles (1 pour chaque langue) dans 2 catégories (1 catégorie = 1 langue). Sans parler du côté usine à gaz et nullement intuitif. Bref une fois de plus j’ai opté pour la solution maison en reprenant les principaux principes du premier site d’ENES.
Physiquement, ENES n’a qu’un seul site mais dans la pratique, il y en a 2 : le site français et anglais. La langue principale du navigateur est automatiquement détectée; dans le cas contraire, la langue par défaut est choisie (l’anglais). Le visiteur (ou moteur de recherche) est donc gentiement guidé vers le site en question avec bien entendu la possibilité de basculer à tout moment d’une langue à l’autre.

Actualité

Quand on poste un billet d’information, on le rédige à la fois en anglais et en français. Les titres peuvent être totalement différents : ça ne pose pas de problèmes pour les adresses naturelles. En effet les adresses sont dites « naturelles » et canoniques : leur arborescence a un cheminement logique, comme si vous aviez des dossiers, sous-dossiers, sous-sous-dossiers etc.
Exemple : http://monsite/news/2005/09/22/titre-de-la-news.htm.
En lisant l’adresse, on devine que l’on se trouve dans la rubrique d’actualité du site, au cours de l’année 2005, dans son mois de septembre du jour 22 et pour une brève intitulée « Titre de la news ». Ca c’est une adresse naturelle.
Canonique parce que si on supprime « titre-de-la-news.htm », on tombera sur toutes les brèves du 22 septembre 2005. Si on poursuit le raisonnement, en supprimant en plus le chiffre 22, on aura toutes les brèves du mois de septembre 2005. Clair, net et précis.

Tellement clair que peu de systèmes fonctionnent comme ça, encore moins en gérant 2 langues. Là oui : l’adresse anglaise aura le titre anglais tandis que l’adresse française le titre français. Difficile de faire mieux et plus clair. Encore une fois, il aurait été impossible d’avoir ça sur un système de blogs préconçu.

La même page, en anglais ce coup-ci

Fils RSS

Une fois qu’une brève est ajoutée ou éditée, vu qu’il n’y a pas non plus 36 000 actualités par jour, le mieux est de générer directement à la suite le fil RSS. Ou plutôt LES fils RSS, anglais et français. C’est pas bien compliqué, suffit de lire la documentation, générer un fichier texte et … et quoi d’ailleurs ? La meilleure solution est-elle de générer dynamiquement un fichier à chaque appel (donc refaire n-fois la même routine alors que le contenu n’a pas changé) ou bien générer une fois pour toute un fichier « statique » ?
Je suis plutôt un partisan de l’économie (on appelle ça parfois la « flemme ») : c’est à dire produire le même résultat avec le mimimum d’effort. Donc en principe, pour moi, je préfère générer un fichier à chaque news éditée puis l’enregistrer en dur comme un fichier classique. Seulement voilà , sur l’hébergement fourni par notre hébergeur de projet, on ne peut pas créer de fichier comme ça. Verdict : tout dynamique ?

Ouaip ben non : on va faire comme prévu sauf qu’au lieu de générer le résultat dans un fichier, on va le stocker … dans la base de données. A première vue c’est débile (car on solicite aussi la base de données) mais c’est la meilleure alternative : la requête est simple (une ligne à chercher contre plusieurs dans le cas du tout dynamique), quasiment aucun traitement à effectuer (requête SQL + affichage au lieu d’une requête « moyenne », l’assemblage puis l’affichage). C’est donc plus rapide que du tout dynamique, un poil plus lent que la version statique (lire un fichier c’est toujours plus rapide qu’accéder à une base de données).

Même si c’était un peu technique, j’explique au moins la logique de fonctionnement : le tout dynamique est débile car il ne sert à rien de générer n-fois un contenu strictement inchangé : ça bouffe des ressources (RAM, processeur) pour pas grand chose. Ca fait juste très style mais c’est là le seul intérêt (sauf quand il est impossible d’agréger le contenu et que là , le fichier est effectivement dynamique).
La prochaine étape sera la nouvelle liste de dumps avec un moteur de recherche intégré afin de rechercher en 2 clics si un jeu en notre possession a bel et bien été sauvegardé.

Petite note : j’ai pris un peu de retard dans la rédaction de mes billets, j’ai 3 films à commenter (La moustache, Collision et la déchirure), la fin de mes vacances et c’est déjà pas mal En attendant j’vais un peu me reposer pardi.