Here With Me

Il y a quelque temps, Matt et Automattic ont annoncé le lancement de VaultPress, un plugin permettant de sécuriser une installation WordPress. On me demande régulièrement, la meilleure méthode pour sécuriser un site web fonctionnant avec WordPress, et ma réponse est la suivante : « Backup journalière des fichiers et de la base de données sur 2 points de stockage ». Et oui la meilleure sécurité, c’est la sauvegarde !

Alors, lorsque j’ai appris le lancement de VaultPress, je me suis dit dans un premier temps : chouette un plugin améliorant la sécurité de WordPress, mais après avoir lu et visionner la vidéo de présentation, j’ai compris qu’il ne s’agissait que d’un plugin de backup automatique des données, alors effectivement on peut se poser la question de l’intérêt de ce service pour les personnes ayant un serveur dédié, mais sur un mutualisé milieu/haut de gamme et/ou pour un blog sensible le service peut s’avérer intéressant.

J’ai donc décidé de postuler à l’inscription de la béta, une première fois pour mon blog perso, sans réussite. Et une seconde fois, pour le site WordPress Francophone, et bingo, 5 jours après je reçois la fameuse invitation permettant de s’inscrire au service !

Lors de l’inscription au service, on vous propose 3 niveaux de service, le basique qui comprend toutes les fonctionnalités de backup, le niveau premium qui offre du support technique en plus et enfin un niveau entreprise disponible après contact pour des services plus personnalisés, audit du code, etc. Le service basique est facturé 15$/mois, tandis que le service premium est facturé 40€/mois.

Dans le cadre de WordPress Francophone, j’ai choisi l’abonnement à 15$/mois afin de tester à moindre coût le service.

Le plugin

Une fois payé, on vous propose de télécharger une extension à installer sur le blog WordPress de votre choix. Une fois, le plugin installé et activé, un menu VaulPress apparait dans le menu de la console d’administration et permet de voir l’avancement de la sauvegarde du blog sur les serveurs de VaultPress.

Le backup se fait en arrière-plan, il n’est pas nécessaire de se connecter à WordPress ou de laisser une fenêtre du navigateur pour que le transfert se fasse. Le transfert initial est assez long, tout dépendra du nombre d’articles et de commentaires, mais surtout tout dépendra de la quantité de pièces jointes.

Dans le cadre de WordPress Francophone, j’ai activé le plugin le soir à 21h, le lendemain tous les fichiers avaient été synchronisés.

Une fois les fichiers complètement synchronisés, on peut observer un tableau de bord VaultPress qui nous affiche les informations principales, nombres d’articles, commentaires, termes, révisions, médias, etc. On peut également trouver le nombre de copies du blog. (ici 40)

Le service

Maintenant que nous avons passé en revue les pages du plugin sur l’admin WordPress, nous allons voir les fonctionnalités du site VaultPress.com. La page de connexion, bien que stylé VaultPress nous rappelle que WordPress n’est jamais très loin…

Pour se connecter à VaultPress, il faut posséder un compte WordPress.com, ce dernier vous sera demandé lors de l’inscription initiale, vous devez alors saisir vos identifiants WordPress.com.
Une fois connecté, on tombe sur un tableau de bord qui contient tous les sites protégés par VaultPress, ici il n’y a que WordPress Francophone.

Le statut affiche la dernière mise à jour de la base WordPress avec VaultPress, ici on peut voir qu’il s’agit du plugin du compteur de vues utilisées sur WordPress Francophones. Le menu propose de voir l’intégralité des backups de votre site, le log d’activité des sauvegardes ainsi qu’un formulaire de contact.

La page « Backups » nous propose de compacter, d’archiver et de télécharger l’ensemble des fichiers et la base de données de WordPress pour chaque backup réalisé. Ainsi, il est possible de télécharger n’importe quel backup de votre blog, l’intérêt majeur, c’est qu’en cas de pertes de données sur votre serveur, vous pouvez récupérer les fichiers à toutes les dates, et surtout les dernières données grâce à la synchronisation en temps réel.

