Moyen le plus sûr de supprimer en bloc les révisions de publication

Un de mes clients est sur un blog assez volumineux en termes de nombre de messages et de trafic. J'essaie de réduire sa base de données à une taille gérable, et une chose qui gonfle est littéralement des dizaines de milliers de révisions de poste.

J'ai déjà défini la configuration de Wordpress pour limiter le nombre de révisions à l'avenir à deux:

define('WP_POST_REVISIONS', 2);

Mais je veux supprimer toutes les révisions existantes.

Question 1 : Est-il sûr de supprimer directement toutes les lignes de la table wp_posts qui ont un post_type de révision? (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 cela n'est pertinent que si je ne devrais PAS simplement supprimer directement la première question:

J'ai trouvé cette réponse où songdogtech fournit une requête de base de données pour supprimer en toute sécurité, mais (1) c'est spécifiquement en réponse à une question multisite (c'est un seul site) et (2) je viens de mettre à jour le site en 3.6, qui comprenait des changements de base de données . (Donc, je ne suis pas assez qualifié pour lire les requêtes de base de données pour savoir exactement ce qui s'y passe et si cela fonctionnerait pour un seul site dans WP 3.6

Est-il sûr de supprimer directement toutes les lignes de la table wp_posts qui ont un post_type de révision? (J'ai vu des réponses contradictoires à ce sujet, mais j'aimerais pouvoir le faire de cette façon si c'est sûr)

Sûr, c'est sûr .

S'il n'y a qu'un seul utilisateur (vous) qui peut modifier les messages sur le site, c'est sûr et ne pose aucun autre problème.

S'il y a plus d'utilisateurs, et que l'un est en train de modifier un article et qu'en attendant vous supprimez les révisions, ce n'est toujours pas dangereux, mais cela peut être gênant pour cet utilisateur de voir les révisions disparaître.

Ce qui est absolument dangereux, c'est d'exécuter la requête SQL sur la base de données WP sans prendre une (ou mieux, plus) sauvegarde (s) abordable (s) et tester la requête sur l'environnement local / dev au préalable.

Imaginons que vous tapiez accidentellement «post» au lieu de «révision» , si vous n'avez pas de sauvegardes 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, il suffit de supprimer {id}_partout où il apparaît dans la requête posté alors wp_{id}_postsdevient wp_postset ainsi de suite.

Un avertissement , la wp_partie est le préfixe de table standard, que les gars sympas changent en quelque chose de différent pendant l'installation de WP.

Si vous l'avez changé et que wp_config.phpvous 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 ceci:

1. Sauvegarder la base de données
2. Sauvegardez à nouveau la base de données
3. Testez la sauvegarde en restaurant la base de données dans une autre base de données
4. Changez votre 'wp_config' pour utiliser cette nouvelle base de données
5. Exécutez la requête sur la nouvelle base de données et vérifiez s'il y a quelque chose qui ne va pas
6. Sinon, vous avez terminé. Si c'est le cas, modifiez à nouveau 'wp_config' et laissez-le utiliser l' ancienne base de données et essayez d'étudier le problème.

Les détails fournis jusqu'à présent sont au mieux incomplets et la requête a, b, c n'est pas bonne - potentiellement même 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 sauvegardez:

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 gère les données plus anciennes où WordPress peut utiliser le même object_id dans la table wp_term_relationships pour un article et un lien. En exécutant les autres versions de cette requête a, b, c, vous pouvez également supprimer involontairement les données de lien. Ce n'est pas autant un problème avec les nouvelles installations de WordPress.

Si vous exécutez cette version de la requête et obtenez 0 suppressions, cela signifie simplement que vous n'avez aucune entrée «link_category» dans votre table wp_term_taxonomy. Vous pouvez vérifier en vérifiant ce tableau, puis supprimez simplement cette dernière ligne et réexécutez la requête.

Mais assurez-vous de sauvegarder, tester et vérifier les résultats avant de les utiliser sur les données de production. Cette requête a pris une de mes tables wp_posts gonflées par révision de 300 Mo à 5 Mo après optimisation.

Exécutez la 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 comme révisions. Si, pour une raison quelconque, vous avez associé une révision à une balise ou à une catégorie qui a ensuite été supprimée lors de la publication du message final, vous aurez des entrées supplémentaires dans d'autres tableaux tels que les termes. » La requête appropriée pour supprimer en toute sécurité toutes vos révisions est la suivante (modifiez le préfixe du tableau 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'