Contrairement à WordPress 3.0, la version 3.1 se doit d’avoir un temps de développement court, les évolutions envisagées seront donc rapides, et il n’y aura pas de gros projets intégrés.

L’objectif de date pour la sortie finale de WordPress 3.1 est prévu pour mi-décembre 2010.

Cette version va avant tout privilégier les évolutions sur l’interface, la qualité et les performances du code et il n’y aura pas de modification sur le schéma. L’avis de l’équipe est de réserver les évolutions majeures pour WordPress 3.2, et ainsi produire un code de qualité en PHP5.

Donc première chose à retenir : pas de modification de schéma et pas de nouvelles API importantes.

Ce que ne contiendra pas WordPress 3.1

La refonte des médias. Une mise à jour importante du gestionnaire des médias a été envisagée par l’équipe de dev, c’est aussi l’une des demandes les plus récurrentes de la communauté. Il ne changera pas pour la simple et bonne raison que le code en question est assez tordu et qu’il serait regrettable de développer quelque chose en PHP4 alors que WordPress 3.2 sera compatible PHP5 uniquement.

De plus, c’est un chantier qui demandera du temps, qui imposera des modifications sur le schéma de la base de données et sur l’interface utilisateur. De fait, c’est un chantier couteux en temps.

Pour WordPress 3.1, la seule évolution possible sur le gestionnaire de médias sera l’envoi de fichiers HTML.

L’autre point important qui ne sera pas modifié dans WordPress 3.1 concernant la gestion de widgets. En effet, le filtrage des widgets par vue article/page/catégorie ne pourra être travaillé que dans WordPress 3.2.

En attendant, les plugins proposent des solutions appréciables.

Les fonctionnalités probables de WordPress 3.1

1. Des évolutions prévues sur l’API de taxonomie afin d’effectuer des requêtes avancées. WordPress 3.0 avec les custom types et les custom taxonomies a radicalement changé la façon de penser un site WordPress. L’API des taxonomies évolue logiquement pour répondre à toutes les attentes.

2. Une refonte importante des rôles/permissions est demandée par certains membres de l’équipe WordPress, pour la version 3.1, une première version de l’API sera proposée avec des fonctions permettant de travailler plus facilement sur les utilisateurs. À l’heure actuelle, les requêtes SQL « maison » priment encore dans ce domaine.

3. Une nouvelle fonctionnalité est également envisagée, il s’agit des liens internes. Autrement dit, la possibilité de créer des relations entre les contenus de WordPress. Il s’agit de la principale évolution à mes yeux de WP 3.1 !

Il fut un temps où seuls les articles relatifs permettaient de créer des liens entre les contenus, désormais il existe plusieurs plugins permettant de créer manuellement des liens entre le contenu (comme mon plugin Relation Post Types). Cette fonctionnalité est en vive discussion sur le trac.

4. Les pages de l’administration vont être largement AJAXifié avec quelques modifications mineures d’interface. La modération des commentaires sera également revue.

5. La barre d’administration avec menu déroulant. Très utile pour les plateformes de sites, buddypress, la barre d’administration semblable à WordPress.com fera probablement son apparition. Mais comme tout le monde n’est pas d’accord, la fonctionnalité restera peut-être sur la forme d’un plugin. (le plugin de Viper007Bond gère cela très bien pour le moment.)

6. Quelques simplifications et nettoyages de l’interface à travers toute l’application, et principalement le multi-site. Des pistes de recherche pour l’élaboration d’un tableau de bord personnel à la place du tableau de bord générale sont menées par Ryan. Ces modifications pourront être publiées dans WordPress 3.2 selon le planning.

7. Quelques corrections à prévoir sur l’API des custom post types.

8. Modification de l’interface de la gestion de thèmes par la version de WordPress.com. Cette dernière est plus efficace, plus légère, supporte la recherche, etc. C’est une étape indispensable pour les personnes ayant un WordPress MS avec beaucoup de thèmes.

9. Les templates de pages pour les articles. Afin de pouvoir supporter des modèles comme les pages)

10. La fonctionnalité QuickPress sera disponible à travers une fonction afin de pouvoir afficher facilement un formulaire sur le thème utilisateur.

Le planning

La date de publication ne devrait pas dépasser le 15 décembre pour ne pas interférer avec les vacances.

• 9 septembre : Confirmation du planning
• 15 octobre : feature freeze, pas de nouvelles fonctionnalités ajoutés dans le code
• 1er novembre : primary code freeze, fin de grands changements dans le code PHP
• 15 novembre :période de béta, plus d’amélioration, uniquement de la correction de bugs.
• 1 décembre : string freeze, traduction !
• 15 décembre : publication de WordPress 3.1

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 ?

Le problème de Tidy, c’est que généralement l’extension n’est pas activée sur les hébergements mutualisés !

