Image du logo montrant « WPML » avec chaque lettre dans des couleurs différentes : W en bleu, P en bleu sarcelle, M en orange et L en marron. Une bulle de dialogue stylisée gris foncé se trouve à gauche de « WPML ». Une icône de balai avec un manche en bois et des poils jaunes se trouve à droite, faisant allusion à la maintenance ou au nettoyage de WordPress.

Désinstaller proprement WPML et nettoyer la base de données avec WP-CLI

Après avoir supprimé et désinstallé les plugins WPML et ses modules complémentaires, vous devez également nettoyer la base de données.

Cette installation particulière que j’ai nettoyée lors d’un projet Codeable n’avait pas WooCommerce ni le module complémentaire WPML WooCommerce installés, donc malheureusement ce guide ne couvre pas le nettoyage spécifique à cela.

Cependant, si vous abandonnez WPML pour des raisons de performance et souhaitez de l’aide pour nettoyer votre base de données, n’hésitez pas à me contacter ici. Vous pouvez également utiliser phpMyAdmin ou Adminer pour nettoyer WPML si vous préférez.

Sauvegardez d’abord votre base de données et testez minutieusement sur un site de staging avant de continuer !

Supprimer les tables et options de base de données WPML

Dans ces sections, nous allons supprimer les lignes pertinentes de WPML de la table wp_options, puis les tables de base de données dédiées à WPML elles-mêmes.

Si vous le souhaitez, vous pouvez recueillir le nombre de données autochargées à l’aide de la commande wp doctor (voir le tutoriel) afin que nous puissions voir à quel point les données autochargées dans wp_options diminuent après avoir nettoyé les plugins WPML.

wp doctor check autoload-options-size --allow-root --skip-plugins --skip-themes

Résultats :

+-----------------------+---------+------------------------------------------------------------+
| name                  | status  | message                                                    |
+-----------------------+---------+------------------------------------------------------------+
| autoload-options-size | warning | Autoloaded options size (1.03mb) exceeds threshold (900kb) |
+-----------------------+---------+------------------------------------------------------------+

Nous dépassons déjà le seuil recommandé de 900 KB de données autochargées dans wp_options (voir ici comment nettoyer les données autochargées).

Lire la suite

Une fenêtre de terminal stylisée affiche la commande « ./WP-CLI » en grand texte blanc, indiquant un audit de profil WordPress pour les problèmes de performances. À droite, un bonhomme allumette rouge s'exécute. La fenêtre comporte une barre de titre bleue et une icône de fermeture.

Auditer les problèmes de performance WordPress avec wp profile

La commande wp profile est un peu comme une alternative à New Relic, capable d’identifier précisément quels composants ralentissent votre site WordPress. Initialement disponible en tant que package premium via runcommand, il est désormais gratuit sur GitHub.

Si vous cherchez un hébergeur compatible avec l’installation de wp profile, jetez un œil à Kinsta et FastNyx.

J’utilise régulièrement wp profile pour diagnostiquer les problèmes de performance chez mes clients sur Codeable. Tous les développeurs WordPress devraient s’en servir ! Après avoir suivi ce guide, vous serez plus proche de la résolution de la lenteur de votre site WordPress.

Installation du package wp-profile

Lancez cette commande pour installer wp profile :

wp package install wp-cli/profile-command

Vous devriez voir que le processus s’est déroulé avec succès et que la commande wp profile est maintenant disponible:

Updating /root/.wp-cli/packages/composer.json to require the package...
Using Composer to install the package...
---
Loading composer repositories with package information
Updating dependencies
Resolving dependencies through SAT
Dependency resolution completed in 0.120 seconds
Analyzed 3696 packages to resolve dependencies
Analyzed 101022 rules to resolve dependencies
Package operations: 1 install, 0 updates, 0 removals
Installs: wp-cli/profile-command:dev-master ef44df5
- Installing wp-cli/profile-command (dev-master ef44df5)
Writing lock file
Generating autoload files
---
Success: Package installed.Code language: JavaScript (javascript)

Si vous voyez une erreur concernant composer.json reverté, l’augmentation de la mémoire devrait résoudre ce problème.

Lire la suite

Un logo carré rose avec la lettre « E » en blanc se trouve à gauche, symbolisant Elementor. À droite, une illustration simple d'un balai avec un manche marron signifie nettoyer complètement.

Nettoyer complètement la base de données WordPress après la désinstallation d’Elementor

