Der Beitrag „wp2shell“: Die WordPress-Sicherheitslücke, die mich zum Newsletter-Comeback gebracht hat erschien zuerst auf Collaborato Training.

Schrift von Google Fonts laden

Zunächst müssen wir wissen, welche Schriftarten (Fonts) und Auszeichnungen (fett, kursiv…) benötigt werden. Manchmal kommt jedes Schriftgewicht als einzelne Datei, häufiger ist jedoch eine Datei mit einem „Variablen Font“ das alle Schriftgewichte enthält. Manchmal kommtn die kursiven Schriften in ein einer extra Datei. Den Hinweis auf „kursiv“ erkennt ihr meist am Zusatz „italic“ im Dateinamen. Diese Schriften laden wir dann bei Google Fonts wie folgt herunter:

Geht auf https://fonts.google.com/ und tippt euere Schrift in das Suchfeld ein, Klickt die entspechende Schrift und und klickt oben auf „Download Family“. Ein Beispiel für Open Sans seht ihr im Bild. Rechts braucht ihr nichts auszuwählen oder kopieren. Wir brachen nur die Datei(en) aus dem Download, der nach dem Klick auf „Download Familiy“ erfolgt sein sollte.

Die .Zip wird ausgepackt und wir haben jetzt so eine Struktur (siehe Bild)

Wollen wir also „Open Sans“ verwenden genügen uns die beiden .ttf Dateien. Die eine ist für alle regulären (geraden) Schriftgewichte (von dünn bis extrafett) und die mit dem „italic“ im Dateinamen enthält alle Schriftgewichte noch mal in kursiv. (Theoretisch kann der Browser auch aus einer regulären Schrift ein kursive Schrift machen, lass das aber nicht deinen Grafiker hören. Das sieht dann nämlich nur kursiv aus, ist aber nicht das was der Schriftdesigner sich unter kursiv vorgestellt hat.)

WordPress auf die Schriftdatei vorbereiten

Von Haus aus kennt WordPress eine Reihe von Dateitypen anhand der Dateiendungen. Alles andere lässt WordPress dich aus „Sicherheitsgründen“ nicht hochladen. Ein Versuch über „Medien“ und „Datei hochladen“ würde genauso scheitern wie der Versuch schon jetzt im Divi-Builder die Schrift einzubinden. Die Fehlermeldung „Du bist leider nicht berechtigt, diesen Dateityp hochzuladen.“ erscheint in diesem Fall.

Wir müssen also WordPress beibringen, dass eine .ttf Datei nicht gefährlich und sogar gewünscht ist. Dazu nutzte ich ein Plugin „WP Add Mime Type“ https://de.wordpress.org/plugins/wp-add-mime-types/ Mit „Mime Types“ wird beschrieben welche Dateiendung welchen Dateityp bedeutet. Einmal installiert und aktiviert haben wir jetzt unter „Einstellungen“ /  „Mime type Settings“ unser Tool. Oben stehen schon einige Mime-Types die WordPress bereits kennt und ganz unten ist ein großes Eingeabefeld „Add Values“. Hier gebe ich immer ttf = font/ttf  ein und drücke unten auf „save“.  Die „Security Options“ über dem Eingabefeld habe ich so gelassen wie sie waren, sonst gibt es doch noch Probleme z. B. beim Upload. Bei mir sind alle Haken aus. Ist das erledigt kann mit dem Hochladen der Schriften begonnen werden. Das Plugin muss so lange aktiviert bleiben, bis alle Schriften hochgeladen wurden.

Hochladen der Schriften (Google Fonts) in DIVI

Jetzt gehen wir auf eine beliebige Divi-Seite die einen Textblock enthält und aktivieren den Divi-Editor (Divi-Builder). Danach gehen wir in die Einstellungen des Textblocks (=Zahnrad-Symbol) und dort auf den Tab „Design“. Hier im Bereich „Text“ auf „Schriftart“ klicken – die Schriftauswahl erscheint als Dropdown. Nun klicken wir auf den Button „Hochladen“ der in der Auswahlbox angezeigt wird. (siehe Bilder).   

In der Dropdown Box auf den Button „Hochladen“ klicken.

Jetzt erscheint diese Dialogbox „Hochladen Schriftart“ Lasst euch von der wirren Übersetzung nicht irritieren, hoffentlich kommt hiee bald mal eine Korrektur.

Oben in das Feld gehört jetzt der Schriftname hinein. Ich ergänze hier um „Regular“ um es von den Kursivschriftarten abzugrenzen. Ausserdem schreibe ich „lokal“ dahinter. Das in zwar unkonventionell, aber ich sehe dann immer gleich woran ich bin. Danach auf den Button „Datei auswählen“ drücken und die .ttf-Datei (nicht die .zip) hochladen. 

Es sieht zwar anders aus, aber das System lasst nur eine Datei zu. Falls ihr keine variable Schriftdatei habt, müsst ihr den Prozess mit jeder Schrift wiederholen. Für diesen Fall gibt es unten die Checkbox „Alle“, die dann – sobald man den Haken entfernt – umschaltet und die Checkboxen für die einelnen Schriftgewichte (Fontweight) freigibt. 

Der Text den ihr oben eingebt, dient dazu später den richtigen Font auszuwählen. Kryptische Bezeichnungen, die ihr euch nicht merken könnt helfen hier nicht weiter. Jetzt ist nur noch wichtig auf „Hochladen“ zu drücken – das wars. Wir wiederholen das mit der Fontdatei für kursive Schrift oder mit allen Einzelfonts.

Einschub aus der Praxis: DIVI Google Fonts lokal einbinden

Kleiner Einschub aus meiner Praxis: Ich habe festgestellt, dass manchmal bei den variablen Fontdateien ich die einzelnen Schriftgewichte nicht vernünftig ansteuern kann. Also mit dem Wahlkonopf „fett, normal, dünn…“ der unter der gewählten Schriftart steht. Der Support konnte das bisher nicht vernünftig beantworten. Wenn ihr den Fall auch haben solltet: Ich lade in dem Fall dann doch noch die einzelnen Schriftgewichte-Dateien hoch – die sind in der geladenen Schrift – Zipdatei meist im Unterordner „static“.

Lokalen eingebundenen Google Font auswählen

So, das Hochladen wäre erledigt. Jetzt gibt es zwei Optionen. 

1. Will ich Schiften eher automatisch und allgemein vergeben, wählen wir in allen Textboxen – so auch hier – nur „Default“ als Schrift aus. Die Schrift wird dann von der Voreinstellung im Customzier übernommen. (ich erkläre gleich wie das geht). Nachdem auf der Seite alle Texte auf „Default“ stehen, bitte speichern und den Editor verlassen.
2. Will ich jede Textbox einzeln mit dem passenden Font versehen, dann bitte jetzt in allen Textblöcken die jeweils gewünschte Schriftart aus den eben hochgeladenen auswählen. Jetzt speichern und den Builder verlassen.

Abschließend für beide Schritte im Theme Cusomizer die lokalen Schriftarten voreinstellen. Dort stellen wir unter „Allgemeine Einstellungen“ / „Typografie“ je eine Schriftart für Überschriften (=Kopfzeile) und die Schriftart den ganzen Rest (=Hauptschriftart) aus. Jetzt klicken wir oben auf „Veröffentlichen“ und verlassen den Customzier über das „X“ oben links. 

Google Fonts deaktivieren

Ist das erledigt, können wir Google Fonts grundsätzlich abschalten. Das machen wir im Menü „Divi / Theme-Optionen“ im ersten Reiter „Allgemeines“ finden wir den Schalter „Google Schriftarten verwenden“ den wir ausschalten. (Der Screenshot zeigt den ausgeschalteten Zustand)

Ab sofort sind keine externen Google Fonts mehr verfügbar, wenn wir Schriften in den Designeinstellungen auswählen. Technisch läuft das Divi-Theme jetzt auf lokalen Fonts, also so wie wir uns das für den Datenschutz wünschen. Es ist aber ratsam, alle Seiten noch mal zu prüfen, und zu schauen, wo jetzt eine Schrift nicht wie gewünscht aussieht. Dort haben wir ggf. noch eine falsche Schrift eingestellt.

