La méthode bourrin

Il existe une méthode qui a fait ses preuves depuis de nombreuses années, à l’époque où peu de sites n’utilisaient de langages tels que PHP. Charger les fichiers à mettre à jour via votre client FTP favoris en remplaçant les anciens. Le problème c’est que le temps de transfert n’est toujours pas immédiat. Donc pendant que vous allez transférer vos fichiers, vos utilisateurs vont utiliser une application avec des bouts de code de versions différentes et là c’est le drame. Soit vous avez de la chance et tout fonctionne, soit le site plante avec une erreur PHP et votre visiteur vous prend pour un charlot, soit tout semble fonctionner pour lui et vos données deviennent incohérentes dans la base. Bref ce n’est pas la meilleur solution si vous avez un peu de trafic sur votre site. Sinon utilisez la plage de 2 heures lorsque personne ne visite votre site (souvent entre 2h et 4h du matin).

La méthode dérangement

Une autre méthode consiste à rediriger toutes les visites vers une page indiquant que pour des raisons techniques et/ou de maintenance le site est indisponible pendant quelques temps, le temps pour vous de mettre à jour tous les scripts, de mettre à jour la base de données et de vérifier que tout s’est bien passé. Malheureusement pendant ce temps, les visiteurs peuvent se décourager et ne pas revenir si le temps de maintenance est trop long ce qui est souvent le cas pour les visites depuis un moteur de recherche.

La méthode transparente

La méthode que je vous propose devrait vous permettre de réduire considérablement le temps d’indisponibilité lors d’une mise à jour majeure.

La première chose à faire est de tester la nouvelle version en local pour s’assurer que tout va fonctionner. C’est évident mais comme ça va sans dire, c’est toujours mieux en le disant. C’est la phase de qualification (pour les pros).

Procédure de déploiement d’une nouvelle version de WordPress :

1. Préparation (en local):
   1. Placer la nouvelle version dans un répertoire spécifique par exemple dans v2
   2. Chargez votre thème dans le dossier v2/wp-content/themes ainsi que vos plugins dans v2/wp-content/plugins
   3. Chargez le fichier de localisation si vous n’utilisez pas WordPress en anglais. Pensez à prendre le fichier de localisation correspondant à la version que vous déployez.
   4. Chargez le contenu de vos uploads (wp-content/uploads) si vous n’avez pas déplacer vos upload ailleurs.
   5. Testez
   6. Chargez le fichier wp-config.php de la version précédente dans le dossier v2 pour récupérer le paramétrage de base de données et de localisation.
2. Déploiement (sur votre serveur)
   1. Chargez le contenu de votre répertoire v2 à l’endroit où votre site doit se situer. A la racine du domaine si votre site est accessible directement depuis le domaine, dans le répertoire « blog » si WordPress est accessible via une adresse du type : http://votredomaine/blog/.
   2. Connectez-vous à l’interface d’administration de la version précédente et modifiez dans les options générales l’adresse WordPress : il suffit de reprendre l’adresse du blog et de coller à la fin le nom du répertoire de la nouvelle version (ici v2)
   3. Préparez en local un fichier index.php qui contient le code suivant :

      <?php /* Short and sweet */
      define('WP_USE_THEMES', true);
      require('./v2/wp-blog-header.php');
      ?>

      v2 doit correspondre au nom du répertoire qui contient la nouvelle version.

3. Bascule
   1. Connectez-vous à l’interface d’administration de la nouvelle version pour mettre à jour la base de données
   2. Chargez le fichier index.php de l’étape 2 dans le dossier père de la nouvelle version

C’est fini. De plus de cette façon, vous avez placé la nouvelle version wordpress dans son propre répertoire ce qui a pour vertu de l’isoler du reste de votre site. Avantage : seule l’étape 3 étant cruciale, vous pouvez préparez les autres étapes sur des mois.

Vous me direz qu’entre les étapes 3.1 et 3.2, vous allez vous retrouvé dans la situation de la méthode bourrin où la version précédente manipule un modèle de données différent de celui pour lequel elle a été construite. Certes rien ne vous empêche de passer par l’astuce du malin et de rediriger vos visiteurs vers un page de maintenance en indiquant de revenir dans la seconde, mais le temps de bascule est réduit à son minimum. Cette opération ne doit pas vous prendre plus de quelques secondes, soit le temps de passer de votre navigateur à votre client FTP.

