Webmaster-Ressourcen, WordPress HowTo

WordPress Multisite mit Domain-Mapping auf Plesk Server mit Letsencrypt SSL versorgen

Die Aufgabenstellung: Auf einer WP Multisite Installation mit Domain-Mapping (d.h. alle Domains haben eigene TLD), die auf einem Plesk 12.5 Server läuft soll für jede Site ein SSL von Letsencrypt installiert werden.

Auf den ersten Blick einfach: SAN Zertifikat holen, das alle Domains beinhaltet und auf der Hauptseite installieren. Und nicht vergessen, das SAN Zertifikat muss spätestens alle 3 Monate wieder manuell erneuert werden. Das alles geht im Terminal mit den Command Line Tools, muss man sich aber erst anlesen und ist mir zu kompliziert gewesen… auch die Aussicht auf Wiederholung im 3-Monats Rhythmus passt mir nicht.

Einfacher gehts mit einem kleinen Umweg: Für Plesk (ab 12.5) gibt es seit kurzem die?tolle Letsencrypt-Extension, die allerdings noch keine SAN Zertifikate holen und installieren kann. Letsencrypt unterstützt darüber hinaus auch keine Alias-Domains.
Daher muss man auf dem Plesk Server alle Domains für die Multisite als eigene Domain einrichten und dabei darauf achten, dass man als Speicherort das bestehende Abo der WP-Hauptseite einträgt und dass auch der Dokumentenstamm gleich lautet wie für die Hauptseite (normalerweise /httpdocs).
Plesk meckert beim Anlegen darüber, dass die Logfiles nicht korrekt erstellt werden künnen – klar, die liegen ja alle im gleichen Verzeichnis, da gibts also Kollisionen.
Abgesehen davon ist die Domain aber funktionsf?hig und zeigt auch auf unsere WP Multisite Installation.

Jetzt kann man für jede Domain mit der Letsencrypt-Extension ein (kostenloses) SSL Zertifikat holen, das auch gleich automatisch installiert wird. Die Extension sorgt auch dafür, dass das Zertifikat jeden Monat automatisch erneuert wird. Kein manueller Eingriff mehr nütig.

Im WP muss man schliesslich noch die nütigen Anpassungen (Site-url und Site-home) so vornehmen, dass die Seiten über https:// laufen und auch htaccess sollte so angepasst werden, dass der Seitenzugriff automatisch auf https:// umgeleitet wird. In Google findet man die passenden Hinweise dafür.

Zu guter Letzt noch ein bisschen Speed-Tuning mit Plesk-Mitteln: im Seitenhosting kann mit ein paar Klicks nginx als Reverse Proxy aktiviert werden, damit werden Bilder, Skripte und Styles viel schneller geliefert. Die Aktivierung von CloudFlare für jede Domain (auch nur ein Klick im Plesk) reduziert die Ladezeiten weiter und schützt darüberhinaus die Seiten vor DDoS-Angriffen. Das Ergebnis: bei einer Multisite mit 10 verschiedenen Domains liegen die Seiten-Ladezeiten (GTmetrix) jetzt bei 1 – 2 Sekunden und die Performance scores so um die 90, das auf einem „ganz normalen“ VPS, d.h. ohne Hardware-Overkill…

Das Tuning geht weiter, da liegt sicher noch mehr drin…

​Read More
WordPress HowTo

Gelöschte (drop table) WordPress Datenbank wiederherstellen

Gestern abend war es soweit: Tief versunken in Adminarbeit mit Plesk auf meinem VPS „mal schnell“ bei einer Domain das „legacy SSL“ Häkchen weggeklickt und gespeichert.

Plesk führt den Vorgang aus ohne Rückfrage und ohne Sicherheitsnetz und dann war die Datenbank meiner Domain weg. Futsch. Einfach im Nirwana verschwunden. Die Seite war natürlich damit hinber: „No Database“ vor weissem Hintergrund… Blöd.

Das VPS läuft auf Ubuntu 14.04 und verwendet Plesk 12.5, also alles auf dem neuesten Stand und das System läuft als Produktiv-Maschine mit ca. 20 anderen Domains, alle auf WP.