Je suis tombé cet après-midi, en faisant des recherches pour une preg nettoyant le code HTML de MS Word, sur une alternative à Tidy écrit entièrement en PHP, j’ai nommé « htmLawed« . Comme le souligne l’auteur du script, les performances sont certes moins bonnes, mais on gagne en compatibilité vu que le script ne nécessite que PHP 4 !

Le script s’intègre d’ailleurs assez facilement avec WordPress, et il semble possible de remplacer le filtre KSES de WP sans trop de modifications. D’ailleurs, d’après ce que j’ai pu voir sur les forums de support de WordPress.org, un paquet de personnes milite pour le remplacement la vieillissante classe Kses par htmlLawed… On verra ;)

Pour ma part, j’ai rencontré quelques soucis avec les accents et l’encodage UTF-8, donc je reste prudent avec l’usage de htmlLawed !
Des personnes ont déjà essayé ?

L’un d’entre eux était:

Comment insérer toutes les images de son blog dans un article, mais avec de la pagination !

Sans pagination, c’est très simple. Il suffit d’utiliser la fonction get_posts() pour récupérer les images.

D’ailleurs petite précision, pour ne récupérer que les attachements de type « image », il faut préciser le paramètre :

‘post_mime_type’ => ‘image’

Pour gérer la pagination, j’ai choisi d’utiliser la pagination internet de WordPress, celle permise avec les marqueurs « nextpage ». Pour la galerie, j’utiliserai la même. Pour cela, j’ai été obligé de créer une petite extension permettant l’insertion d’un shortcode.

Voila le mode d’exécution :

1. Je récupère l’article juste après la requête SQL de WordPress.
2. Je force l’application du shortcode dans le contenu de l’article récupéré.
3. Je récupère les images
4. Je fais une boucle pour imprimer les images et tous les X images, j’imprime le marqueur « nextpage »

Ainsi, WordPress lors de l’affichage propose la pagination des articles. Pour cela, il ne faut pas oublier la fonction wp_list_pages() dans les fichiers single.php ou page.php (selon le cas article ou page).

Le shortcode permet de paramétrer, la taille des images, le nombre d’images par page et optionnellement l’ID d’un article parent. Tout cela est décortiqué dans le code de l’extension.

Vous pouvez retrouver cette extension depuis mon trac de plugins open-source, plus précisément dans le dossier Simple All Pictures.
Pour télécharger le fichier, allez en bas de la page,  et sous l’intitulé « Download in other formats: », sélectionnez le format que vous voulez.

Pour le but du code tout est dit dans le titre ou presque… le code qui va bien suit!

<?php
// ID de la catégorie
$category_id = 3;
// On récupérer les ID des articles
$post_ids = get_objects_in_term( $category_id, 'category' );
// On récupérer les ID des tags liés à ces articles
$tag_ids = wp_get_object_terms( (array) $post_ids, 'post_tag', array('fields' => 'ids') );
// On passe le tableau des tags dans une chaine de caractère séparé de ","
$tag_param = '';
if ( ! empty($tag_ids) ) {
$tag_param = 'exclude=' . implode(',', (array) $tag_ids );
}
// On utilise Simple Tags - Nuage de tags
st_tag_cloud('number=100&'.$tag_param);
?>

• Page blanche sur le tableau de bord et la page apparence
• Page blanche lors de la publication d'un article et/ou d'un commentaire

Le problème intervient sur les installations WordPress Mu à haute fréquentation uniquement.

Cause possible ?

Créer un fichier info.php à la racine de votre blog, placez-y :

<?php phpinfo(); ?>

Enregistrez le fichier, consultez la page générée et partez à la recherche de l'extension eAccelerator pour PHP.

Si le module est présent; vous êtes simplement victime d'un bug avec les caches OPcode PHP et les fonctions de filtrage HTML Kses de WordPress. Cela provoque une erreur de segmentation PHP, et hop page blanche.

La solution ?

Désinstallez eAccelerator de votre serveur dédié. Installez à la place l'extension pour PHP, j'ai nommé Alternative PHP Cache (APC).

Et n'oubliez pas de filtrer le fichier kses.php de l'optimisation. Pour cela, ajoutez dans votre fichier de configuration de PHP la ligne suivante:

apc.filters = "(kses.php)"

Redémarrez votre serveur Web et hop problème résolu !

Bref, revenons à nos moutons, aujourd’hui j’ai eu besoin de travailler avec Curl pour récupérer une page distante. Rien de très folichon !

En général, je travaille directement avec les fonctions PHP destinées à CURL, mais quoi qu’on en dise, 12 define CURL à la suite pour un petit appel GET, ça n’est pas très lisible.

Je suis tombé, via un commentaire de php.net, sur une petite classe, compatible PHP4 et PHP5, simplifiant l’usage de CURL…Cette classe, on peut la trouver sur le dépôt Git Hub.

Et maintenant, petit exemple pour récupérer une page web avec cette classe:

require_once 'curl.php';
$curl = new Curl;
$response = $curl->get('google.com?q=test');

Pas de doute, c’est tout de suite plus joli :)