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.

Trouver les enregistrements les plus gourmands

Pour trouver les enregistrements les plus gourmands en taille, voici la requête à effectuer:

SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)Code language: JavaScript (javascript)

Cela vous donne le top 10 des plus gros enregistrements qui sont chargés automatiquement sur chaque page. Si vous ravisez un enregistrement qui correspond à un plugin que vous n’utilisez plus, supprimez-le (sauvegardez-le avant!).

Top 10 des plus gros enregistrements

Voici la requête qui donne les 10 plus gros enregistrements de la table wp_options:

SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;Code language: PHP (php)

Il ne vous reste plus qu’à vérifier que ces enregistrements appartiennent bien à des plugins actifs sur votre installation WordPress. Si ce n’est pas le cas, supprimez-les (faites une sauvegarde avant!).

Que contient la table wp_postmeta?

La table wp_postmeta est un cas particulièrement délicat: elle n’a pas de lignes évidentes à effacer, comme wp_posts (révisions) ou wp_options (transitoires). Mais dans certaines circonstances, elle peut finir par avoir une taille gigantesque.

Les deux dangers de la table wp_postmeta sont importer les restes d’un autre CMS (tel que Blogger, Movable Type, etc) qui peut créer des doublons dans les enregistrements, et les restes de plugins supprimés ou désactivés qui ne se sont pas nettoyés après eux-mêmes lors de leur désactivation et suppression.

La table wp_postmeta est une table méta standard de WordPress. Elle comporte donc un identifiant unique pour la ligne, l’ID de la publication à laquelle la ligne est attachée et des paires meta_key et meta_value qui ajoutent les métadonnées aux publications, aux pages et aux pièces jointes.

Les lignes meta_key sont préfixées d’un underscore (pour les paramètres secret / par défaut) et d’aucun underscore (pour les paramètres accessibles par l’utilisateur dans le tableau de bord de l’administrateur), nous devons donc rechercher les deux.

Trouver les enregistrements publics (sans underscore)

SELECT SUBSTRING_INDEX(meta_key, '_', 1) AS `Meta`,
(SUM(LENGTH(meta_id)+LENGTH(post_id)+LENGTH(meta_key)+LENGTH(meta_value)))/1048567 AS `Size`, COUNT(*) AS `Count`
    FROM wp_postmeta
    WHERE meta_key NOT LIKE '\_%'
    GROUP BY `Meta`
    ORDER BY `Size` DESC;Code language: JavaScript (javascript)

Trouver les enregistrements privés (avec underscore)

SELECT SUBSTRING_INDEX(meta_key, '_', 2) AS `Meta`, 
(SUM(LENGTH(meta_id)+LENGTH(post_id)+LENGTH(meta_key)+LENGTH(meta_value)))/1048567 AS `Size`, COUNT(*) AS `Count`
    FROM wp_postmeta
    WHERE meta_key LIKE '\_%'
    GROUP BY `Meta`
    ORDER BY `Size` DESC;Code language: JavaScript (javascript)

Un peu de ménage

Lorsque vous lancez les deux requêtes ci-dessus, il suffit de regarder la dernière date d’utilisation de la meta_key en question.

Un exemple concret : si vous avez utilisé WooCommerce il y a deux ans et que vous ne l’utilisez plus sur votre site, vous aurez très certainement à nettoyer toutes les clés de WooCommerce ainsi que toutes les clés des fiches produits.

Si vous avez besoin d’un professionnel pour prendre en charge le nettoyage de votre site WordPress en toute sécurité, contactez-moi.