Tous les articles relatifs à WordPress et à son optimisation.
Ah, ce moment magique durant lequel tu constates que ta note PageSpeed monte à 99%, via GTmetrix :
C’est beau, sachant qu’au niveau CSS, c’est la barre WordPress du haut qui génère l’overhead.
Prochaine étape : mettre les fichiers statiques sur un sous-domaine cookieless.
Pour éviter cela, j’ai écrit un petit script bash qui me permet de stopper le serveur MySQL, procéder à la réparation de toutes les tables de toutes les bases de données puis relancer le serveur MySQL, Apache et Varnish.
#!/bin/sh
# MySQL Auto-Repair
# Written by Matt - skyminds.net
# stop the MySQL server
/etc/init.d/mysql stop
# check for errors
myisamchk /var/lib/mysql/*/*.MYI
# ask permission to repair
read -p "Repair tables ? (y/n)" -n 1 -r
if [[ $REPLY =~ ^[Yy]$ ]]
then
# repair everything
myisamchk -r /var/lib/mysql/*/*.MYI
# restart servers
/etc/init.d/mysql restart
/etc/init.d/apache2 restart
/etc/init.d/varnish restart
else
/etc/init.d/mysql restart
fiC’est le genre de petit fichier bash à garder au frais sur le serveur, facile à lancer en SSH depuis n’importe quel terminal en cas de besoin.
Maintenant que nous avons mis à jour le code des oEmbed Youtube, nous allons rendre le code de l’iframe valide. Voici ce que le code oEmbed de WordPress donne par défaut avec un lien Youtube :
<iframe src="https://www.youtube.com/embed/Gvh2Zo7UL6E" width="660" height="371" frameborder="0" allowfullscreen="allowfullscreen"></iframe>Code language: HTML, XML (xml)Résultat:
Or le petit problème, c’est que tout cela n’est pas vraiment valide au niveau W3C et je commence à me lasser de voir ces erreurs de validation sur toutes les pages du site avec des vidéos :
Erreur 1 : Attribute allowfullscreen not allowed on element iframe at this point.
Erreur 2 : The frameborder attribute on the iframe element is obsolete. Use CSS instead.Code language: JavaScript (javascript)
Voici donc la solution que j’ai mise en place sur le site : je filtre le code oEmbed de WordPress de manière à retirer le tag allowfullscreen qui n’a rien à faire là et à supprimer l’attribut frameborder, que je remplace par un style="border: none".
Éditez le fichier functions.php de votre thème et ajoutez-y cette fonction:
<?php
/*
|-----------------------------------------------------------------------
| Sky oEmbed Filter by Matt - www.skyminds.net
|-----------------------------------------------------------------------
|
| The sky_oembed_filter() function attempts to validate WordPress
| video oEmbeds for HTML5.
| $return is the normal HTML that the oEmbed process would return.
| $data is the data received from the oEmbed call, in an object format.
| $url is the original URL being queried for oEmbed info.
|
*/
add_filter('oembed_dataparse', 'sky_oembed_filter', 90, 3 );
function sky_oembed_filter( $return, $data, $url ) {
$return = str_replace('frameborder="0" allowfullscreen', 'style="border: none"', $return);
return $return;
}Code language: HTML, XML (xml)Notez que WordPress cache les résultats oEmbed dans la table postmeta donc après avoir installé ce code et si vous voulez vérifier que cela fonctionne, éditez un article pour que le postmeta se mette à jour.
Voilà, vos pages avec vidéos YouTube devraient maintenant être valides.
Sur votre site ou blog, vous avez peut-être ajouté le widget ou bouton +1 de Google+, le réseau social de Google. Or le petit problème, c’est que le code fourni empêche la bonne validation du document.
Voici le code fourni par Google :
<a title="Google+" href="https://plus.google.com/114535411372700844744" rel="publisher nofollow">Google+</a>Code language: HTML, XML (xml)et voici l’erreur renvoyée par le validateur W3C :
Keyword publisher is not registeredHTML5 étant toujours en cours de réalisation, les valeurs de la balise rel sont assez restreintes et on ne peut pas mettre tout ce que l’on veut sans déclencher l’erreur.
La solution est toute simple : il faut ajouter la valeur du rel en argument dans le lien, comme ceci :
<a title="Google+" href="https://plus.google.com/114535411372700844744?rel=publisher" rel="nofollow">Google+</a>Code language: HTML, XML (xml)Et voilà, plus d’erreur lors de la validation.
N’oubliez pas de faire une sauvegarde de votre base de données avant de lancer ces requêtes. Backup now.
wp_postmetaAvant optimisation, ma table wp-postmeta faisait 12 403 enregistrements.
DELETE FROM wp_postmeta WHERE meta_key = '_edit_lock';
DELETE FROM wp_postmeta WHERE meta_key = '_edit_last';
DELETE FROM wp_postmeta WHERE meta_key = '_wp_old_slug';Maintenant : 12 240.
wp_commentmetaOn supprime tout ce qu’Akismet nous a mis dans la table wp_commentmeta :
DELETE FROM wp_commentmeta WHERE meta_key LIKE '%akismet%';et on supprime toutes les entrées qui n’ont aucune relation avec wp_comments :
DELETE FROM wp_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments);wp_optionsPassage de 880 enregistrements à 476. WordPress crée ces entrées automatiquement et les purge occasionnellement, autant l’aider un peu.
DELETE FROM wp_options WHERE option_name LIKE '_site_transient_browser_%';
DELETE FROM wp_options WHERE option_name LIKE '_site_transient_timeout_browser_%';
DELETE FROM wp_options WHERE option_name LIKE '_transient_%';
Je me suis rendu compte qu’un des fichiers javascript d’un plugin WordPress est appelé sur chaque article du site et qu’il n’est pas mis en cache par défaut…
C’est très moyen au niveau optimisation étant donné que c’est typiquement le genre de fichier statique qui n’est pas prêt d’être modifié.
Voici donc les en-têtes (headers) qui vont nous permettre de mettre un fichier en cache en PHP :
<?php
/*
|--------------------------------------------------------------------------
| Enable Caching with PHP headers by Matt - www.skyminds.net
|--------------------------------------------------------------------------
|
| Let's set it to 90 days caching.
| seconds, minutes, hours, days
|
*/
$expires = 60*60*24*90;
header('Pragma: public');
header('Cache-Control: maxage='.$expires);
header('Expires: ' . gmdate('D, d M Y H:i:s', time()+$expires) . ' GMT');Code language: HTML, XML (xml)Et voilà, page mise en cache.
Cela fait moins de requêtes sur le serveur puisque le navigateur n’a pas besoin de redemander la page à chaque visite.
Il y a quelques mois, je vous ai montré comment changer la structure des permaliens WordPress. Cela fonctionne très bien et tout le trafic des anciennes URL est bien redirigé vers les nouvelles.
Il est toutefois encore possible de faire mieux que cela : éditer toutes les URL de la base de données pour afficher les bons liens directement et éviter les redirections Apache à chaque fois qu’un visiteur clique sur un lien de vos anciens articles.
Cela évite une redirection donc permet d’afficher la bonne page directement, sans le temps de latence dû à l’exécution de mod_rewrite.
On n’insistera jamais assez sur l’importance de sauvegarder les données avant d’effectuer une quelconque manipulation des données.
Commancez donc par faire une sauvegarde de votre base WordPress, vu que nous allons l’éditer en direct.
Or, après avoir changé de navigateur deux fois (Chromium et Opéra), je me suis vite rendu compte que quelque chose clochait : une fois que l’on cliquait sur le bouton login, il y avait comme une redirection qui ne se faisait pas bien. Le navigateur moulinait et finissait par cracher un bout de page avec seulement quelques éléments HTML.
Du coup, je me suis dit que l’on pouvait peut-être arranger les choses, c’est ainsi que j’ai écrit un nouveau plugin WordPress : Sky Login Redirect.
Sky Login Redirect est un plugin WordPress extrêmement simple : il vérifie l’adresse de la page que l’utilisateur était en train de consulter juste avant l’identification et la passe à la fonction de redirection. Du coup, vous pouvez vous identifier et rester sur la même page.
Vous n’aterrissez plus dans le backend WordPress et vous pouvez finir votre lecture ou poster votre commentaire tranquillement.
Si la page n’est pas définie, on redirige l’utilisateur vers la page d’accueil du blog.
Lorsque vous quittez votre session, le plugin vous ramène sur la page d’accueil au lieu de vous représenter la page login.
Tout simple, aucune configuration n’est nécessaire, il suffit d’activer le plugin.
Version: 3.7.8
Vous pouvez télécharger Sky Login Redirect ici ou visiter la page du plugin chez WordPress.
M’étant quelque peu arraché les cheveux pendant les vacances pour trouver comment afficher correctement un shortcode dans une template WordPress, voici comment afficher un shortcode dans un article, une page ou une modèle de page.
Cela me servira de référence ultérieure mais je suis certain que cela en aidera d’autres.
Pour créer un shortcode, on crée une fonction puis le shortcode associé dans le fichier functions.php du thème WordPress :
/* Fonction */
function sky_hello_readers($content) {
return 'Hello readers !';
}
/* Création du shortcode avec add_shortcode() */
add_shortcode( 'hello', 'sky_hello_readers' );Code language: PHP (php)
Après avoir cherché un peu, il s’avère que j’ai copié directement les fichiers de bases de données mais que MySQL n’a pas les droits dessus. Du coup, toutes les tables sont en lecture seule, comme me l’a indiqué une petite requête simple :
Failed to save field : SQL alter table `wp_posts` modify `ID` bigint(20) unsigned not null default NULL auto_increment failed : Table 'wp_posts' is read onlyVous avez besoin de modifier les droits d’accès et d’écriture des fichiers de bases de données. Il faut soit se connecter à distance en SSH sur votre serveur ou en local sur votre machine et lancer la commande chown.
On se met donc dans le répertoire de travail de MySQL :
cd /var/lib/mysql/et on attribue à l’utilisateur mysql les droits à nos bases de données :
chown -R mysql:mysql *
Je me suis rendu compte que finalement, il y avait très peu d’intérêt à garder la date de création de l’article dans l’URL étant donné qu’elle est présente dans chaque article, cela permet de raccourcir les URLs et mes articles sont plutôt timeless.
Cela se fait en 2 étapes, en 5 minutes top chrono.
C’est tout simple, il suffit de se rendre dans Settings > Permalinks et de sélectionner Post name:
Depuis WordPress 3.3, choisir l’option /%postname%/ ne pose plus de problème de performance. C’était le cas auparavant et l’option n’était pas disponible.
Validez les changements.