Lorsque vous désinstallez des plugins WordPress, de nombreux éléments peuvent rester dans la base de données. Cela rend la base de données inutilement volumineuse et peut même ralentir les requêtes.

Il est toujours recommandé de nettoyer votre base de données WordPress après avoir supprimé des plugins. J’ai récemment migré un site d’Elementor vers GenerateBlocks pour améliorer les performances, donc naturellement j’ai dû nettoyer la base de données.

Ce tutoriel concerne le nettoyage post-désinstallation d’Elementor pour supprimer les lignes restantes des tables options, postmeta, usermeta et posts avec WP-CLI.

Dans ce tutoriel, nous allons couvrir les points suivants :

  • Supprimer les plugins et fichiers Elementor
  • Supprimer les types de publication Elementor
  • Supprimer la taxonomie Elementor
  • Supprimer les meta_keys Elementor des tables usermeta et postmeta
  • Supprimer les options orphelines Elementor de wp_options

Lire la suite

Graphique textuel comportant les mots « MyISAM » et « InnoDB » en grandes lettres, de style bleu et orange. Un symbole de flèche circulaire bleu foncé les relie, faisant allusion à une conversion ou une intégration dans les environnements WordPress.

Convertir des tables de base de données WordPress de MyISAM à InnoDB avec WP-CLI

Dans cet article, je vous montre comment convertir facilement vos tables de base de données WordPress du moteur MyISAM au moteur InnoDB avec WP-CLI.

Si vous vous demandez pourquoi vous voudriez effectuer cette conversion de base de données, je vous avais déjà parlé des améliorations d’InnoDB par rapport à MyISAM (tirer parti de plusieurs cœurs est assez impressionnant). On constate d’énormes améliorations du temps de réponse et une réduction de la charge du serveur après la conversion de MyISAM à InnoDB. Il existe également des différences d’index MySQL intéressantes entre les deux moteurs.

Commençons !

Conversion des tables WordPress de MyISAM à InnoDB avec WP-CLI

Vérifiez si certaines de vos tables utilisent MyISAM au lieu d’InnoDB:

wp db query "SHOW TABLE STATUS WHERE Engine = 'MyISAM'" --allow-rootCode language: JavaScript (javascript)

Si vous n’obtenez aucune sortie, il n’y a pas de tables MyISAM. Si vous obtenez une sortie, elle ressemblera à ceci :

+----------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+--------------------+----------+----------------+---------+
| Name     | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         | Update_time         | Check_time          | Collation          | Checksum | Create_options | Comment |
+----------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+--------------------+----------+----------------+---------+
| wp_posts | MyISAM |      10 | Dynamic    | 2579 |           1916 |     443644 | 28147497610655 |      4224000 |         0 |          11861 | 2017-08-19 21:56:47 | 2017-09-07 03:55:17 | 2017-08-19 21:56:48 | utf8mb4_unicode_ci |     NULL |                |         |
+----------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+--------------------+----------+----------------+---------+Code language: PHP (php)
Faites une sauvegarde de votre base de données avant de commencer !

Lire la suite

Un fond vert présente « Jetpack » dans une police élégante et stylisée à gauche, associée à une icône de balai à droite pour une touche de fantaisie. Au dessus du texte, un logo WordPress circulaire arbore un éclair audacieux à l'intérieur, offrant une ambiance électrique à votre expérience de désinstallation.

WordPress : désinstaller Jetpack proprement avec WP-CLI

Des fonctionnalités de Jetpack maintenant payantes

J’ai utilisé Jetpack pour les statistiques de mes sites WordPress site depuis 2004, soit 20 ans… mais voilà que Jetpack demande maintenant de payer pour avoir accès aux statistiques mensuelles et annuelles. Cela ne va pas être possible.

Jetpack est une extension couteau suisse, mais qui utilise vraiment tous les outils du couteau suisse? J’ai donc fait le tour des fonctionnalités de Jetpack que j’utilisais réellement et elles sont somme toute peu nombreuses: Stats, Related Posts, Publicize, et Protect.

Au lieu de Stats, j’utilise depuis quelques semaines Koko Analytics : vos statistiques sont dans votre base de données WordPress, donc chez vous, et le plugin respecte le RGPD (pas de cookies, pas d’informations personnelles). J’utilise également Plausible Analytics qui tourne sous Docker et dont je vous avais parlé il y a quelques mois.

Publicize permet d’envoyer vos posts sur les réseaux sociaux, je trouverai bien une alternative plus tard. Protect, le module de sécurité, n’est pas vraiment essentiel puisque la sécurité est en grande partie gérée par le serveur et le WAF.

