Category

WordPress

Category

Tous les articles relatifs à WordPress et à son optimisation.

Je travaille actuellement sur un projet Codeable qui nécessite de passer de PHP5.6 à PHP7.2. Le site en question est une boutique WooCommerce avec un thème custom qui est hébergé chez WPEngine. Jusque là, tout va bien.

Lors de la migration sur un serveur PHP7.2, le site de developpement (Staging) affiche alors un message d’avertissement sur toutes les pages :

Parameter 1 to wp_default_styles() expected to be a reference, value given
Parameter 1 to wp_default_scripts() expected to be a reference, value given

Après avoir passé un bon moment à éliminer les causes (plugins et thème), il se trouve que c’est un bug de WordPress 4.9.8 (la dernière version en date) dont il est question dans le ticket #44979.

Voici la solution temporaire à ce problème :

  1. éditez /wp-includes/script-loader.php
  2. retirez le caractère & de l’argument des fonctions wp_default_scripts() et wp_default_styles()
  3. sauvegardez le fichier
  4. rechargez le site, les deux messages d’avertissement ont disparu.

Voilà, ce n’est qu’un hotfix mais ce bug devrait être corrigé dans la prochaine version de WordPress – version 4.9.9 – qui sortira prochainement.

Aujourd’hui, nous installons le serveur Redis pour accélérer les temps de chargement de tous les sites présents sur le serveur.

Installer Redis pour accélérer WordPress sous Debian photo

Redis (de l’anglais REmote DIctionary Server qui peut être traduit par « serveur de dictionnaire distant » et jeu de mot avec Redistribute1) est un système de gestion de base de données clef-valeur scalable, très hautes performances, écrit en C ANSI. Il fait partie de la mouvance NoSQL et vise à fournir les performances les plus élevées possibles.

Redis permet de manipuler des types de données simples : chaînes de caractères, tableaux associatifs, listes, ensembles et ensembles ordonnés.

Une des principales caractéristiques de Redis est de conserver l’intégralité des données en RAM. Cela permet d’obtenir d’excellentes performances en évitant les accès disques, particulièrement coûteux sur ce plan.

Lorsqu’une page WordPress est chargée par exemple, des requêtes sur la base de données sont lancées et cela prend un certain temps pour récupérer ces informations. Lorsque Redis est activé, il garde ces requêtes SQL en mémoire, ce qui permet de gagner en temps de chargement des pages.

Voici donc le tutoriel pour mettre en place Redis sur votre serveur. Cela prend environ 15 minutes.

Installation du serveur Redis

Nous installons le serveur Redis et le paquet PHP associé:

apt install redis-server php-redis

Nous vérifions que Redis est bien actif, il nous suffit de lancer redis-cli:

redis-cli

On tape ping dans l’invite:

127.0.0.1:6379> ping

Réponse:

PONG

Parfait, le serveur Redis est bien installé et actif.

Configuration de Redis

Editons le fichier de configuration de Redis :

nano /etc/redis/redis.conf

Changez les valeurs suivantes :

maxmemory 256mb # max memory 
maxmemory-policy allkeys-lru # replace old keys with fresher ones
requirepass VOTRE-MOT-DE-PASSE

Enregistrez et relancez le serveur pour prendre en charge la nouvelle configuration:

service redis-server restart
CSS : supprimer subtilement le placeholder d'un champ input ou textarea photo

Je viens de finir un projet sur Codeable qui utilisait WordPress et Gravity Forms et lors de la réalisation d’un formulaire de réservation complexe, je me suis heurté à Chrome qui ne supprime pas toujours (suivant les versions utilisées) le texte du placeholder d’un champ de type input ou textarea lorsque le curseur est placé à l’intérieur (action focus).

Normalement, la valeur du placeholder disparaît et permet à l’utilisateur de compléter sa saisie mais sous certaines versions de Chrome, cela ne passe pas bien.

J’ai considéré l’utilisation de JavaScript, évidemment, avant de me rendre compte que l’on pouvait résoudre le problème avec quelques règles CSS natives. Toutes les déclarations sont à ajouter – ne cherchez pas à les compiler, cela ne fonctionnera pas !

On joue donc avec l’opacité et un léger effet de transition pour le côté subtil et smooth :

/* Placeholders */
::-webkit-input-placeholder { opacity: 1; -webkit-transition: opacity .5s; transition: opacity .5s; }  /* Chrome 56, Safari 9 */
:-moz-placeholder { opacity: 1; -moz-transition: opacity .5s; transition: opacity .5s; } /* FF 4-18 */
::-moz-placeholder { opacity: 1; -moz-transition: opacity .5s; transition: opacity .5s; } /* FF 19-51 */
:-ms-input-placeholder { opacity: 1; -ms-transition: opacity .5s; transition: opacity .5s; } /* IE 10+ */
::placeholder { opacity: 1; transition: opacity .5s; } /* Modern Browsers */