La page « logs » retrace toutes les modifications apportées sur votre installation WordPress, ajout d’un article, d’un commentaire, d’un méta via un plugin, etc. bref tout est enregistré !

Conclusion

La conclusion est difficile. Le service est efficace et fonctionne très bien sur un serveur mutualisé comme Infomaniak. Pour les personnes possédant un dédié, un backup automatique et incrémentiel de la base de données et des fichiers sur 2 lieux de stockage me paraissent largement suffisant…

Alors, je ne sais pas trop… Pour qui ?

Les personnes ayant de « gros blogs » sont bien souvent sur des serveurs dédiés et/ou infogérés, dans un tel cas la backup serveur me parait suffisante…
Les personnes sur des hébergements mutualisés seront-elles prêtes à mettre de l’argent pour un service de backup ? Au prix proposé, on n’est pas loin d’un serveur virtualisé de base…

Mon avis est partagé sur l’intérêt d’un tel service… et vous ? pour qui ? quel contexte ?

Depuis WordPress 3.0, il est possible de créer facilement à la volée des types de contenus (en anglais : custom post types), et d’y coupler des taxonomies. On peut par exemple, créer des petites annonces, et ajouter des taxonomies comme la région, un ordre de prix, l’état du bien, etc.

Mais les taxonomies ne sont pas nécessairement suffisantes dans un usage pro pour monter un site avec de nombreuses relations. Parfois, on souhaite relier 2 types de contenu ensemble, par exemple sur un site contenant des petites annonces, on voudra avoir la possibilité de lier des articles d’actualités à des petites annonces. Ainsi, on pourra facilement afficher des blocs de contenus liés sur le thème.

Pour y parvenir, j’ai développé le plugin : Relation Post Types

Relation Post Types - Réglages

Ce dernier offre la possibilité de choisir dans la console d’administration quelles liaisons voulez vous mettre en place. Par exemple, si vous avez des petites annonces et des articles à relier, vous pouvez choisir d’afficher un bloc « articles » sur la page d’édition des petites annonces, et inversement vous pouvez afficher le bloc « petites annonces » sur la page d’édition des articles. Ainsi, vous pouvez créer des relations dans les 2 sens.

Boite de sélection dans la page de rédaction

On peut même pousser le bouchon le plus loin et créer des relations entre contenus d’un même type de données, par exemple relier une petite annonce à d’autres petites annonces. Cela peut être utile pour générer du contenu relatif, mais manuellement.

Le plugin est disponible en téléchargement sur WP.org, dans le référentiel de plugins. Le plugin est réservé à un public de développeur ou d’utilisateurs avertis, il n’existe pas de fonctions prêtes à l’emploi à utiliser dans le thème, il vous faudra coupler les fonctions du plugin et WP_Query.

N’hésitez pas à me contacter pour tout bug ou évolution allant dans le sens du plugin.

Cforms est réellement un plugin très bien pensé, avec un nombre de fonctionnalités impressionnantes, mais il possède 2 défauts à mes yeux…

Le premier, c’est qu’il ne se trouve pas dans le référentiel officiel des plugins, ce qui rend handicapantes les mises à jour et son installation. Son deuxième défaut, c’est les problèmes liés au déplacement d’un blog.

Dans de nombreux cas, on développe un blog WordPress avec une adresse de développement et lorsqu’on souhaite migrer, tout se passe bien sauf pour le plugin Cforms, pour 3 raisons :

1. Il enregistre le chemin complet vers le plugin dans un fichier PHP
2. Il enregistre l’adresse du blog dans un fichier JavaScript
3. Il enregistre l’adresse du blog et de destination des fichiers dans une option de WordPress.

L’inconvénient est que lorsqu’on change d’adresse du blog, Cforms conserve les réglages du blog où il a été installé, chose très gênante, car cela implique la modification des 2 fichiers et un bidouillage dans la base de données pour corriger le plugin.

