La forma más segura de eliminar en masa las revisiones de publicaciones

Uno de mis clientes está en un blog bastante grande en términos de cantidad de publicaciones y tráfico. Estoy tratando de reducir su base de datos a un tamaño manejable, y una cosa que está aumentando es literalmente decenas de miles de revisiones posteriores.

Ya configuré Wordpress config para limitar el número de revisiones en el futuro a dos:

define('WP_POST_REVISIONS', 2);

Pero quiero eliminar todas las revisiones existentes.

Pregunta 1 : ¿Es seguro eliminar directamente todas las filas de la tabla wp_posts que tienen un post_type de revisión? (He visto respuestas contradictorias sobre esto, pero me encantaría poder hacerlo de esta manera si es seguro).

Pregunta 2 : ... y esto solo es relevante si NO debo simplemente eliminar directamente de la pregunta uno:

Encontré esta respuesta donde songdogtech proporciona una consulta de base de datos para eliminar de forma segura, pero (1) está específicamente en respuesta a una pregunta multisitio (este es un sitio único) y (2) acabo de actualizar el sitio a 3.6, que incluyó cambios en la base de datos . (Por lo tanto, no soy lo suficientemente hábil en la lectura de consultas de bases de datos para saber exactamente lo que está sucediendo allí y si funcionaría para un solo sitio en WP 3.6

¿Es seguro eliminar directamente todas las filas de la tabla wp_posts que tienen un post_type de revisión? (He visto respuestas contradictorias sobre esto, pero me encantaría poder hacerlo de esta manera si es seguro)

Seguro, es seguro .

Si solo hay un usuario (usted) que puede editar publicaciones en el sitio, es seguro y no causa ningún otro problema.

Si hay más usuarios, y uno está editando una publicación y, mientras tanto, elimina las revisiones, aún no es inseguro, pero puede ser molesto para ese usuario, ya que las revisiones desaparecen.

Lo que es absolutamente inseguro es ejecutar la consulta SQL en la base de datos de WP sin tomar una (o mejor, más) copias de seguridad asequibles y probar la consulta en el entorno local / dev de antemano.

Imaginemos que accidentalmente escribe 'publicar' en lugar de 'revisión' , si no tiene copias de seguridad y ejecuta la consulta en el sitio de producción, ¿qué sucede?

Con respecto a la segunda pregunta, simplemente elimine {id}_todas las partes que aparezcan en la consulta publicada, así se wp_{id}_postsconvierte, wp_postsetc.

Una advertencia , la wp_parte es el prefijo de tabla estándar, que los chicos geniales cambian a algo diferente durante la instalación de WP.

Si lo has cambiado y en tu wp_config.phpves$table_prefix = 'something_else_than_wp_';

Su consulta se convierte en:

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'

Sugiero proceder así:

1. Copia de seguridad de la base de datos
2. Copia de seguridad de la base de datos nuevamente
3. Pruebe la copia de seguridad restaurando la base de datos en otra base de datos
4. Cambie su 'wp_config' para usar esta nueva base de datos
5. Ejecute la consulta en la nueva base de datos y verifique si hay algo que sale mal
6. Si no, has terminado. Si es así, el cambio 'wp_config' de nuevo un dejar que se utilice la antigua base de datos y tratar de investigar el problema.

Los detalles proporcionados hasta ahora son incompletos en el mejor de los casos, y la consulta a, b, c no es buena, potencialmente incluso peligrosa. Se olvida de tener en cuenta muchas de las dependencias potenciales. Hay una discusión completa y mejores consultas aquí

También existe esta versión revisada de la consulta que debería ser mucho mejor, pero probar en un entorno de desarrollo y copia de seguridad de bajo riesgo:

Específicamente:

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 maneja datos más antiguos donde WordPress podría estar usando el mismo object_id en la tabla wp_term_relationships para una publicación y un enlace. Al ejecutar las otras versiones de esta consulta a, b, c, también puede eliminar involuntariamente los datos del enlace. Esto no es tanto un problema con las nuevas instalaciones de WordPress.

Si ejecuta esa versión de la consulta y obtiene 0 eliminaciones, solo significa que no tiene entradas 'link_category' en su tabla wp_term_taxonomy. Puede verificarlo verificando esa tabla, y luego simplemente elimine esa última línea y vuelva a ejecutar la consulta.

Pero asegúrese de hacer una copia de seguridad, probar y verificar los resultados antes de usar los datos de producción. Esta consulta tomó una de mis tablas wp_posts de 300 MB hasta 5 MB después de la optimización.

Ejecute la consulta SQL:

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

NOTA: La consulta anterior "simplemente elimina la publicación marcada como revisiones. Si por algún motivo asocia una revisión con una etiqueta o una categoría que luego se eliminó cuando se publicó la publicación final, tendrá entradas adicionales en otras tablas, como los términos ". La consulta adecuada para eliminar de forma segura todas sus revisiones es la siguiente (cambie el prefijo de la tabla según sea necesario):

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'