Viel Erfolg mit euerer Webseite. Fragen und Anregungen einfach in die Kommentare schreiben.

Über mich 

Ich bin Günther A. Biebl und gebe WordPress-Seminare, erstelle Webseiten und unterstütze euch gerne mit euerer WordPress Webseite. Bei Fragen einfach melden.

Der Beitrag Google Fonts im Divi Theme lokal einbinden erschien zuerst auf Collaborato Training.

Damit das Problem nicht offensichtlich vor allen Besuchern der Webseite passiert, wäre es klasse, solche Probleme frühzeitig zu erkennen und Ausfälle zu vermeiden, richtig? Es gibt ja schon seit gut zwei Jahren die Funktion „Website-Zustand“ in WordPress die uns zu Updates, entfernen nicht genutzter Plugins und Themes, update der PHP-Version und dergleichen ermahnt. (Im Backend unter dem Menüpunkt „Werkzeuge“ zu finden) Das ist natürlich eine gute Sache. Aber es gibt da noch ein System das nicht so offensichtlich ist: Fehlermeldungen bzw. Warnungen des Browsers oder Webservers. 

Offensichtliche und verdeckte Probleme

Manche Probleme auf der Webseite sind offensichtlich – da stimmt was nicht, da sieht was komisch aus oder da ist eine Funktion kaputt, klar. Da hilft häufig ein Blick in die Fehlerconsole des Browsers. (Ich spreche nicht von 404 oder 500er-Fehlermeldungen im Browser, sondern „niedrigschwelligeren“ Meldungen.) In Chrome oder Firefox am Desktop ist das einfach: Rechte Maustaste im Browserfenster drücken, „Untersuchen“ anklicken und auf den Reiter „Console“ gehen. Jetzt die Seite neu laden oder den fraglichen Prozess auf der Seite durchführen und es sollte eine verwertbares Ergebnis kommen: Eine Fehlermeldung oder eine Warnung. (Dabei ist der Eintrag in Chrome: „DevTools failed to load source map“ zu ignorieren, der kommt so gut wie immer.)

Soweit, so gut. Aber was ist jetzt, wenn ein Fehler auftritt, wenn ich gar nicht dabei bin? Ein Nutzer ein Formular ausfüllt und im Prinzip zwar alles läuft, aber im Hintergrund ein paar „rote Fahnen“ gehisst werden, die sagen sollen, dass hier was nicht ganz korrekt ist? Es wäre doch gut, das früh zu erkennen, noch bevor wichtige Daten verloren gehen oder Funktionen unbrauchbar werden. In meinem Beispiel (unten) wären das Anmeldedaten für meinen Newsletter oder sogar die Anmeldung für meine WordPress Seminare.

WordPress Ausfall vermeiden: Logfiles auswerten

Für solche Fälle gibt es in der IT die Logfiles. Das sind separate Dateien, in die die Software alle Meldungen des laufenden Prozesses schreibt. Natürlich macht es keinen Sinn, diese Meldungen jedem Besucher der Webseite um die Ohren zu hauen und wirre Meldungen auszuspucken. Das ist der Grund warum ein normaler Besucher üblicherweise von so etwas verschont bleibt. Im Standardfall ist die Logfile-Generierung in WordPress sogar deaktiviert.

Es gibt die Möglichkeit, das reine generieren des Logfiles direkt in der wp-config.php zu aktivieren und dort eine Datei für die Speicherung anzugeben. Das hat den Nachteil, dass ich in diese Datei auch gelegentlich reinschauen muss. Ich weiss nicht wie das bei Euch ist, aber ich würde das vergessen. Ich bin ja meistens im Backend unterwegs und nicht auf Dateiebene.

Lösung per Plugin „Error Log Monitor“