Pour Related Posts, j’ai modifié le plugin qui j’utilise depuis des années pour qu’il génère des miniatures à la mode Jetpack mais sans le tracking. Car oui, tous les services de Jetpack (comme WooCommerce d’ailleurs) téléphonent les informations du site et du serveur chez Automattic. Mettons-y un terme.

Je vous propose donc un tutoriel pour désinstaller Jetpack proprement et supprimer les enregistrements Jetpack de la base de données car ils ne sont pas retirés à la suppression du plugin. Ainsi, vous aurez une base de données plus propre et donc un site plus rapide.

Lire la suite

Illustrated portrait of a man with a polygonal art style against a blue background, holding a magnifying glass, with the WordPress logo visible, with the text PHPCS, WPCS, and VSCode.

Valider votre projet VSCode avec PHP CodeSniffer (PHPCS) et WordPress Coding Standards (WPCS)

Dans ce tutoriel, nous allons explorer comment utiliser Composer pour installer et configurer PHP CodeSniffer (PHPCS) et WordPress Coding Standards (WPCS) dans un projet WordPress (PHP), spécifiquement en utilisant l’éditeur de code Visual Studio Code (VSCode). 

PHPCS est un outil indispensable pour analyser le code PHP, JavaScript et CSS afin de détecter les violations de standards de codage. WPCS est un ensemble de règles pour assurer que le code WordPress respecte les conventions de codage recommandées par WordPress. 

L’intégration de ces outils dans votre environnement de développement peut grandement améliorer la qualité du code et faciliter le respect des normes de codage.

Installation de Composer

Pour commencer, vous devez installer Composer, un gestionnaire de dépendances pour PHP qui permet d’installer et de gérer des bibliothèques au sein de vos projets PHP.

  • Windows :
    • Téléchargez et exécutez l’installateur de Composer depuis getcomposer.org.
    • Suivez les instructions à l’écran pour installer Composer.
  • macOS et Linux :
    • Ouvrez un terminal et exécutez la commande suivante pour télécharger le programme d’installation de Composer :
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"Code language: JavaScript (javascript)

Ensuite, exécutez le programme d’installation :

php composer-setup.phpCode language: CSS (css)

Pour rendre Composer accessible globalement, déplacez le fichier composer.phar dans un répertoire accessible dans votre PATH :

mv composer.phar /usr/local/bin/composer

Confirmez l’installation en vérifiant la version de Composer :

composer --version

Passons maintenant à la configuration de Visual Studio Code pour utiliser PHPCS et WPCS.

Lire la suite

Useful snippets photo

WordPress : trouver tous les articles de moins de 300 mots

Useful snippets photo

On m’a demandé sur Codeable un audit SEO sur un site qui avait plusieurs années d’existence et dont la ligne éditoriale a évolué avec le temps.

Les vieux articles, très courts et peu informatifs, offraient peu de valeur aux visiteurs et devaient donc être listés dans le but de les amender ou de les supprimer.

Le site était sous WordPress donc voici la requête que j’ai utilisée pour dresser la liste de tous les articles qui contiennent moins de 300 mots (on ne compte pas les espaces):

SELECT LENGTH(post_content) - LENGTH(REPLACE(post_content, ' ', ''))+1, post_title, ID
FROM wp_posts WHERE post_type='post' AND post_status='publish' AND ((LENGTH(post_content) - LENGTH(REPLACE(post_content, ' ', ''))+1) < 300);Code language: JavaScript (javascript)

Vous pouvez lancer cette requête SQL sur votre serveur MySQL ou dans un outil comme PHPMyAdmin ou Adminer: cela vous renvoie un tableau de 3 entrées qui contiennent le nombre de mots de l’article, le titre de l’article et son ID.

Au point de vue du SEO, il est recommandé de supprimer les articles zombies qui n’offrent pas de valeur aux visiteurs. Ces pages ne sont généralement pas indexées et n’apparaissent donc pas dans les résultats de recherche.

Mieux vaut consolider le site avec des pages à fort potentiel et avec un contenu conséquent. Ce n’est pas tant le nombre de mots qui compte que la richesse de contenu mais un nombre très faible de mots est un bon indicateur d’un article peu qualifié.

WordPress : résoudre le problème de la table wp_options à qui manquent une colonne Unique et une Primary Key photo

WordPress : résoudre le problème de la table wp_options à qui manquent une colonne Unique et une Primary Key

