Les VPS deviennent vraiment intéressants

OVH, le plus grand hébergeur français, a augmenté les tarifs de ses offres mutualisées. Les tarifs commencent désormais à 3,6 € par mois pour l’offre « Perso » et l’offre « Pro » en milieu de gamme nécessite de payer 7,2 € par mois. Des tarifs justifiés par la nécessité d’embaucher plus de personnels pour le support technique, ce qui n’a rien d’anormal et il faut reconnaître que l’hébergeur a fait de gros progrès sur ce point.

ovh-mutu.png

Les tarifs indiqués par OVH sont hors taxe.

Cette augmentation de tarifs améliore, en contrepartie, l’intérêt des VPS proposés par OVH. Ces serveurs virtuels s’approchent des serveurs dédiés que les sites les plus exigeants utilisent. On partage toujours un matériel, comme avec les offres mutualisées, mais on a une maîtrise totale sur le serveur et un accès mieux garanti aux ressources.

Désormais, les tarifs des VPS d’entrée de gamme d’OVH sont identiques aux offres mutualisées de l’hébergeur. La première offre est ainsi facturée 3,6 € par mois et pour bien des sites, c’est une meilleure affaire à mon avis. Mais, car il y  a un mais, et un gros : pour utiliser un VPS, il faut manier le terminal et ne pas prendre peur face à des lignes de commande. Si vous n’êtes pas à l’aise avec cet outil, il sera préférable d’en rester à une offre classique.

ovh-vps.png

Lire la suite

Publicités

Combien de mots avez-vous publié ?

J’aime bien, par pure curiosité, savoir comment j’écris sur mon blog personnel. Grâce à WP Word Count, une extension gratuite que j’utilise depuis des années, je peux savoir combien de mots j’ai écrit et publié, mois après mois. L’extension donne aussi la moyenne par article et j’ai reporté systématiquement ces deux informations dans un tableur.

Ce qui permet d’avoir des graphiques comme ceux-là :

volume-publication.png rythme-publication.png frequence-publication.png longueur-articles.png

Le plugin ne fait pas ce genre de graphique, malheureusement, mais il affiche le nombre de mots publiés chaque mois, ainsi que le palmarès des dix articles les plus longs. Ce n’est pas indispensable, loin de là même, mais j’aime bien avoir cette information sous la main, notamment pour essayer de ne pas faire trop long. Je surveille ainsi le dernier graphique de la liste et la courbe rouge, pour limiter son ascension.

J’ajoute que l’extension n’a pas été mise à jour depuis très longtemps, mais qu’elle fonctionne parfaitement (elle ne gère probablement pas les custom post néanmoins). Elle fait partie de celles qui sont en place sur mon blog depuis quasiment les débuts… Elle a donc enregistré les 1 350 000 publiés à ce jour, un chiffre qui fait tourner la tête !

nombre.png

L’extension affiche le nombre de mots publiés depuis la création du blog, ainsi que la moyenne générale.

Trier les articles par date de modification dans l’admin

S’il vous arrive de modifier régulièrement les articles sur votre blog, comme c’est mon cas, vous avez peut-être envie de lister les dernières modifications dans l’administration. Par défaut, WordPress ne propose pas cette option et si l’on a plusieurs choix de colonnes, on n’a que la date de publication comme choix de date. Avec un peu de code, vous pouvez néanmoins facilement y remédier et obtenir ceci :

admin-tri-modification.png

Cliquer sur l’image pour l’agrandir

Avant toute chose, sachez que j’ai utilisé ce plugin comme base. Il n’a pas été mis à jour depuis des années et il fonctionne très bien, mais je voulais le modifier et je préfère tout conserver dans le fichier functions.php de mon thème. Ce n’est pas un bon conseil de manière générale, puisque si je changeais de thème, je perdrais tout, mais ce thème est conçu par mes soins et si je le modifie, je sais ce que je dois faire.

Bref, mieux vaut utiliser le plugin, mais si vous êtes comme moi, voici le code complet :

// Tri dans la colonne des news par dernière modif (source : https://wordpress.org/plugins/sort-by-modified/)

// Register Modified Date Column for both posts & pages
function modified_column_register( $columns ) {
$columns['date modif'] = __( 'Modification', 'date modified' );

return $columns;
}
add_filter( 'manage_posts_columns', 'modified_column_register' );
add_filter( 'manage_pages_columns', 'modified_column_register' );