A moins que vous ne fassiez cette opération depuis une ligne GSM…

J’ai fait quelques tests ce matin, après avoir fraichement installé la RC1 (téléchargeable ici). Je n’ai pas testé la localisation mais il n’y a pas de raison que cela ne fonctionne pas.

Cette nouvelle version n’apporte pas grand chose de plus, si ce n’est quelques petites fonctionnalités, très intéressantes. Principalement, celle qui permet de remplacer la page d’accueil par une page et une page par la liste des articles, ayant pour conséquence directe de rendre obsolète mon article sur le sujet.

Dans la barre le lien vers le gestionnaire de liens dans l’administration n’était pas le bon, c’est maintenant réparé. Je pense que ceux qui utilisent le gestionnaire de lien, n’ont pas attendu pour faire la correction eux-même. Mais au moins on part sur des bases saines pour la futures versions.

La nouvelle version est donc disponible à la même adresse que d’habitude.

Concernant les fonctionnalités nouvelles, il y en a principalement deux :

• Plus de fonctions sont accéssibles depuis la barre et ces fonctions ne s’affichent que si l’utilisateur a les droits apropriés
• Le style est totalement paramétrables : la couleur de fond, du texte, ainsi que la position gauche ou droite et la taille du texte (et donc de la barre)

N’hésitez pas à faire vos remarques ici dans les commentaires. Je pense avoir pris en compte vos remarques sur le forum wordpress-fr…

Le premier vient du fait qu’il ne s’agit d’une balise vide comme input qui porte le texte du bouton dans un attribut. Il est donc possible de faire des boutons avec des contenus complexes, alors que la balise input ne permet que de présenter une chaîne de caractères.

<input type="submit" value="Envoyer votre réponse" />

<button type="submit"><strong>Envoyer</strong> votre réponse</button>

Autre avantage, il est possible de passer une valeur de paramètre différente du texte du bouton:

<button type='submit' name='action' value='1'>Ajouter</button>
<button type='submit' name='action' value='2'>Supprimer</button>

Cette balise permet d’utiliser n’importe quelle balise dans le contenu exceptés les liens et d’autres contrôles de formulaire bien entendu. De plus les navigateurs n’impose pas de style prédéfini pour la balise button à l’instar de la balise input qui reprend un style peu joyeux d’interface utilisateur « classique ». Il devient beaucoup plus aisé de faire coïncider le design du formulaire avec celui du site, voir même de s’affranchir du bouton valider.

Aaron Gustafson donne de beaux exemples d’utilisations de cette balise button :

• Transformer un formulaire pour qu’il ne ressemble pas à un formulaire (choix entre plusieurs cadeaux)
• Application pour la vente d’hébergement
• Application pour une gestion de la pagination

Avec cette solution l’arborescence des pages WordPress sont visibles à la racine du site alors que les articles du blog apparaisse dans un dossier nommé blog.

Pour donner au weblog son propre répertoire dans l’arborescence des pages, il faut d’abord modifier les permaliens pour que les articles soient publiées dans un sous-répertoire en changeant la structure pour faire apparaitre un sous répertoire blog par exemple. La structure des permaliens devrait ressembler à ceci : /blog/%year%/%monthnum%/%day%/%postname%.

Ensuite vous pourrez remarquer que si vous allez à l’adresse http://www.votresite.com/blog une erreur 404 va apparaitre. C’est parce que WordPress n’interprète pas ce répertoire comme l’accueil du weblog. Pour cela il faut ajouter une règle de redirection pour ce répertoire en utilisant le filtre rewrite_rules_array qui permet d’ajouter des règles de redirections. Nous allons donc utiliser les point d’entrés fournis par WordPress pour les plugins.

Dans un thème WordPress la page d’accueil du weblog utilise le gabarit home.php si celui-ci existe, sinon c’est le fichier index.php qui est utilisé. Nous allons ajouter une règle permettant à WordPress d’afficher un autre gabarit quand nous sommes sur l’accueil du site et de rediriger vers le gabarit de l’accueil classique du blog lorsque nous sommes dans notre répertoire /blog/.

Pour cela il faut ajouter un fichier functions.php dans le thème, si celui-ci n’existe pas déjà. Ainsi notre modification sera active pour notre thème uniquement et ne sera pas dépendante de l’activation ou non d’un plugin. Cela évite les mauvaises manipulations et de voir notre mise en page totalement désordonnées en cas de désactivation du plugin ou de changement de thème.