Die Lösung dafür ist ein Plugin: „Error Log Monitor“ von Janis Elsts (https://de.wordpress.org/plugins/error-log-monitor/). Nach der Installation und Aktivierung, mochte es mich für Newsletter und Tracking gewinnen, was ich mit „Skip“ überspringen kann, oder per „Allow & Continue“ erlaube.

Danach befinden wir uns in der Liste der aktivierten Plugins und werden oben aber darauf hingewiesen, dass wir das Error Log Monitor Plugin noch konfigurieren müssen. Um es einfach zu haben, hier auf „Use Recommended Settings“ drücken. (Über „Manual Configuration“ gibt es mehr Einstellmöglichkeiten. Unter anderem kann man einstellen, wo das Logfile auf dem Server liegen soll. Das ist aus Sicherheitsgründen gar nicht schlecht, ich bleibe hier aber bei der einfachen Lösung. Die Anleitung liefert das Plugin auf englisch mit sobald man auf den Knopf drückt. Und: Falls Ihr jetzt „Recommended“ gedrückt habe und zu „Manual“ wollt: Einfach im Backend noch mal auf den Menüpunkt „Plugins“ klicken)

Etwas Code dann doch

Nach dem Klick auf „Use Recommended Settings“ fordert es den Nutzer auf, ein paar Zeilen Code in die wp-config.php einzutragen und ggf. einen Eintrag anzupassen. Das geht am besten über einen FTP-Zugang. (Web-FTP im Backend des Providers oder z.B. die kostenlose Software „Filezilla“ mit den Zugangsdaten des Providers. (Aus Sicherheitsgründen empfehle ich euch bevor es weitergeht, ein Backup anzulegen – Veränderungen im Dateisystem können euer WordPress lahm legen und wir wollen ja Ausfälle vermeiden. Ein Option ist hier beschrieben: Backup per Updraft Plus)

Seid ihr per FTP eingeloggt, navigiert in das WordPress-Hauptverzeichnis, kopiert euch die wp-config.php auf den lokalen Computer (Bei Filezilla wird die Datei von der Server-Seite auf die andere mit dem lokalen Dateisystem gezogen.) Legt bitte zusätzlich eine Backup-Kopie der wp-config.php an, die unberührt bleibt, sollte was sein (Ausser ihr habt jetzt tatsächlich ein Backup, dann wäre das doppelt 😊). Jetzt öffnet ihr die lokale Datei in einem geeigneten* Editor. 

Bearbeiten der wp-config.php

*Mit „geeignet“ ist keinesfalls Word oder ähnliches gemeint. Gemeint ist ein reiner Text-Editor oder auch ein Code-Editor. Also: MS-Editor (=Notepad unter Windows) oder Textedit (auf Mac). Oder wahlweise als Extraprogramme zum kostenlosen download: BB-Edit (Mac) oder Notepad++ (Windows). Jetzt kopiert Ihr den Code, den das Plugin vorsieht, an das Ende der Datei und speichert die veränderte Datei ab.

Eine Leerzeile darüber ist OK, dann wird es übersichtlicher. Für den Fall dass euch Fehlermeldungen und Warnungen nicht reichen, kann auch noch die Zeile „define( ‚WP_DEBUG‘, false );“ auf define( ‚WP_DEBUG‘, true ); gesetzt werden. Dann wird das Log aber schnell voll. Das macht für mich nur Sinn, wenn ich grade auf der Suche nach einem Fehler bin – für meine Frühwarnfunktion lasse ich das aber aus, also auf „false“. Sonst bekomme ich so viele Meldungen, dass die wirklichen Fehler unter den Meldungen begraben werden, befürchte ich. (Obwohl ich grade sehe, dass bei den Konfigurations-Einstellungen es eine Filteroption gibt, falls ihr die testet, lasst mir einen Kommentar da.)

Bitte keine weiteren Änderungen ohne Knowhow vornehmen – hier reagiert WordPress empfindlich. Danach wird die wp-config.php wieder hochgeladen und damit die bestehende Datei überschrieben und im Plugin (WordPress-Backend) der Vorgang bestätigt. (Button „Done“ anklicken“)

Hat alles geklappt, nimmt das Programm seine Arbeit auf. Es ist gibt jetzt eine neue Anzeige auf der Backend-Seite “Dashboard“ die zunächst leer ist – und idealerweise leer bleibt. Weitere Konfigurationen können über dieses Dashboard-Widget vorgenommen werden. Dazu mit der Maus über die Kopfzeile des Widgets fahren und „Konfigurieren“ anklicken.

Es gibt eine Funktion sich die Einträge über Mail senden zu lassen – die bei mir aber nicht funktioniert.

Meine Erfahrung damit: Es wurde beim Test recht schnell klar, dass das Plugin, das die Mailadresse über das Anmeldeformular für Seminare an die Newsletter-Software weitergibt ein Problem hat. Und das, obwohl alles (noch) sauber ankommt und funktioniert. Um welches Modul es sich handelt, war an dem Pfad zur problematischen Datei zu erkennen der in der Fehlermeldung angegeben ist. Daraufhin habe ich auch gesehen, dass für das Plugin seit 1 Jahr kein Update mehr herausgebracht wurde. Einen Fehlerreport habe ich an den Autor über die Plugin-Support-Seite auf WordPress.org zwar gesendet, dort gibt es aber seit einiger Zeit kaum noch Rückmeldungen. Sprich: Früher oder später muss ich das Plugin ersetzen. Was sich gut trifft, denn ich wollte ja ohnehin ein Veranstaltungsplugin ausprobieren.

Letzte Worte zum Thema „Sicherheit“: Neben diesem Tool gibt es zusätzlich für Sicherheitslücken das sehr gute Sicherheitsplugin „iThemes Security“ das Sicherheitslücken frühzeitig anzeigt und inzwischen auch in der kostenlosen Version einen automatischen Scan auf und 2-Faktor Anmeldung anbietet.

Über mich

Ich bin Günther A. Biebl und gebe WordPress-Seminare und unterstütze Unternehmen dabei Ihre WordPress Webseite selbst zu erstellen und eigenständig zu publizieren. Bei Fragen einfach melden.

Headerbild: von Rudy and Peter Skitterians auf Pixabay

Der Beitrag WordPress Ausfälle vermeiden – ein Frühwarnsystem erschien zuerst auf Collaborato Training.

Vorbereitung für den WordPress Umzug

Es gibt ein paar Sachen, die das Plugin nicht mag. Dazu gehören Dateiennamen die Sonderzeichen und Umlaute enthalten. Das sollte aber sowieso guter Standard sein: Dateinamen können aus Buchstaben und Zahlen bestehen. Zusätzlich gibt es den Unterstrich „_“ und Bindestrich „-“. Ein Punkt trennt den Namen vom Dateityp. Keine Sonderzeichen, Umlaute oder Leerzeichen. 

Jetzt können wir das Plugin installieren und aktivieren. 

WordPress Umzug: Ausführung

Das Plugin legt einen Hauptmenüpunkt im Backend unten links an. Wir starten mit dem Button „Neues erstellen“ rechts.

Der Prozess besteht aus drei Stufen. In der ersten Stufe können wir Änderungen vornehmen oder einfach alles belassen wie es ist. Alles so lassen und auf „Weiter“ drücken wäre mein Tipp.

Danach erfolgt ein Scan. Hier kommt es ggf. zu Warnungen wegen zu großer Dateien oder Dateinamen mit Sonderzeichen / Umlauten. In dem Fall entweder noch mal abbrechen und korrigieren oder die Warnung ignorieren und es probieren. Die Dateigrößenwarnung rührt daher, dass das Tool vermutet, der Provider schafft das Komprimieren der großen Dateinen nicht. Das muss ja nicht stimmen. Aufklappen erklärt mögliche Probleme genauer. Mit „Erstellen“ geht es weiter. Eventuell müsst ihr das ignorieren der Warnungen vorher noch bestätigen.

Jetzt wird das Archiv erstellt und es gibt einen Ladebalken. Etwas Geduld ist angesagt. Nachdem der Prozess fertig ist, bietet es zwei Dateien zum Download an. Eine Archivdatei und ein Installationsprogramm. Beides laden wir jetzt auf unseren Rechner.

WordPress Umzug: Vorbereitung Zielsystem

Beim neuen System benötigen wir Zugang zur Webspace-Verwaltung. Hier kann ich nachsehen oder anpassen mit welchem Unterverzeichnis auf dem Webspace unsere Domain verknüpft ist. Jetzt solltet Ihr noch eine neue Datenbank anlegen – der Menüpunkt könnte auch „MySQL“ heissen. 

Meist werdet Ihr in diesem Dialog gebeten, ein (möglichst komplexes) Passwort zu vergeben. Im Anschluss werden die wichtigen Parameter wie Username, Datenbankname und falls nötig die URL der Datenbank verraten. Diese Angaben benötigt Ihr während der folgenden Installation.  

Falls die FTP-Zugangsdaten unbekannt sind, kann man hier im Provider-Backend jetzt noch die Parameter nachschlagen oder ein neues Passwort oder einen neuen Account anlegen. Das ist wichtig für den nächsten Schritt. Falls euere Domain noch eine Fehlermeldung anzeigt, wenn sie mit der Vorsilbe https:// im Browser aufgerufen wird, ist jetzt die Gelegenheit das entsprechnde SSL-Zertifikat zu aktivieren. Vielleicht müsst ihr das vorher kaufen – das kommt auf eueren Hostingvertrag an.

Besonderheit Providerwechsel

Geht es nicht darum die Domain während des Umzugs zu ändern, sondern soll die Domain vom alten Provider übernommen werden, gibt es einen Zwischenschritt: Zunächst wird die Domain beim alten Provider gekündigt. Das kann man auch „den Auth-Code der Domain anfordern“ nennen. Liegt euch der Auth-Code dann vor, kann die Domain vom neuen Provider übernommen werden. Das führt automatisch zu einer Zwangspause, da der alte Provider meist nicht sofort reagiert und die Übernahme der Domain erst im Internet bekannt gemacht werden muss. Letzteres kann 1-2 Tage dauern. Handelt es sich nicht um eine .de – Domain wird häufig von beiden Parteien per Mail noch eine Zustimmung eingeholt. Ein Hinweis: Denkt an euere Mails, wen Ihr den Provider wechselt. Das Postfach muss beim neuen Provider angelegt werden, die Mails gesichert und das Mailprogramm auf den neuen Provider eingestellt werden. 

Upload auf Zielsystem

Ein FTP-Programm ist eine Software die Dateien von und zum Webserver kopieren kann. Habt ihr keines zur Hand, dann schaut euch das gute und für alle Plattformen kostenlose Filezilla an. Das Programm muss jetzt eine Verbindung zum Webspace aufbauen. Dazu benötigt es Serveradresse, Benutzername und Passwort. Eine kleine Gemeinheit ist, dass es nicht nur reguläres, unverschlüsseltes FTP, sondern auch verschlüsselte Varianten wie SFTP und FTP-SSL gibt. Das sollte der Provider bei der FTP-Accounteinrichtung verraten oder ihr probiert es durch. Möglicherweise müsst Ihr noch den Port mit angeben. Unverschlüsseltes FTP wird schon mal genutzt – Verschlüsselung wäre aber der empfohlene Weg. Euer Coworking- oder WLAN-Cafe Nachbar könnte sonst euere Dateien abgreifen.  Filezilla-Anleitung

Steht die Verbindung, müsst ihr nur noch zum richtigen Serverordner navigieren und in dem Verzeichnis, in das das WordPress später laufen soll die beiden Dateien hochladen. Bei Filezilla geschieht das per „Drag and Drop“. Dateien links anfassen und nach rechts auf den Server „schieben“.

WordPress Installation auf Zielsystem starten

Nach erfolgreichem Upload der Dateien ruft einfach mit dem Webbrowser eure Domain (am besten per HTTPS://) auf und ergänzt die Adresse um „/installer.php“. Zunächst folgt ein einen kurzer Systemtest und die Bestätigung der Lizenzbedingungen mit “Next“. Danach könnt ihr die Datenbank-Parameter aus dem vorhergehenden Schritt eingeben. 

Steht die Datenbankverbindung wird im Schritt 3 noch mal Titel, URL und Installationspfad editierbar angezeigt. Die Angaben sollten aber bereits korrekt sein. Nach drücken auf „Next“ startet die Installation und bestätgt nach ein paar Minuten den erfolgreichen Abschluss. 

Sicherheit: Duplicator löschen

Zur Sicherheit solltet ihr nach dem erfolgreichen WordPress Umzug das Duplicator-Plugin und die Installationsdateien aus dem Webspace löschen. Das muss nicht händisch passieren. Duplicator zeigt genau dafür einen „Admin Login“-Knopf auf der Seite „Installatin fertig“ an. Wenn ihr diesen Knopf jetzt für die Anmeldung klickt, werden die Dateien automatisch gelöscht. Viel Spass mit euerem neuen WordPress 

Fazit

Das Tool hilft mir, die für Kunden gebauten Seiten vom Test-/Staging-Server auf den Liveserver umzuziehen. Ich erspare mir Datenbank-Aktionen mit Suchen und Ersetzen, die immer etwas fehleranfällig sind. Es beschleunigt den Vorgang, weil statt tausender winziger und unkomprimierter Dateien nur eine komprimierte Archivdatei kopiert wird. Das lässt sich viel schneller laden. Und: Wenn man das nicht regelmäßig macht, vereinfacht es den Prozess erheblcih. Einen Nachteil gibt es: Da man die Installation erst aufrufen kann, sobald die Domain auf dem Zielsystem verfügbar ist – Beispiel: Providerwechsel mit Domainübernahme – gibt es einen kurzen Ausfall von ein oder zwei Tagen für die Webseite. Schliesslich kann ich mein WordPress nicht schon vorher vorbereiten, so dass es beim Domainwechsel schon auf dem neuen System vorhanden ist. Das Problem trifft vor allem Seiten, die nicht lange ausfallen dürfen wie gut besuchte Onlineshops oder Seiten, die stark vom erworbenen SEO-Rang leben.

Über mich

Ich bin Günther A. Biebl und gebe WordPress-Seminare und unterstütze Unternehmen dabei Ihre WordPress Webseite selbst zu erstellen und eigenständig zu publizieren. Bei Fragen einfach melden.

Foto im Header: skeeze auf pixabay

Der Beitrag WordPress Webseiten per Plugin umziehen – kostenlos mit Duplicator erschien zuerst auf Collaborato Training.

Fundstellen:

(a) die knappe Pressemitteilung: https://curia.europa.eu/jcms/upload/docs/application/pdf/2019-10/cp190125de.pdf

(b) das Urteil in voller Länge: http://curia.europa.eu/juris/document/document.jsf?text=&docid=218462&pageIndex=0&doclang=de&mode=req&dir=&occ=first&part=1&cid=1436279

(c) Zusammenfassung bei Heise: https://www.heise.de/newsticker/meldung/EuGH-Keine-Cookies-ohne-Zustimmung-4543630.html

(d) Etwas ausführlicher bei Golem: https://www.golem.de/news/eugh-urteil-jeder-cookie-erfordert-einwilligung-der-nutzer-1910-144187.html

(e) Am ausführlichsten bei Spiegel Online mit Stellungnahme von Bitkom: https://www.spiegel.de/netzwelt/netzpolitik/europaeischer-gerichtshof-cookies-brauchen-aktive-einwilligung-des-nutzers-a-1289439.html

Aussagen des EuGH:

Ohne übertrieben komplizierten Begründungsaufwand verweist das Gericht mehr oder weniger klar auf nachvollziehbare Sprache der einschlägigen EU-Normen. Und kommt zu folgenden fünf Ergebnissen:

(1) Cookies: Für alle Cookies (die nicht unter die enge Ausnahme nach Art. 5 Abs. 3 Satz 2 der ePrivacy-Richtlinie in der Fassung von 2009 fallen) muss eine aktive Einwilligung über ein Opt-in erfolgen. Sprich: Das Zustimmungshäkchen darf nicht schon vorab gesetzt sein.

(2) Voraussetzung für eine wirksame Einwilligung ist eine klare Information darüber, in was man einwilligt.

(3) Die Cookie-Vorschrift gilt sowohl für Cookies, die personenbezogene Daten speichern, wie für solche, die nur nicht-personenbezogene Daten erfassen. Also für alle Cookies (die nicht unter die enge Ausnahme nach Art. 5 Abs. 3 Satz 2 der ePrivacy-Richtlinie in der Fassung von 2009 fallen).

(4) In den Datenschutzinformationen muss auf jeden Fall auch über die Speicherzeit der Cookies im Browser informiert werden. Und über alle Dritten, an die Daten weitergeleitet werden und deren Verwendungszwecke.

(5) Weil vom deutschen Gericht nicht als Frage vorgelegt, sagt das Urteil ausdrücklich (siehe Randnummer 64) nichts zur Frage, ob ein Angebot (z.B. eine kostenfreie Nutzung einer Website) gekoppelt werden darf an die Einwilligung in ein Cookie (für Werbetracking). Das wird diskutiert unter dem für wirksame Einwilligungen erforderlichem Merkmal „ohne Zwang“ (in der Fachliteratur unter dem Schlagwort „Koppelungsverbot“).

Fazit:

Da viele Besucher der Websites die Einwilligungen nicht erteilen werden, wird sich wahrscheinlich das gesamte System des Onlinemarketings neu aufstellen. Ein Freund von mir bei Teads (einem großen Dienstleister für Videowerbung) sagte heute Morgen schon: „Zurück in die Online-Steinzeit.“

Handlungsbedarf:

Nach diesem Urteil sind alle einfachen Cookie Banner irrelevant. Zugespitzt formuliert: Man kann Websites auch genauso gut ganz ohne ein Banner betreiben.

(1) Jeder Onlinedienst (Website, App, etc.), der mindestens ein Cookie setzt, muss eine Funktion für Cookie Consent anbieten (das ist deutlich mehr als ein herkömmliches Cookie-Banner). Die Einwilligung muss erfolgt sein, BEVOR der Cookie gesetzt wird.

(2) Jeder Cookie muss mit ausreichenden Informationen in den Datenschutzinfos vorgestellt werden.

(3) Für alle Third Party-Cookies müssen – falls nicht bereits vorliegend – (belastbare) Informationen von deren Anbietern zur Verarbeitung der Daten in deren Bereich eingeholt werden. Nur so kann man diese Angaben in die eigene DS-Info aufnehmen. Sprich: Google, Facebook, Oracle und diverse andere Dienstleister, mit denen man zusammenarbeitet, müssen unter Umständen weitere Informationen zur Verfügung stellen.

Der einfache Weg:

Dies ist die große Stunde der Cookie Consent-Tools. Deren Anbieter sollten die notwendigen Informationen zusammentragen, soweit das noch nicht geschehen ist, und über das Consent-Tool anbieten.

Die Betreiber von Websites müssen dann „nur“ ein leistungsstarkes Consent-Tool in ihre Seiten einbauen.

Und abhängig vom eigenen Geschäftsmodell muss man schauen, wie hart Einbußen dadurch sind, dass bisherige Funktionen zur „zielgruppengerechten“ Ausspielung von Inhalten und Kampagnen nicht mehr möglich ist.

______________________________

Mark Rüdlin

Rechtsanwalt + Datenschutzbeauftragter 

https://markruedlin.de

Headerbild: Brigitte Tohm/Pexels via Canva

Der Beitrag Gastbeitrag RA Mark Rüdlin: Keine Cookies ohne Einwilligung erschien zuerst auf Collaborato Training.

Inhalt

• Ankunft
• Unbezahlbar und dabei kostenlos
• WordPress Training Team
• Ziel des Teams
• Arbeitsorganisation
• WordPress Theme Review Team
• Kongress WCEU
• Ausblick

Ankunft

Der Kongress war Ende Juni „Estrel“, einem großen Kongress-Hotel in Berlin Neukölln. Viel Glas und relativ schick – sowas hatte ich in der Gegend nicht vermutet – aber das ist eben Berlin. Gegenüber war ein Schrotthändler und auf der anderen Seite waren Schrebergärten – ehemalige Grenze. Trotzdem gab es rund um den Veranstaltungsort schon vor dem Beginn einige „Warm-Up-Treffen“ zu verschiedenen Themen. Neukölln erinnerte mich noch an das „alte Berlin“ – das noch nicht komplett modernisiert war. Trotzdem mit guter Infrastruktur und Kneipendichte.

Unbezahlbar und dabei kostenlos

WordPress ist ja eine Software die von Freiwilligen lebt, die kostenlos Inhalte beisteuern, das ist bekannt. Aber wer sind diese Leute und wie ist das organisiert? Das lässt sich hier leicht herausfinden, denn dafür gibt es den Contributor Day am Tag vor dem Kongress. Hier wurden auf 610 Stück begrenzte aber kostenlose Tickets „verkauft“ und ich war schnell genug, eines zu ergattern. Für den nächsten Schritt – nämlich der Frage: „Wo möchte ich mich einbringen?“ Gibt es einen simplen Selbsttest. Korrektur: den Selbsttest gibt es nicht mehr, hier ist ein allgemeiner Einstieg für Freiwillige: https://make.wordpress.org/ Für mich kamen aus den erhaltenen Empfehlungen die Bereiche „Training“ und „Theme Review“ in die engere Auswahl. Hier die Liste der Teams auf der offiziellen Webseite.

WordPress Training Team

Als ich morgens frühzeitig ankam ging alles recht problemlos. Schnell hatte ich meinen Ausweis mit Namen drauf und war zum ersten mal in den Räumen. Der Contributor Day war ganz am anderen Ende der Kongressfläche auf zwei Stockwerke verteilt. Unten die Programmier- Teams (mit dunklerem Licht, ohne Bühne und Luftballons dafür mit mehr Ruhe) und oben alles andere. Der Raum war voller runder Tische für 6-8 Personen. Je nach erwarteten Teilnehmern waren einer oder mehrere Tische für je ein Team reserviert. Neben einer Übersichtskarte vor dem Raum zur Orientierung waren oben auch noch Schilder an Luftballons befestigt. Für das Training Team gab es zunächst nur einen Tisch – später haben wir uns allerdings noch einen weiteren Tisch dazu geholt um in Ruhe zu arbeiten.

Nachdem sich der Raum und unser Tisch langsam füllte haben wir uns kurz gegenseitig vorgestellt. Durch die Eigenheit des Kongresses waren wir schnell in einer vertrauten Arbeitsatmosphäre und gefühlt beim „Du“. Denn es wurde ohnehin nur Englisch gesprochen und die Wurzeln von WordPress liegen unverkennbar in den USA. Auch die Kleidung war eher leger – ich habe auf dem gesamten Kongress niemanden in Krawatte und Anzug gesehen. Trotzdem gab es einen Team Lead für den Tag – danke für die gute Arbeit an Jesse Owens aus Chicago. Ihn konnten wir mit unseren Fragen löchern.

Ziel des Teams

Das Training Team möchte Schulungsmaterialien zur Verfügung stellen. Jeder kann dort Slides und Trainer-Notizen herunterladen und für ein Seminar einsetzen. Derzeit ist die Seite aber aktuell noch verwaist (inzwischen ist hier schon frischer Inhalt zu finden) und besticht mit einem Eintrag aus 2013. Die Training-Gruppe wird deshalb derzeit auch nicht auf der offiziellen WordPress.org – Seite erwähnt. Aber: Daran wird gearbeitet. Es gibt schon eine neue Webseite im Beta-Stadium, die bald online gehen soll. Auch neue Kursen werden entwickelt. Der Kurs „Geschichte von WordPress“ ist ein interner Leitfaden und wird dann wahrscheinlich einer der ersten sein, die online gehen werden.

Arbeitsorganisation

Vor der Veranstaltung wurden wir schon darauf hingewiesen, welche Accounts wir benötigen werden. Dafür gibt es extra eine Team-Onbording-Seite – die inwzischen offline ist – und jedes Team arbeitet etwas anders. Im wesentlichen ist die Struktur so: Meetings finden wöchentlich per Textchat auf #Slack statt. Daten liegen auf GitHub – das war mir bisher als zentraler Speicher für Programmcode an dem dezentral gearbeitet wird, bekannt. Beim Training-Team wird das auch für Anleitungen und Präsentationen benutzt. So ist sicher gestellt, dass niemand die Arbeit des Kollegen zerstört. Dann gibt es noch Trello – hochtrabend kann man es als „Kanban-Board“ bezeichenen. Faktisch kann man hier Aufgaben von einem Status in den nächsten schieben, kommentieren und Personen zuweisen. Ich verwende das selber gerne für meine Kundenprojekte. So kann ich immer transparent berichten wie hoch die angefallenen Aufwände sind oder welche Schritte noch zu erledigen sind. Zu diesem speziellen WordPress-Training-Bord muss man von der Gruppe allerdings erst eingeladen werden. Dann gibt es noch Zenhub – das ist ein bisschen wie Trello, aber man kann von hier direkt auf die Dateien in GitHub zugreifen. Das erspart den Umweg über Trello. Zenhub ist zwar nicht kostenlos, aber WordPress hat dort einen Account, so dass der einzelne keine eigene Lizenz kaufen muss. 

Für uns waren einige Aufgaben vorbereitet worden, um mit den Abläufen klar zu kommen. Kollege Claus hatte sich mit einem Kollegen einen Kurs zu CSS-Basics für Einsteiger ausgesucht. Dieser war nur als rudimentäre Idee angelegt aber es fehlten noch Struktur, Lerneinheiten, Übungen, Folien und die Hinweise für den Dozenten. Nach einer Weile stellen sie fest, dass es zu viel Material für einen einzelnen Kurs ist. Kein Problem – beim nächsten #Slack-Meeting wurde das Thema diskutiert und eine Aufteilung in mehrere Kurse beschlossen.

Ich hatte um die Abläufe zu lernen mir zunächst eine kleine Aufgabe ausgesucht: Es ging darum den Fehler im Verzeichnispfad einer Kursstruktur zu finden. Dazu musste ich die Aufgabe in Zendesk als meine Aufgabe markieren (lassen) und den entsprechenden Kurs aus Github in mein lokales Verzeichnis laden (auschecken). Nachdem ich den Fehler behoben hatte, konnte ich den Kurs wieder bereitstellen. Dazu werden die Änderungen mit einem „Commit“ von mir bestätigt ein „Pull-Request“ erzeugt um den Code wieder in Github als aktuellen Stand hochzuladen.

Nachdem ich diesen Ablauf einmal durchlaufen hatte, habe ich mich mit einem anderen Kollegen am Kurs mit dem Thema „Google Fonts zu WordPress hinzufügen“ beschäftigt. Zielgruppe: Einsteiger. Aus einer internationalen Sicht mag das in wenigen Stunden erklärt sein. Mit der DSGVO im Nacken wäre es für europäische Nutzer aber meiner Meinung nach fahrlässig nicht auf das dadurch entstehende Datenschutzproblem aufmerksam zu machen. Insofern haben wir unter anderem für den Kurs vorgeschlagen, das Thema mit aufzunehmen und auch auf die Möglichkeit der lokalen Einbindung von Google Fonts hinzuweisen.

Der Einblick in die Arbeitsweise und der Austausch mit den durchwegs netten Kollegen aus USA, Schweiz, Deutschland und Japan im Team haben mir gut gefallen. Auch die Abläufe – die zunächst sehr sperrig wirken – machen Sinn. So professionell, agil und digital arbeiten sonst nur wenige internationale Grosskonzerne. Nur dass es sich hier um eine Freiwilligenorganisation handelt. Auf diese Weise dauert es etwas, bis man sich eingearbeitet hat – aber danach kann man zum Projekt beitragen. Ich selbst habe bisher nur wenig helfen können, mangels Zeit – aber ich will auf jeden Fall den Kontakt halten und in der Zukunft weitere Beiträge leisten.

WordPress Theme Review Team

Gestärkt durch leckeres Fingerfood in der Mittagspause habe ich mir mal das Theme Review Team aus der Nähe angesehen. So ein Wechsel ist für Neueinsteiger auch tatsächlich vorgesehen. Diese Gruppe testet alle von Autoren eingereichten, kostenlosen Themes. Bei Erfolg werden die Themes in das offizielle Verzeichnis eingetragen und sind danach für alle dort und über das WordPress-Backend auffindbar / abrufbar. Ich finde es beruhigend, dass die Themes – wie auch die Plugins – tatsächlich vorher getestet werden.

Im Vorfeld habe ich gelesen, dass es für das Team spezielle Software gibt, um die Themes auf bestimmte Mindestanforderungen zu testen. Mein Ausflug war aber nur von kurzer Dauer, da ich mit den Leuten und den Aufgaben in „meinem“ Training-Team sehr zufrieden war und mich nicht schon wieder in ein neues Team und deren Abläufe einarbeiten wollte.

Kongress WCEU

Der Kongress selbst war dann noch mal erheblich größer. Bei über 2700 Besuchern entstand bei der Registrierung am Morgen nur eine kleine Schlange. Auch sonst war der Ablauf recht reibungslos ohne größere Pannen. Neben den größten Sponsoren Google, WooCommerce und Jetpack gab es noch viele kleinere Sponsoren. Schön war, dass ich z.B. mit dem netten Team von Polylang über ein aktuelles Problem sprechen und lösen konnte. Auch hat mich erstaunt wie groß Yoast – das SEO-Plugin – hier aufgetreten ist. Vielen Dank an alle Sponsoren.

Bei den Veranstaltungen gab drei verschiedene Tracks mit Vorträgen, ein Cafe mit Themen und 3 Workshopbereiche. Daneben wurde auch die Kinderbetreuung mit WordPress-Kurs oder Yoga nicht vergessen. Die Themen gingen von sehr speziellen, techlastigen Themen wie Git-Tools des Team-Kollegen David und dem Entwickeln von Gutenberg-Blöcken über SEO, Preisgestaltung, Design für Non Profit Organistaion bis zu einen Ausblick wohin die Reise gehen wird. Es macht keinen Sinn meine Notizen zu bemühen – ein paar Vorträge gibt es auch auf WordPress TV. Jeder Talk wurde gefilmt, vielleicht kommt also noch mehr hinterher. Einen Vortrag darüber wie man Text für sein Blog schreibt fand ich gut und habe ich Euch hier noch im Video eingebunden.

Für mich war es ein Erlebnis wie nett und hilfsbereit hier die WordPress-„Gemeinde“ zusammenstand. Alle hatten gute Laune und jeder war hilfsbereit, egal ob Kollege, Mitbewerber, Freelancer oder große Agentur. Nach dem Kongress bin ich auf dem aktuellen Stand der WordPress Entwicklungen und haben neue spannende Kontakte geknüpft.

Ausblick

Das nächste WCEU ist in Portugal und ich wäre gerne wieder dabei, Vielleicht klappt es ja? Vorher gibt es ein WordPress-Retreat in Soltau. Vielleicht ist da ja auch was für Euch dabei? Schreibt es gerne in die Kommentare, vielleicht sieht man sich ja dort.

Über mich

Ich bin Günther A. Biebl und gebe WordPress-Seminare und unterstütze Unternehmen dabei ihre WordPress Webseite zu erstellen und eigenständig zu publizieren. Bei Fragen einfach melden.

Der Beitrag WCEU – WordCampEurope 2019 – meine Eindrücke erschien zuerst auf Collaborato Training.

WordPress fordert vom Webserver einiges an Leistung: Die Seiten müssen mit PHP zusammengebaut werden und die Datenbank soll Inhalte liefern. Ausserdem laden Themes und Plugins viele Dateien nach, die alle zum Besucher gelangen müssen. Da wünscht man sich manchmal eine statische HTML-Seite, die hier einfach einen Vorsprung hat. Nicht verzagen, hier ein paar Tipps wie man WordPress beschleunigen kann.

• Basis Webserver: Überprüft doch mal ob euer Server schon HTML/2 beherrscht. Einfach euere Adresse hier eingeben: https://http2.pro/ Falls kein grüner Haken kommt: Sprecht mal mit euerem Provider was er für euch tun kann. Bei mir war es ein kostenloser und reibungsloser Umzug auf den neuen Server. HTTP/2 kann einfach effektiver die einzelnen Dateien zum User übertragen als unser gutes altes HTTP 1.1.
• Bilder verkleinern: Schaut doch mal welche Bilder zu langsam laden. Alles was über 200 KB groß ist, braucht einen guten Grund dafür und ist hoffentlich in der Minderheit. Über die Mediathek im Backend könnt ihr in der Detailansicht die Bildgrößen sehen und mit Pfeiltasten durchklicken. Was zu groß ist, stärker komprimieren und austauschen. Falls ihr keine gute Bildbearbeitung euer eigen nennt, dann gebt es einfach dem Panda: https://tinypng.com/ (Gibt es sogar als Plugin, kennt das jemand? Es will eine Registrierung. https://wordpress.org/plugins/tiny-compress-images/)

WordPress beschleunigen: Gut für die Besucher

• Server Cache per Plugin integrieren:  Da wir in der Regel die Webseite nicht laufend aktualisieren, muss WordPress ja nicht für jeden Besucher einzeln die Seiten aus dem PHP zusammenbauen. Das reicht ja alle paar Stunden oder sogar Tage. Der Plan ist: Der erste User generiert die Seite und alle anderen bekommen dann nur noch die gespeicherte, bereits generierte Seite. Mein Favorit ist dabei „WP Super Cache“ von Automattic selbst. Ist im Prinzip schnell konfiguriert: Cache einschalten und den empfohlenen Einstellungen folgen. Meist drehe ich dann noch die Chache-Vorhaltezeit nach oben.
•  Reduzieren der Dateien: Wie gesagt übertragen alle aktivierten Plugins und das Theme kleine Dateien. 50 Stück ist noch wenig. Da jede Datei angekündigt, übertragen und überprüft werden muss gibt das einen Stau. HTTP/2 macht die Autobahn schon breiter, aber es geht noch besser. Einfach mal testen. Ich verwende für den Fall „Autoptimze“ von Frank Goossens.

Optimierte Webseite: Gut für SEO

• Lazy Loading: Wenn ihr viele Bilder verwendet und lange Seiten habt, dann könnte man überlegen, die Bilder weiter unten erst zu laden, wenn sie wirklich sichtbar werden. Dazu gibt es Plugins wie z.B.: „a3 Lazy Load“ von a3rev Software. Ich selbst habe das (noch) nicht im Einsatz.
• Nerven bewahren: Die Testtools meckern immer wieder Sachen an, an die wir gar nicht (so einfach) herankommen und je nach Tagesform kommen etwas unterschiedliche Werte dabei heraus. Nicht vergessen: Cache muss auch erst erzeugt werden bevor er etwas beschleunigt. Mit diesen Tools könnt Ihr testen:
  • Google Pagespeed insights:  https://developers.google.com/speed/pagespeed/insights/?hl=de und
  • Pingdom: https://tools.pingdom.com/

Habt ihr noch weitere Anregungen oder Kommentare? Einfach unten reinschreiben.

Über mich

Ich bin Günther A. Biebl und gebe WordPress-Seminare und unterstütze Unternehmen dabei ihre WordPress Webseite selbst zu erstellen und eigenständig zu publizieren. Bei Fragen einfach melden.

Der Beitrag WordPress beschleunigen: die 6 wichtigsten Punkte erschien zuerst auf Collaborato Training.

Vorteile des Plugins:

• Schnelle Grundkonfiguration mit „Secure Site“-Funktion.
• Umfangreiche Funktionen mit englischer Beschreibung 
• Über den Menüpunkt „Log“ bekommt man einen Eindruck was alles passiert

Nachteile des Plugins:

• Man kann sich schnell selber aussperren, wen man nicht aufpasst
• Manchmal werden etwas zu Warnungen zu leichtfertig ausgesprochen
• Es speichert IP-Adressen der (vermeintlichen) Angreifer und meldet diese bei aktivierter Funktion „Network Brute Force Detection“ auch an den Hersteller.

Ich schalte also immer die Funktion „Network Brute Force Detection“ ab und deaktiviere auch den Newsletter beim ersten Durchlauf der „Secure Site“-Funktion. Danach warte ich erstmal ab was sich in ein paar Wochen im Log findet. Passieren viele unberechtigte Loginversuche von unbekannten Nutzern, ziehe ich Schritt für Schritt die Sicherheitseinstellungen höher. Weniger Loginversuche, längere Aussperrungen usw. Nach meiner Erfahrung ist der Punkt „File Change Detection“ zu hysterisch in seinen Meldungen – das macht eher Panik als dass es hilft. Und: Es gibt einen Punkt „Lockout Whitelist“ unter „Global Settings“ mit dem man seine aktuelle IP-Adresse eintragen kann, falls ohne Aussperrungsgefahr das Plugin testen will.

In der Pro-Version (die ich Wartungskunden zur Verfügung stellen kann) gibt es z. B. zusätzlich eine Funktion die eine 2-Faktor-Anmeldung für Benutzer ermöglicht. Dann entfällt das zuletzt vorgestellte Math-Captca zugunsten einer Authentifizierungs-App auf dem Handy. Kleiner DSGVO-Hinweis: Da für das Log IP-Adressen gespeichert werden, sollte das meines Wissens nach auch in der Datenschutzerklärung beschrieben sein.

Hier der Link zum Plugin und hier mein WordPress-Beratungsangebot.

Der Beitrag Security-Plugin iThemes Security – eine kurze Einschätzung erschien zuerst auf Collaborato Training.

Zum einen sind die dafür benötigten SSL-Zertifikate heute kostenlos zu bekommen und zum anderen haben wir in der Vergangenheit gesehen, wer alles diese Daten mitlesen will. Die Browserhersteller – allen voran Mozilla mit dem Firefox – warnen inzwischen sogar den Benutzer, wenn er Daten in ein unverschlüsseltes Formular eingibt und Google will mit Chrome nachziehen.  Deshalb zeige ich hier, wie Sie ein bestehendes WordPress auf HTTPS:// umschalten können. Ich halte die Beschreibung allgemein, meine Beispiele kommen aber von meinem Provider All-inkl.com.

1. Zertifikat bestellen

Zunächst gilt es zu prüfen, ob ein einfaches SSL-Zertifikat bereits im Webspace-Vertrag enthalten ist. Es gibt immer auch noch extra zu bezahlende Zertifikate wie z.B. „Wildcard-Zertifikate“, die für alle Subdomains gelten – die meine ich nicht. Es reicht, wenn z.B. „Lets Encrypt“ oder ähnliche freie Zertifikate unterstützt werden. Ist das nicht der Fall, muss ggf für ca. 10-12 Euro / Jahr die Funktion dazu gebucht werden.

Bei All-inkl.com muss nur im kleinsten Tarif „Privat“ die Funktion für 99ct / Monat über die Members-Area dazugebucht werden. Alle anderen Pakete enthalten die Funktion bereits.

2. Zertifikat aktivieren

Jetzt wird das Zertifikat einer Domain (Webadresse) zugewiesen. Die Funktion ist über den Login-Bereich beim Provider zu erreichen. Bei All-Inkl.com befindet sich die Funkton im „KAS“ unter dem Menüpunkt „Domain“. Hier der Ablauf für All-inkl.com – bei andern Providern analog verfahren.

Dort erscheint eine Liste aller verfügbaren Domains – zunächst noch ohne das rote Schloss-Symbol. Hier wählen wir die Domain aus auf der die Webseite läuft und klicken rechts auf das Bearbeiten-Symbol (links von der Mülltonne).

Jetzt erscheinen die Details zur Domain. Hier einfach auf neben dem Text „SSL-Schutz“ auf „Bearbeiten“ klicken.

Dann wird das Zertifikat ausgewählt und aktiviert: Auf den Reiter „Let’s Encrypt“ klicken, Haftungsausschuss zustimmen durch anhaken und den Button „Jetzt ein Let´s Encrypt Zertifikat beziehen….“ klicken.

Nach kurzer Zeit meldet sich das System mit „Das Zertifikat wurde bearbeitet….“ zurück. Jetzt gilt es, ein paar Minuten zu warten. Je nach Provider kann das auch ein paar Stunden dauern.

3. Zertifikat testen

Rufen Sie jetzt Ihre Seite auf indem Sie die Domain mit führendem https:// in die Adresszeile des Browsers eintippen. z.B. „https://collaboato.de“ . Kommt eine Fehlermeldung wie „Seite ist nicht sicher….“ ist das Zertifikat noch nicht fertig eingerichtet. Bitte unbedingt warten bis hier KEINE Fehlermeldung mehr erscheint, und die Seite anstandslos geladen wird.

In der Adresszeile steht dann gleich nach dem Laden der Seite „https://“ – oder „Sicher“ – Je nach Browser. Die Anzeige wird heute nicht mehr unbedingt in grüner Schrift mit einem grünen Schloss dargestellt, da die Browserhersteller das als den Normalzustand anzeigen wollen.

4. WordPress umschalten

Wenn das zuverlässig klappt, loggen wir uns im WordPress ein und begeben uns zum Menüpunkt „Einstellungen“ und dort in den Bereich „Allgemein“. Hier steht Titel und Untertitel auch die WordPress-Adresse  und die Webseiten-Adresse.

Unsere Domain steht hier noch ohne „https://“. Also hier bitte das fehlende „s“ einfügen und unten auf „Änderungen speichern“ klicken. Bei der Adressänderung bitte besonders vorsichtig sein und keine weiteren Änderungen vornehmen – sonst reagiert WordPress gleich nicht mehr. Die Tatsache, dass wir uns jetzt wieder einloggen müssen ist allerdings normal.

5. Plugin installieren und aktivieren

Warum jetzt noch ein Schritt wo HTTPS doch schon läuft? Im momentanen Stadium kann man zwar jede Seite per HTTPS aufrufen, sobald man aber einen internen Link oder einen Menüpunkt anklickt, ist „https://“ aber wieder weg, da die internen Links noch auf „http://“ lauten. Das wollen wir aber dauerhaft umstellen. Dazu ändern wir die Verlinkung in der Datenbank per suchen & ersetzen mit einem Plugin. Die Schritte 5-7 entfallen, falls das WordPress gerade erst frisch installiert wurde und noch keine Inhalte angelegt wurden.

Bitte folgendes Plugin installieren und aktivieren: Better Search Replace von Delicious Brains. Nach dem Aktivieren finden wird die neue Funktion unter dem Menüpunkt „Werkzeuge“ im Unterpunkt „Better Search Replace“.

6. Backup der Datenbank

Spätestens jetzt sollten wir unsere Datenbank sichern. Ich benütze dafür gerne das Plugin BackWPup von Inpsyde GmbH. Das Tool ist recht umfangreich, erklärt sich aber auch weitgehend selbst. Ich gehe hier jetzt nicht detailliert auf die Konfiguration ein. Falls Sie mein WordPress Seminar besucht haben, haben Sie meine Anleitung bereits im Handout vorliegen.

7. Suchen und Ersetzen mit dem Plugin

Zurück im Menü des Better Search Replace Plugins unter „Werkzeuge“ / „Better Search Replace“ stellen wir folgendes ein:

1. Suchen nach: Die Adresse (URL) Ihrer Webseite ohne „https“.
   (Achtung, meine Adresse im Foto ist nur ein Beispiel…)
2. Ersetzen durch: Die Adresse Ihrer Webseite mit „https:“.
   Bitte noch mal kontrollieren ob man sich vertippt hat, oder irgendwo Leerzeichen sich eingeschlichen haben. Das Ergebnis wäre ein nicht mehr reagierendes WordPress. Bitte auch auf jeden Fall die Adresse (URL, Domain) der eigenen Webseite mit angeben, nicht nur „http://“ und „https://“ – sonst erwischt man ggf. zu viele ungewollte Stellen gleich mit.
3. Jetzt alle Tabellen auswählen (das sind sicher andere als auf meinem Bild vom Testserver, bitte nicht irritieren lassen). Einen Eintrag anklicken und mit Cmd+A (Mac) oder Ctrl+A (PC) alle Tabellen markieren spart Arbeit.
4. Den Haken bei „Gross- und Kleinschreibung ignorieren“ setzen.
5. Den Haken bei „auch GUIDs ersetzen“ setzen

Wenn Testlauf gewünscht, dann den „Testlauf“-Haken drin lassen. Dann werden zunächst keine Änderungen vorgenommen, sondern nur angezeigt wie viele Änderungen anstehen. Für eine tatsächliche Durchführung muss der Haken aber raus.

8. Neu einloggen und testen.

Sobald das Plugin fertig ist, sollte immer „Sicher“ angezeigt werden, egal welche Seite wir aufrufen und welchem Link wir folgen. Sollte es auf einer Seite so sein, dass noch ein Fehler angezeigt wird, kann es sein, dass zusätzliche Inhalte wie eingebettete Karten oder Videos noch nicht per HTTPS:// eingebunden sind. Diese Inhalte dann bitte noch mal mit der richtigen Adresse einbetten.

9. Optional: Webserver auf HTTPS umleiten.

Nach meiner Erfahrung reichen die Schritte oben für eine komplette Umstellung. Es gibt noch den Fall, dass jemand bewusst http://meinefirma.de aufruft – also bewusst ohne das „s“, oder eine alte Verlinkung noch nicht auf „https:“ umgestellt ist. In der Vergangenheit war das dann so, dass WordPress auch diese eine Seite ohne Verschlüsselung ausgeliefert hatte. Es gab die Seite also sozusagen doppelt: Mit und ohne https. Meine Tests ergeben aber, dass schon bis hierher konfiguriert der Server per erwünschter 301 Umleitung auf https:// verweist. Früher war das tatsächlich nicht so, inzwischen ist das aber Standard bei WordPress. Weiss jemand mehr dazu? Infos gerne in die Kommentare. (Nachtrag unten)

Will man diesen letzten Schritt noch gehen, gibt es eine allgemeine Methode und eine Abkürzung bei All-Inkl.com.

1. Allgemeine Methode: Es muss die Datei .htaccess auf dem Server bearbeitet werden. Dazu braucht man ein FTP-Programm wie „Filezilla“ und die FTP-Zugangsdaten seines Providers. Im Hauptverzeichnis der WordPress-Installation findet man dann diese Datei. Dort schreibt man folgendes rein: (nachdem man sich eine Kopie gemacht hat!) ….
   <IfModule mod_rewrite.c>
   RewriteEngine On
   RewriteCond %{HTTPS} off
   RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
   </IfModule>
2. Oder, falls man All-Inkl.com nutzt, kann man auch im KAS wieder zu seinem SSL-Zertifikat navigieren (wie in Punkt 2 dieser Anleitung). Also erst zum Menüpunkt Domains und dann dort bei der einsprechenden Domain auf „bearbeiten“ klicken.
   

   

   
   Jetzt auf SSL-Schutz bearbeiten klicken

   

   
   Dann öffnen sich jetzt die Details zum oben neu eingerichteten Zertifikat.

   

   
   Dort können Sie den Schalter bei „SSL erzwingen“ auf „Ja“ schalten. Auf diese Weise verhindert der Server, dass noch http ausgeliefert wird. (Bevor die Frage kommt: HSTS ist ein zusätzliches Sicherheitsfeature – dann kann die Seite in nächster Zeit NICHT MEHR ohne HTTPS:// aufgerufen werden. Falls Sie also HTTPS:// doch wieder deaktivieren, können Sie für diese Zeitspanne nicht mehr auf Ihre Webseite zugreifen. In meinem Beispiel sind das knapp 2 Wochen – also Vorsicht mit dieser Funktion, für den Basisschutz ist sie nicht notwendig.)

Soweit von mir, viel Erfolg mit euerer Webseite!

Nachtrag: Ich hatte kürzlich die Gelegenheit den Umzug bei einem Strato-Kunden durchzuführen. Tatsächlich musste ich eine separate Umleitung einrichten, damit die Seite immer sofort und zuverlässig auf https:// umschaltet. Ich habe mir das einfach gemacht und das Plugin iThemes-Security (das schon installiert war) verwendet. Dort gibt es ein Modul namens „SSL“ das einfach auf „Enabled (Recommended)“ eingestellt wird. Fertig. Da ich das Plugin ohnehin ganz gut finde, passt die Lösung für mich.

Abkürzung per Plugin (Nachtrag 2)

Wem der Weg oben zu aufwändig ist, der kann das Plugin „Really Simple SSL“ probieren. Vorher ist es aber gut, wie im Schritt 3 oben beschrieben zu testen ob bereits ein SSL-Zertifikat für die Seite aktiv ist. Kommt eine Fehlermeldung das Plugin bitte nicht per Schalter in den Plugin-Einstellungen scharf schalten, sondern vorher die obigen Schritte 1 und 2 ausführen und dann noch mal testen. (Bzw. analog zu euerem Provider das Zertifikat ggf. bestellen und für die verwendete Domain aktivieren.

Der Beitrag Die WordPress Webseite auf https:// umstellen (=per SSL absichern) erschien zuerst auf Collaborato Training.

Die Lösung ist recht simpel: Unter dem Formular wird noch ein Zustimmungs-Haken angefordert und das Ergebnis am besten mit den Formularinformationen gespeichert. So habe ich das umgesetzt: https://collaborato.de/kontakt/

Konkretes Beispiel für das Plugin Contact-Form-7 in drei Schritten:

1. Kopieren Sie den Code unten in die Konfiguration Ihres Kontaktformulars. Sie finden es unter dem Menuepunkt „Formulare“ im Backend.

Die richtige Stelle ist nach dem vorletzten „Label“-oder „p“-Block. Danach kommt nur noch Code des Absende-Buttons „Submit“:


<label>
[acceptance Datenschutzerklaerung-zugestimmt] Ich habe die <a href="https://collaborato.de/datenschutzerklaerung/" target="_blank" rel="noopener">Datenschutzerklärung</a> zur Kenntnis genommen. Ich stimme zu, dass meine Angaben und Daten zur Beantwortung meiner Anfrage elektronisch erhoben und gespeichert werden. Hinweis: Sie können Ihre Einwilligung jederzeit für die Zukunft per E-Mail an E-Mail-Adresse info@collaborato.de widerrufen. [/acceptance]
</label>


2. Ersetzen Sie die beiden Stellen an denen meine Adressen stehen mit Ihrer Mailadresse und Ihrem Link zur Ihrer Datenschutzerklärung. (Korrektur: In einer früheren Version haben sich die Anführungszeichen beim Kopieren in gebogene „typographische Anführungszeichen“ verwandelt. Das versteht Contact-Form-7 nicht, deshalb korrigiert)

3. Um das nachher im Zweifel beweisen zu können, habe ich noch das neue Feld [Datenschutzerklaerung-zugestimmt] in die Mail kopiert, die mir den Formularinhalt sendet. Die Konfiguratiion finden Sie unter dem Reiter „E-Mail“ oben in den Formulareinstellungen.

Klappt das alles nicht, können Sie anstelle des Formulars auch einfach die Mailadresse mit einem „mailto:-Link“ auf der Seite angeben (wie hier bei Hubspot erklärt ) dann umgehen Sie das Problem.

Da ich keine weitere Quelle als eRecht24 habe, gehe ich mal davon aus, dass es sich derzeit um keine große „Abmahnwelle“ handelt. Wenn Sie andere Hinweise haben, bin ich für eine Info dankbar. Vielleicht erledigt sich das Thema auch mit dem neuen Hinweis zum Kontaktformular in der neuen Datenschutzerklärung im Zweifel also den Anwalt fragen.

Der Beitrag Abmahnschutz für Kontaktformular erschien zuerst auf Collaborato Training.