Heute habe ich endlich ein Problem gelöst, an welchem ich mir schon seit einiger Zeit den Kopf zerbreche.
In einem meiner WordPress Projekte hatte sich ein Bestand von rund 12.000 Artikeln angesammelt. Eigentlich handelte es sich gar nicht um Artikel, sondern um kurze Ausschnitte aus zu dem Projekt passenden RSS-Feeds.
Diese 12.000 „Artikel” machten das WordPressprojekt etwas behäbig. Schlimmer allerdings war die Tatsache, dass eine Datensicherung des Systems regelmäßig an einem Time-out des Webservers scheiterte.
Da ich darüber hinaus festgestellt hatte, dass diese „Artikel” von den Besuchern der Website kaum angeklickt wurden, beschloss ich diesen Datenwust von knapp 300 MB endgültig zu löschen.
Das manuelle Löschen in WordPress wäre eine sehr Zeit raubende Arbeit gewesen, da WordPress nur maximal 200 Artikel untereinander auflistet.
Plugins alle gescheitert
Ich fand insgesamt drei Plugins, die versprachen, ein solches massenweise Löschen umsetzen zu können. Leider sind alle drei Plugins an dieser Aufgabe gescheitert.
Ich experimentierte noch mit verschiedenen Optionen fand aber keine Lösung.
Eines der gescheiterten Plugins nennt sich Bulk Delete. Ich fand schließlich heraus, dass dieses Plugin nichts anderes machte, als wenn man im Admin-Bereich manuell Artikel löschen würde. Bei einer solch großen Anzahl von Artikeln war aber einfach die Serverlast zu groß und die Versuche endeten jedes Mal entweder in einem Time-out oder es taten sich Probleme mit dem verfügbaren Arbeitsspeicher auf.
Ähnlich war es mit den anderen beiden Plugins.
Reiner SQL-Code ist die Lösung
Keine Angst vor Operationen am offenen Herzen von WordPress
Ich musste also einen anderen Weg finden, um das vorhandene Problem zu lösen. Nach langem recherchieren in Google fand ich schließlich eine Lösung die auf einem simplen SQL Skript basiert. Da ich nichts mehr zu verlieren hatte, folgte ich der gefundenen englischsprachigen Anleitung. Der erste Schritt bestand darin, den PHP-MyAdmin Bereich aufzurufen und sich dort einzuloggen.
Der nächste Schritt bestand darin, den folgenden SQL Code innerhalb des Admin-Bereichs auszuführen.
SELECT *
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 ( d.term_taxonomy_id = b.term_taxonomy_id )
LEFT JOIN wp_terms e ON ( e.term_id = d.term_id )
WHERE e.term_id =<category id>
Als Ergebnis dieser Aktion erhielt ich eine Auflistung aller zu löschenden Artikel. Ich musste in dem Code lediglich in der letzten Zeile die ID-Nummer der Kategorie eingeben, in welcher die Artikel abgelegt waren. Da es sich nur um eine einzige Kategorie handelte, brauchte ich den Code nicht mehrfach auszuführen.
Die zu löschenden Artikeln waren also nun alle selektiert und der nächste Schritt bestand darin, wiederum einige Zeilen SQL Code auszuführen.
delete a,b,c,d
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 ( d.term_taxonomy_id = b.term_taxonomy_id )
LEFT JOIN wp_terms e ON ( e.term_id = d.term_id )
WHERE e.term_id =<category id>
Nach Ausführen dieser Codezeilen war das gewünschte Ergebnis erreicht. Sämtliche Artikel waren gelöscht. Andere Daten wurden nicht beeinträchtigt. Natürlich hatte ich für den Ernstfall vorher noch manuelle Datensicherungen durchgeführt.
Dieses kleine Skript hatte tatsächlich innerhalb weniger Sekunden nicht nur sämtliche Artikel gelöscht, sondern auch zu diesen Artikeln gehörender weiterer Daten im folgenden Tabellen:
wp_term_relationships, wp_postmeta, wp_term_taxonomy, wp_terms
Was lernen wir daraus?
Word Press ist sicherlich ein fantastisches System, aber bei einer hohen vierstelligen Anzahl an Artikeln stößt es dann doch irgendwo an seine Grenzen. Diese Grenzen werden aber bei einem normalen Webhosting Paket im Prinzip nur durch die Restriktionen des Webservers definiert. In erster Linie bestehen diese Restriktionen in
- der Menge des zur Verfügung stehenden Arbeitsspeichers und
- in der Beschränkung der CPU Laufzeit
Letztere führt dazu, das Skripte mit einem Time-out abgebrochen werden.
WordPress selbst ist also eigentlich gar nicht schuld an dieser Misere. Würde man WordPress auf einem eigenen Stand-Alone Server installieren, bei welchem es diese Restriktionen dann nicht gäbe, sähe das ganze mit Sicherheit anders aus.
Zum Glück befinden sich die Preise für dedizierte Server in freiem Fall. Ich habe schon seriöse Angebote für weniger als 50 € pro Monat gesehen und stelle mir daher ernsthaft die Frage, ob ich nicht meine diversen Webhostingpakete zusammen schnüre und alle auf einen eigenen Server installiere.
Was denken Sie darüber?