Chez Codeable, j’ai travaillé sur l’optimisation d’un site e-commerce propulsé par WooCommerce récemment, qui connaissait quelques problèmes de lenteur.

Sous phpMyAdmin, on trouvait également cette erreur:

Current selection does not contain a unique column

Si vous obtenez cette erreur, c’est que la structure de la table wp_options n’est pas à jour donc nous la vérifions avec wp-cli:

wp db query "DESCRIBE $(wp db prefix --allow-root)options" --allow-rootCode language: JavaScript (javascript)

Le résultat obtenu nous montre qu’il n’y a pas de clé primaire (primary key) qui est normalement option_id et qu’il n’y a pas de restriction unique imposée sur la colonne option_name:

+--------------+---------------------+------+-----+---------+-------+
| Field        | Type                | Null | Key | Default | Extra |
+--------------+---------------------+------+-----+---------+-------+
| option_id    | bigint(20) unsigned | NO   |     | NULL    |       |
| option_name  | varchar(191)        | YES  |     | NULL    |       |
| option_value | longtext            | NO   |     | NULL    |       |
| autoload     | varchar(20)         | NO   |     | yes     |       |
+--------------+---------------------+------+-----+---------+-------+Code language: PHP (php)

Et c’est là que le bât blesse – voici à quoi ressemble la structure standard de la table wp-options:

+--------------+---------------------+------+-----+---------+----------------+
| Field        | Type                | Null | Key | Default | Extra          |
+--------------+---------------------+------+-----+---------+----------------+
| option_id    | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| option_name  | varchar(191)        | NO   | UNI | NULL    |                |
| option_value | longtext            | NO   |     | NULL    |                |
| autoload     | varchar(20)         | NO   | MUL | yes     |                |
+--------------+---------------------+------+-----+---------+----------------+Code language: PHP (php)

Ajouter la Primary Key manquante à wp_options

On ajoute à la colonne option_id la clé primaire qui lui manque:

wp db query "ALTER TABLE $(wp db prefix --allow-root)options MODIFY option_id INT AUTO_INCREMENT PRIMARY KEY;" --allow-rootCode language: JavaScript (javascript)

Et on vérifie le résultat:

wp db query "DESCRIBE $(wp db prefix --allow-root)options" --allow-rootCode language: JavaScript (javascript)

Ajouter la contrainte Unique qui manque à wp_options

Pour ajouter la contrainte UNIQUE à la colonne option_name, on lance:

wp db query "ALTER TABLE $(wp db prefix --allow-root)options ADD UNIQUE (option_name);" --allow-rootCode language: JavaScript (javascript)

Là, il est possible que cela bloque, suivant ce qui se trouve dans votre table wp_options.

Résoudre le problème des doublons

Si vous obtenez une erreur comme :

ERROR 1062 (23000) at line 1: Duplicate entry 'jetpack_available_modules' for key 'option_name'Code language: JavaScript (javascript)

alors cela signifie qu’il existe des enregistrements option_name dupliqués, des doublons qui portent le même nom alors que chaque nom option_name devrait être unique.

On peut obtenir la liste des enregistrements option_name doublons avec cette requête:

wp db query "SELECT option_name, COUNT(*) optioncount FROM $(wp db prefix --allow-root)options GROUP BY option_name HAVING optioncount > 1 ORDER BY optioncount DESC;" --allow-rootCode language: JavaScript (javascript)

Par ordre ascendant, voici la liste des doublons:

+---------------------------------------------+-------------+
| option_name                                 | optioncount |
+---------------------------------------------+-------------+
| jetpack_callables_sync_checksum             |       47123 |
| jetpack_sync_full_config                    |          50 |
| jetpack_sync_full_enqueue_status            |          43 |
| jpsq_sync_checkout                          |          10 |
| jetpack_sync_full__params                   |           5 |
| jetpack_sync_settings_sync_via_cron         |           4 |
| jetpack_sync_full__started                  |           4 |
+---------------------------------------------+-------------+

On peut supprimer automatiquement tous les doublons option_name de deux manières différentes, soit en utilisant la plus vieille valeuroption_id(donc la plus petite valeur d’ID), soit en utilisant la valeuroption_id la plus récente (plus grande valeur d’ID).

Garder le doublon option_name le plus ancien

Voici la requête SQL qui montre uniquement le plus ancien enregistrement (MIN) option_id pour chaque doublon de valeur option_name:

SELECT *
FROM wp options
WHERE option_id NOT IN
    (SELECT *
     FROM
       (SELECT MIN(n.option_id)
        FROM wp_options
        GROUP BY n.option_name) x)Code language: CSS (css)

