Service-Themen

Eine Frage, die uns immer wieder gestellt wird: "Wann sollte ich meine Drupal Webseite auf eine neue Version upgraden"? Da ist es wohl an der Zeit unseren letzten Beitrag zu diesem Thema zu aktualisieren.

Werfen wir zunächst einen Blick auf den aktuellen Versionsstand

Momentan gibt es drei Drupal-Versionen, die von der Community unterstützt werden: Drupal 7 (erschienen im Januar 2011), Drupal 8 (erschienen im November 2015) und Drupal 9 (erschienen im Juni 2020). Zunächst war geplant, dass der Support für Drupal 7 im November 2021 ausläuft ("End-of-Life") - zeitgleich mit Drupal 8. Während das End-of-Life für Drupal 8 unverändert geblieben ist, wurde der Termin für Drupal 7 aufgrund der Corona-Pandemie auf November 2022 verlängert. Das Drupal 8 jetzt vor Drupal 7 endet, erscheint zunächst seltsam. Der Grund liegt darin, dass Drupal 8 das Framework Symfony 3.4 verwendet, welches seinerseits im November 2021 sein Support-Ende erreichen soll. Dies muss man berücksichtigen, wenn man ein Upgrade seiner Drupal-Webseite plant.

Was bedeutet "End-of-Life"?

Wenn der Support für eine Drupal-Webseite eingestellt wird, bedeutet dies dass

  • es keine neuen Updates des Drupal-Core mehr geben wird,

  • das Drupal Sicherheitsteam keinen Support mehr leisten und keine Sicherheitsupdates mehr veröffentlichen wird,

  • Drittmodule für diese Drupalversion offiziell nicht länger unterstützt, upgedated oder dokumentiert werden.

Man ist also bei einer Drupal-Seite ohne offiziellen Support darauf angewiesen, dass man noch Unterstützung in der Community findet oder man muss - eventuell teuren - Langzeit-Support von spezialisierten Anbietern einkaufen. Eine frühzeitige Upgrade-Planung ist also in jedem Falle empfehlenswert.

Wann auf welche Version upgraden?

Webseiten, die mit Drupal 6 oder noch älteren Versionen laufen, lassen wir bei der Betrachtung außen vor. Sie sollten lieber heute als morgen ein Upgrade erhalten.

