WordPress aufräumen , ein nicht alltäglicher Bericht

Bunte Besen via Pixabay.com

Was für mich als ein kleiner Exkurs in dem Aufräumen meines Blogs begonnen hatte, wurde sehr schnell ein ungewollter ernüchternder Blick in WordPress als Software. Dieser nicht alltägliche Bericht hilft vielleicht ein wenig mehr auf die Sicherheit von WordPress zu achten, ohne mit Code und einer Anleitung zu winken zu müssen

Mein Neustart meines Weblogs geschah nicht nur aus ästhetischen Gründen.  Für mich war es wichtig diesen Schritt noch vor diesem Herbst zu gehen, eigentlich vor dem Release von WordPress 4.0. Leider brachte mir dieser Umzug nicht nur ein neues Theme von Oliver Gast ein, einem Entwickler den ich auch auf Grund der Kommunikation sehr schätze, sondern auch Einsichten, welche ich bei meiner Installation nicht erwartet hatte.

Whitepages

Im Laufe der Zeit sammelt sich ja so einiges in der Installation von WordPress an.
Bei mir war die vorhergehende Installation so aus dem Häusschen, dass ich des öfteren eine Whitepage präsentiert bekam. Auch die Webmaster Tools von Google meldeten mir den einen und anderen Fehler bei einem Seitenaufruf.
Ein entspanntes Schreiben der Blogartikel war nicht wirklich möglich.

Das schlimmste an dem berühmten und gefürchteten Whitepagefehler war, dass er auch bei dem Schreiben von Blogposts auftrat und mich schier zur Weißglut trieb. Weil der Browser nicht die Daten gespeichert hatte und teilweise auch nicht eine Revision vorlag. Man kann sich bestimmt vorstellen, welchen Spaß ich am schreiben hatte. Das schreiben in vim, mit anschließendem einfügen und reformatieren in den Editor von WordPress war nicht wirklich von Freude, geschweige Spaß beflügelt. Der Wahnsinn hatte mich dann aber  endgültig, als ich auch nach dem Ändern des Themes und dem Ausschalten aller Plugins von dem Fehler nicht verschont blieb.

Aber man kann ja bekanntlich auch den Fehler auf den Webhoster schieben. Ich machte ein Backup der Datenbank und verband mein Blog mit der Datenbank meines Rootservers. Ich möchte hier den Fehler aussschließen, dass die Verbindung zu dem DBMS meines Webhosters gestört hätte sein können. Leider brachte dies auch kein Ergebnis. Das berühmte Problem der „einfachen“ Nutzer traf mich. Ich wollte schreiben und mich nicht wieder einmal um ein Stück Software kümmern.
Entspannen und nicht basteln.

Ganz pedantisch habe ich natürlich auch das Schreiben des Logs für WordPress per wp-config.php eingeschaltet, aber auch dies brachte leider keine Auskunft. Ein Henne-Eiproblem, wenn ich keine Fehlermeldungen habe, kann ich auch nicht den Fehler einkreisen und Ihn beheben.

Ein Check per md5sum auf alle Dateien brachte mich auch nicht weiter. Hier werde ich aber in Zukunft auf git zurückgreifen und kann somit Änderungen an den Dateien nachvollziehen. git ersetzt kein Backup, aber erlaubt mir doch eine erweiterte Übersicht über Dateiänderungen.

Nach all diesen Tests war für mich klar, dass ich in einer Subdomain das Blog neu aufbaue und dann einfach den Eintrag des Webservers auf das neue Verzeichnis umbiege.

WordPress aufräumen

Am Anfang hatte ich für das Design eines neuen Themes mir ein Script für Docker gebaut, welches Debian Jessie inkl Nginx, MariaDB und der letzten erhältlichen Version von WordPress installiert. Somit habe ich nun Erfahrungen mit Docker gesammelt und ein schönes Theme erstellt, aber es am Schluss nun nicht genutzt und mich für ein anderes Theme entschieden und ein Childtheme gestellt.

Um WordPress aufzuräumen bin ich folgenden Liste für mich abgelaufen:

  1. Backup der Daten
  2. Für Plugins und sichere, sowie responsive Alternativen finden
  3. Neustrukturierung der Mediendatenbank

Backup und Import der Daten

Für das Backup habe ich per Werkzeuge > Daten exportieren > Alle Inhalte exportiert und ein Backup in form eines SQL-Files gemacht.

Daten exportieren in WordPress

Alle Post und Kommentare exportieren

Für die Mediendatenbank bin ich zwei Wege gegangen.
Ich habe den Import der XML-Datei ohne den Import der Bilder vorgenommen und dafür ein Plugin benutzt, welches meiner Meinung nach den Import der Mediendateien besser vornimmt Attachment Importer:

I found the WordPress Importer plugin is good for importing posts and comments, but is lacking when it comes to importing large attachments (like images) from large sites. My import would often time out and crash. I wrote this plugin to help with my own blog migrations, but I hope you find it useful too.

Attachment Importer ignoriert Dateien, welche den selben:

  • Namen
  • Dateinamen
  • Datum des Uploads
  • Dateigröße haben

Einige Dateien sind nicht importiert worden, da sie Altlasten aus Serendipity, Jekyll, oder Drupal waren. Diese wurden dann mit dem Plugin Add from Server nachgezogen. Hier muss beachtet werden, dass das Plugin nicht die schon vorhandenen Dateien beachtet und sie einfach nochmals importiert. Man sollte sich sicher sein, dass eine Datei nicht schon in der Mediendatenbank vorhanden ist.

Bevor ich dies aber gemacht habe, hatte ich nach einem Backup der Mediendatenbank alle extra erstellten Bildgrößen über die Shell gelöscht.

find . -name *-*x*.* -exec rm {} \;

 

Welche Mediendateien nach dem Import fehlten sagte mir eines meiner Stammplugins Broken Link Checker.
Es sollte in keiner Installation von WordPress fehlen. Zu viele Links kommen und gehen und leider lassen sich alle verbloggten nicht im Auge behalten.

Falls ein fehlerhafter Link gefunden wurde, bietet Broken Link Checker automatisch an, dass ein Link von Archive.org genommen wird. Falls dies nicht möglich ist, wird der Link nach einem eigens definierten Stil per CSS markiert und auf Wunsch herausgenommen.

Für das rekomprimieren der Bildgrößen habe ich das Plugin WP Smush.it genutzt. Hier muss auf jeden Fall bei einem Import unter Einstellungen > Medien > WP Smush.it der Punkt Use Smush.it on upload? auf Do not process on upload eingestellt sein.

Nach der Installation des Themes habe ich natürlich AJAX Thumbnail Rebuild für das neugenerieren der Bildergrößen genommen, welches bei mir ein wenig länger dauert, da das vorab gewählte Theme Minimaze responsive ist und Bildgrößen für die Endgeräte aktiv unterstützt. Hoffte ich ;)

WordPress AJAX Thumbnail Rebuild Alle Miniaturbilder neu erstellen

Ich hoffe wirklich, dass mein Theme Endgeräte mit den richtigen Bildgrößen versorgt

Verlassene Plugins und Themes

Es gibt Plugins, welche nachdem sie geschrieben wurden, eigentlich eine Grundlage der Nutzung von WordPress sein sollten. Ich finde sie gehören direkt in den Kern von WordPress. Das Plugin 404 Redirect wäre so ein Plugin für mich gewesen.

Das Plugin ist in meinen Augen sehr nützlich. Es kann automatische Weiterleitungen ( 301, 302 ) generieren und fängt 404-Error auf und trägt sie in ein Log ein. Es bietet dann die Option an selbst eine Weiterleitung anlegen. Wer es einmal genutzt hat, der möchte es nicht mehr missen.

Aber leider ist das Plugin ein Zombie, eine wandelnde Zeitbombe innerhalb meiner Installation gewesen.

Warum es immer noch nicht aus dem Verzeichnis seitens des Developers gelöscht wurde ist mir immer noch nicht ganz klar. Eigentlich sollte es aus dem Verzeichnis von WordPress verschwinden. Nach meinem Kommentar, bzw. nach der Aussage und Kontaktaufnahme von caseyfern ging ich davon aus. Es wird seit 2 Jahren nicht mehr aktiv betreut und sie haben auch nicht mehr vor es zu betreuen. Ich werde es vielleicht die Tage unter meine Fittiche nehmen und neu schreiben.

WordPress Support 404 redirected

Das Plugin ist leider immer noch vorhanden

 

Mir wäre nie seit der Installation bewusst gewesen, dass jenes Plugin nicht mehr in der aktiven Entwicklung ist. Nur durch den Fehler mit den Whitepages musste ich mich mit jedem Plugin einzeln befassen und war erschreckt, dass ich wirklich ein, zwei faule Eier in meiner Installation hatte.
Dies, obwohl ich doch immer so auf Sicherheit bedacht bin.

Ich befolge die Regeln

  • nutze die minimalste Anzahl von Plugins
  • nehme aktiv in der Entwicklung stehende Plugins
  • nehme nur Plugins aus dem Verzeichnis bei WordPress und nicht aus obskuren Quellen ( Nein, nicht einmal Github nehme ich)
  • Und validiere und installiere jedes Update

Auch versuchte ich eigentlich immer per functions.php in meinem Childtheme die von manchen Plugins gestellten Funktionen auf sichere Art und weise selbst zu erstellen. Was man natürlich nicht machen sollte, wie ich durch den Artikel Why You Shouldn’t Use functions.php (And What You Should Do Instead) von wpmudev lernte. Ich habe nun mein Minimum an, für mich wichtigen, Funktionen als Plugin.

