Category: WordPress | Page 5

Serveur dédié : passer WordPress en HTTPS (TLS/SSL)

30 September 202407 octobre 2014 by Matt Biscay · Lecture: 9 minutes

Vous avez sauté le pas et avez validé votre nom de domaine avec un certificat TLS/SSL. Très bien ! Voyons comment passer WordPress sur la version sécurisée de votre site.

Il existe des plugins WordPress entièrement dédiés à SSL pour rediriger vers les pages sécurisées mais on peut très bien faire sans, avec un peu d’huile de coude.

Le tutoriel est pour Debian et WordPress tourne sous Apache chez moi. Cela prend moins d’une heure pour configurer l’essentiel mais il est probable que vous ayez des petites corrections (thèmes, plugins) pour que tout soit servi en https.

Le but est de tout (oui, absolument tout!) servir via la connexion sécurisée.

Étape 1 : configurer Apache

On édite notre fichier de configuration :

nano /etc/apache2/sites-available/www.skyminds.net

et voici ce que garde pour VirtualHost *:80 :

ServerName www.skyminds.net
ServerAlias skyminds.net
DocumentRoot /home/skyminds/public_html/
Redirect 301 / https://www.skyminds.net/Code language: JavaScript (javascript)

La directive ServerName est nécessaire. Ensuite, une simple redirection renvoie toutes les requêtes du port 80 vers le port 443, sécurisé. Même pas besoin de mod_rewrite!

WordPress : héberger les images sur un sous-domaine

30 March 202219 juin 2014 by Matt Biscay · Lecture: 4 minutes

Cela fait des années que je parle d’héberger les images du site sur un sous-domaine mais j’ai toujours remis cela à plus tard.

Je pensais que la configuration me prendrait un temps infini mais au final cela ne m’aura pris qu’un peu de réflexion et quelques minutes pour tout finaliser.

Le plus long aura été d’écrire ce tutoriel!

Aujourd’hui, c’est chose faite : les images des articles du site sont donc placées sur un sous-domaine pour des raisons de performances.

Voici donc un petit tutoriel qui détaille toutes les étapes. Cela prend environ 20 minutes.

Principe de fonctionnement

Les fichiers du site sont présentement servis par Apache. Le domaine est skyminds.net et nous allons créer un sous-domaine, qui est en fait un répertoire au niveau de l’arborescence du site, qui contiendra toutes les images de nos articles.

Par défaut, WordPress place tous les fichiers uploadés via l’interface d’administration dans /wp-content/uploads.

Nous allons donc créer un sous-domaine (static.skyminds.net) qui pointera vers le répertoire /wp-content/uploads.

L’intérêt est que nous n’avons pas à copier ou à déplacer de fichiers. Cela permet aussi de revenir à une installation plus classique à tout moment, sans intervention majeure.

Une fois ce VirtualHost créé, il ne reste plus qu’à modifier les options de WordPress pour les futurs articles et changer les anciennes URI des images dans les anciens articles. P

our finir, nous redirigerons les anciennes URI vers les nouvelles via .htaccess.

Etape 1 : on crée le sous-domaine sur le serveur Apache

Commençons par créer un nouveau VirtualHost pour notre sous-domaine:

nano /etc/apache2/sites-available/static.skyminds.netCode language: JavaScript (javascript)

et ajoutons-y ceci :

ServerAdmin webmaster@localhost
DocumentRoot /home/skyminds/public_html/wp-content/uploads
ServerName static.skyminds.net
ErrorLog /var/log/apache2/www-error.log

        
          AllowOverride None
          RequestHeader unset Cookie
          Header unset Set-Cookie
          Options FollowSymLinks
          Order allow,deny
          Allow from allCode language: JavaScript (javascript)

Plusieurs choses sont importantes à noter dans ce fichier de configuration Apache:

DocumentRoot pointe vers le répertoire /home/skyminds/public_html/wp-content/uploads
on retire tous les cookies servis par static.skyminds.net

Pas de cookies, pas de soucis et un site qui gagne en rapidité !

WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod

30 March 202212 mai 2014 by Matt Biscay · Lecture: 6 minutes

Il est primordial d’accorder les bonnes permissions aux fichiers et dossiers d’un site sur un serveur web. Si ces permissions sont trop permissives, l’administrateur du site s’expose à la compromission du site, voire du serveur.

Sous WordPress, c’est la même chose : les fichiers et dossiers du site doivent avoir les bonnes permissions.

Le problème : des permissions trop larges

Sur le site, j’ai eu pendant trop longtemps un problème avec les fichiers et répertoires de thèmes ou de plugins.

Je m’explique : à chaque fois qu’un plugin voulait créer des fichiers (dans un répertoire /cache par exemple), la seule solution était de mettre les permissions de ce répertoire à 777, le mal absolu puisque cela permet au monde entier de lire, écrire et exécuter des fichiers dans ce dossier.

Pour les fichiers de thèmes éditables par WordPress, il fallait que leurs permissions soient à 666, ce qui là aussi posait un gros souci de sécurité.

