In den letzten Tagen habe ich mich etwas mit der Datenbankbereinigung meiner Blogs beschäftigt. Auf der Suche nach ein paar Tipps, landete ich bei Majeres Beitrag Entrümpelung 2. Teil – Aufräumen der Tabelle wp_options.

Allerdings habe ich mich statt für das Plugin WP-Option Manager für Clean Options entschieden. Ich verwende zwar seit einiger Zeit das Plugin CleanFix, aber das löscht nicht die Restbestände deinstallierter Plugins in der Datenbank.

Vorsichtshalber hatte ich Clean Options erst einmal in meinem Testblog ausprobiert und prompt hatte ich einen Eintrag entfernt, den ich weiterhin benötige.

Glücklicherweise hatte ich kurz vorher noch eine Datenbanksicherung erstellt und konnte diese zurückspielen. Mich hatte schon gewundert, warum bei der Analyse Einträge von Plugins gelistet waren, die ich aktiv verwende, z. B. von Subscribe to Comments Reloaded. Daher habe ich diese natürlich nicht gelöscht.

Schön finde ich wiederum die Anzeige eines Links zu jedem Eintrag und mit einem Klick darauf wird bei Google meistens angezeigt, zu welcher Funktion von WordPress er gehört. Im Zweifelsfall habe ich allerdings lieber die Finger davon gelassen und nehme dadurch eventuell ein paar (überflüssige) Einträge mehr in Kauf.

Nachdem ich diese Bereinigung der wp_options per Plugin also erfolgreich auf meinem Hauptblog durchgeführt hatte, schaute ich mir nun meine Datenbank und die darin enthaltene wp_postmeta-Tabelle genauer an. Bei Blick auf die Tabelle meines Testblogs traf mich erst einmal der Schlag. Da existierten über 4.000 (!) Seiten bei einer Anzeige von 30 Datensätzen pro Seite.
Sämtliche pc_views und _thumbnails_ids usw. waren mehrfach zu einem Beitrag vorhanden. Ich schließe daraus, dass dafür das mehrmalige Importieren von Inhalten meines Hauptblogs per xml-Datei durch WordPress-Importer zu meinem Testblog verantwortlich ist.

Nicht ganz so schlimm sah die wp_postmeta-Tabelle meines Hautpblogs aus, allerdings waren auch da einige Inhalte mehrfach vorhanden. Ich hatte mir also die Datensätze nach post_ids auflisten lassen, um mir einen besseren Überblick zu verschaffen. Die Mehrfacheinträge habe ich dann händisch – also nacheinander markieren und seitenweise löschen – entfernt.

Einträge von deinstallierten Plugins entfernen

Nun bin ich bei meiner Recherche auf AllGuru.net auf seine Beiträge Why Clean Up WordPress WP_PostMeta Table? und How To Clean WordPress Database gestoßen, die mir einen tollen ersten Ansatz gaben, durch welche SQL-Befehle ich überhaupt die Reste nicht mehr existierender Plugins entfernen kann.

Dazu zählten unter anderem WP-to-Twitter (ich bin nun dazu übergangen, Beiträge per Feed bei dlvr.it zu twittern), Tweet-Button, Topsy-Button und das Plugin “Articles”.

Neben den von Guru empfohlenen SQL-Befehlen habe ich auch noch folgende angewandt:

für das Plugin “Articles”

DELETE FROM wp_postmeta WHERE meta_key = '_ak_article';

für das Plugin WP Tweet Button

DELETE FROM wp_postmeta WHERE meta_key = '_twitterrelated_short_url';

DELETE FROM wp_postmeta WHERE meta_key = '_twitterrelated_short_urlHash';

DELETE FROM wp_postmeta WHERE meta_key = '_activeshortener';

für das Plugin “SubHeading”

DELETE FROM wp_postmeta WHERE meta_key = '_subheading';

für das Plugin Topsy Retweet Button

DELETE FROM wp_postmeta WHERE meta_key = '_topsy_long_url';

DELETE FROM wp_postmeta WHERE meta_key = '_topsy_cache_timestamp';

Diese Einträge habe ich ergoogelt und konnte sie daher zuordnen. Grob überschlagen wurden dadurch insgesamt

• 13.999 Reihen von WP-to-Twitter,
• 1.135 Reihen von Articles
• 3.125 Reihen von Tweet Button
• 345 Reihen von Subheading und
• 1.265 Reihen von Topsy Retweet Button

entfernt.

Das Schöne ist, dass ich nun ich das Prinzip verstehe und wenn ich mal wieder ein Plugin deinstalliert habe, kann ich mich gezielter auf die Suche nach übriggebliebenen Einträgen in der wp_postmeta machen und entsprechend löschen.

… und wie man sich nach gelungener Datenbankbereinigung noch selber ein Beinchen stellen kann

Als ich die Bereinigung zum größten Teil beendet hatte, begann ich analog diesen Beitrag zu schreiben und lud den ersten Screenshot hoch. Aber was war das? Statt des Bildes wurde im Beitrag lediglich ein weißes Bildsymbol angezeigt. Ich nahm sofort an, dass etwas bei der Aktion schiefgelaufen war und spielte die letzte Datebanksicherung zurück. Leider ist dabei der letzte Kommentar zu einem Beitrag  verloren gegangen und natürlich auch dieser Beitragsentwurf.

Was war letztendlich die Ursache? Ich hatte einen viel zu langen Dateinamen für das Bild vergeben – eigentlich nur aus reiner Bequemlichkeit und um die Medieninformation (Titel und Alternativtext) dazu nachträglich nicht noch großartig ergänzen zu müssen. Somit hatte dieser Fehler überhaupt nichts mit der DB-Bereinigung zu tun.