Leider scheinen diese als best practices  gepriesenen Arbeitsabläufe doch nicht wirklich die letzte Weisheit zu sein.

Für mich bedeutet dies nun, ein Script zu erstellen, welche das Datum der Datei eines Plugins per Cron immer wieder checkt, wenn sich nach einem Jahr nichts getan hat, bekomme ich eine Mail mit dem Hinweis mal in das CVS des Plugins zu schauen.  Im Fazit habe ich dann mal eine Idee grafisch umgesetzt, wie wie WordPress dies selbst ändern könnte und auch müsste.

Wie es da an der Front für die Themes aussieht kann ich nicht wirklich sagen. Ich versuche nur Themes zu verwenden, welche eine gute Codebasis haben, gepflegt werden und wenn es geht direkt zu den Standardthemes von WordPress gehören. Das momentan genutzte Theme ist war/nur die Warteschleife für das Theme Twentyfifteen auf welches ich warte und dann mir zu Nutzen mache.

Ordnung in der Datenbank, neue und alte Plugins

Da nun durch eine Neuinstallation die Datenbank aufgeräumt ist, habe ich mich an die Suche nach Plugins gemacht, welche ich absolut brauche und alles nur noch auf ein Minimum beschränkt.

Nicht wirklich eine einfache Sache und ich hatte in dem Moment Glück, dass ich in den Verzug mit dem Blog aufräumen kam. Ich konnte anhand der Zeit zwischen dem Erscheinen der neuen WordPressversion und dem Update eines Plugins, sowie der Reaktionszeit auf Supportanfragen schauen, wer da seiner selbstgewählten Arbeit wirklich nach kommt.

Jeder SEO würde bei der Frequenz der Artikel, welche dadurch die letzten Monate erschienen aufschreien und mich für den Einbruch meiner CTR schütteln. Wie ein Nikotinsüchtiger den Zigarettenautomat, wenn jener seinen letzten Euro eingezogen hatte ohne die Ware zu liefern. Gott, ich meine das ist ein Hobby und Spaß und nicht ein… :)

Da stellt sich die Frage, wie denn da große Seiten reagieren und agieren können auf Grund dieser Situation. Ich frage mich, ob es dann bei den bezahlten Plugins auch mit solchen Problematiken belegt ist. Obwohl ich da gerne Sergej Müller, der Entwickler mehrer Plugins für WordPress und auch Herausgeber eines Newsletters, als positives Beispiel nehme. Es geht, wenn man möchte.

Bis auf 10 Plugins sind viele ausgetauscht worden und es laufen aktiv nun 22 Plugins die argwöhnisch von mir beobachtet werden.

Im Bereich Maintenance möchte ich das Plugin WP Maintenance Mode , welches mir in der Subdomain vor dem Umzug sehr geholfen, empfehlen.

  • Komplett Anpassbar betreffend Farben, Text, Hintergründe
  • Abonnementsfunktion, Emailadressen lassen sich als CSV-Datei exportieren
  • Countdown bis zu dem Neustart der Seite
  • Kontaktform für Besucheremails
  • Coming soon Seite
  • Landingpagetemplates
  • Multisitefähig
  • Responsive design
  • Social media Icons
  • Arbeitet mit jedem WordPressteheme
  • SEOOptions
  • URLs vom Maintenancemode ausschließen.
  • Maintenance nicht sichtbar für angemeldete Nutzer

WordPress und das Thema Sicherheit, kurze Daten, IMO

  1. WordPress ist sicher.
    Das ist Fakt. Im Grunde genau so Sicher wie die Software unter Debian GNU/Linux, ich beziehe mich hier spaßeshalber nun auf OpenSSL und BASH.
  2. Plugins und Themes in WordPress sind unsicher.
    Und auch das ist für mich genau so ein Fakt. Für mich eines der größten Probleme bei einer Installation von WordPress und eine Sache, welche mich zur Weißglut treibt. Timthumb, Caching Plugins die Credentials zum DBMS ausplaudern, Slideshowplugins usw usf
  3. Benutzer kümmern sich absolut nicht darum was Anleitung, Hinweise, wohlgemeinte Ratschläge bezüglich der Installation betrifft. Ich habe es schon mehrmals erlebt.

