Il modo più sicuro per eliminare in blocco le revisioni post

Uno dei miei clienti è su un blog piuttosto grande in termini di numero di post e traffico. Sto cercando di ridurre il suo database a dimensioni gestibili e una cosa che si sta espandendo è letteralmente decine di migliaia di revisioni post.

Ho già impostato la configurazione di Wordpress per limitare il numero di revisioni in futuro a due:

define('WP_POST_REVISIONS', 2);

Ma voglio eliminare tutte le revisioni esistenti.

Domanda 1 : è sicuro eliminare direttamente tutte le righe nella tabella wp_posts che hanno un post_type di revisione? (Ho visto risposte contrastanti su questo — ma mi piacerebbe poterlo fare in questo modo se è sicuro).

Domanda 2 : ... e questo è rilevante solo se NON dovessi semplicemente cancellare dalla prima domanda:

Ho trovato questa risposta in cui songdogtech fornisce una query di database per eliminare in modo sicuro, ma (1) è specificamente in risposta a una domanda multisito (questo è un singolo sito) e (2) ho appena aggiornato il sito a 3.6, che includeva modifiche al database . (Quindi, non sono abbastanza esperto nella lettura delle query del database per sapere esattamente cosa sta succedendo lì e se funzionerebbe per un singolo sito in WP 3.6

È sicuro eliminare direttamente tutte le righe nella tabella wp_posts che hanno un post_type di revisione? (Ho visto risposte contrastanti su questo — ma mi piacerebbe poterlo fare in questo modo se è sicuro)

Sicuro, è sicuro .

Se c'è un solo utente (tu) che può modificare i post sul sito è sicuro e non causa altri problemi.

Se ci sono più utenti e uno sta modificando un post e nel frattempo elimini le revisioni non è ancora pericoloso, ma può essere fastidioso per quell'utente vedere le revisioni scomparire.

Ciò che non è assolutamente sicuro è eseguire la query SQL sul database WP senza prendere uno (o meglio, più) backup economico (s) e testare preventivamente la query sull'ambiente locale / di sviluppo.

Immaginiamo di digitare accidentalmente 'post' anziché 'revision' , se non si dispone di backup ed si esegue la query sul sito di produzione, cosa succede?

Per quanto riguarda la seconda domanda, basta eliminare {id}_ovunque appare nella query pubblicata così wp_{id}_postsdiventa wp_postse così via.

Un avvertimento , la wp_parte è il prefisso standard della tabella, che ragazzi fantastici cambiano in qualcosa di diverso durante l'installazione di WP.

Se l'hai cambiato e nel tuo wp_config.phpvedi$table_prefix = 'something_else_than_wp_';

La tua query diventa:

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'

Suggerisco di procedere così:

1. Eseguire il backup del database
2. Eseguire nuovamente il backup del database
3. Testare il backup ripristinando il database in un altro database
4. Modifica "wp_config" per utilizzare questo nuovo database
5. Esegui la query sul nuovo database e controlla se c'è qualcosa che non va
6. Altrimenti, hai finito. In tal caso, modificare nuovamente "wp_config" e utilizzare il vecchio database e provare a esaminare il problema.

I dettagli forniti finora sono incompleti nella migliore delle ipotesi e la query a, b, c non è buona, potenzialmente anche pericolosa. Si dimentica di considerare molte delle potenziali dipendenze. C'è una discussione completa e domande migliori qui

Esiste anche questa versione rivista della query che dovrebbe essere molto migliore, ma test in un ambiente di sviluppo a basso rischio e backup:

In particolare:

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

Questa query gestisce i dati più vecchi in cui WordPress potrebbe utilizzare lo stesso object_id nella tabella wp_term_relationships sia per un post che per un collegamento. Eseguendo le altre versioni di questa query a, b, c, è anche possibile eliminare involontariamente anche i dati dei collegamenti. Questo non è un grosso problema con le nuove installazioni di WordPress.

Se si esegue quella versione della query e si ottengono 0 eliminazioni, significa solo che non ci sono voci "link_category" nella tabella wp_term_taxonomy. È possibile verificare controllando quella tabella, quindi rimuovere l'ultima riga ed eseguire nuovamente la query.

Assicurati però di eseguire il backup, testare e verificare i risultati prima di utilizzare i dati di produzione. Questa query ha preso una delle mie tabelle wp_posts gonfiate di revisione da 300 MB a 5 MB dopo l'ottimizzazione.

Esegui query SQL:

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

NOTA: la query sopra "elimina solo i post contrassegnati come revisioni. Se per qualche motivo hai associato una revisione a un tag o una categoria che è stata quindi rimossa al momento della pubblicazione del post finale, avrai altre voci in altre tabelle come i termini ". La query corretta per rimuovere in modo sicuro tutte le revisioni è la seguente (modificare il prefisso della tabella secondo necessità):

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'