Une fois que vous avez vérifié le résultat, on peut passer à la suppression.

Cette requête SQL garde l’enregistrement (MIN) option_id le plus ancien de tous les doublonsoption_name et supprime tous les enregistrements plus récents que la valeur trouvée:

DELETE
FROM wp options
WHERE option_id NOT IN
    (SELECT *
     FROM
       (SELECT MIN(n.option_id)
        FROM wp_options n
        GROUP BY n.option_name) x)Code language: CSS (css)

Voici l’équivalent wp-cli:

wp db query "DELETE FROM $(wp db prefix --allow-root)options WHERE option_id NOT IN (SELECT * FROM (SELECT MIN(n.option_id) FROM $(wp db prefix --allow-root)options n GROUP BY n.option_name) x)" --allow-rootCode language: JavaScript (javascript)

Garder le doublon option_name le plus récent

Cette requête SQL ne montre que les enregistrements option_id les plus récents (MAX) pour tous les doublons option_name :

SELECT *
FROM wp_options
WHERE option_id NOT IN
    (SELECT *
     FROM
       (SELECT MAX(n.option_id)
        FROM wp_options n
        GROUP BY n.option_name) x)Code language: CSS (css)

Et voici la requête qui permet de garder les enregistrements option_id les plus récents (MAX) pour tous les doublons option_name en supprimant tous les doublons les plus anciens:

DELETE
FROM wp_options
WHERE option_id NOT IN
    (SELECT *
     FROM
       (SELECT MAX(n.option_id)
        FROM wp_options n
        GROUP BY n.option_name) x)Code language: CSS (css)

Voici l’équivalent wp-cli pour garder l’enregistrement option_name le plus récent:

wp db query "DELETE FROM $(wp db prefix --allow-root)options WHERE option_id NOT IN (SELECT * FROM (SELECT MAX(n.option_id) FROM $(wp db prefix --allow-root)options n GROUP BY n.option_name) x)" --allow-rootCode language: JavaScript (javascript)

Vérifier les clés et contraintes de la table wp_options

Ajoutons de nouveau la contrainte UNIQUE sur la colonne option_name :

wp db query "ALTER TABLE $(wp db prefix --allow-root)options ADD UNIQUE (option_name);" --allow-rootCode language: JavaScript (javascript)

Si vous n’obtenez pas d’erreur, vérifiez la table une nouvelle fois pour constater les changements:

wp db query "DESCRIBE $(wp db prefix --allow-root)options;" --allow-rootCode language: JavaScript (javascript)

Kaboom! Votre table wp_options possède maintenant une PRIMARY KEY sur la colonne option_id et la contrainte UNIQUE sur la colonne option_name:

+--------------+---------------------+------+-----+---------+----------------+
| Field        | Type                | Null | Key | Default | Extra          |
+--------------+---------------------+------+-----+---------+----------------+
| option_id    | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| option_name  | varchar(191)        | NO   | UNI |         |                |
| option_value | longtext            | NO   |     | NULL    |                |
| autoload     | varchar(20)         | NO   |     | yes     |                |
+--------------+---------------------+------+-----+---------+----------------+Code language: PHP (php)

Je vous conseille de vérifier la structure de la table de temps à autre, notamment si vous constatez une prise de poids anormale en très peu de temps

WordPress : nettoyer les tables wp_options et wp_postmeta photo

WordPress : nettoyer les tables wp_options et wp_postmeta

Nous allons aujourd’hui examiner deux tables importantes de votre base de données WordPress, wp_options et wp_postmeta.

C’est un domaine qui est souvent négligé en ce qui concerne les performances globales de WordPress et de la base de données.

Cela est très visible sur les sites les plus anciens et les plus gros et peut être la cause des temps de requête lents sur votre site en raison des données à chargement automatique laissées par les plugins et les thèmes tiers.

Voici quelques conseils pour vérifier, dépanner et nettoyer vos tables wp_options et wp_postmeta.

Que contient la table wp_options ?

La table wp_options contient toutes les données relatives aux options et paramètres de votre site WordPress telles que:

  • URL du site, URL de la page d’accueil, adresse électronique de l’administrateur, catégorie par défaut, publications par page, format d’heure, etc.
  • Paramètres pour les plugins, les thèmes, les widgets,
  • Données temporairement mises en cache.

La table wp_options contient plusieurs champs :

  • option_id
  • option_name
  • option_value
  • autoload