// Display the modified date of each post
function modified_column_display( $column_name, $post_id ) {
global $post;
$modified = the_modified_date();
echo $modified;
}
add_action( 'manage_posts_custom_column', 'modified_column_display', 10, 2 );
add_action( 'manage_pages_custom_column', 'modified_column_display', 10, 2 );

// Register the column as sortable
function modified_column_register_sortable( $columns ) {
$columns['date modif'] = 'modified';
return $columns;
}
add_filter( 'manage_edit-post_sortable_columns', 'modified_column_register_sortable' );
add_filter( 'manage_edit-page_sortable_columns', 'modified_column_register_sortable' );

Je n’ai pas modifié grand-chose, simplement traduit le nom de la colonne et ajouté date dans son nom. Cette opération m’a permis d’avoir une colonne de la même taille que celle de date ajoutée par WordPress sans effort supplémentaire, puisque l’on retrouve alors le même identifiant. J’ai aussi retiré une partie du code original qui concernait les articles pas standard (« post_type »), étant donné que je n’en ai pas sur mon blog.

Ajoutez le plugin ou le code quelque part, et vous aurez désormais une colonne avec la date de modification de chaque article. Et on peut trier la liste par cette colonne : voilà un moyen simple et efficace de trouver les derniers articles modifiés !

Passer à PHP 7 avec un mutualisé chez OVH

Si vous utilisez WordPress — et c’est certainement le cas si vous suivez ce blog — et que vous hébergez votre blog sur l’une des offres mutualisées d’OVH, vous pouvez désormais passer à PHP 7 ! Cette mise à jour majeure se concentre sur la vitesse d’exécution et le gain est très net. Sans rien changer à votre installation, sans aucun effort d’optimisation, le site sera plus rapide, tout particulièrement s’il est complexe.

J’ai repris le module qui m’avait servi à comparer plusieurs hébergeurs pour vérifier sur mon blog personnel s’il y avait une différence visible entre le PHP 5 qui était jusque-là la norme, et le PHP 7 qui va le devenir. Comme vous pourrez le constater, on gagne sur tous les tableaux : le site est plus rapide à exécuter le PHP et les tests spécifiques à WordPress montrent également que le blog va tourner plus vite. Dans certains cas, on divise par trois le temps d’exécution, ce qui permet alors de passer de plus d’une seconde à 300 ms, un temps quasiment imperceptible pour le visiteur.

php-7-chiffres

Avant de continuer, un mot au sujet de la compatibilité. PHP 7 est une mise à jour majeure qui casse plusieurs choses qui fonctionnaient auparavant. Concrètement, cela veut dire que la mise à jour peut bloquer certaines fonctions, voire le site tout entier dans les cas les plus graves. Si vous utilisez WordPress toutefois, vous devriez être tranquille : la dernière version du CMS fonctionne parfaitement avec PHP 7 et certains modules ou thèmes peuvent être incompatibles, mais ils sont a priori très rares.

En cas de problème, vous pourrez toujours revenir en arrière. Je vous conseille ainsi d’essayer, et d’annuler le changement si quelque chose ne fonctionne plus.

Comment activer PHP 7 sur votre hébergement mutualisé OVH ? C’est très facile : il suffit de se connecter en FTP à votre compte et de modifier le fichier .ovhconfig qui se trouve à la racine de votre site, ou bien de modifier celui à la racine de votre compte. Vous pouvez ainsi gérer chaque site différemment et n’activer PHP 7 que là où c’est possible, tout en gardant les autres sites hébergés avec une ancienne version.

ovhconfig

Voici ce que doit contenir le fichier pour activer PHP 7 :

app.engine=php
app.engine.version=7.0
http.firewall=none
environment=production

Si le fichier est déjà présent, modifiez la deuxième ligne et remplacer la valeur après le = par 7.0. S’il n’est pas présent, vous pouvez créer ce fichier en reprenant bien son nom (le point au début est essentiel). Enregistrez les modifications et vérifiez immédiatement que tout fonctionne. Si ce n’est pas le cas, vous pouvez supprimer le fichier et vous reviendrez à la version précédente de PHP.

Pour plus de détails ou si vous avez des questions ou des problèmes sur la transition, un sujet dédié a été ouvert dans les forums d’OVH.

Tester les performances d’un hébergeur avec WP Performance Tester