Il va falloir mettre en place 2 fonctions pour gérer cette fonctionnalité :

• la première (add_rules) va permettre à WordPress de
  reconnaitre notre dossier /blog/ en l’assimilant à l’accueil de
  la partie weblog
• la seconde (template_redirect) va permettre à WordPress
  d’utiliser le fichier homepage.php comme gabarit de la
  racine de notre site.

Pour éviter que nos fonctions entrent en collision avec celles de WordPress, celles-ci seront encapsulées dans une classe. De la même manière que je le préconise pour les plugins.

  function add_rules($rules) {
// Récupération des informations de redirections d'adresse
    global $wp_rewrite;
// Génération des liens pour les commentaires, pagination, etc.
    $new_rules = $wp_rewrite->generate_rewrite_rules($wp_rewrite->front);
// Génértation de la règle de redirection principale
    $global_home_rule = substr($wp_rewrite->front,1).'?';
    $new_rules[$global_home_rule] = "index.php";

// ajout des nouvelles règles de redirection
    $rules += $new_rules;
    return $rules;
  }

  function redirect() {
//Récupération du contexte
    global $wp;
// S'il s'agit de l'accueil et de la racine du site charger le gabarit homepage.php
    if(is_home() and ($wp->matched_rule == '')) {
      if(file_exists(dirname(__FILE__).'/homepage.php')) {
        include(dirname(__FILE__).'/homepage.php');
      } else {
        include(get_query_template('homepage'));
      }
// La page est affichée on sort
      exit;
    }
  }

Sans vouloir dénigrer le travail de biou et zbb qui ont apporté à DotClear le plugin antispam Spamplemousse qui manquait terriblement à DotClear, je me suis penché sur l’intégration de l’API Akismet. Pour moi, il s’agit de 2 méthodes de détection des spams qui sont complémentaires et qui peuvent coexister sur le même blog. De plus

J’ai quasiment fini le plugin pour DotClear2, et je recherche donc quelques beta-testeurs volontaires pour utiliser ce plugin sur un ou plusieurs de leur blog sous DotClear2.

Fonctionnalités du plugin :

• Activation du plugin pour chaque blog
• Détection des spams à la soumission des commentaires et des trackbacks via le système de détection d’Akismet.
• Soumission à Akismet des spams non détectés et des commentaires détectés injustement comme spam car le système peut apprendre de ses erreurs.
• Possibilité d’activer une suppression automatique des spams après un certains nombre de jours, paramétrable par l’administrateur du blog.
• Système de log pour le super administrateur.
• Gestion des droits pour le paramétrage du plugin.
• Affichage d’une liste des spams.

Si vous êtes intéressés pour tester ce plugin, contactez-moi via les commentaires de cet article. De même si vous avez des questions, laissez un commentaire.

Quelques bonnes pratiques

• Encapsuler ses functions dans une classe afin de complètement isoler le fonctionnement du plugin de WordPress. Cela évite les conflits de variables, de nom de fonction, etc.
• Penser à l’internationalisation du code en utilisant les fonctions __() et _e() et déclarer un domaine pour votre plugin.
• Penser à documenter l’utilisation du plugin : rédiger une page de mode d’emploi que l’on affichera ensuite par le menu plugins > aide plugin X
• N’utilisez pas n’importe quel « hook », mais assurez-vous qu’il correspond bien à votre usage.

Un modèle de squelette de plugin

Dans le squelettes suivant, je vous propose un petit coup de pouce pour mettre en place vos plugins. Copiez ce code dans un nouveau fichier et créez votre plugin…

Dans l’exemple proposé, le plugin va ajouté à la fin de chaque billet le nom du plugin. Cen’est pas très utile mais ça permet de faire un exemple.

/*
Plugin Name: Nom du Plugin
Plugin URI: http://www.example.com/votre_plugin
Description: Ce que fait votre plugin en quelques mots.
Version: 1.0
Author: Votre Nom
Author URI:  http://www.example.com
*/

