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

Un éditeur de code dans WordPress : CodePress

L’intégration de la librairie JavaScript « CodePress » permettant une amélioration notable l’éditeur en ligne des thèmes et des extensions de WordPress. Cette librairie permet de mieux visionner le contenu des thèmes et des extensions WordPress.

Elle apporte également des améliorations concernant les raccourcis claviers, ce que ne permet pas un champ textarea classique.

CodePress lors de l'édition d'un thème

Simple Pie

Simple Pie est une librairie PHP bien connu des développeurs PHP. Elle permet d’agréger des flux RSS, RSS 2.0, Atom très facilement. Depuis très longtemps WordPress utilise la classe Magpie pour faire ce travail, mais le problème est que cet outil n’est plus mis à jour et que ses performances et ses fonctionnalités montrent leurs limites.

Dans WordPress 2.8, toutes la partie agrégation RSS (tableau de bord et Widget RSS) devrait être pris en charge par Simple Pie, qui lui a l’avantage de gérer la mise en cache en base de données, chose très pratique et de suivre un développement très actif.

Un générateur de classe HTML pour l’élément « body » de votre thème.

Cette fonctionnalité, à destination des intégrateurs et créateurs de thèmes, ajoute une fonction body_class() permettant de générer une classe pour l’élément BODY de votre thème. Ainsi, vous pourrez facilement personnaliser l’aspect CSS de votre thème selon l’emplacement où vous êtes.

Il utilisera différents critères, la vue (catégorie, tags, archives), le type (article, page), le statut de connexion (logged-in), etc. Par exemple, sur la page d’accueil du blog, vous obtiendrez :

<body class="home blog logged-in">

Les créateurs de thèmes complexes apprécieront !

La taxinomie de WordPress évolue

Et une nouveauté dédiée aux développeurs de plugins ! Afin de rendre l’API de taxinomie de WordPress encore plus souple, les développeurs de WordPress lui ont apporté des modifications afin de générer des pages d’édition (ajout, édition, suppression) plus facilement. Aujourd’hui la manipulation consistait à s’inspirer de la structure des tags ou des catégories…

Il devrait encore être plus facile de créer de nouvelle taxinomie dans WordPress !

Amélioration des performances (DB + JavaScript)

Plus WordPress évolue, plus il a tendance à grossir… Assez logique ! Pour améliorer la situation, les développeurs ont ajouté dans WordPress 2.5, la fonctionnalité Turbo. Cette fonctionnalité bien qu’efficace n’a pas satisfait tous les utilisateurs, et les développeurs bien conscients de la situation travaille sur une amélioration des performances dans WordPress 2.8.

Les librairies JavaScript

La fonction wp_enqueue_script() va recevoir un nouveau paramètre permettant de spécifier si le script doit être chargé dans l’entête ou dans le pied de la page. WordPress gérera par la même occasion la concaténation des scripts et CSS, la compression Gzip des JavaScripts et des CSS. Cela permettra ainsi de réduire la taille des JavaScripts et diminuera le nombre de connexions HTTP.

Pour plus d’informations sur ces ajouts, il y a 2 articles (en anglais) qui traitent de cette modification:

• http://wpdevel.wordpress.com/2009/02/06/script-loader-updates/
• http://lesterchan.net/wordpress/2009/01/26/loading-javascript-in-footer-in-wordpress-28/

Cela amène l’ajout de différentes constantes de configuration: (je ne traduis pas, ça me parait assez explicite !)

define(‘SCRIPT_DEBUG’, true); loads the develppment (non-minified) versions of all scripts
define(‘CONCATENATE_SCRIPTS’, false); disables both compression and cancatenating,
define(‘COMPRESS_SCRIPTS’, false); disables compression of scripts,
define(‘COMPRESS_CSS’, false); disables compression of CSS,
define(‘ENFORCE_GZIP’, true); forces gzip for compression (default is deflate).

La base de données

Ryan parle sur son blog d’une amélioration de la base de données, d’après les développements présents dans le trac, il n’y a encore rien en place à ce sujet !

Amélioration de la sécurité SQL

Depuis les premières versions de WordPress, les développeurs ont toujours préféré la fonction addslashes() de PHP pour sécuriser les requêtes SQL. Ce choix peut parait surprenant pour tout développeur PHP, en effet il existe depuis quelques années la fonction mysql_real_escape_string() qui est destinée à cet effet…

En fait, la fonction addslashes() ne pose aucun problème de compatibilité avec les hébergeurs, ce qui n’est pas toujours le cas avec la fonction mysql_real_escape_string(). De nos jours, les hébergeurs étant majoritairement passer à PHP5 et le problème ne se pose plus vraiment, ainsi la classe de connexion à la base de données WPDB de WordPress 2.8 choisira ainsi la meilleure fonction disponible pour sécuriser les données !

Correction d’un bug gênant avec la classe WP-Cron

Je détaille la chose dans l’article :Des problèmes avec WP Cron et la programmation des articles ?

Amélioration de la classe HTTP

La classe HTTP ajoutée dans WordPress 2.7 se voit greffer quelques nouveautés:

• Le support des compressions Gzip et Deflate pour le transfert des données
• La possibilité de créer un cookie de connexion via la classe HTTP
• La possibilité de bloquer l’appel à certaines URL via une liste noire (pratique si vous êtes derrière un serveur proxy par exemple)
• Meilleur support du SSL

