投稿のリビジョンを一括削除する最も安全な方法


8

私のクライアントの1つは、投稿数とトラフィックの点でかなり大きなブログを利用しています。私は彼女のデータベースを扱いやすいサイズに縮小しようとしています。そして、増大していることの1つは文字通り数万のポストリビジョンです。

私はすでにWordpressの構成を設定して、将来のリビジョン数を2つに制限しています:

define('WP_POST_REVISIONS', 2);

しかし、私はすべての既存のリビジョンを削除したいと思います。

質問1:post_typeがrevisionであるwp_postsテーブルのすべての行を直接削除しても安全ですか?(私はこれについて矛盾する回答を見てきました—しかし、安全であれば、この方法でそれを実行できるようになりたいです)。

質問2...と私は必要がある場合にのみreleventではありませんただ、質問1から簡単な削除を実行します。

songdogtechが安全に削除するデータベースクエリを提供するこの回答を見つけましたが、(1)これは特にマルチサイトの質問(これは単一サイトです)への回答であり、(2)サイトをデータベースの変更を含む3.6にアップグレードしました。(つまり、データベースクエリを読んで、そこで何が起こっているのか、そしてそれがWP 3.6の単一のサイトで機能するかどうかを正確に理解するのに十分なスキルはありません

回答:


18

post_typeがrevisionであるwp_postsテーブルのすべての行を直接削除しても安全ですか?(私はこれについて矛盾する答えを見てきました—しかし、安全であればこの方法でそれを実行できるようになりたいです)

安全、安全です。

サイトの投稿を編集できるユーザー(あなた)が1人だけの場合、安全で他の問題は発生しません。

より多くのユーザーがいて、投稿を編集していて、その間にリビジョンを削除しても、それは危険ではありませんが、そのユーザーがリビジョンが表示されなくなるのを煩わしく感じる可能性があります。

絶対に安全でないのは、1つ(またはそれ以上)の手頃な価格のバックアップを作成せずにWPデータベースでSQLクエリを実行し、事前にローカル/開発環境でクエリをテストすることです。

「revision ではなく「post」と誤って入力したとしましょう。バックアップがなく、本番サイトでクエリを実行した場合、どうなりますか?

2番目の質問については、単に削除する{id}_ことがで表示され、どこでも、クエリ掲示そうwp_{id}_postsなっwp_posts等々 。

警告はwp_一部には、クールな男が、WPのインストール中に何か別のに変更することを、標準テーブルの接頭辞です。

あなたの中にあなたがそれを変更している場合はwp_config.php、あなたが見$table_prefix = 'something_else_than_wp_';

クエリは次のようになります。

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'

私はこのように進めることをお勧めします:

  1. データベースをバックアップする
  2. データベースを再度バックアップします
  3. データベースを別のデータベースに復元して、バックアップをテストします
  4. この新しいデータベースを使用するように 'wp_config'を変更してください
  5. 新しいデータベースでクエリを実行し、問題があるかどうかを確認します
  6. そうでない場合は、完了です。その場合は、「wp_config」を再度変更して、古いデータベースを使用させ、問題の調査を試みます。

ありがとうございました。まさに聞きたかったこと。はい、すべてのバックアップなどに
StudioAl

2
1. Backup DB 2. Backup DB Again、私はこの部分が好きです、これのために+1。
shyammakwana.me 2015年

あなたも、カスタム作成することができWP-cliのワークフローを自動化するコマンドを:$ wp post delete $(wp post list --post_type='revision' --format=ids)
ダルマ

4

これまでに提供された詳細はせいぜい不完全であり、a、b、cクエリは適切ではありません-潜在的に危険です。多くの潜在的な依存関係を考慮することを忘れています。ここで完全な議論とより良いクエリがあります

あります。この修正された低リスクのdevの環境とバックアップで非常に良いはずのクエリのバージョンが、テストは:

具体的には:

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';

このクエリは、WordPressが投稿とリンクの両方のwp_term_relationshipsテーブルで同じobject_idを使用している可能性がある古いデータを処理します。このa、b、cクエリの他のバージョンを実行すると、リンクデータも誤って削除される可能性があります。これは、WordPressの新しいインストールではそれほど問題ではありません。

そのバージョンのクエリを実行して削除が0の場合は、wp_term_taxonomyテーブルに「link_category」エントリがないことを意味します。そのテーブルをチェックして確認し、最後の行を削除してクエリを再実行します。

ただし、本番データで使用する前に、必ず結果をバックアップ、テスト、および確認してください。このクエリは、最適化後、リビジョンが肥大化したwp_postsテーブルの1つを300 MBから5 MBに減らしました。


誰かが解決策を見つける可能性がある場所へのリンクではなく、実際の解決策を投稿してください
Pieter Goosen

OK!やります-最初に自分自身をテストして、それが有効であることを確認します。
Andrew

2

SQLクエリを実行します。

DELETE FROM wp_posts WHERE post_type = "revision" // for "wptest" DB, note the table name

注:上記のクエリは、「リビジョンとしてマークされた投稿を削除するだけです。何らかの理由で、最後の投稿が公開されたときに削除されたタグまたはカテゴリにリビジョンを関連付けた場合、用語などの他のテーブルに追加のエントリが含まれます。」すべてのリビジョンを安全に削除するための適切なクエリは次のとおりです(必要に応じてテーブルのプレフィックスを変更します)。

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'

クエリについての説明をありがとうございます。完全に理にかなっています。
StudioAl
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.