Le champ qui nous intéresse particulièrement est le champ autoload, qui contient un drapeau qui peut être soit “yes”, soit “no”. Cela contrôle essentiellement si la valeur est chargée ou non par la fonction wp_load_alloptions().

Les données à chargement automatique sont des données qui sont chargées sur chaque page de votre site WordPress. L’attribut autoload est défini sur «yes» par défaut pour les développeurs, mais tous les plugins ne doivent théoriquement pas charger leurs données sur chaque page.

Le problème que les sites WordPress peuvent rencontrer est celui où la table wp_options contient une grande quantité de données auto-chargées. Cependant, la table wp_options n’a pas non plus été conçue pour contenir des milliers de lignes.

Combien coûte trop de données autoloadées? Cela peut varier, bien sûr, mais idéalement, vous voulez que la taille de votre ordinateur soit comprise entre 300 Ko et 1 Mo.

Une fois que vous commencez à approcher la plage de 3 à 5 Mo ou plus, il existe très probablement des éléments pouvant être optimisés ou supprimés du chargement automatique.

Et tout ce qui dépasse 10 Mo doit être traité immédiatement. Cela ne signifie pas toujours que cela posera un problème, mais c’est un bon point de départ.

Vérifier la taille totale des données auto-chargées

On peut calculer la taille totale des données auto-chargées d’un site WordPress en effectuant la requête suivante sous MySQL:

SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';Code language: JavaScript (javascript)

La valeur d’autoload_size est exprimée en octets. Il y a 1024 octets dans un KB et 1024 KB dans un MB. Dans notre cas, 622 138 octets sont donc égaux à 0,62 MB. Donc pour ce site, c’est une bonne taille! Si vous restituez moins de 1 Mo, ne vous inquiétez pas. Cependant, si le résultat était beaucoup plus grand, passez à l’étape suivante.

Lire la suite

Serveur dédié : remplacer gzip par pigz pour profiter de la compression multi-core photo

Serveur dédié : remplacer gzip par pigz pour profiter de la compression multi-core

Tous les matins, une sauvegarde des sites hébergés sur le serveur est effectuée.

A ce moment là, gzip tourne à plein régime et utilise pendant un certain temps le CPU – la montée en charge atteint 50%, ce qui devient limite pour la réactivité des sites Et pour cause : gzip ne fonctionne qu’en mono-core.

Il nous faut donc optimiser tout cela ! Mark Adler, l’auteur de gzip, a écrit pigz (qui se prononce pig-zee, à l’américaine) pour compresser fichiers et répertoires en utilisant tous les coeurs du processeur simultanément.

Pigz représente donc un gain de temps mais allège également la charge du processeur, sollicité moins longtemps.

Installation de pigz

Pigz est disponible sur la plupart des distributions linux, on peut donc l’installer avec un simple :

apt install pigz

L’autre avantage, c’est que si on lit le manuel, on se rend compte que les options et paramètres sont les mêmes que ceux de gzip, ce qui en fait un drop-in replacement de choix.

Remplacer gzip par pigz sur le serveur

L’occasion d’optimiser la compression des sauvegardes est trop belle : et si nous remplacions tout simplement gzip par pigz, sur l’intégralité du serveur et sans toucher à aucun de nos scripts ?

Allez, c’est parti ! On édite donc le fichier .bashrc :

nano .bashrcCode language: CSS (css)

et on y ajoute les deux fonctions suivantes :

###
# Matt Biscay
# https://www.skyminds.net/?p=29838
# Use pigz instead of gzip
###
function gzip(){
 pigz $@
}
export -f gzip

function gunzip(){
 unpigz $@
}
export -f gunzipCode language: PHP (php)

Cela nous permet de remplacer les fonctions gzip et gunzip par pigz et unpigz, respectivement.

Sauvegardez le fichier et rechargez-le pour activer les changements :

source .bashrcCode language: CSS (css)

Et voilà : pigz remplace désormais gzip pour toutes les opérations de compression du serveur. A nous la compression multi-core :)

WordPress : corriger l'erreur "Warning: Parameter 1 to wp_default_styles() expected to be a reference, value given" photo

WordPress : corriger l’erreur “Warning: Parameter 1 to wp_default_styles() expected to be a reference, value given”

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 PHP 7.4, 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.

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

Installer Redis pour accélérer WordPress sous Debian

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

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> pingCode language: CSS (css)

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-PASSECode language: PHP (php)

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

service redis-server restart

Lire la suite