Pour me simplifier la vie, j’ai développé un petit plugin qui permet l’édition depuis la console d’administration de ces différentes informations. Le plugin se présente de la façon suivant :

Le plugin est disponible sur le référentiel de WordPress.org et répond au doux nom de « Advanced Edit Cforms » (j’essaie d’être explicite !)

De mon point de vue, l’une des grandes forces de Drupal est sa modularité. Je développe sous WordPress depuis bientôt 5 ans, et presque 30% des sites réalisés n’utilisent pas les articles de WordPress, mais uniquement les pages. Et je ne vous parle même pas du pourcentage de projets n’utilisant pas les commentaires…

Malheureusement, WordPress ne permet pas la désactivation des fonctionnalités non utilisées, c’est regrettable à plusieurs points. Le premier, c’est les performances, charger en mémoire des lignes de code non utilisé peut s’apparenter à un gâchis de ressources. Le deuxième point, c’est la présence de menus inutiles dans la console d’administration. Cet aspect peut être corrigé via des plugins permettant  la personnalisation la console d’administration, ces derniers proposent de choisir précisément les fonctionnalités que l’on souhaite afficher ou masquer.

Mais revenons à drupal…

Lorsque je discute avec des clients, des développeurs, on me dit, WordPress ce n’est pas vraiment un CMS, Drupal oui !

C’est vrai et faux, en fait techniquement parlant, ces 2 outils sont des CMS. WordPress est un CMS orienté gestion de contenu personnelle (plutôt blog), tandis que Drupal est un CMS « non orienté ». Autrement dit, Drupal est extrêmement générique et on le ressent bien à l’installation. (Comme l’on dit plusieurs blogueurs de la communauté WP, WordPress est beaucoup plus packagé que Drupal, plus « ready to use »).

Cette orientation, publication personnelle/blog, est donc à la fois la plus grande force et faiblesse de WordPress.

Force, car cela lui attire la sympathie d’un très grand nombre de webmestres, développeurs et surtout des utilisateurs. Faiblesse, car comme beaucoup d’outils de masse, on le considère à tort comme un outil d’entrée de gamme peu adapté au monde professionnel et à un usage CMS. Et pourtant…

J’ai installé un drupal en local, et j’ai comparé les modules par défaut de drupal avec ceux de WordPress. Vous trouverez dans un premier le tableau comparatif, puis mon analyse.

Comme vous pouvez le constater, mis à part 1-2 fonctionnalités mineures qui n’ont pas d’alternative complète sous WordPress, la totalité des fonctionnalités des modules intégrés dans Drupal possède une alternative ou plusieurs alternatives. Parfois nativement, parfois sous la forme de plugins de la communauté !

Lorsque la fonctionnalité est native, elle possède le même niveau de qualité que sa concurrente drupal. Lorsqu’il s’agit d’un plugin, c’est variable. Certains plugins de la communauté sont bien plus évolués que leurs concurrents par défaut de drupal (mais des plugins drupal peuvent équilibrer la balance), tandis que dans certains cas, c’est l’inverse.

Je conclurai en 3 points.

1. WordPress n’a rien à envier aux modules de base de Drupal. La communauté très active remplit parfaitement son rôle en réalisant des plugins de qualité similaire.

2. Le programme de plugins « officiel » de WordPress.org va permettre de constituer une base de plugins sûrs, vérifiés et mis à jour régulièrement. Ces plugins deviendront l’équivalent des modules de drupal.

3. Drupal possède une longueur d’avance concernant la possibilité de créer nativement des types de contenus à la volée. (je ne parle pas de CCK, mais des types de contenus), WordPress supporte depuis très longtemps ce genre d’ajout via des plugins, mais rien de  très propre. La version 3.0 ajoutera une API complète permettant d’ajouter autant de types de contenu que souhaité.