Si vous cherchez le meilleur hébergeur pour votre blog ou site sous WordPress, il y a un grand nombre de critères à prendre en compte évidemment, mais la performance du serveur est essentielle. Sans cela, le site sera lent à la base et les erreurs risquent de se multiplier dès lors que le nombre de visiteurs augmente. Pour connaître les performances d’un hébergeur, on peut se référer à des guides, comme ceux très bien réalisés de Review Signal, mais tous ces tests comparatifs ont un défaut : ils ne sont pas exhaustifs.

review-signal

Pour prendre mon exemple, j’avais besoin de trouver un nouvel hébergeur après un an passé chez SiteGround. Ce dernier a une offre excellente sur le plan technique, un support disponible et compétent, bref, c’est un excellent choix… quand on en a les moyens. La meilleure offre en hébergement mutualisé coûte près de 30 € par mois, beaucoup plus que ce que je pouvais me permettre pour ce blog que je devais transférer.

Cela fait longtemps que je voulais essayer les VPS, ces serveurs virtuels qui offrent la souplesse d’un serveur dédié, mais avec un peu moins de puissance, plus de souplesse et surtout un prix bien plus intéressant. Sur ce marché, le leader est DigitalOcean qui propose des offres à partir de 5 $ HT par mois, soit moins de 5,5 € par mois environ avec la TVA. C’est une offre bien connue, mais j’étais aussi intéressé par les VPS d’OVH qui ne sont dans aucun comparatif alors qu’ils sont moins chers et plus performants sur le papier.

ovh-vps

Pour 3,5 € environ par mois, on dispose d’un serveur virtuel a priori beaucoup plus puissant que le modèle de base de Digital Ocean. Et a priori, un serveur largement assez puissant pour un blog comme le mien, avec peu de trafic quotidien. Je voulais en avoir le cœur net et c’est précisément pour cette raison que je voulais tester les performances de chaque hébergeur avant de me décider.

Lire la suite

InstantClick charge les pages instantanément

Pour obtenir un site sous WordPress rapide, un bon hébergeur, un thème optimisé et un système de cache constituent la base de ce qui est nécessaire. Mais il y a des manières d’aller plus loin encore, la preuve avec ce petit module JavaScript qui commence à charger les pages avant même de cliquer sur un lien.

InstantClick part d’un principe assez simple : entre le moment où on place le curseur de la souris sur un lien, et le moment où on le clique pour ouvrir la page correspondante, il se passe en moyenne entre 200 et 300 ms (vous pouvez essayer ici, vous verrez). C’est imperceptible, certes, mais dans cet intervalle de temps, le serveur ne fait rien alors qu’il aurait largement le temps de charger la page, ou au moins de commencer ce chargement. Et c’est exactement ce que fait InstantClick : dès que vous survolez un lien, il demande au serveur de précharger la page. Avec un peu de chance, au moment où vous cliquez, le chargement sera terminé et vous aurez instantanément le résultat, sans le moindre temps d’attente.

Lire la suite

J’ai failli abandonner WordPress…

Depuis plusieurs années, j’ai envie d’abandonner WordPress. Non pas que le CMS le plus populaire sur internet soit vraiment un problème, mais je me suis lassé de ses lourdeurs, de ses multiples extensions et surtout de son code PHP souvent assez lourd. Lourd pour le serveur, mais aussi, il faut être honnête, pour moi qui ne suis pas développeur. Modifier le thème est toujours assez compliqué, on fait souvent des erreurs (il suffit d’oublier un point virgule), bref, c’est contraignant.

Ainsi, j’ai essayé à plusieurs reprises des moteurs de blogs statiques qui permettent de générer l’intégralité du site sur son ordinateur, et de ne publier que des fichiers HTML sur le serveur. Une approche qui a plusieurs avantages, à commencer par la légèreté du site final. Il n’y a plus de bases de données, plus de création à la volée des pages, tout est prévu à l’avance et le serveur ne sert que du contenu HTML. Par ailleurs, cette solution simplifie le développement, puisque l’on ne travaille qu’en local. On génère le site et si tout est cassé, il suffit de modifier, générer à nouveau l’ensemble et c’est terminé. Quand tout est prêt, on synchronise le serveur.

Lire la suite

Allègement de la recherche instantanée

Petite mise à jour pour la recherche instantanée mise en place sur mon blog personnel depuis un petit peu plus d’un an. Jusque-là, l’index — un fichier JSON généré à chaque ajout d’article — contenait le nom de l’article et son lien complet. Une idée simple, mais qui posait un problème d’échelle : avec 1064 articles publiés, mon index pesait plus de 125 Ko. Cela n’a l’air de rien, mais il faut charger ce fichier à chaque page et sur les plus gros blogs, cela peut vite bloquer.

