L'un de mes clients est sur un blog assez volumineux en termes de nombre de publications et de trafic. J'essaie de réduire sa base de données à une taille raisonnable. Une des choses qui pèse sur vous est littéralement des dizaines de milliers de révisions de publications.
J'ai déjà configuré Wordpress config pour limiter le nombre de révisions à deux:
define('WP_POST_REVISIONS', 2);
Mais je veux supprimer toutes les révisions existantes.
Question 1 : Est-il prudent de supprimer directement toutes les lignes de la table wp_posts comportant un type de révision post_type? (J'ai vu des réponses contradictoires à ce sujet - mais j'aimerais pouvoir le faire de cette façon si c'est sûr).
Question 2 : … et ceci n’est pertinent que si je devraisPASsimplement supprimer directement de la question un:
J'ai trouvé cette réponse où songdogtech fournit une requête de base de données à supprimer en toute sécurité, mais (1) elle répond spécifiquement à une question multisite (il s'agit d'un site unique) et (2) je viens de mettre à niveau le site vers 3.6, qui comprenait des changements de base de données. (Donc, je ne suis pas assez doué pour lire les requêtes dans les bases de données pour savoir exactement ce qui se passe là-bas et si cela fonctionnerait pour un seul site dans WP 3.6
Est-il prudent de supprimer directement toutes les lignes de la table wp_posts ayant un type de révision post_type? (J'ai vu des réponses contradictoires à ce sujet - mais j'aimerais pouvoir le faire de cette façon si c'est sans danger)
Sûr, c'est sûr.
S'il n'y a qu'un seul utilisateur (vous) qui peut éditer des publications sur le site, c'est sans danger et cela ne pose aucun autre problème.
S'il y a plus d'utilisateurs, et qu'un d'entre eux est en train de modifier un article et entre-temps, vous supprimez les révisions, cela n'est toujours pas dangereux, mais cela peut être gênant pour cet utilisateur de voir disparaître les révisions.
Ce qui est absolument unsafe est d’exécuter la requête SQL sur la base de données WP sans prendre une (ou plusieurs, plus) sauvegarde (s) abordable (s) ni tester la requête dans l’environnement local/dev. préalablement.
Imaginons que vous tapiez accidentellement 'post' au lieu de 'révision', si vous n'avez aucune sauvegarde et que vous exécutez la requête sur le site de production, que se passe-t-il?
En ce qui concerne la deuxième question, supprimez simplement {id}_
partout où il apparaît dans la requête posté so wp_{id}_posts
devient wp_posts
et ainsi de suite.
A warning , la partie wp_
est le préfixe de table standard, qui indique que les types sympas changent en quelque chose de différent lors de l’installation de WP.
Si vous l'avez changé et que dans votre wp_config.php
, vous voyez $table_prefix = 'something_else_than_wp_';
Votre requête devient:
DELETE a,b,c
FROM something_else_than_wp_posts a
LEFT JOIN something_else_than_wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN something_else_than_wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'
Je suggère de procéder comme ça:
Les détails fournis jusqu'à présent sont au mieux incomplets, et la requête a, b, c n'est pas bonne, voire dangereuse. Il oublie de prendre en compte de nombreuses dépendances potentielles. Il y a une discussion complète et de meilleures requêtes ici
Il y a aussi cette version révisée de la requête qui devrait être bien meilleure, mais testez dans un environnement de développement à faible risque et effectuez une sauvegarde:
Plus précisément:
DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON ( a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON ( a.ID = c.post_id )
LEFT JOIN wp_term_taxonomy d ON ( b.term_taxonomy_id = d.term_taxonomy_id)
WHERE a.post_type = 'revision'
AND d.taxonomy != 'link_category';
Cette requête traite des données plus anciennes pour lesquelles WordPress pourrait utiliser le même object_id dans la table wp_term_relationships pour une publication et un lien. En exécutant les autres versions de cette requête a, b, c, vous pouvez également supprimer involontairement des données de lien. Ce n’est pas un problème avec les nouvelles installations de WordPress.
Si vous exécutez cette version de la requête et obtenez 0 suppression, cela signifie simplement que vous n'avez aucune entrée 'catégorie_lien' dans votre table wp_term_taxonomy. Vous pouvez vérifier en vérifiant cette table, puis supprimez simplement la dernière ligne et réexécutez la requête.
Mais assurez-vous de sauvegarder, tester et vérifier les résultats avant d'utiliser des données de production. Cette requête a fait passer l’une de mes tables wp_posts de 300 Mo à 5 Mo après optimisation dans ma table de révision.
Exécuter une requête SQL:
DELETE FROM wp_posts WHERE post_type = "revision" // for "wptest" DB, note the table name
REMARQUE: La requête ci-dessus "supprime simplement les publications marquées en tant que révisions. Si, pour une raison quelconque, vous associez une révision à une balise ou à une catégorie qui avait ensuite été supprimée lors de la publication de la publication finale, vous aurez des entrées supplémentaires dans d'autres tableaux, tels que des termes. "La requête appropriée pour supprimer en toute sécurité toutes vos révisions est suit (changez le préfixe de la table si nécessaire):
DELETE a,b,c FROM wp_posts a LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id) LEFT JOIN wp_postmeta c ON (a.ID = c.post_id) WHERE a.post_type = 'revision'