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.

S’il me paraissait logique de créer chaque dépôt manuellement dans Subversion, ça l’était en revanche beaucoup moins pour le serveur Web Apache. Je souhaite en effet disposer d’un accès HTTP, pour tester les différents protocoles SVN entre autre. Flemme oblige, je n’avais vraiment pas envie de configurer également des alias et configurations de répertoires pour chaque dépôt.

Une fois de plus, la flemme a vaincu.

Après avoir lu des billets intéressants sur l’installation de Subversion sur Ubuntu ainsi que l’installation de Subversion sur Ubuntu ou Debian, je devais me rendre à l’évidence : pour chaque dépôt créé, il faut également modifier (à la main) le fichier de configuration d’Apache.

Directive DirectoryMatch

J’ai tenté de contourner le problème en utilisant la directive DirectoryMatch d’Apache mais impossible de récupérer le résultat du masque.
Si vous comptiez faire ceci, oubliez de suite, ce n’est pas possible :

<directorymatch "/chemin/vers/racine/svn/([a-z0-9-]*)>
 DAV svn
 SVNPath /chemin/vers/racine/svn/$1
 ...
</directorymatch>

En effet, DIrectoryMatch ne fait que vérifier l’existence d’un chemin par rapport à un masque ; il n’en récupère pas le contenu pour une exploitation ultérieure. C’est bien dommage.

Solution : SVNParentPath

Heureusement tout a été prévu (mais rarement mentionné). Au lieu d’utiliser SVNPath pour renseigner le chemin d’un seul dépôt, il vaut mieux utiliser SVNParentPath qui, lui, spécifie la racine des dépôts Subversion. En gros, tous les répertoires enfants à SVNParentPath sont considérés comme étant des dépôts (référentiels) indépendants.

Exactement ce qu’il me fallait.

Au final, après avoir cherché à configurer Subversion pour Windows, voici ce que j’ai rajouté dans ma config Apache :

<Location /svn>
  DAV svn
  # any /svn/foo URL will map to a repository D:/svn/foo
  SVNParentPath D:/svn
  #AuthType Basic
  #AuthName "Subversion repository"
  #AuthUserFile d:/svn/.htaccess
  #Require valid-user
</Location>

Je ferai très probablement d’autres billets sur Subversion. Depuis le temps que je voulais m’y mettre, apprendre ses rouages et sa rigueur ne sont pas forcément faciles.

Je vous l’annonce, depuis janvier 2007 je suis boulimique. Boulimique mais d’informations, de connaissances et de savoir. S’il y a bien un univers qui ne pardonne pas à ceux qui se contentent des acquis, c’est bien celui d’Internet. Donc en plus des 300 brèves quotidiennes que je lis, je viens de passer commande de trois livres :

• Ppk on Javascript (New Riders Publishing, en anglais)
• CSS Mastery (Friends of ED, en anglais)
• Subversion : Pratique des projets collaboratifs avec SVN (Eyrolles, en français)

Au début de l’année j’avais jeté mon dévolu sur trois autres références pour voir où j’en étais, ce que j’avais encore à apprendre (beaucoup) et ce qui pouvait me faciliter la vie :

• PHP 5 avancé (Eyrolles) que j’avais trouvé moyen car davantage débutant qu’avancé
• Maîtriser MySQL 5 (O’Reilly) que je n’ai pas encore terminé mais intéressant bien que pas assez complet à mon goût au niveau des fonctions utiles
• Gestion de projets avec Subversion (O’Reilly) que je n’ai pas non plus terminé, très technique et instructif mais il me manquait les bases pour bien comprendre comment bien utiliser Subversion

D’ailleurs peut-être que ça en intéresse certains d’avoir une critique de plus sur ces ouvrages. Faites signe (ou canard)

C’est finalement en relisant un article fort intéressant concernant l’installation d’un dépôt Subversion sous Ubuntu que j’ai décidé de passer à l’acte.

Subversion : Pratique des projets collaboratifs avec SVN

Subversion est un formidable outil de gestion et d’archivage de fichiers très utilisé dans les projets informatiques. Il est performant, efficace et permet le travail simultané de plusieurs personnes sur un même projet. Je souhaitais coupler cet outil avec l’interface en ligne TRAC pour gérer des tickets d’incidents ainsi que les feuilles de route. Pour ne plus jamais oublier un bug à corriger ou une fonctionnalité à rajouter.

Ppk on Javascript

J’ai découvert le site de l’auteur bien avant qu’il écrive son livre et je le trouvais déjà fort bien renseigné concernant les différences de comportement entre les différents navigateurs Web concernant Javascript. Egalement de bonnes explications à propos de la gestion des objets, des évènements et les manipulations du DOM. Ce livre très orienté sur la pratique et l’expérience de son auteur (le plus important à mes yeux) aborde les manipulations de CSS, les incompatibilités des navigateurs, bien déboguer son code ainsi que des cas pratiques avec des exemples concrets. Pour que Thomas = { 'taille' : 183, 'feignant' : true } ne soit plus un mystère pour vous

CSS Mastery

La même chose que Ppk on Javascript mais avec des CSS ! Pour bien comprendre les différents bugs des navigateurs, les histoires de DOCTYPE et de mode navigateur, les bonnes pratiques pour maintenir son code CSS, les hacks, les filtres et tout ce qui est recommandé ou pas. Bref ça me paraît être un bon choix.

Rendez-vous dans quelques temps : on verra bien si ça me servira