Diverses choses

• Nouvel importeur pour le service LiveJournal
• Minification (Minified) de tous les JavaScripts utilisés par WordPress. (en plus de la compression Gzip et la concaténation)
• Amélioration de l’API XML-RPC concernant les médias de WP

La version 2.8 est prévue pour le 9 mars 2009, mais personnellement je doute qu’il soit dans les temps !

Pour visionner les évolutions, visitez le site de démo de la version de développement de WordPress

Pour y remédier, une solution simple et peu couteuse à mettre en place consiste à installer le plugin WP Super Cache, de mon ami Donncha. (mainteneur de WPmu au passage)

Malheureusement, il se trouve que le plugin bien que très efficace provoque un bug assez aléatoire.

Pour comprendre la source du bug, petit rappel technique sur le fonctionnement de WP Super Cache.

1. Un visiteur consulte une page X
2. Si la page n’est pas en cache, WP Super Cache créé 2 copies :
   • 1 exemplaire HTML
   • 1 exemplaire compressé Gz
3. Le visiteur suivant, qui consulte la même page X, va vérifier la présence d’une copie.
   • Dans un premier temps, la copie compressée Gz
   • Dans un second temps, la copie HTML
   • Sinon, il charge WordPress pour créer la copie (on revient au point 2)
4. Et ainsi de suite.

Petite précision, mais pas importante ici, les copies HTML et Gz ont une durée de vie. Cette dernière est spécifiée dans les options du plugin. Une fois la durée dépassée, les 2 copies sont supprimées pour obliger une nouvelle création.

Revenons au bug, il est assez simple. Lors de la première consultation, WP Super Cache va créer une copie compressée avec Gzip, malheureusement avec la version actuelle (0.7.0.1), il ne vérifie pas l’intégrité de l’archive.

De ce fait, il lui arrive de créer aléatoirement des archives corrompues. On tombe alors sur des pages comme:

L'art moderne selon WordPress

Pour éviter ce bug, tout en profitant du cache HTML classique de WP Super Cache, rien de plus simple… Il suffit de désactiver la compression GZ dans les options du plugin.

Cependant pour des raisons assez mystérieuses, le bug se reproduit par moment. Pour être sur que le bug ne se reproduit, je vous conseille de désactiver la redirection du fichier .htaccess concernant la compression Gz.

C’est-à-dire les lignes suivantes:

RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{QUERY_STRING} !.*p=.*
RewriteCond %{QUERY_STRING} !.*attachment_id=.*
RewriteCond %{QUERY_STRING} !.*wp-subscription-manager=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]

En supprimant cette partie, vous pouvez être sûr que les pages avec hiéroglyphes, c’est terminé !

Turbo permet de stocker les fichiers fréquemment utilisés de la console d’administration dans un cache local grâce à la technologie Gears de Google.

Jusqu’à très récemment Safari ne pouvez pas profitez cette fonctionnalité pour la simple et bonne raison que Gears n’est pas compatible Safari.

Les choses changent, Google a lancé une version Safari de Gears (lien direct vers le DMG). WordPress 2.6 est désormais optimisé sur le navigateur Apple !

Ce mec, c’est moi… Pour l’anecdote momo360modena, c’est le pseudonyme de mes jeunes années…

J’ai donc proposé il y a très peu de temps un énorme ticket pour passer les fonctions Mu sous les nouvelles fonctions de la classe WPDB, pour des raisons de lisibilités et de performances. Le patch contient également la proposition de déplacer tous les hooks par défaut de WordPress Mu dans un fichier, comme le fait WordPress.

J’espère que tout le patch sera retenu… ça m’a pris deux bonnes heures cette histoire…

Passons maintenant à la suite de ma todo:

• Manage Sites : La possibilité de gérer les sites sous WordPress Mu
• Clean DB : Effacer la table inutile, et rétaper wp_sitecategories
• Manage Global Terms : Permettre l’édition, même basique de la table des globals terms.
• Hardcoded $table_prefix : Permettre l’utilisation d’autre chose que wp_ comme préfixe de table (inutile mais c’est pour la beauté du geste)
• Localize Installer : Avoir un installeur localisé :) pour me faciliter la vie lors des mises à jour !
• Split mu-functions : Séparer les fonctions mu-functions par thématiques…
• Localize Users : Offrir la possibilité à chaque utilisateur de lancer la traduction de son choix. Actuellement ce choix est fait au niveau de l’admin.
• Mu Plugins : Reproduire la page des plugins pour les mu-plugins…

Conclusion derrière ces noms de codes, rien d’extraordinaire… juste les fonctionnalités qui manquent à mon gout à WordPress Mu.

Avant de me lancer dans le développement de ces patchs, je vais probablement discuter avec Donncha, pour voir de son côté si tout ça peut être intégré… En fait la grande difficulté d’un projet comme WordPress Mu, c’est de délimiter les fonctionnalités qui doivent être inclus dans le core et celles qui doivent rester en tant que mu-plugins…

Si de votre coté, vous avez des idées de fonctionnalités manquantes, je suis preneur ;) (le premier qui me répond le domaine mapping, je l’envoi chiez, ca existe déjà en mu-plugins…)