Voici donc un tuto pour apprendre comment mettre les bonnes permissions à vos fichiers et dossiers pour votre site, qu’il tourne sous WordPress ou non.

Étape 1 : définir le bon propriétaire et groupe pour les fichiers

Les fichiers du site doivent appartenir au propriétaire et au groupe qui les fait tourner.

En règle générale; les serveurs de fichiers (comme Apache ou NginX) ont comme propriétaire www-data et comme groupe groupe www-data.

Dans mon cas, ayant installé les fichiers via SSH, les fichiers étaient détenus par l’utilisateur root. Je crée donc un nouvel utilisateur pour mon site:

adduser caddy www-data

Je vais donc assigner à l’utilisateur caddyet au groupe www-data la permission d’être propriétaire de mes fichiers, avec la commande chown.

Pensez à changer caddypour le nom de votre utilisateur web ou FTP.

Des images qui renvoient une erreur 403

8 April 202226 mars 2014 by Matt Biscay · Lecture: 1 minute

Aujourd’hui, j’édite un ancien article et le prévisualise pour voir les changements : je m’aperçois alors que l’image de l’article ne s’affiche plus.

Ni une ni deux, je sors mon terminal et tente de récupérer l’image avec wget. Erreur 403. Je vérifie la configuration Apache et Varnish, rien à signaler (et surtout rien n’avait été modifié).

Je vérifie alors le fichier via FTP : il se trouve qu’il ne possédait pas les bons droits!

Evidemment, avec un chmod 600, cela ne risque pas de s’afficher… Les autres images, celles qui s’affichaient bien et renvoyaient un code 200, étaient bien chmodées en 644.

Solution : CHMOD

Il faut donc chmoder l’ensemble des fichiers du répertoires, 640 pour les images ce sera parfait :

find /home/public_html/wp-content/uploads -type f -exec chmod 640 {} \;

et pour les répertoires, 750 c’est correct :

find /home/public_html/wp-content/uploads -type d -exec chmod 750 {} \;

Notez la différence de syntaxe : on utilise f pour les fichiers (files) et d pour les répertoires (directory).

WordPress : afficher la date en français dans le thème (sans utiliser le pack de langue ou setlocale())

13 April 202216 octobre 2013 by Matt Biscay · Lecture: 4 minutes

Cela fait des années que j’utilise le même thème graphique pour mon site et je n’ai jamais vraiment pris le temps de traduire la date de publication ou de mise à jour des articles en français.

Le tutoriel qui suit ne s’adresse qu’à un cercle réduit de développeurs : il est évidemment bien plus aisé d’installer WordPress en français (avec le langage pack qui convient) ou d’utiliser la fonction PHP setlocale() comme je l’avais fait précédemment avec WP-Date FR.

Dans mon cas bien précis, je n’ai pas accès aux locales étant donné que le serveur est installé en anglais.

Je ne souhaite pas non plus installer la locale française, qui serait alors ajoutée à tous mes paquets Debian.

Et je ne souhaite pas non plus utiliser la traduction française de WordPress. It’s coding time !

La fonction sky_date_french()

Vous pouvez placer cette fonction dans le fichier functions.php de votre thème :

/*
|-----------------------------------------------------------------------
| Sky Date in French by Matt - www.skyminds.net
|-----------------------------------------------------------------------
|
| Returns or echoes the date in French format (dd/mm/YYYY) for WordPress themes.
|
*/
function sky_date_french($format, $timestamp = null, $echo = null) {
	$param_D = array('', 'Lun', 'Mar', 'Mer', 'Jeu', 'Ven', 'Sam', 'Dim');
	$param_l = array('', 'Lundi', 'Mardi', 'Mercredi', 'Jeudi', 'Vendredi', 'Samedi', 'Dimanche');
	$param_F = array('', 'Janvier', 'Février', 'Mars', 'Avril', 'Mai', 'Juin', 'Juillet', 'Août', 'Septembre', 'Octobre', 'Novembre', 'Décembre');
	$param_M = array('', 'Jan', 'Fév', 'Mar', 'Avr', 'Mai', 'Jun', 'Jul', 'Aoû', 'Sep', 'Oct', 'Nov', 'Déc');
	$return = '';
	if(is_null($timestamp)) { $timestamp = mktime(); }
	for($i = 0, $len = strlen($format); $i < $len; $i++) {
		switch($format[$i]) {
			case '\\' : // fix.slashes
				$i++;
				$return .= isset($format[$i]) ? $format[$i] : '';
				break;
			case 'D' :
				$return .= $param_D[date('N', $timestamp)];
				break;
			case 'l' :
				$return .= $param_l[date('N', $timestamp)];
				break;
			case 'F' :
				$return .= $param_F[date('n', $timestamp)];
				break;
			case 'M' :
				$return .= $param_M[date('n', $timestamp)];
				break;
			default :
				$return .= date($format[$i], $timestamp);
				break;
		}
	}
	if(is_null($echo)) { return $return;} else { echo $return;}
}Code language: PHP (php)

WordPress : retourner et exécuter un shortcode dans une fonction

2 October 202426 août 2013 by Matt Biscay · Lecture: 2 minutes