/*
Squelete de plugin : Mode d'emploi

1. Remplir le cartouche en début de fichier, ce sont les informations qui apparaissent dans la description du plugin dans WordPress
2. Remplacer {{VotrePlugin}} par le nom de votre plugin composé de lettres (sans accents), chiffre, underscore (_)
3. Ajouter vos fonctions dans la partie à éditer
4. Gérer le contenu de la page d'aide de votre plugin (fonction AdminHelpPage)
5. (facultatif) Gérer l'installation options de paramétrage, tables... (fonction install)

*/

class {{VotrePlugin}} {
  var $domain = '';
  var $version = '1.0'; //Changer pour correspondre à la version courante
  var $option_ns = '';
  var $options = array();

// Raccourci interne pour ajouter des actions
  function add_action($nom, $num = 0) {
    $hook = $nom;
    $fonction = $nom;
    if(!$num) { $fonction .= $num; }
    add_action($hook, array(&$this, 'action_'.$nom));
  }

  function {{VotrePlugin}}() {
// Initialisation des variables
     if ($this->domain == '') $this->domain = get_class($this);
     if ($this->option_ns == '') $this->option_ns = get_class($this);
// Récupération des options
		$this->options = get_option($this->option_ns);

// Doit-on lancer l'installation ?
    if(!isset($this->options['install']) or ($this->options['install'] != $this->version))
    	$this->install();

//Charger les données de localisation
    load_plugin_textdomain($this->domain); 

// gestion automatique des actions
		foreach(get_class_methods(get_class($this)) as $methode) {
			if(substr($methode, 0, 7) == 'action_') {
				$this->add_action(substr($methode, 7));
			}
		}		

  }      

  function action_admin_menu() {
    if (function_exists('add_submenu_page')) {
      add_submenu_page('plugins.php',
                       __('{{VotrePlugin}}', $this->domain),
                       __('{{VotrePlugin}}', $this->domain),
                       3,
                       basename(__FILE__),
                       array(&$this, 'AdminHelpPage'));
    }
  }

  function set($option, $value) {
  	$this->options[$option] = $value;
  }

  function get($option) {
  	if (isset($this->options[$option])) {
  		return $this->options[$option];
  	} else {
  		return false;
  	}
  }

  function update_options() {
  	return update_option($this->option_ns, $this->options);
  }

//---------------------------------------------
// Editez à partir d'ici
//---------------------------------------------

  function install() {
// Fonction permettant l'installation de votre plugin (création de tables, de paramètres...)
		$this->set('install', $this->version);
		$this->set('page', 0);
		$this->update_options();
  }

  function AdminHelpPage() {
  	echo '
Page d'admin de votre plugin

';
  }

  function action_wp_title($titre) {
  	return $titre.' (on stéroïd)';
  }

//---------------------------------------------
// Fin de la partie d'édition
//---------------------------------------------

}

$inst_{{VotrePlugin}} = new {{VotrePlugin}}();

Dans la partie édition, il suffit de créer de nouvelles méthodes action_« nom du hook » pour que celles-ci soient automatiquement enregistrées et exécutées par WordPress. De plus il est facile de gérer les options de votre plugin parmi les options de WordPress en utilisant les méthodes get, set et update_options

N’hésitez pas à faire vos remarques dans les commentaires.

Télécharger le squelette

Ressources connexes

Pour vous aider à créer vos propres plugins, n’hésitez pas à consulter :

• Ecrire un plugin (en anglais)
• Plugin API (en anglais)
• Hook Database : documentation des points de branchement des plugins (en anglais)

Le plugin DashBar sert donc à avoir toujours sous la main les liens importants liés à l’activité du site et à la maintenance des articles et pages.

Elle permet pour les utilisateurs identifiés de voir apparaitre une barre d’administration similaire à celle présente sur WordPress.com offrant ainsi un accès direct:

• au tableau de bord
• au formulaire d’écriture d’article
• à la modification des articles présents sur la page
• à la modération des commentaires
• à son profile d’utilisateur WordPress
• au lien de déconnexion

Tous les détails sur la page officielle du plugin DashBar pour WordPress

Ce plugin a été testé sur ce site en version 1.5.2 (à l’heure actuelle) mais il a aussi été testé sur la version 2.0RC1 de WordPress. Problème connu : Problème de taille de la barre sous Internet Explorer mais je ne connais que très peu de personnes que cela pourrait gêner

La dépose d’un commentaire sur cette page fait office de ticket si vous rencontrez des problèmes, merci de préciser sous quelle version de WordPress et avec quel thème le problème est rencontré.