Dans un prochain article, je vous parlerai de Views/CCK et WordPress !

PS: J’ai sûrement oublié certaines fonctionnalités, je pense par exemple aux permissions, je me suis contenté des modules de base pour le moment, mais si vous voyez des fonctionnalités de bases qui n’existe pas dans WordPress, dites-le-moi, j’essaierai de trouver l’alternative si elle existe !

Un bug assez connu de la communauté WordPress Mu subsiste lors de l'édition de mots clefs. Le bug se produit uniquement dans certaines situations et est amplifié lors que l'installation WordPress Mu vient d'une migration de WordPress.

En fait, le bug se caractérise par la perte des catégories/mots clefs ou bien une "confusion" dans la taxonomie de WordPress. Vous éditez un mot clef avec l'ID 199 et ce dernier disparait au profit de la catégorie avec l'ID 8.

Étrange n'est ce pas !

Pourtant en base de données rien n'est perdu, c'est juste que la fonctionnalité globale catégories de WordPress Mu fout le bordel dans la table term_taxonomy.

Pour éviter d'avoir ce problème à l'édition, je vous donne un correctif très rapide : créer un fichier fix-bug-cat.php dans le dossier mu-plugins de votre installation WordPress Mu.

Et insérez-y le code suivant :

<?php
remove_filter ( 'term_id_filter', 'global_terms' );
?>

En désactivant le filtre fautif, vous vous évitez ce bug ennuyant... Pour ceux que ça intéresse, j'ai créé un ticket sur le trac à ce sujet pour probablement une correction définitive d'ici WordPress 3.0 !

Les widgets, bien qu'améliorer depuis WordPress 2.8 (avec la nouvelle classe PHP et la multiplicité de ces derniers), sont toujours une source de frustration pour les utilisateurs.
Par exemple, n'ajouter un widget que sur une certaine page reste encore mission impossible ou presque !

Ici, je vais vous montrer avec 2 bouts de code, comment on peut générer automatiquement une barre de sidebar pour chaque page de votre blog/site sous WordPress, sans oublier une sidebar par défaut pour le reste du blog et les pages n'ayant aucun widget spécifique !

Étape 1 : Enregistrement automatique des nouvelles sidebars

Ici, on procède en 2 étapes,dans un premier temps on enregistre la sidebar par défaut, puis on récupère la liste complète des pages disponibles de votre blog via la fonction get_pages() et on fait une boucle dessus pour enregistrer chaque sidebar.

<?php
if ( function_exists('register_sidebar') ) {
 // Default sidebar
 register_sidebar(array(
 'id' => "sidebar-default",
 'name' => 'Sidebar par défaut',
 'before_widget' => '<li id="%1$s">',
 'after_widget' => '</div></li>',
 'before_title' => '<h2>',
 'after_title' => '</h2><div>',
 ));
 // One sidebar by page
 $_pages = get_pages();
 foreach( (array) $_pages as $_page ) {
 register_sidebar(array(
 'id' => "sidebar-$_page->ID",
 'name' => esc_html($_page->post_title),
 'before_widget' => '<li id="%1$s">',
 'after_widget' => '</div></li>',
 'before_title' => '<h2>',
 'after_title' => '</h2><div>',
 ));
 }
 unset($_pages, $_page);
 wp_reset_query();
}
?>

Étape 2 : Appel de la sidebar depuis votre thème

(Code généralement à placer dans le fichier sidebar.php de votre thème)

Ici il ne faut pas oublier d'ajouter la variable globale $wp_query, grâce à cette dernière nous récupérons l'ID de l'objet actuellement chargé, et je vérifie que je suis bien sur une page et que la sidebar est utilisée. (autrement dit qu'elle contient au moins un widget). Si ça n'est pas le cas, je charge la sidebar par défaut.