Leider hatte ich bei dieser Domain übersehen, dass die wp-Installation – und natürlich auch die MySQL Datenbank von Plesk verwaltet wird. Ein dummer Fehler, der mir sicher nicht mehr passieren wird.

Stellt sich also die Frage: Wie stellt man eine WordPress Datenbank wieder her, wenn man keine DB-Backups hat? Ausserdem sollen ja alle anderen Domains ungestört weiterarbeiten, während sozusagen hinter den Kulissen die Reparaturen für die zerschossene Domain laufen.

Die Google-Recherche fördert keine vernünftigen Lösungen zutage; passiert mir sowas wirklich als einzigem? oder traut sich sonst keiner mit Fragen in die Foren zu posten?

Zum Glück gibts die freundlichen Fachleute vom Hosteurope-Support und mit deren kompetenter Anleitung hat es dann auch geklappt:

  • Mein VPS macht tagesaktuelle Backups – gottseidank :-), daraus hab ich erst mal die komplette MySQL Datenbank in ein temp-Verzeichnis extrahiert und dann auf meine lokale Maschine runtergeladen.
  • Auf der lokalen Maschine dann MySQL Server installiert – gleiche Version wie auf dem VPS (!) und nachdem der lief, erst mal wieder gestoppt und ihm im Datenverzeichnis die MySQL Datenbank vom Server-Backup untergejubelt. Hier mussten erst die passenden Zugriffsrechte und Benutzer gesetzt werden, dann lief der lokale Server mit den MySQL Datenbanken vom Server – Stand gestern Mittag.
  • Nächster Schritt: mit mysqldump die passende Tabelle als SQL Datei exportieren. Jedoch leichter gesagt als getan: Aus irgendeinem Grund ist die Hälfte der Tabellen nicht greifbar und es gibt nur ein lapidares „Table not found“. Nachdem diese von der Bezeichnung her einem bestimmten Plugin zuzuordnen waren, hab ich einfach die zugehörigen Dateien gelöscht – das Plugin kann man ja anschliessend wieder neu installieren…
  • Jetzt klappt der dump und damit habe ich nun endlich die Daten als SQL wieder – uff… Jetzt nur noch schnell einspielen mit phpMyAdmin, dazu vorher noch …
  • in Plesk die Datenbank neu anlegen – mit dem alten Datenbank-Namen, und auch mit dem gleichen Benutzernamen und Passwort, sonst gibts gleich die nächsten Probleme…
  • Und jetzt kann die SQL-Datei in die neue Datenbank importiert werden. Fertig.

Kurzer Test: Die Seite ist wieder da – alles läuft einwandfrei…

Und zum Schluss noch ein paar Aufräumarbeiten – das Plugin muss ja erst deinstalliert und dann wieder installiert werden. Das wars.

Klingt so einfach, wenn mans hinter sich hat…

​Read More
Webmaster-Ressourcen, Website-Marketing, WordPress HowTo

Doppelter Content und der non-www Redirect

Jerry West schreibt in seinem aktuellen Post: Fixing Internal Duplicate Content with a Non-www Site Redirect wieder mal über ein altbekanntes Thema, das ich aus aktuellem Anlass nochmal aufgreifen will, weil viele Webmaster sich immer noch diese Nachlässigkeit leisten; Sie führt zu der Duplicate Content Abstrafung durch Google mit reduziertem PageRank und damit schlechteren Listings für die eigenen Seiten. Folge ist weniger Suchmaschinentraffic – ein böser Fehler für jeden Webmaster, nicht nur für die, die mit Ihrer Site Geld verdienen wollen.
Dabei ist der Duplicate Content Fix sehr einfach über die .htaccess im root-Verzeichnis der Site zu erledigen. Noch einfacher geht’s mit der neuesten WordPress-Version: stellt man WordPress-Adresse und Blog-Adresse korrekt mit „http://www.“ ein, erledigt WordPress das von ganz alleine.

​Read More