Qu’attendre de WordPress 2.8 ?

28 février 2009 § 13

Après une très solide version 2.7 et 2.7.1, voila ce que nous prépare les développeurs pour WordPress 2.8 :

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

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

WP Super Cache et le bug de la compression Gzip, solution temporaire

3 septembre 2008 § 4

Les blogs à haute fréquentation sous WordPress ne rendent pas la vie facile au webmaster… Car quoi qu’on en dise, WordPress possède plein davantage sauf celui d’être économique en terme de performances.

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

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é !

WordPress passe la seconde avec Gears sous safari !

27 août 2008 § 0

WordPress 2.6 a apporté une fonctionnalité très intéressante pour les performances de la console d’administration.

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 !

WordPress Mu, ma todo liste…

25 août 2008 § 10

Pour les personnes qui suivent le développement de WordPress Mu, vous devez régulièrement voir un mec nommé « momo360modena » proposant des patchs à tour de bras, et maniant l’anglais comme un enfant de 8 ans.

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…)

Where Am I?

You are currently browsing entries tagged with performance at Here With Me.