<?php
global $wp_query;
if ( function_exists('dynamic_sidebar') ) {
 if ( is_page() && is_active_sidebar( 'sidebar-' . $wp_query->queried_object_id ) ) {
 dynamic_sidebar( 'sidebar-' . $wp_query->queried_object_id );
 }  else {
 dynamic_sidebar( 'sidebar-default' );
 }
}
?>

Vous pouvez retrouver l'intégralité du code depuis cette page pastebin

Comme beaucoup des utilisateurs de MailPress, je suis frustré de voir l'éditeur visuel cassé lors de la rédaction d'un email. En fait, il se trouve que MailPress fonctionne très bien lorsqu'il est installé sans aucun autre plugin interagissant avec l'éditeur visuel.

J'ai donc cherché une solution sur le net, et sur le groupe de support de MailPress, je suis tombé sur un sujet traitant du problème, et la réponse d'André m'a fait sourire :)

ask viper and cform dev to stop spreading their code all over all admin pages ! ?

En fait, il a en partie raison... Les plugins en questions, Viper Video Quicktags, Cforms et bien d'autres, ajoutent sans trop se soucier leur bouton à l'éditeur visuel de WordPress, et ils ne font pas du tout attention sur quelle page est chargé l'éditeur et encore moins par quel plugin... Mais ils n'ont pas tort... Lorsque j'ajoute le plugin Viper Video Quicktags, je souhaite ajouter les boutons des services vidéos... Et si je déporte l'éditeur visuel sur une page du site, je souhaite également avoir ses boutons...

En fait, le fautif à mes yeux est WordPress, les filtres offrent des superbes possibilités d'extensibilité, mais le nombre d'incompatibilités entre les extensions est en croissance exponentielle... Ici, l'éditeur visuel devrait pouvoir être appelé avec ou sans les filtres. (WordPress le propose déjà pour la fonction get_posts/query_posts)

Mais trêve de bavardage, pour corriger l'incompatibilité, j'ai développé un petit plugin qui corrige la situation pour les 2 plugins (cforms, viper vidéo quicktags), et de la sorte pas besoin de modifier/désactiver l'un ou l'autre des plugins...

<?php
/*
Plugin Name: MailPress Fix TinyMCE
Plugin URI: http://www.herewithme.fr
Description: Fix TinyMCE for MailPress with Viper Video Quicktags and Cforms
Author: Amaury Balmer
Version: 0.1
Author URI: http://www.herewithme.fr
*/
add_action( 'init', 'fixTinyMCE_MailPress', 999 );
function fixTinyMCE_MailPress() {
 if ( !isset($_GET['page']) && $_GET['page'] != 'mailpress_write' ) {
 return false;
 }
 // Viper video quicktags
 global $VipersVideoQuicktags;
 remove_filter( 'tiny_mce_version', array(&$VipersVideoQuicktags, 'tiny_mce_version') );
 remove_filter( 'mce_external_plugins', array(&$VipersVideoQuicktags, 'mce_external_plugins') );
 remove_action( 'edit_form_advanced', array(&$VipersVideoQuicktags, 'AddQuicktagsAndFunctions') );
 remove_action( 'edit_page_form', array(&$VipersVideoQuicktags, 'AddQuicktagsAndFunctions') );
 if ( 1 == $VipersVideoQuicktags->settings['tinymceline'] )
 remove_filter( 'mce_buttons', array(&$VipersVideoQuicktags, 'mce_buttons') );
 else
 remove_filter( 'mce_buttons_' . $VipersVideoQuicktags->settings['tinymceline'], array(&$VipersVideoQuicktags, 'mce_buttons') );
 // Cforms
 remove_filter( 'mce_external_plugins', 'cforms_plugin');
 remove_filter( 'mce_buttons', 'cforms_button');
 return true;
}
?>

Le fichier est également disponible au téléchargement ici.

Actuellement Simple Tags n’est pas toute à fait compatible avec WordPress 2.8.

Une version optimisée et compatible est en préparation… patience ;)

For english users : a new version of Simple Tags for WordPress 2.8 is in preparation and will be release soon !