Pour les besoins du Centre de Kriya Yoga France, j’ai écrit une fonction qui doit afficher une vidéo automatiquement.

Or je voulais juste renvoyer un shortcode vidéo qui prendrait en charge toute la partie code du lecteur vidéo.

On ne peut pas juste renvoyer la valeur, il faut utiliser la fonction do_shortcode() de WordPress.

Cas 1 : exécuter un shortcode dans une fonction

La solution réside dans l’utilisation de la fonction do_shortcode(). Voici un petit exemple :

<?php
/*
|-----------------------------------------------------------------------
| Sky Show Video by Matt - www.skyminds.net
|-----------------------------------------------------------------------
|
| Returns shortcode to be executed in WordPress.
|
*/
function sky_show_video($content) {
   // do stuff
   // return video
   return do_shortcode("[video src='$vid_url' width='600' height='480' type='video/mp4' preload='true']");
}Code language: HTML, XML (xml)

Cet exemple exécute le shortcode [video].

WordPress : des images qui ont perdu leur chemin

28 December 202327 avril 2013 by Matt Biscay · Lecture: 2 minutes

Problème : chemin erroné pour certaines images

En allant faire un tour sur Google Search Console, je me suis aperçu qu’il y a avait des erreurs sur la page Si je pouvais (vraiment) choisir ma voiture… et effectivement, les images ne s’affichaient pas!

Après vérification, il se trouve que le chemin des images était totalement inexistant : c’était un mélange d’URL publique et de chemin privé, donc aucun moyen que les images d’affichent comme il faut avec le chemin privé. Et bien sûr, on ne peut pas éditer le chemin des fichiers depuis WordPress.

Solution : MySQL

En faisant une petite requête sur la table postmeta, je me suis aperçu que ce n’était pas le seul article touché. J’ai donc purement et simplement supprimé le chemin privé dans la table, via une requête SQL :

Query:

UPDATE wp_postmeta SET meta_value = replace(meta_value, '/home/public_html/images/', '') WHERE meta_key='_wp_attached_file';Code language: JavaScript (javascript)

Résultat : 173 rows affected.

Ah oui quand même, 173 enregistrements affectés, cela fait quand même quelques dizaines d’articles sur lesquels les images ne s’affichaient pas. Je n’ai aucune explication à ce phénomène, d’autant que certains de ces articles ont plusieurs années. Sûrement une mauvaise configuration de ma part à un moment donné, je suppose.

Enfin, tout cela pour dire que garder un oeil sur GWT, cela peut être utile pour débugger aussi.

Performance du site : PageSpeed à 99%

8 April 202224 janvier 2013 by Matt Biscay · Lecture: 1 minute

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.

Bash : réparer les tables MySQL en cas de crash

16 November 201520 janvier 2013 by Matt Biscay · Lecture: 1 minute

Bash Il arrive que parfois une table SQL soit complètement plantée, ce qui peut bloquer l’accès à la base de données et donc l’accès au site.

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
fi

C’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.

HTML5 : corriger l'erreur "The frameborder attribute on the iframe element is obsolete. Use CSS instead." photo

WordPress : valider le code oEmbed Youtube en HTML5

26 September 202428 novembre 2012 by Matt Biscay · Lecture: 2 minutes

Le problème : le code des vidéos n’est pas valide en HTML5

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)

La solution : filtrer le rendu oEmbed de WordPress pour purifier le code

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.

HTML5 : résoudre l’erreur “keyword publisher is not registered” (validateur W3C)

8 April 202216 novembre 2012 by Matt Biscay · Lecture: 1 minute

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 registered

HTML5 é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.

WordPress : nettoyage de la base de données

16 November 201506 novembre 2012 by Matt Biscay · Lecture: 2 minutes

wordpress_icon_blue Avec le temps, les mises à jour successives et l’installation de différents plugins, la base de données de WordPress a tendance à prendre du poids, ce qui nuit aux performances. Voici donc comment lui faire bénéficier d’un petit régime.

N’oubliez pas de faire une sauvegarde de votre base de données avant de lancer ces requêtes. Backup now.

Nettoyage de `wp_postmeta`

Avant 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.

Nettoyage de `wp_commentmeta`

On 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);

Nettoyage de `wp_options`

Passage 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_%';

← Précédent Suivant →

Étape 1 : configurer Apache

Principe de fonctionnement

Etape 1 : on crée le sous-domaine sur le serveur Apache

Le problème : des permissions trop larges

Étape 1 : définir le bon propriétaire et groupe pour les fichiers

Solution : CHMOD

La fonction sky_date_french()

Cas 1 : exécuter un shortcode dans une fonction

Problème : chemin erroné pour certaines images

Solution : MySQL

Le problème : le code des vidéos n’est pas valide en HTML5

La solution : filtrer le rendu oEmbed de WordPress pour purifier le code

Nettoyage de wp_postmeta

Nettoyage de wp_commentmeta

Nettoyage de wp_options

Nettoyage de `wp_postmeta`

Nettoyage de `wp_commentmeta`

Nettoyage de `wp_options`