Punkt 1
WordPress selbst hat seit 2004 gerade einmal 183 mal ein Sicherheitsprobleme gehabt. Zum Vergleich Joomla mit 298 seit 2005 und Drupal mit 131 seit 2002. Drupal steht sehr Gut da, aber das Bloggen mit Drupal macht keinen Spaß. Probiert es einmal aus. Ich habe es im Laufe der Zeit dreimal versucht. Ist mal einen Spaß wert, so ein Versuch, wenn man zuviel Zeit hat. Somit kann man sagen, die Kernanwendung, das System WordPress an sich, ist sicher und das Unken über die Software ist eher in einen Bereich zu schieben, damit Jemand einen Grabenkrieg heraufbeschwören könnte. Ich weiß, jede PHP-Anwendung ist schlecht ;)
Man merkt, dass ich den oberen Satz vor dem Durpalgate geschrieben hatte, welches eine Reaktionszeit des Seitenbetreibers von maximal 5 Stunden für den Fix de jour forderte, oder seine Seite war komprimitiert.

Punkt 2
90% der Plugins in dem WordPressverzeichnis sind unter aller Kanone, welches den Code und die Sicherheit anbetrifft und zum Teil auch sehr schlecht gepflegt. Gerne würde ich die Schuld hier auf WordPress als Hoster der Plugins schieben und sagen, wer minimal seit einem Jahr sein Plugin, oder Theme, nicht einem Update unterzieht, der fliegt raus. Nur geht das leider nicht, denn viele Plugins sind sauber geschrieben und brauchen nur ein Update, wenn sich etwas an der Syntax von WordPress ändert. Dies gilt auch für Themes. Andere, faule und böse Individuen, könnten ja nur ein zwei Zeilen Code ändern und ausrufen, dass etwas geändert wurde. Ein Audit ist auch nicht gerade preiswert und kann nicht immer von der Community ausgeführt werden.

Punkt 3
Wenn man sich betrachtet wie viele Hilfestellungen es im Internet zu dem Absichern von WordPress gibt, der möchte nicht glauben, dass auch größere Seite diese ignorieren. Auch von mir wohlgemeinte Ratschläge per Mail, oder auch mal per Sozialnetz inkl weiterhelfender Links führe eher zu einer Diskussion mit anschließendem Nichtstun anstelle zu einem Handeln. Ich von meiner Seite aus habe meine letzten Versuche die Tage unternommen. Hätte ich mir sparen sollen. Nicht einmal das Absichern per htaccess für die URL $DOMAIN/wp-admin wurde vorgenommen. Ich kenne mehr ungesicherte mit WordPress betriebene Seiten im Netz, als gesicherte. Und dies ist bestimmt nicht die Schuld von WordPress (Hardening WordPress). Ich zeige hier wirklich mit dem Finge auf die Nutzer und beschuldige jene, nicht wirklich das absolute dokumentierte Minimum vorzunehmen, welches sie in anderen Bereichen auch machen würden. Können sie es nicht, dann möchten sie doch bitte einen Softwaremechaniker dafür zahlen, wie sie es auch in anderen Bereichen machen.

Man kann wirklich offen sagen, wenn es bei WordPress ein Sicherheitsproblem gegeben hat, war es prozentual gesehen eher ein Plugin, ein Theme, die Serversoftware, oder der/die Bloggende. Wer WordPress sicher installiert, härtet und mit Updates versorgt, der steht auf der sichereren Seite. Es ist wie bei jeder anderen Software auch. Man muss halt die freundliche gemeinte Anleitung lesen und sich für einen Dienst, welchen man betreibt interessieren. Nicht dafür interessieren, gibt es entweder nur für Geld und Fachpersonal, oder auf Kosten der Sicherheit für die eigene und andere Installationen.

Die letzten Pluginupdates ?

WordPress hat einen maroden Fehler und ich glaubte wirklich, dass jener mit der Version 4.0 ausgemerzt wurde. Ich ging davon aus, dass nicht nur in der Übersicht das letzte Datum eines Updates eines Plugins zu erfahren wäre, sondern auch im Administrationsbereich der installierten Plugins.

Natürlich ist die Übersicht toll, ich mag sie und auch dort findet man sofort heraus, wann das letzte Update eines Plugins geschehen ist, aber es ist nicht jenes, welches ich mir wünschte.

Es sollte die gleich Information wie auf der Pluginseite von  WordPress zu sehen sein.
Wenn das Plugin seit zwei Jahren nicht einem Update unterzogen wurde, dann bitte im Backend melden. Wie bei Antispambee von Sergej zu sehen ist, wann das letzte Update des Plugins war. Der Button Dismiss erklärt sich von selbst und der Button Details kann von der Pluginsuche übernommen werden.

 

WordPress Pluginübersicht mit Meldung

So sollte die Pluginübersicht sein

 

Fazit

Unbemerkte Altlasten können leicht zu einer unterschätzten Gefahr werden und man muss für sich eine Form finden, welche die oben genannten Probleme umgeht. Auf jeden Fall bis eine Alternative gefunden ist diesen Mangel zu beheben. Bis jetzt ist mir leider kein Service bekannt, welcher dies automatisiert übernehmen kann.

Auf jeden Fall kann nun weiter gebloggt werden.

 

 

9 Kommentare

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.