Maneira mais segura de excluir em massa as revisões de postagem

Um dos meus clientes está em um blog bastante grande em termos de número de postagens e tráfego. Estou tentando reduzir o tamanho do banco de dados a um tamanho gerenciável, e uma coisa que está aumentando é literalmente dezenas de milhares de revisões posteriores.

Eu já defini a configuração do Wordpress para limitar o número de revisões no futuro para duas:

define('WP_POST_REVISIONS', 2);

Mas quero excluir todas as revisões existentes.

Pergunta 1 : É seguro excluir diretamente todas as linhas da tabela wp_posts que possuem um post_type de revisão? (Vi respostas conflitantes sobre isso - mas eu adoraria poder fazer dessa maneira se for seguro).

Pergunta 2 : … e isso é relevante apenas se eu NÃO fizer a exclusão direta da pergunta um:

Encontrei esta resposta em que o songdogtech fornece uma consulta ao banco de dados para excluir com segurança, mas (1) é especificamente em resposta a uma pergunta multissite (este é um site único) e (2) acabei de atualizar o site para 3.6, que incluiu alterações no banco de dados . (Portanto, não tenho habilidade suficiente para ler consultas de banco de dados para saber exatamente o que está acontecendo lá e se funcionaria em um único site no WP 3.6

É seguro excluir diretamente todas as linhas da tabela wp_posts que possuem um post_type de revisão? (Vi respostas conflitantes sobre isso - mas eu adoraria poder fazer dessa maneira se for seguro)

Seguro, é seguro .

Se houver apenas um usuário (você) que pode editar postagens no site, é seguro e não causa outros problemas.

Se houver mais usuários, e um estiver editando uma postagem e, enquanto isso, você excluir as revisões, ela ainda não é insegura, mas pode ser irritante para o usuário ver as revisões desaparecerem.

O que é absolutamente inseguro é executar a consulta SQL no banco de dados WP sem fazer um (ou melhor, mais) backup (s) acessível (s) e testar a consulta no ambiente local / dev antecipadamente.

Vamos imaginar que você digite acidentalmente 'post' em vez de 'revisão' , se você não possui backups e executa a consulta no site de produção, o que acontece?

Em relação à segunda pergunta, basta excluir {id}_todos os lugares em que aparece na consulta postada para que wp_{id}_postsse torne wp_postse assim por diante.

Um aviso , a wp_parte é o prefixo da tabela padrão, que os caras legais mudam para algo diferente durante a instalação do WP.

Se você mudou e no seu wp_config.phpvocê vê$table_prefix = 'something_else_than_wp_';

Sua consulta se torna:

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'

Sugiro proceder assim:

1. Faça backup do banco de dados
2. Faça backup do banco de dados novamente
3. Teste o backup restaurando o banco de dados em outro banco de dados
4. Altere seu 'wp_config' para usar esse novo banco de dados
5. Execute a consulta no novo banco de dados e verifique se há algo de errado.
6. Caso contrário, você terminou. Nesse caso, altere 'wp_config' novamente e deixe-o usar o banco de dados antigo e tente investigar o problema.

Os detalhes fornecidos até agora estão incompletos, na melhor das hipóteses, e a consulta a, b, c não é boa - potencialmente perigosa. Esquece de levar em consideração muitas das dependências em potencial. Há uma discussão completa e melhores consultas aqui

Há também esta versão revisada da consulta, que deve ser muito melhor, mas teste em um ambiente de desenvolvimento e backup de baixo risco:

Especificamente:

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

Esta consulta lida com dados mais antigos, nos quais o WordPress pode estar usando o mesmo object_id na tabela wp_term_relationships para uma postagem e um link. Ao executar as outras versões dessa consulta a, b, c, você também pode excluir acidentalmente os dados do link. Isso não é tão problemático nas instalações mais recentes do WordPress.

Se você executar essa versão da consulta e receber 0 exclusões, significa apenas que não há entradas 'link_category' na tabela wp_term_taxonomy. Você pode verificar verificando essa tabela e, em seguida, basta remover a última linha e executar a consulta novamente.

Mas não se esqueça de fazer backup, testar e verificar os resultados antes de usar nos dados de produção. Essa consulta levou uma das minhas tabelas wp_posts com revisão revisada de 300 MB para 5 MB após a otimização.

Execute a consulta SQL:

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

NOTA: A consulta acima “exclui apenas as postagens marcadas como revisões. Se, por algum motivo, você associou uma revisão a uma tag ou categoria que foi removida quando a postagem final foi publicada, você terá entradas extras em outras tabelas, como termos. ” A consulta adequada para remover com segurança todas as suas revisões é a seguinte (altere o prefixo da tabela conforme necessário):

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'