Bei einer Drupal 7 Webseite sieht das anders aus. Ein Upgrade auf Drupal 8 macht wenig Sinn, da man in wenigen Monaten auf Drupal 9 upgraden müsste. Während ein Upgrade von Drupal 7 auf Drupal 8 und weiter auf Drupal 9 für das Core-System in der Regel unproblematisch ist, gilt das nicht für Dritt-Module (also alles, was man unter https://www.drupal.org/project/project_module findet). Bevor man hier also an ein Upgrade denkt, müssen zunächst folgende Punkte geprüft werden:

  • Setzt die Webseite Drittmodule ein? Das ist sehr häufig der Fall. Hier muss zunächst ermittelt werden, ob es diese Module bereits für eine neuere Drupal-Version gibt oder ob dies zumindest in Arbeit ist. Da Drupal 8 vor Drupal 7 sein End-of-Life erreicht, brauchen wir auf jeden Fall eine Modulversion für Drupal 9! Wenn es für ein eingesetztes Modul keine neue Version gibt, muss man prüfen, ob es nicht vielleicht ein anderes Modul gibt, dass die gewünschten Funktionen bereitstellt. Das erschwert zwar ein wenig das Upgrade, ist aber in der Regel zu verkraften. Einige frühere Drittmodule sind mittlerweile auch in den Core gewandert, ein Upgrade ist hier also obsolet.
  • Gibt es speziell programmierte, eigene Module? Wenn ja, muss hier Budget eingeplant werden, um diese Module für Drupal 9 umzuschreiben.
  • Gibt es für das eingesetzte Theme ein Upgrade? Wenn nicht muss eine Entscheidung für ein neues Theme gefällt werden. Hier bietet es sich dann auch an, über ein Redesign der Webseite nachzudenken. Dementsprechend sollte man zusätzliche Zeit (und Geld) für das Upgrade einplanen.
  • Bin ich mit der Funktionalität meiner Webseite zufrieden? Wenn es Änderungs- oder Erweiterungswünsche gibt, ist es oft sinnvoll, diese im Rahmen des Upgrades gleich mit einzuplanen.

Auf jeden Fall bleibt genug Zeit, um das Upgrade in Angriff zu nehmen - dank der Support-Verlängerung um ein Jahr.

Ich habe schon Drupal 8 - was mache ich jetzt?

Wer in der Vergangenheit bereits ein Upgrade auf Drupal 8 durchgeführt hat, oder eine neue Webseite gleich damit aufgesetzt hat, hat dagegen weniger Zeit, sich um ein Upgrade zu kümmen. In der Regel ist es nicht so, dass eine Drupal-Webseite sofort unsicher wird, nur weil der Support ausläuft. Aber man sollte sich vor Augen halten, dass das Risiko, dass Sicherheitslücken entdeckt werden, für die es keinen Fix mehr gibt, mit jedem Tag steigt. Man sollte daher zügig die Prüfschritte durchführen, die wir oben für eine Drupal 7 Seite empfohlen haben. Lassen sich alle Dritt-Module upgraden oder ersetzen, steht dem Upgrade auf Drupal 9 auch hier nichts im Wege.

Was ist, wenn ich keine Ressourcen für ein Upgrade meiner Drupal-Webseite habe?

Es drohen mit dem Wegfall des Supportes Sicherheitslücken. Diese sind umso wahrscheinlicher, je offener die Seite für Besucher ist. Handelt es sich um eine Community-Seite mit zahlreichen, nicht näher verifizierten und damit weniger vertrauenswürdigen Usern, oder bietet die Seite die Möglichkeit Kommentare oder User-Content einzustellen, so sind die Risiken erheblich höher, als wenn nur eine handvoll bekannter Benutzer Zugang zum Backend und erweiterten Funktionen hat. Ein weiteres Sicherheitsrisiko entsteht dadurch, dass ältere Drupal-Versionen nicht mehr mit den aktuell unterstützten PHP-Versionen laufen. Die Webseite muss als mit einer älteren PHP-Version laufen, für die es unter Umständen ebenfalls keine Sicherheitsupdates mehr gibt. In solchen Fällten sollte zumindest geprüft werden, inwieweit man z.B. bestimmte Formulare zusätzlich absichern kann oder potenziell sicherheitsrelevante Funktionen, wie Kommentare oder Datei-Uploads, ganz abschaltet.

Durch diese Maßnahmen läßt sich Zeit gewinnen, bis ein Budget für ein Upgrade in ausreichender Höhe zur Verfügung steht.

Womit sollte ich eine neue Webseite aufbauen?

Wenn eine völlig neue Seite geplant ist, sollte Drupal 9 gewählt werden, sofern die Anforderungen mit dieser Version und den derzeit verfügbaren Drittmodulen realisierbar ist. Ist dies nicht der Fall und sind die fehlenden Funktionen kritisch, bleibt eigentlich nur, die fehlenden Funktionen durch eigenen Programmcode nachzurüsten. Das ist zwar teurer als der Einsatz von fertigen Drittmodulen, dafür kann die Seite deutlich länger ohne neues Upgrade genutzt werden.

Ach je, immer dieser Spam ... Nach unliebsamen Erfahrungen mit Spam-Filtern in meinem E-Mail-Programm, die mir auch gewünschte E-Mails gnadenlos rausgefiltert und gelöscht haben, bin ich dazu übergegangen, den Posteingang weitestgehend von Hand zu filtern.

E-Mails aus Kontaktformularen filtere ich gar nicht raus – schließlich möchte ich erreichbar sein, also kann ich nicht sagen "Lösche mir alles mit dem Absender meines Kontaktformulars", der ja in der Regel mit einer Absender-Adresse der eigenen Domain verschickt wird. Contact Form 7 bietet die Möglichkeit, "Honeypots" einzubauen, das sind unsichtbare Felder, auf die Spambots reinfallen sollen: Füllen sie sie aus, wird das Formular ungültig und kann nicht abgeschickt werden. So weit, so nützlich. Klappt aber nicht immer. Und in letzter Zeit kamen Unmengen saublöder Kontaktanfragen rein mit viel Text und wenig Sinn, bekloppte Werbetexte, Spam halt. Ich habe etwas recherchiert und bin dann auf eine Methode gestoßen, die wir in Drupal schon lange verwenden: Quizfragen auf Deutsch mit einfachen Antworten. 

In Contact Form 7 wird die Option "Quiz" mit ausgeliefert und man findet einen entsprechenden Knopf bei der Bearbeitung von Formularen. Man kann auch an der gewünschten Stelle im Formular-Editor einen Textschnipsel einzufügen, z.B.

[quiz random-quiz "Wieviele Beine hat ein Pferd? (Bitte Zahl eingeben)|4" "Wie heißt die Hauptdstadt von Burkina Faso|Ouagadougou"]

Okay, die Fragen sollten einfach gehalten werden, nicht jeder kennt die Hauptstadt von Burkina Faso. Theoretisch kann man einfache Rechenaufgaben verwenden oder Farben abfragen. Zwischen den Anführungszeichen ist jeweils ein Frage-Antwort-Set und sie werden automatisch per Zufallsprinzip ausgespielt. 

Der Trick bei der Sache: Die allermeisten Spambots können kein Deutsch! Da hilft auch der Google-Übersetzer nicht, selbst kinderleichte Fragen (z.B. nach der Farbe von Bananen) oder Rechenaufgaben, bei denen Zahlen nicht als Ziffern sondern in Buchstaben ausgeschrieben werden, können die blöden Bots nicht interpretieren. Noch nicht. 

Zwei auffällige Webseiten habe ich auf diese Weise schon entschärft. Einziger Nachteil natürlich: Neben dem DSGVO-Geraffel, das die Formulare schon unschön aufbläst, hat man jetzt noch ein weiteres Feld, das ausgefüllt werden muss. Dafür ist aber wieder eine Weile Ruhe im Karton.

Ab sofort heben wir die Trafficbegrenzung für alle Webhosting-Pakete mit 1 Gbyte Uplink dauerhaft auf. Das bedeutet, dass der ausgehende Trafficverbrauch unbegrenzt und kostenlos ist, auch wenn das gebuchte Hosting-Paket bisher eine Obergrenze vorgesehen hat. Die Anbindung wird somit bei höherem Trafficverbrauch nicht mehr reduziert.

Bei Kunden, die die Limitierung der Bandbreite aufgrund einer dauerhaften Überschreitung ihres Trafficlimits aufgehoben haben und somit eingewilligt
haben, über das Limit hinausgehenden Traffic zu bezahlen, entfallen diese Kosten zukünftig. Die Umstellung erfolgt automatisch.

Tracking-Software wie Matomo (vormals Piwik) ist dazu da, das Verhalten von Besuchern auf Webseiten zu verfolgen und zu analysieren. Will man das als Besucher vermeiden, gibt es grundsätzlich die Möglichkeit im Browser eine "Do-not-Track"-Einstellung zu aktivieren. Richtig konfiguriert beachtet Matomo diese Einstellung. Darüber hinaus gibt es die Möglichkeit ein Opt-out in Form eines iFrames auf der Webseite einzubinden, z.B. auf der Seite mit der Datenschutzerklärung. Was es bisher (= Version 3.6 von Matomo) nicht gibt , ist eine Opt-In-Funktion, d.h. dass Besucher explizit Ihre Zustimmung erteilen müssen, bevor Matomo mit dem Tracking beginnt. Um diese Funktion zu realisieren, ist etwas Arbeit erforderlich und das Modul EU Cookie Compliance.

Und so geht's:

  1. Zunächst einmal installiert man Matomo (vormals Piwik) - vorzugsweise unter der gleichen Domain wie die zu trackende Webseite, damit umgeht man schon mal alle 3rd-Party-Cookie-Probleme.
     
  2. In Drupal installiert und konfiguriert man das  "EU Cookie Compliance"-Modul. Folgende Einstellungen sind wichtig:
    Consent method: Opt-in. Don't track visitors unless they specifically give consent. (GDPR compliant)
    Die Texte, die im Banner erscheinen müssen angepasst (und ggf. übersetzt werden). Insbesondere dieser Text ist falsch: "By clicking any link on this page you are giving your consent for us to set cookies.". Ein Klick auf "any link" bewirkt nämlich gerade keinen Consent!
    Zustimmung zurückziehen: "Enable floating privacy settings tab and withdraw consent banner" aktivieren. Damit erscheint unten auf der Seite ein kleiner Tab, den man aufmachen kann, um die Zustimmung zum Tracking zu widerrufen.
    Script scope: auf "Header (Scripts variable)" setzen.
    Standardmäßig ist eine Cookie-Lifetime (für den EU-Cookie "cookie agreed", nicht für die Matomo Tracking-Cookies!) von 100 Tagen gesetzt. Diesen Wert kann man nach belieben verändern. Soll der Cookie immer beim Beenden des Browser gelöscht werden, setzt man einen Haken bei  "Prompt for consent (from the same user) at every new browser session. ". Dann wird der Cookie auch dann am Ende der Sitzung gelöscht, wenn der Browser ansonsten so konfiguriert ist, dass er alle Cookies beim Beenden behält.
     
  3. Jetzt installiert und konfiguriert man das Matomo-Modul.
    Wichtig: In den Einstellungen des Moduls muss man unter "Benutzer" den Eintrag "Das Tracking ist standardmäßig aktiviert, Benutzer mit Tracking wahlweise An- oder Abschalten-Berechtigung können es abschalten" aktivieren. Das klingt zwar erstmal wiedersprüchlich, aber wir verwenden einen anderen Mechanismus, um das Tracking an- und abzuschalten.

    Matomo-Modul: cookie-agreed wird am Ende der Browser-Session gelöscht

  4. Jetzt braucht es noch etwas zusätzliches Javascript, um dafür zu sorgen, dass Matomo erst dann mit dem Tracken anfängt, wenn der Besucher seine Zustimmung durch Anklicken des "OK"-Buttons im Cookie-Banner erteilt hat. Dieses Javascript wird in den Einstellungen des Matomo-Moduls eingetragen unter "Erweiterte Einstellungen >> Benutzerdefinierter JavaScript-Code >> Codeausschnitt (vorher) ". Dort tragen wir Folgendes ein:

    <code>if (!Drupal.eu_cookie_compliance.hasAgreed()){_paq.push(['requireConsent']);_paq.push(['disableCookies']);}if (Drupal.eu_cookie_compliance.hasAgreed()){_paq.push(['setConsentGiven']);}</code>

    Hierdurch wird abgefragt, ob in dem Cookie-Modul die Zustimmung erteilt wurde. Solange dies nicht der Fall ist werden im Matomo-Modul die Tracking-Cookies gelöscht. Die erteilte Zustimmung wird ein einem Cookie "cookie-agreed" gespeichert und bleibt mindestens während der laufenden Browser-Sitzung erhalten (siehe auch die Einstellungen für EU-Cookie-Compliance unter Punkt 2).

    Weiterhin muss im Feld "JavaScript-Bereich " der Scope auf "Fußbereich" gesetzt werden.

    Benutzerdefinierte Einstellungen für Matomo Tracking Opt-In

     

So sieht das dann aus, wenn man sich im Browser die Cookies anzeigen läßt:

Consent erteilt:

Zustimmung für Matomo-Tracking erteilt

_pk sind die beiden Matomo Tracking-Cookies. Cookies-agreed hat den Wert 2, d.h. Tracking wurde vom User erlaubt. Der letzte Cookie "Sess..." ist der Drupal Session-Cookie, der gesetzt wird, wenn man sich auf der Seite ins Backend einloggt. Oben sieht man gerade noch den Tab "Privacy settings". Wenn man diesen anklickt, kann man seine Zustimmung zum Tracking widerrufen. Hat man das getan, sieht die Cookie-Landschaft so aus:

Zustimmung zum Matomo-Tracking widerrufen

Die Matomo Tracking-cookies sind jetzt weg und cookie-agreed steht auf "null". Das Tracking ist also deaktiviert und es erscheint wieder das Banner, in dem man seine Zustimmung erteilen kann. Klickt man hier übrigens auf "Ablehnen" so taucht das Banner während der Laufzeit von cookie-agreed nicht mehr auf! Ansonsten wird es beim Durchklicken durch die Webseite auf jeder Seite erneut eingeblendet. Lässt man das cookie-agreed Cookie beim Beenden der Browsersitzung löschen, so erscheint das Abfragebanner ebenfalls wieder beim nächsten Aufruf der Seite.

Ach ja, noch ein Punkt, den man beachten muss: Das Matomo iFrame für das Opt-out darf man nicht mehr verwenden und muss es ggf. aus der Datenschutzerklärung entfernen und dort den Hinweis auf die Widerspruchsmöglichkeit umformulieren.

 

Schon seit letztem Jahr nerven die Browser: Diese Seite ist unsicher, nix ssl, blabla, und schlechtesten falls bekommt man sie gar nicht angezeigt (Firefox ist da besonders rigide). Das ist schade, besonders wenn man es eigentlich ganz gerne hätte, dass die Webseite Besucher anlockt. Was tun?

Man muss die Seite "auf ssl umstellen", also dafür sorgen, dass sie anstatt mit http://meine-domain.de mit https://meine-domain.de aufgerufen wird. Das erfordert in Wordpress ein paar Handgriffe, die aber recht schnell erledigt sind.

Vorbereitung

Als Werkzeuge benötigt man einen FTP-Client, um die entsprechenden Datein aus der Wordpress-Installation herunter- und wieder heraufzuladen (die meisten Hoster bieten Web-FTP aus der Konfigurationsoberfläche des Webseitenpakets an, man muss da also nicht zwingend was auf dem Rechner installieren), einen Text-Editor (Windows hat z.B. Wordpad an Bord, das reicht) und um es sich leichter zu machen, muss man noch ein zusätzliches Plugin installieren (dazu gleich mehr). Und natürlich braucht man ein Zertifikat. Als erstes besorgt man sich das Zertifikat. Das geht eigentlich inzwischen bei jedem Hoster bequem über die Verwaltung des Hostingpakets, und dort in der Verwaltung der Domain. Es gibt kostenpflichtige und kostenlose Zertifikate, mittlerweile bieten die Hoster beides an. Für eine kleine private Webseite genügt ein kostenloses Zertifikat. Ein paar Hintergrundinformationen über Zertifikate und was der Unterschied ist zwischen kostenlos und kostenpflichtig, gibt es z.B. auf t3n.de. Sobald das Zertifikat für die Seite beim Hoster registriert ist, kann die Webseite umgestellt werden.

Erst der Admin ...

Für alle Änderungen am System gilt immer: Ein aktuelles Backup durchführen! Dateien und Datenbank, bitte. Als erstes stellt man den Admin-Bereich um. Per FTP lädt man die wp-config.php Datei  herunter und fügt oberhalb der Zeile

/* That's all, stop editing! Happy blogging. */

folgendes ein:

define('FORCE_SSL_ADMIN', true);

Und wieder hochladen, die Datei. Den Admin-Bereich sollte man jetzt per https:// aufrufen können.

... dann der Rest

Jetzt geht man in der entsprechenden Wordpress-Seite auf Einstellungen/Allgemein und ändert die Seiten-URL von http:// auf https://.

Jetzt ist also auch das Frontend per https:// aufrufbar, aber wir sind noch nicht fertig. Es gibt noch einen Haufen interne Links und alle Medien, die mit http:// aufgerufen werden. Die muss man jetzt in der Datenbank alle aufspüren und mit https:// ersetzen. Au weia! Wenn man jetzt die Seite besucht, ist das Schloß-Symbol oben in der Adress-Leiste auch noch nicht grün, sondern rot und/oder durchgestrichen. Aber es gibt ja Gott sei Dank Plugins, die das für uns machen, ohne dass wir in die Datenbank gehen müssen! Sehr geschmeidig ist Better Search Replace. Hat man das installiert und aktiviert, findet man es unter "Werkzeuge". Gleich oben trägt man ein, was durch was ersetzt werden muss:

Hier wird http://meine-domain.de durch https://meine-domain.de ersetzt und um sicher zu gehen, dass das klappt, kann man weiter unten erst einmal einen Testlauf machen.

Wenn hier keine Fehler ausgegeben werden, kann man das Ganze abschicken, warten und beten ... Wenn das Schloss jetzt immer noch nicht grün ist, ist möglicherweise im Theme noch irgendwo händisch ein http:// eingetragen, das geändert werden muss. Fehler aufspüren kann man bequem über die Webseite Why No Padlock.

Hello world, ich bin jetzt HTTPS!

Der allerletzte Schritt ist jetzt noch, den Aufruf der https://-Seite zu erzwingen, auch wenn jemand die http:// der Webseite aufruft. Das geschieht durch einen Eintrag in der Datei .htaccess. Die muss man also wieder per FTP herunterladen und im Texteditor bearbeiten. Wichtig ist es, die richtige .htaccess zu finden: Es muss die aus dem oberen Wordpress-Verzeichnis sein, in dem auch die wp-config.php liegt! Dort fügt man jetzt am Anfang ein:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Speichern, wieder auf den Server hochladen. Jetzt sollte zuverlässig beim Aufruf von http://meine-domain.de die https://-Variante aufgerufen werden. Wenn es Probleme gibt, kann man auch mal versuchen, den Schnipsel ans Ende zu setzen. Klappt das nicht, muss leider Tante Google nochmal befragt werden, bei meinen Seiten hat das bisher aber anstandslos geklappt.

Am 25. Mail 2018 tritt die viel diskutierte Datenschutzgrundverordnung in Kraft, ebenso ein neues Bundesdatenschutzgesetz. Über Sinn oder Unsinn dieses bürokratischen Machwerks wollen wir hier nicht diskutieren, sondern Hilfestellung geben, was auf der eigenen Webseite gemacht werden sollte,


um diese DSGVO-konform zu machen. Mustertexte bieten wir nicht an, die finden sich aber auf zahlreichen Seiten. Ein paar Hinweise zu solchen Webseiten haben wir aufgeführt.


  1. Datenschutzerklärung: die gehört nicht nur auf jede Webseite, sie sollte auch gut auffindbar sein. Ein Link im Footer der Seite bietet sich da in der Regel an - am besten gleich neben dem Link zum Impressum. Es gibt diverse Webseiten (meist von Rechtsanwälten), die vorformulierte Erklärungen zur freien Verwendung anbieten. In der Regel wird verlangt, dass neben dem Urheberrechtshinweis ein Link zu der betreffenden Seite auf der eigenen Seite unter dem Text erscheint.

    Hier ein paar Beispielseiten: https://dsgvo-muster-datenschutzerklaerung.dg-datenschutz.de/, http://www.anwaltblog24.de/kostenlose-muster-datenschutzerklaerung-onlin...

    Noch ein Tipp: Da davon auszugehen ist, dass sich gewerbliche Abmahner gerne Webseiten anschauen werden, in der Hoffnung dort Verstöße zu finden, sollte die eigene Seite mit der Datenschutzerklärung für Suchmaschinen blockiert werden. Das kann man über die robots.txt machen und/oder die entsprechenden Metatags (
  2. Newsletter: Das man einen Newsletter nur per Double-Opt-In abonnieren lassen sollte, ist keine neue Erfindung der DSGVO, sondern schon seit Jahren zwingend. Ab dem 25.5. ist es aber erforderlich in der Zustimmungsmail, die den Link enthält, mit dem sich der Interessent endgültig anmelden kann, Hinweise zum Datenschutz enthält. Warum das so ist, wird hier erklärt und einen Beispieltext findet man auf der Seite auch. In den Newsletter selber gehört dann neben dem Impressum auch ein Link zur Webseite mit der Datenschutzerklärung.
  3. Kontaktformular: Auch hier braucht es künftig einen Hinweis auf die Verarbeitung der persönlichen Daten, die ja regelmäßig mit einem Kontaktformular erhoben werden. Bei flexiblen Formular-Generatoren wie z.B. Drupals Webform-Modul ist das schnell erledigt.
  4. User können sich auf der Webseite einen Account anlegen? Dann gehört die Zustimmung zur Verarbeitung der übermittelten persönlichen Daten auf die Seite, auf der sich der User erstmalig registrieren kann.
  5. Tracking mit Google Analytics & Co. Hier wird die Verarbeitung der persönlichen Daten aus der Hand gegeben. Daher muss der Seitenbesucher in der Datenschutzerklärung darauf hingewiesen werden. Ebenso wie auf die Möglichkeit, dass er dem Tracking widersprechen kann und eine Möglichkeit, das Tracking auszuschalten sollte dort auch vorhanden sein. Für den Seitenbetreiber ist zusätzlich der Abschluss eines Vertrages zur Auftragsdatenverarbeitung notwendig. Google bietet einen solchen Vertrag an. Andere Anbieter von Trackingdiensten sicher auch. Mehr zu diesem Thema findet sich hier. Alternativ kann man sich überlegen, ob man das Tracking nicht lieber in die eigene Hand nimmt und z.B. Matomo (vormals Piwik) auf dem eigenen Server betreibt. Die Anonymisierung der IP-Adresse sollte man bei allen Diensten aktivieren, sofern sie nicht ohnehin eingeschaltet ist.
  6. User können Kommentare auf der Webseite hinterlassen. Hier sollte man genau prüfen, ob dabei personenbezogene Daten gespeichert werden, z.B. die vollständige IP-Adresse oder die E-Mail-Adresse. In diesen Fällen muss auch wieder die Genehmigung zur Datenspeicherung eingeholt werden. Alternativ kann man natürlich auf darauf verzichten, solche Daten zu speichern. Bei der IP-Adresse genügt es, wenn man diese anonymisiert indem man die letzten drei (besser noch die letzten sechs) Ziffern z.B. durch "XXX" oder "xxx.xxx" ersetzt. Statt 192.168.1.100 wird dann 192.168.xxx.xxx gespeichert.
  7. Cookies: Kaum eine Webseite kommt ohne sie aus. Neben wichtigen technischen Informationen, die für das ordnungsgemäße Funktionieren der Seite erforderlich sind, gibt es auch noch Tracking-Cookies. Auch hierüber muss der User in der Datenschutzerklärung informiert werden - inklusive Angaben was er gegen die Cookies machen kann - und sinnvollerweise auch, was das für Folgen hat, nämlich, dass die Seite nicht mehr alle Funktionen bietet.

Noch mehr Informationenn zum Thema findet man hier: https://www.bitkom.org/sites/default/files/pdf/Presse/Anhaenge-an-PIs/2016/160909-EU-DS-GVO-FAQ-03.pdf


Und noch ein Hinweis: Unsere Tipps sind ohne Anspruch auf Vollständigkeit. Auch übernehmen wir keine Haftung, falls etwas unrichtig dargestellt wurde. Wer seine eigene Webseite DSGVO-konform machen will, dem empfehlen wir, sich anwaltlich beraten zu lassen.


Wer Hilfe bei der technischen Umsetzung der oben beschriebenen Maßnahmen benötigt, dem stehen wir gerne zur Seite.


Und hier noch die Gesetzestexte von  Datenschutzgrundverordnung und Bundesdatenschutzgesetz.

Spam-Mails sind grundsätzlich ein Ärgernis und können zu einer echten Belastung im Arbeitsalltag führen. Zwar sorgt ein serverseitiger Spamfilter in der Regel dafür, dass der größte Teil der eingehenden Spam-Mails markiert und ausgefiltert wird. Aber die Spammer verbessern natürlich ihre Methoden genauso, wie der Spamfilter verbessert wird. Und so kann es passieren, dass vorübergehend eine größere Zahl Spam-Mails durch den Filter rutscht. Jüngst betraf es einen Kundenaccount, der plötzlich eine große Zahl von Mails mit chinesischen Texten erhielt. Obwohl international tätig, erhält er keine regulären Mails mit chinesischen Schriftzeichen. 

Wie kann man sowas ausfiltern, wenn es durch den Spamfilter gelangt ist? Die Idee, einfach alle Mails auszufiltern, deren Textcodierung "Chinesisch traditionell" oder "Chinesisch vereinfacht" ist, funktioniert heutzutage nicht mehr, denn diese Mails sind in der Regel UTF8-kodiert. Aber es gibt eine andere Möglichkeit. Die Idee dahinter ist ganz simpel: Jede Spam-Mail enthält zwingend ein gängiges Wort wie "der", "eine", "an" oder "diese". Mit einer kleinen Wortliste von ca. 20 gängigen chinesischen Wörtern wie z.B. diesen 的 一 是 不 了 人 我 在 有 他 这 中 大 来 上 国 个 到 说 läßt sich jetzt im Mailclient ein einfacher Filter einrichten. Nachfolgend zeigen wir, wie das im Thunderbird geht.

  1. Hauptmenü oben auf "Extras" und dann auf "Filter" klicken.
  2. Es öffnet sich ein neues Fenster. Hier klicken wir auf "Neu".
  3. Im nächsten Fenster geben wir dem Filter einen Namen, damit wir ihn später in der Filterliste leicht wiederfinden. Aktivieren unter "Filter anwenden bei" die  Felder "Manuellem Ausführen" und "Nachrichtenabruf" und darunter den Radiobutton "Mindestens eine Bedingung erfüllen".
  4. Jetzt tragen wir für jedes der oben aufgeführten Zeichen eine Regel ein. Dazu wählen wir das Feld "Inhalt", die Bedingung "enthält" und tragen das erste Zeichen in das leere Feld daneben ein. Anschließen klicken wir auf das Pluszeichen rechts neben der Regel. In der neuen Zeile tragen wir das zweite Schriftzeichen ein. Das wiederholen wir solange, bis alle Zeichen in je einer Regel eingetragen sind.
  5. Unter "Auszuführende Aktionene" wählen wir "Verschieben der Nachricht in" und unsern Junk-Ordner.
  6. Jetzt noch auf "OK" klicken und die Regel ist aktiv.

Und so sieht der fertige Spamfilter dann aus (es werden nur die ersten vier Zeilen im Screenshot angezeit):

Spamfilter im Thunderbird für gängige chinesische Wörter

Beim nächsten Mailabruf werden jetzt alle Mails, die eines dieser chinesischen Schriftzeichen enthalten automatisch in den Junk-Ordner verschoben. Hin und wieder sollte man einen Blick in den Spam-Ordner werfen, um zu prüfen, ob die Spamwelle abgeebt ist. Dann kann man den Filter wieder deaktivieren. Sollte trotzdem noch China-Spam reinkommen, kann man den Filter auch manuell ausführen (deshalb hatten wir in Schritt 3 den entsprechenden Haken gesetzt). Einen ähnlichen Filter kann man natürlich auch für Spam in russischer Sprache erstellen - falls das erforderlich sein sollte.

Die Fähigkeit des Views-Moduls seine Ausgaben zu cachen ist in der Regel ausgesprochen nützlich und sorgt oft für einen Performance-Gewinn. Manchmal kann die Aktivierung des Cache jedoch kontraproduktiv sein und zu Fehlern auf der Website führen.

Einen solchen Fall hatten wir kürzlich. Auf einer Kundenwebseite gibt es eine OpenLayers-Karte mit einer Suchfunktion die mit einem View arbeitet. Diese Suchfunktion zeigt die gefundenen Standorte auf einer Karte von OpenStreetMaps an und listet sie mit zusätzlichen Informationen in einer angehängten Tabelle auf. Diese Tabelle hat die übliche Seitennavigation mit der man jeweils um 10 Einträge vor oder zurück blättern kann. Alles funktionierte einwandfrei... bis zum Einschalten des Cache für diesen View. Sobald der Cache aktiv ist, funktioniert die Seitennavigation nicht mehr. Klickt man z.B. den Link für Seite 2 an so kommt man noch auf die zweite Seite. Ein Klick auf den Link für Seite 3 ändert dagegen die Ansicht nicht, man bleibt auf Seite 2. Auch die Links für die folgenden Seiten funktionieren nicht mehr. Das gleiche gilt für die Vor- und Zurückblättern-Links. Entweder passiert gar nichts oder man kommt zurück auf Seite 1.

Die Fehlersuche gestaltete sich zunächst etwas schwierig, weil wir zunächst ein Views-Update in Verdacht hatte. Ein Vergleich des Views der Liveseite mit dem in der Entwicklungsumgebung (wo die Navigation funktionierte) brachte uns dann auf die richtige Spur. Der einzige Unterschied zwischen beiden Views war, dass bei dem einen der Cache eingeschaltet war, bei dem anderen nicht. Kaum war der Cache deaktiviert, schon funktioniert alles wieder.

Und so schaltet man den Cache für einen View ein oder aus:

  1. View zum Bearbeiten öffnen
  2. Im Master-Display auf der rechten Seite den Link neben "Cache" anklicken.
    Cache im View-Modul von Drupal ein- und ausschalten
  3. Im folgenden Dialog kann man den Cache einnschalten indem man "Zeitbasiert" wählt, bzw. ausschalten indem man "Keines" anklickt.
  4. Zum Schluss noch den View speichern und ab sofort ist für diesen View der Cache deaktiviert.

 

 

Wer LaTex kennt, wird sich jetzt vielleicht fragen, was dieses für das Erstellen von Textsatz seit den 80er Jahren entwickelte Softwarepaket mit einer Website zu tun hat. Dafür kann es gute Gründe geben.

So kann man mit LaTex relativ einfach mathematische Formeln erstellen. Mit HTML vor HTML5 ein nahezu unmögliches Unterfangen, weshalb Formeln auf den meisten Webseiten als Grafiken eingefügt werden. Aber auch das in HTML5 verfügbare MathML ist nicht gerade intuitiv. Da im akademischen Bereich häufig Kenntnisse in LaTex vorhanden sind, ist es natürlich attraktiv, wenn man für seine Website dieses auch direkt verwenden kann. Für Drupal gibt hierfür das Modul MathJax, das die hervorragende gleichnamige MathJax-Library einbindet.

Die Installation ist einfach. Die Library laden wir von der MathJax Github-Seite herunter. Anschließend entpacken wir das Paket und laden alles in einen Ordner "mathjax" im Library-Verzeichnis (in der Regel ist dies site/all/libraries) der Drupal-Installation. Als nächstes installieren wir das Drupal MathJax-Modul und aktiviert es. Das Modul bringt nur eine Berechtigung mit: "Administer MathJax". Diese gewähren wir dem oder den Administratoren der Website.

Jetzt ist es an der Zeit, zu schauen ob MathJax funktioniert. Dazu gehen wir auf die Seite admin/config/content/mathjax. Wenn wir alles richtig installiert haben, erscheint dort eine Beispielformel wie im folgenden Screenshot.

MathJax-Test zeigt: es wurde erfolgreich installiert

Damit wir auch wirklich LaTex-Formeln eingeben können, bleibt noch ein letzter Schritt zu tun. Der vom Modul bereit gestellt Inhaltsfilter muss mindestens einem Textformat zugewiesen werden. FullHTML ist da eine gute Wahl. Nach dem Aktivieren des Filters schieben wir diesen an das Ende der Filterliste. Das sieht dann so oder so ähnlich aus:

MathJax-Filter für Textformat FullHTML aktiviert

Jetzt können wir LaTex-Formeln in unseren Inhalten einsetzen. Hier ein paar Beispiele:

Anzeige alleinstehend, zentriert

Hier steht die Formel allein innerhalb einer Zeile und wird zentriert in der Mitte des Inhaltes angezeigt. Die Lesbarkeit ist sehr gut, da genügend Abstand zum Text gegeben ist.

$$f(x)=x^2-x$$

$$\displaystyle\frac{\Delta y}{\Delta x}=\frac{f(x+\Delta x)-f(x)}{\Delta x}$$

$$A=\{1,2,3,4,5\}, B=\{3,5,7\}, C=\{8,9\}, M=\{1,2,3,4,5,6,7,8,9\}$$

Inline-Anzeige 

Hier wird die Formel in einen umgebenen Fließtext eingebettet. Diese Form ist u.a. für die Formulierung von Aufgaben geeignet. Die Lesbarkeit ist etwas schlechter, vor allem bei mehrzeiligem Text.

Ermitteln Sie die erste Ableitung der Funktion <math>f(x)=x^2-x</math>, indem Sie den Differenzenquotienten <math>\displaystyle\frac{\Delta y}{\Delta x}= \frac{f(x+\Delta x)-f(x)}{\Delta x}</math> bilden und nach geeigneter Umformung den Grenzübergang <math>\Delta x\Abbildung0</math> vollziehen.

Die Ausgabe der Website sieht dann so aus:

Gerenderte Website mit LaTex-Formel und MathJax

Anpassungen des MathJax-Moduls

Bei der Arbeit mit dem Modul zeigten sich zwei Probleme. Das erste: die Konstruktion des HTML-Outputs von Mathjax mit Hilfe von <div> führte dazu, dass das Layout der Website auf manchen Seiten zerstört wurde. Die Abhilfe ist einfach. In der Datei mathjax.module (im Verzeichnis sites/all/moduls/mathjax) ändern wir die Zeile 143 von

return '<div class="tex2jax">' . $text . '</div>';

zu

return '<span class="tex2jax">' . $text . '</span>';

Jetzt wird der MathJax-Teil mit <span> konstruiert und kollidiert nicht mehr mit anderen <div>-Konstruktion der Seite.

Das zweite Problem zeigte sich erst nach einiger Zeit bei der täglichen Arbeit. Die Verwendung von Dollarzeichen für die Markierung von LaTex-Formeln führte zu fehlerhaften Darstellungen, wenn in den Texten Dollarzeichen für andere Zwecke verwendet wurden. Zum Glück läßt sich in der Konfiguration des MathJax-Moduls einstellen, welche Tags für die Markierung verwendet werden sollen. Dazu stellen wir auf der Seite admin/config/content/mathjax unter "Configuration Type" auf "Benutzerdefiniert" um und tragen im Feld "Custom configuration" diesen Code-Schnippsel ein:

MathJax.Hub.Config({
  extensions: ['tex2jax.js'],
  jax: ['input/TeX','output/HTML-CSS'],
  tex2jax: {
    inlineMath: [ ['<math>','</math>']],
    processEscapes: true,
    processClass: 'tex2jax',
    ignoreClass: 'html'
  },
  showProcessingMessages: false,
  messageStyle: 'none'
});
 

Dieser sorgt dafür, dass wir für Inline-LaTex-Code künftig die Tags <math> und </math> verwenden können. So klappt's dann auch mit den Dollarzeichen. ;-)

Während der Installation von Drupal werden verschiedene Einstellungen abgefragt und in der Datenbank gespeichert, z.B. der Name der Website oder der Pfad zum temporären Verzeichnis. Und auch später werden Einstellungen, die man vornimmt in der Datenbank abgelegt, wie zum Beispielt das Einschalten der CSS- und Javascript-Kompression. Während der Entwicklung einer Website hat man häufig andere Einstellungen als später auf der Live-Seite oder auch in der Testumgebung für den Kunden. So kann es zum Beispiel sein, dass die Entwicklungsumgebung mit Apache unter Linux läuft, während die Liveseite auf einem Microsoft Internet Information Server (IIS) läuft. In diesem Fall unterscheidet sich z.B. der temporäre Dateipfadt. Während auf dem Apache die Angabe "../.tmp" funktioniert verlangt der IIS etwas in dieser Form "C:\irgend\ein\pfad\drupaltemp". Zieht man nun eine Drupal-Version vollständig, d.h. die Drupal-Files und die Datenbank, vom Apache zum IIS rüber (inkl. Datenbankimport), so wird die Seite nicht fehlerfrei laufen. Nun könnte man den Weg gehen, sich einzuloggen und die Einstellungen von Hand korrigieren. Das ist  mühsam, fehleranfällig und muss man das nach jedem neuen Import wiederholen.

Eleganter und einfacher ist es, solche Einstellungen in der settings.php von Drupal vorzunehmen. Die settings.php sollte bei einem Übertragen der Seite nicht mitgeliefert werden, da darin auch die Zugangsdaten für die Datenbank liegen. Und diese Zugangsdaten lauten in der Regel auf dem anderen System ganz anders. Daher sollte jede Drupal-Instanz eine eigene settings.php besitzen, die bei Übernahme der Seite nicht überschrieben wird. Bei Einsatz eines Versionskontrollsystems wie z.B. git, lässt sich das leicht bewerkstelligen, indem man die settings.php in .gitignore als zu ignorierende Datei einträgt.

Nachdem man auf jeden System eine eigene settings.php-Datei angelegt hat trägt man in diese neben den Zugangssdaten zur Datenbank noch die Variablen ein, die für jedes System individuell lauten sollen. Um die Übersicht zu behalten sollte man seine Einträge an das Ende der settings.php stellen. So sieht jeder später auf einen Blick welche Einstellungen vorgenommen wurden und muss nicht die ganze settings.php durchsuchen. Ein kurzer Kommentar, was die jeweilige Variable bewirkt sollte nicht fehlen. Vor allem neu eingeführte Variablen wie x_frame_options sind am Anfang noch nicht jedem geläufig und spätere User werden dankbar für den Hinweis sein. ;-)

Hier einige Beispieleinträge:

Eintrag in der settings.php des Entwicklungssystems:

$conf['site_name'] = 'Entwicklungsumgebung'; // hier geben wir der Seite einen Namen, der auf den Dev-Status hinweist
$conf['admin_theme'] = 'bartik';  // jeder wählt sein Admin-Theme
$conf['file_temporary_path'] = 'C:\Windows\Temp'; // temporärer Pfad auf dem Entwicklunssystem
$conf['preprocess_js'] = 0 // javascripte nicht aggregieren, komprimieren und cachen
$conf['preprocess_css'] = 0 // CSS nicht aggregieren, komprimieren und cachen
$conf['theme_debug'] = TRUE // debugging für das Theme aktivieren
$conf['x_frame_options'] = ''; // x-Frame-Options deaktivieren, Achtung: sicherheitsrelevant, nicht in Produktivumgebungen verwenden!

Eintrag in der settings.php des Livesystems:

$conf['site_name'] = 'Die neue Kunden Livesite'; // hier der richtige Name der neuen Website
$conf['admin_theme'] = 'customer admin theme';  // hier wird das Admin-Theme für den Kunden vorgegeben
$conf['file_temporary_path'] = '../.tmp'; // temporärer Pfad auf dem Livesystem
$conf['preprocess_js'] = 1 // javascripte aggregieren, komprimieren und cachen
$conf['preprocess_css'] = 1 // CSS aggregieren, komprimieren und cachen
$conf['theme_debug'] = FALSE // debugging für das Theme aktivieren