/* Focus */
*:focus::-webkit-input-placeholder { opacity: 0; } /* Chrome 56, Safari 9 */
*:focus:-moz-placeholder { opacity: 0; } /* FF 4-18 */
*:focus::-moz-placeholder { opacity: 0; } /* FF 19-50 */
*:focus:-ms-input-placeholder { opacity: 0; } /* IE 10+ */
*:focus::placeholder { opacity: 0; } /* Modern Browsers */

Ps : Chrome souffre également d’un bug qui concerne la fonction autofill qui aide les utilisateurs à pré-remplir les formulaires.

Pensez donc à supprimer les valeurs enregistrées pendant vos tests (Chrome > Paramètres > Paramètres avancés > Confidentialité et sécurité > Effacer les données de navigation > Paramètres avancés > cocher Données de saisie automatique).

Enjoy !

Dernièrement, j’ai développé un nouveau site WordPress pour une cliente dont l’hébergement ne prévoit pas de staging site, ce qui est un peu ballot.

Plutôt que d’utiliser son hébergeur, je me suis dit que j’allais travailler sur la nouvelle version depuis un répertoire sous SkyMinds.

Ajouter un nouveau site WordPress dans un répertoire, sans conflit avec le site principal photo

Le problème s’est assez rapidement posé : les diverses règles de configuration de SkyMinds (à la racine du domaine) entrent en conflit avec le nouveau site qui se trouve dans un répertoire. Il est donc nécessaire d’ajuster la configuration du bloc serveur NginX.

J’ai bien sûr effectué quelques recherches sur le net et après moults tests, il s’avère que la plupart des configurations nginx que l’on y trouve sont erronées. En relisant les docs, j’ai fini par trouver une solution satisfaisante.

Des erreurs 404, 403 ou 500

Je mentionnais à l’instant les configurations erronées – elles ne permettent pas au nouveau site d’afficher les pages correctement : erreur 404 pour les pages, erreur 404 pour la partie administration ou alors erreur 403 ou même 500…

Le plus surprenant est que l’on retrouve quasiment ces mêmes configurations dans tous les tutoriels. Cela fonctionnait peut-être à une époque mais plus maintenant avec les dernières versions de WordPress et NginX.

La configuration qui fonctionne