Avant (gauche) et après (droite)

Avant (gauche) et après (droite)

En changeant deux petits éléments, j’ai allégé le fichier par plus de plus de 1,5 fois : le nouvel index pèse désormais moins de 75 Ko, pour la même quantité d’articles. La différence, c’est que ce sont plus les liens complets qui sont stockés, mais uniquement les identifiants des articles. On peut alors très facilement compléter l’identifiant pour constituer une URL valide (http://adressedemonblog.fr/?=identifiant). Dès lors, quelle que soit la configuration choisie, WordPress affichera l’URL finale automatiquement.

Le changement, très simple, est visible sur GitHub comme d’habitude. Si vous utilisiez le système, je vous encourage à reprendre l’idée pour un chargement plus rapide. Le visiteur n’y verra que du feu : cela ne change rien du tout pour lui.

Changements effectués sur la recherche instantanée.

Changements effectués sur la recherche instantanée.

Permaliens : plus ils sont simples, mieux c’est…

Les « permaliens » est le nom technique que l’on donne aux liens de chaque article sur votre blog. Par défaut, les permaliens des blogs WordPress sont très mauvais : on a quelque chose sous la forme http://adressedevotreblog.fr/?p=123. Certes, cela fonctionne, mais on a aucune idée sur le contenu, seulement un identifiant généré par le moteur du blog. Beaucoup de blogueurs choisissent le réglage “ Date et titre » qui donne cette forme : http://adressedevotreblog.fr/2015/02/27/exemple-article/.

Les différents réglages proposés par WordPress

Les différents réglages proposés par WordPress

C’est mieux, mais c’est encore beaucoup trop. Comme l’explique cet article de Matt Gemmell, la date est le plus souvent une information inutile. Elle encombre les URL et repousse l’information la plus importante, à savoir le slug, c’est-à-dire l’identifiant textuel de l’article. Par défaut, il s’agit du titre de l’article, sans espace, ni ponctuation, mais vous pouvez le modifier. Et d’ailleurs, je préconise de le modifier pour le rendre le plus court possible. Sur cet article par exemple, « permaliens » suffit largement, pas besoin de reprendre le titre complet.

Ajoutons que WordPress gère très bien les identifiants doubles. Si vous utilisez deux fois le même slug, le CMS ajoutera automatiquement un numéro pour distinguer les deux. Libre à vous ensuite de changer l’un des deux, si vous le souhaitez, mais il n’y aura jamais de confusion.

Remarque importante : passer des permaliens avec la date à des liens sans la date est très simple, et vous ne perdrez pas les URL précédentes. Il suffit d’ajouter cette ligne de code au fichier .htaccess et les visiteurs passeront automatiquement des anciennes adresses aux nouvelles (pensez bien à changer l’adresse de votre blog, tout de même) :

RedirectMatch 301 ^/([0-9]{4})/([0-9]{2})/([0-9]{2})/(.*)$ http://addressedevotreblog.fr/$4

Dernier point : malheureusement, les blogs sous WordPress.com ne permettent pas de changer les réglages de permaliens. On est obligé d’utiliser les URL avec date, ce qui est assez frustrant…

Améliorer les notes de bas de page avec bigfoot.js

Ce n’est pas forcément très connu, ni très utilisé, mais WordPress sait gérer les notes de bas de page à condition d’activer l’un des modules qui ajoutent la prise en charge du Markdown. Si vous utilisez le module Jetpack, vous pouvez l’activer en un clic, par exemple. Ensuite, il suffit d’insérer [^1] à l’endroit où l’on veut insérer une note de bas de page, puis à la fin de l’article, commencer une ligne avec [^1]: pour constituer une note de bas de page, avec le texte de la note sur cette ligne. Ce n’est pas forcément évident à saisir à la main, mais on prend vite la main et certains logiciels spécialisés dans le Markdown automatisent un petit peu le processus.

C’est bien, mais ces notes de bas de page sont alors situés… en fin d’article, c’est logique. À l’usage, elles ne sont pas idéales toutefois, surtout sur un petit écran. Le lecteur doit multiplier les allers et retours entre le texte et les notes et on perd un peu le fil. Souvent, on finit par ne plus lire les notes du coup, ce qui les rend totalement inutiles. Ce serait bien mieux si on pouvait avoir le contenu de la note au niveau du texte, non ? Comme ici, par exemple :

bigfoot
Lire la suite