Nous venons de publier deux mises à jour rapides pour WPML. Ces mises à jour règlent quelques petits problèmes remontés par le support après la mise à jour plus importante de WPML 3.2.3.
- Correction d'un problème de performances lors de la recherche de pages par slug avec un très grand nombre d'articles dans la base de données – nous ne sommes pas certains que quelqu'un d'autre que wpml.org ait pu remarquer ce problème. Une modification apportée à une instruction SQL entraînait une charge importante sur notre serveur de base de données. Nous l'avons retracée jusqu'à une modification récente qui résolvait un bug. Cette modification a été améliorée pour résoudre le bug sans provoquer de charge sur la base de données. Encore une fois, ce problème n'était perceptible que sur de très grandes bases de données soumises à une forte charge (comme le site wpml.org).
- Résolution du problème où, dans certains cas, WPML affichait un avertissement de paramètres corrompus – une séquence d'activations, de désactivations et de réactivations d'extensions en lot pouvait déclencher un message alarmant indiquant que les paramètres étaient corrompus. Bien que cela ne cause aucun problème réel, nous pensons que c'est suffisamment alarmant pour justifier un correctif rapide.
- Correction du script xdomain qui ne s'exécutait pas toujours, en raison d'un problème de dépendance – dans certains cas, les ressources JS n'étaient pas chargées.
- Résolution d'un problème où les slugs de page prenaient la priorité sur les slugs de type de publication personnalisé lors de la résolution des permaliens, même si l'URI spécifiait le type de publication personnalisé – la résolution de ce bug est ce qui a causé le problème de performances pour les très grands sites.
Nous comprenons que la mise à jour des extensions est une corvée et nous essayons de limiter nos mises à jour à celles qui sont strictement nécessaires. Au moment où j'écris cet article, nos développeurs ajoutent de plus en plus de tests automatisés à WPML. Notre objectif est d'atteindre une couverture de test de 100 % d'ici la fin de l'année 2015. Cela nous permettra de publier des mises à jour sans craindre de causer des effets secondaires. Actuellement, notre cycle de contrôle qualité prend le temps faramineux de 20 semaines de travail. Il est géré par 4 personnes pendant un mois entier. Nous exécutons plusieurs milliers de tests sur de nombreuses configurations. La quantité de tests est énorme et nous cherchons à en remplacer une grande partie par des tests automatisés.
Des questions ? Des idées ? Des suggestions ? Laissez votre commentaire et nous vous répondrons.