Voici donc la configuration que j’ai concoctée et qui permet d’avoir un autre site WordPress (comme par exemple https://example.com/nouveau-site/) lorsqu’un site WordPress (de type https://example.com) existe déjà à la racine du domaine. Le but est donc d’avoir deux sites fonctionnels qui n’entrent pas en conflit au niveau de la gestion des règles.

On édite le server block de notre domaine :

nano /etc/nginx/sites-available/example.com

Dans la partie server de la configuration, on ajoute :


# Script name : Add new WP site in subfolder
# Author : Matt Biscay
# Author URI : https://www.skyminds.net/?p=29604

# Add new location point with rewrite rule
location @nouveausite{
rewrite . /nouveau-site/index.php last;
}

# Add subfolder config
location  /nouveau-site {
         root /home/example/public_html/nouveau-site;
         index index.php;
         try_files $uri $uri/ @nouveausite;
}

Sauvegardez le fichier. On teste la nouvelle configuration:

nginx -t

et on relance nginx et PHP:

service nginx restart 
service php7.2-fpm restart

Et voilà, le nouveau site dans son répertoire devrait maintenant être fonctionnel, sans conflit avec le site principal.

Sur un serveur qui héberge plusieurs sites WordPress différents, il est fort probable qu’il y ait quelques plugins en commun sur chaque installation.

WordPress permet de mettre à jour les thèmes et plugins en quelques clics mais cela suppose de s’identifier sur chaque site ou alors de donner permission à une application tierce comme JetPack pour vous faciliter la tâche.

WorddPress : éviter d'avoir à mettre le même plugin à jour sur chaque site hébergé sur le serveur photo

Cela suppose toutefois de bien vouloir rassembler toutes les autorisations sur un seul compte, ce qui n’est pas optimal puisqu’il n’y a plus cloisonnement entre les sites hébergés.

Nous allons donc mettre en place un système de liens symboliques (symlink ou symbolic link en anglais) pour gagner pas mal de temps lors des mises à jour.

Principe d’optimisation de la mise à jour des plugins récurrents

Sur le serveur, j’utilise une petite astuce tout simple : j’utilise mon site comme master officiel du serveur. C’est lui que je mets à jour en premier et tous les autres sites “hériteront” des nouvelles mises à jour, automatiquement et sans manipulation de ma part.

Mise en place de liens symboliques

Comme le serveur tourne sous Linux, il nous suffit de faire un lien symbolique sur le site slave vers le dossier d’un plugin qui se trouve sur le site master.

Lorsque je mettrai certains plugins de SkyMinds à jour par exemple, ces plugins qui sont également installés sur le site du Centre de Kriya Yoga France seront également à jour. En fait, aucun fichier de ce plugin ne sera présent chez eux, seul un lien symbolique.

Concrètement, voici la marche à suivre :

  1. On se place dans le répertoire /wp-content/plugins du site slave (kriyayoga.fr dans cet exemple):
    cd /kriyayoga/wp-content/plugins
  2. On crée un lien symbolique qui va pointer vers le répertoire qui se trouve dans le répertoire de SkyMinds :
    ln -s /skyminds/wp-content/plugins/my-plugin my-plugin
  3. Et voilà !

Lorsque le site est servi via HTTPS, toutes les ressources – même les ressources oEmbed automatiquement générée par WordPress – qui composent une page doivent également être servies via une connexion chiffrée aussi.

WordPress : afficher des média oEmbed avec HTTPS photo

Il se trouve que je mets des vidéos Youtube et consorts de temps en temps : elles ne s’affichaient plus en https, étant servies par défaut en http.

Le changement vers HTTPS est en marche mais tous les services oEmbed n’ont pas encore adopté le chiffrement des connexions.

Servir les vidéos Youtube en HTTPS

Au lieu d’utiliser Youtube.com, nous allons utiliser la version cookie-less de Youtube, à savoir youtube-nocookie.com : cela permet d’éviter les cookies pisteurs de Google et donc offre plus de sécurité et de respect de la vie privée.

J’utilise ce système depuis des années sur SkyMinds donc je me suis dit qu’il était bien temps de le partager dans ces colonnes.

Le code permet donc de remplacer youtube.com par youtube-nocookie.com dans le code généré par l’oEmbed WordPress.

Ce code est à ajouter dans votre utility plugin (ou à défaut le fichier functions.php de votre thème WordPress).

Le premier code remplace toutes les occurences des médias HTTP pour HTTPS :

<?php
/* Force HTTPS rewrite for oEmbeds
* Source : https://wordpress.stackexchange.com/questions/40747/how-do-i-embed-youtube-videos-with-https-instead-of-http-in-the-url
*/
add_filter( 'embed_oembed_html', 'sky_embed_oembed_html' );
function sky_embed_oembed_html( $html ) { 
  return preg_replace( '@src="https?:@', 'src="', $html );
}

Le second code modifie tous les appels à youtube.com et les remplace par youtube-nocookie.com, ce qui empêche la création de cookies pisteurs :

<?php
//BEGIN Embed Video Fix - HTTPS and privacy mode
//https://wordpress.org/support/topic/forcing-ssl-return-for-youtube-oembed

add_filter('the_content', 'sky_add_secure_video_options', 10);
function sky_add_secure_video_options($html) {
   if (strpos($html, "<iframe" ) !== false) {
    	$search = array('src="http://www.youtube.com','src="http://youtube.com');
	$replace = array('src="https://www.youtube-nocookie.com','src="https://www.youtube-nocookie.com');
	$html = str_replace($search, $replace, $html);
   	return $html;
   } else {
        return $html;
   }
}

Cela a l’air tout bête mais cela permet de faire respecter un peu plus notre droit au refus de se faire pister à tout bout de champs sur le net.

Le petit plus : on charge également moins de cookies, qui ne sont pas des ressources cachables par essence donc on améliore un peu aussi le temps de chargement de la page.

Il peut être nécessaire de changer le mot de passe d’un utilisateur WordPress par exemple lorsque l’on migre un compte, lorsque l’on repart de zéro avec une base de données vierge ou lorsque le mot de passe du site de développement diffère de celui du site de production. Ou tout simplement pour en mettre un plus facile à retenir.

WordPress : changer le mot de passe d'un utilisateur depuis le serveur SQL photo

Voici donc comment changer le mot de passe d’un utilisateur WordPress directement depuis un terminal connecté sur le serveur de la base de données.

Changer le mot de passe d’un utilisateur WordPress depuis MariaDB

1. Connectez-vous au serveur de base de données :

mysql -u root -p

puis entrez votre mot de passe :

Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.

2. Sélectionnez la base de données qui contient l’installation WordPress concernée :

USE wordpress_wpdb;

Résultat :

Database changed

3. Vérifiez que votre utilisateur (ici : matt) est bien présent dans la base :

SELECT ID, user_login, user_pass FROM wp_users WHERE user_login LIKE '%matt%';

Résultat:

+----+-------------+------------------------------------+
| ID | user_login  | user_pass                          |
+----+-------------+------------------------------------+
| 78 | matt                | $P$BUZ6Uvu8aie2tBEWqwTu07qfzlKXc80 |
+----+-------------+------------------------------------+
1 row in set (0.00 sec)

4. Choisissez un mot de passe (ici: q8U@jM5uNMa*R66R), qui sera automatiquement chiffré en MD5 :

UPDATE wp_users SET user_pass = MD5('q8U@jM5uNMa*R66R') WHERE ID=78 LIMIT 1;

Résultat:

Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

Sous WordPress, il est très simple de traduire les thèmes et plugins grâce au logiciel PoEdit et à un fichier de langue au format .pot ou .po – mais qu’advient-il de vos traductions lorsque le plugin ou thème est mis à jour avec de nouvelles chaînes?

PoEdit : mettre à jour les fichiers de traduction de vos thèmes et plugins WordPress photo

Mettre à jour votre fichier de traduction avec PoEdit

Et bien, il suffit tout simplement de resynchroniser votre fichier de traduction avec le fichier de traduction modèle, généralement au format .pot pour ajouter à votre fichier les chaines manquantes.

1. Dans PoEdit, ouvrez votre fichier de traduction au format .po

2. Ouvrez le menu Catalog > Update from POT file et sélectionnez le fichier POT de votre thème ou plugin mis à jour.

Cela ajoute toutes les nouvelles chaines à traduire dans votre fichier de traduction et retire les chaines obsolètes.

3. Traduisez les nouvelles chaines qui viennent d’être ajoutées.

4. Sauvegardez votre fichier et pensez à exporter vos traductions en .mo également. Vous devriez toujours avoir vos traductions en .po et .mo

5. Pour ne pas que vos traductions soient écrasées à la prochaine mise à jour du thème ou plugin, elles sont à placer dans le dossier :

  • wp-content/languages/themes pour les thèmes
  • wp-content/languages/plugins pour les plugins

Voilà, les traductions de votre thème ou plugin sont maintenant à jour.

WordPress : récupérer la liste emails des membres et commentateurs photoLorsque vous installez WordPress en local sur votre machine, il est assez courant que les droits des fichiers et dossiers ne permettent pas d’entrée de jeu d’installer ou de mettre à jour des plugins ou des thèmes.

Voici comment résoudre ce problème en quelques minutes.

Passage au système de fichier direct

1. On commence par éditer notre fichier wp-config.php, qui contient pas mal de constantes primordiales pour WordPress:

nano wp-config.php

2. On y rajoute, vers le haut du fichier, une constante qui passe le système de fichier en mode direct:

define('FS_METHOD', 'direct');

Sauvegardez votre fichier wp-config.php. Les fichiers de thèmes et de plugins seront désormais directement installés sans que la popup demandant des informations FTP ou SSH ne s’affiche.

Vérification des droits des fichiers et répertoires

En local, par contre, ce sera un petit peu différent : l’utilisateur www-data (Apache) doit pouvoir gérer les fichiers mais si vous souhaitez éditer des fichiers, ce qui est quand même le but d’une installation en locale, il faut que votre utilisateur puisse aussi gérer et avoir le droit d’écriture sur les fichiers.

1. Tout d’abord, on donne les droits à Apache à tous les fichiers et dossiers de l’installation WordPress :

sudo chown www-data:www-data -R /home/matt/www/

2. J’ajoute ensuite mon utilisateur de session, matt, dans le groupe www-data (Apache):

sudo usermod -aG www-data matt

3. On vérifie que l’utilisateur matt fait bien partie du groupe www-data :

groups matt

Cela nous retourne la liste de tous les groupes auquel j’appartiens :

matt : matt adm lp dialout fax cdrom floppy tape audio dip www-data video plugdev fuse lpadmin netdev admin sambashare vboxusers usb bluetooth scanner

4. On stipule que l’utilisateur matt est propriétaire de ces fichiers :

sudo chown matt:www-data -R /home/matt/www/

5. On assigne les permissions standard de WordPress, chmod 755 pour les répertoires et chmod 664 pour les fichiers, le tout en mode récursif pour n’oublier personne :

cd /home/matt/www
sudo find . -type d -exec chmod -R 755 {} \;
sudo find . -type f -exec chmod -R 664 {} \;

6. Enfin, on assigne des permissions plus larges (chmod 775) pour le répertoire /wp-content de notre installation qui contient nos plugins et thèmes pour pouvoir les éditer :

 cd /home/matt/www/wp-content
sudo find . -type d -exec chmod -R 775 {} \;
sudo find . -type f -exec chmod -R 664 {} \;

Vous pouvez maintenant installer thèmes et plugins en local et être en mesure d’éditer vos fichiers avec votre utilisateur linux, sans problèmes de droits.

wordpress-svn-logo

De temps en temps, je mets mes plugins WordPress sur le dépôt officiel mais j’utilise assez rarement subversion – connu également sous le doux nom svn – et j’ai tendance à en oublier la syntaxe.

Voici donc un petit aide-mémoire pour l’utilisation de subversion avec les plugins WordPress.

Ajouter un plugin sur le dépôt officiel WordPress

1. On crée un répertoire local sur notre machine pour y accueillir notre projet:

mkdir my-local-dir

2. On synchronise le dépôt avec un check-out en donnant le slug du plugin:

svn co https://plugins.svn.wordpress.org/your-plugin-name my-local-dir

Résultat:

> A	my-local-dir/trunk
> A	my-local-dir/branches
> A	my-local-dir/tags
> Checked out revision 1135625.

Subversion vient d’ajouter ( “A” signifie “add” ) tous les répertoires du dépôt central à notre copie locale.

3. On copie tous les fichiers du plugin dans le répertoire trunk/:

cd my-local-dir/
my-local-dir/$ cp ~/my-plugin.php trunk/my-plugin.php
my-local-dir/$ cp ~/readme.txt trunk/readme.txt

4. On prépare l’ajout des fichiers du plugin au dépôt central:

my-local-dir/$ svn add trunk/* assets/*
> A	trunk/my-plugin.php
> A	trunk/readme.txt

5. On donne un message à notre check-in et on envoie les fichiers au dépôt central :

my-local-dir/$ svn ci -m 'Adding first version of my plugin'
> Adding	trunk/my-plugin.php
> Adding	trunk/readme.txt
> Transmitting file data .
> Committed revision 1135626.

Voilà, vous venez d’ajouter votre plugin au dépôt officiel de WordPress !

Supprimer un fichier sur le dépôt

Pour supprimer un fichier sur le dépôt, il faut supprimer le fichier avec svn delete puis commettre les changements avec svn commit. C’est lors du commit que le fichier est supprimé du dépôt :

svn delete myfile
> D         myfile

svn commit -m "Deleted file 'myfile'."
> Deleting       myfile
> Transmitting file data .
> Committed revision 1135629.

Le problème : des iframes entièrement vides dans l’interface d’administration WordPress

Wordpress iconDepuis mon passage à HTTPS, j’ai constaté que lorsqu’un plugin possédait une mise à jour et que l’on cliquait sur le lien “voir les détails de la version x.x”, j’avais droit à une jolie lightbox (ThickBox sous WordPress) toute vide.

C’était également le cas lors de la mise à jour des plugins, des thèmes ou de WordPress même : je n’obtenais jamais la ligne qui confirmait que le plugin avait bel et bien été réactivé.

Cette situation a duré des mois : j’ai d’abord soupçonné une mise à jour de WordPress qui aurait abimé un fichier donc j’ai ré-uploadé tous les fichiers, procédé à de multiples mises à jour mineures puis majeures. J’ai ensuite jeté un œil aux plugins, en désactivant quelques uns pour essayer de trouver celui qui perturbait le système. Rien. Et visiblement, personne n’a jamais été confronté à ce problème sur la toile.

Et puis cette semaine, eurêka !

La solution : la configuration Apache du serveur

J’ai trouvé la solution un jour que je travaillais sur autre chose, en analysant les messages de l’inspecteur de code. Ce dernier me renvoyait de multiples avertissements lorsqu’un message a attiré mon attention :

[quote class=”center”]Load denied by X-Frame-Options…. X-Frame-Options does not permit framing.[/quote]

Et là, banco, j’ai immédiatement compris ce qui clochait. Lors de la bascule vers la version chiffrée du site, j’avais effectivement ajouté un nouvel entête X-Frame-Options comme ceci :

Header always set X-Frame-Options DENY

Cela est bien trop restrictif puisque la valeur DENY empêche l’affichage du site dans un cadre (frame). Or le back-office de WordPress charge effectivement les messages relatifs aux mises à jour dans un cadre, sous la forme d’une lightbox: il faut donc utiliser la valeur SAMEORIGIN.