Service-Themen

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

 

Ein Webform mit Parametern aus einer URL beim Aufruf zu befüllen, z.B. ein Kontaktformular bei dem man die Empfängerabteilung voreinstellt, kann manchmal sehr nützlich sein. Wie es geht zeigen wir im folgenden Beitrag.


Der Anwendungsfall: Auf einer Webseite gibt es ein Kontaktformular in dem die Besucher auswählen können, mit welcher Abteilung sie Kontakt aufnehmen möchten, z.B. Einkauf, Vertrieb, Buchhaltung, Support. Dann gibt es auf der Seite verschiedene Unterbereiche für die einzelnen Abteilungen. Hier soll es jeweils einen Link zum Kontaktformular geben, bei dessen Aufruf die Abteilung, aus deren Bereich man gerade kommt, bereits mit dem Abteilungsschlüssel vorbelegt ist. Wenn der Besucher also im Bereich "Support" der Website auf einen Kontakt-Link klickt kommt er auf das Kontaktformular, wo das Ziel "Support" bereits voreingestellt ist.


Dazu legen wir ein neues Webform an, in dem wir zunächst die üblichen Felder anlengen, z.B. Name, Mailadresse, Betreff, Nachricht usw. Zusätzlich legen wir ein Options-Auswahlfeld an und stellen dieses auf Listenansicht ein. Wir nenen das Feld "Ihren Ansprechpartner auswählen" mit dem Feld-Key "ihr_ansprechpartner".  In den Feldeinstellungen tragen wir unter "Optionen" dann die Schlüssel-Werte-Paare für die oben aufgeführten Abteilungen ein und im Feld "Standardwert" den Wert "[current-page:query:service_name]" ein. Hierbei ist "service_name" ein von uns gewählter Schlüssel, der später in der URL für den Aufruf des Webforms verwendet wird. Der Teil "[current-page:query:]" ist ein im Webform verfügbares Token. Das ganze sieht dann so aus:



Jetzt tragen wir noch die E-Mail-Adressen ein, die mit den jeweiligen Abteilungen verknüpft werden sollen. Die geschieht wie gewohnt unter "Webform >> E-Mails". Unter "Component value" wählen wir unser Feld "Ihren Ansprechpartner auswählen" und klicken anschließend auf "Hinzufügen".



Auf der nächsten Seite tragen wir für jeden Schlüsselwert die gewünschte Ziel-Mailadresse ein, also für "Support" support@example.com, für "Buchhaltung" buchhaltung@example.com usw.


Anschließend speichern wir alles und testen unser Formular, um zu sehen, ob alles wie gewünscht funktioniert.


Um das Formular jetzt mit einem vorbelegten Wert für "Ihren Ansprechpartner auswählen" aufzurufen, müssen wir die URL des Aufrufs mit dem oben eingetragenen Key "service_name" und dem jeweiligen Optionskey für die Abteilung aufrufen. Für die Abteilung Support sieht die URL dann so aus:


http://example.com/kontaktformular?service_name=support


Hierbei ist kontaktformular unser URL-Alias für das Kontaktformular und example.com unsere Domain. Hinter dem "?" kommt dann unser Schlüssel aus dem Feld "Standardwert" des Webforms und nach dem "=" der Optionskey der Abteilung.


Fertig. Der Aufruf der URL öffnet nun das Formular mit vorbelegten Feld "Ihren Ansprechpartner auswählen".


Die Möglichkeit mit Hilfe des CK-Editors auf seiner Webseite beim Schreiben eines Beitrages einen Zeichensatz auszuwählen ist eher die Ausnahme. Meistens wird im Template festgelegt welche Textteile in welchem Zeichensatz dargestellt werden. Aber es gibt durchaus Fälle, wo es erwünscht ist, dass beim Bearbeiten eines Beitrages ein anderer Font gewählt werden kann. Dazu genügt es nicht, wenn man in der Konfiguration des CK-Editors (unter admin/config/content/ckeditor/edit/) die Schaltfläche für die Fontauswahl aktiviert. Zusätzlich muss man CK-Editor mitteilen, welche Fonts überhaupt verfügbar sind. Dies geschieht durch einen Eintrag in dem Profil, das diese Fonts nutzen soll (in der Regel wird es zumindest das Profil für "FullHTML" sein. Dazu öffnet man das Profil zum Bearbeiten und geht ganz nach unten auf "Erweiterte Optionen". Dort trägt man im Feld "Angepasste JavaScript-Konfiguration" die Variable config.font_names ein und gibt ihr die Werte für die Fonts mit, so wie sie im Theme im CSS definiert sind.

Hier ein Beispiel mit dem vier Zeichensätze eingebunden werden, die anschließend in der Font-Auswahlbox des CK-Editors zur Verfügung stehen:

Beispiel für die Einbindung von Fonts in die Fontauswahl von CK-Editor

Die Fonts-Definition erfolgt in unserem Beispiel in der Datei ./sites/all/themes/mytheme/css/mytheme.styles.css und sieht so aus

 

/* Google-Font importieren
@import url(https://fonts.googleapis.com/css?family=Roboto+Condensed:300,400,700|Roboto:300,400,700);
 
/**
 * auf dem Server installierte Fonts einbinden
 * $FONT-FACE
 */
@font-face {
  font-family: "TheAntiquaB Semilight";
  src: url("../fonts/TheAntiquaB-W4SemiLight.otf"); }
@font-face {
  font-family: "TheAntiquaB LT";
  src: url("../fonts/TheAntiquaB_LT_400.eot");
  src: url("../fonts/TheAntiquaB_LT_400.eot?#iefix") format("embedded-opentype"), url("../fonts/TheAntiquaB_LT_400.woff") format("woff"), url("../fonts/TheAntiquaB_LT_400.svg#TheAntiquaB_LT_400") format("svg");
  font-weight: normal;
  font-style: normal; }
 
usw. ;-)

Letztens trat ein kurioser Fehler beim Installieren einer neuen Drupal7-Website auf. Die "lesbaren URLs" unter admin/config/search/clean-urls ließen sich nicht aktivieren. Beim Prüfen kam jedesmal die Fehlermeldung "Clean URL test failed" und die Checkbox zum Einschalten erschien nicht. Normalerweise liegt dies an Problemen mit der Serverkonfiguration weil das Rewrite-Modul des Apache-Webservers nicht aktiviert ist oder an einer fehlerhaften .htaccess. Diese Fehler konnten wir hier ausschließen, da auf dem Server bereits andere Drupal-Installationen problemlos liefen. Dementsprechend führten auch das Setzen von RewriteBase in der .htaccess und $base_url in der Drupal setttings.php nicht zum gewünschten Ergebnis.

Nach einiger Recherche stellte sich heraus, dass dieser Fehler gelegentlich auftritt, obwohl alles korrekt konfiguriert ist. Abhilfe schafft in diesem Fall das Entfernen von "?q=" aus der URL

[your-site-url]/?q=admin/config/search/clean-urls

Diese sollte nun so aussehen:

[your-site-url]/admin/config/search/clean-urls

Jetzt einmal Enter drücken und wenn die Server-Konfiguration korrekt ist, erscheint die Checkbox und man kann die "lesbarern URLs" einschalten.

Warum es sinnvoll ist, seine Webseite auf SSL umzustellen, hatten wir in unserem letzten Blogbeitrag beschrieben.


Wie das bei einer Drupal-Webseite geht, erklären wir im Folgenden.


Als erstes besorgt man sich ein SSL-Zertifikat für zu sichernde Domain und installiert dieses auf dem Webhosting-Account auf dem die Webseite läuft. Wie das geht ist von Provider zu Provider verschieden, so dass wir hier nicht näher darauf eingehen. Sobald das Zertifikat installiert ist, können wir die Drupal-Konfiguration anpassen.


Zunächst ändern wir die Datei settings.php im Unterordner ../sites/default/. Hier tragen wir am Ende der Datei die Zeile


 $_SERVER['HTTPS'] = 'on';


ein.


Falls auch ein Wert für $base_url gesetzt wurde, so stellen wir diesen auf https um. Das sieht dann beispielsweise so aus:


 $base_url = "https://www.example.com" // NO trailing slash!


Jetzt speichern wir die settings.php ab. Bitte nicht vergessen den Schreibschutz wieder zu setzen!


Jetzt müssen wir noch die .htaccess anpassen. Hier ergänzen wir nach dem Eintrag


 RewriteEngine on


diese beiden Zeilen:


 RewriteCond %{HTTP_HOST} !^meine-domain\.de$ [NC,OR] RewriteCond %{HTTPS} =off RewriteRule ^(.*)$ https://meine-domain.de/$1 [R=301,L]


Im folgenden Abschnitt entfernen wir die Kommentarzeichen der Rewrite-Regel:


 RewriteRule ^ - [E=protossl] RewriteCond %{HTTPS} on RewriteRule ^ - [E=protossl:s]


Zum Abschluss speichern wir die .htacces noch ab und unsere Webseite läuft ab sofort SSL-gesichert. Außerdem werden Aufrufe der Seite mit dem ungesicherten http auf https umgeschrieben.


Piwik umstellen


Wer zum Tracken seiner Seitenbesucher Piwik benutzt, muss noch eine Änderung im Piwik-Modul vornehmen: In den Modul-Einstellungen muss im Feld "Piwik HTTPS URL" die URL zur Piwik-Installation mit https eingetragen werden. Falls diese auf einer anderen Domain läuft, als unsere Drupal-Webseite muss auch auf dieser ein SSL-Zertifikat installiert werden!


Anschließend läuft das Tracking der Webseite mit Piwik wie gewohnt weiter.

Für Unternehmen gibt es mehrere Gründe, warum sie ihre Webseiten verschlüsselt ausliefern sollten. Werden sensible Daten wie z.B. Passwörter oder Bankdaten auf der Seite abgefragt, sollte eine Verschlüsselung bei der Übertragung selbstverständlich sein.

Darüber hinaus liefert Google weitere Argumente für die Nutzung von SSL-Verschlüsselung: So sollen Webseiten mit aktiver Verschlüsselung (erkennbar an dem "https" in der URL) im Ranking bevorzugt behandelt werden. Auch wenn der Faktor HTTPS zur Zeit wohl nur sehr gering im Rankingalgorithmus gewichtet ist, sollte man ihn beachten. Zumal nicht auszuschließen ist, dass er künftig an Gewicht zunimmt.

Einen weiterern Grund für Verschlüsselung liefert der Chrome-Browser. Ab Januar 2017 wird Chrome Nutzer davor warnen, wenn eine Webseite ein Passwort oder Kreditkarteninformationen über eine unverschlüsselte Website übertragen soll. Verfügbar ist diese Funktion ab der Chrome-Version 56. Dabei handelt nach Angaben von Google nur um einen ersten Schritt. Später soll der Browser auch an anderen Stellen vor unverschlüsselten Webseiten warnen.

Die jährlichen Kosten für ein SSL-Zertifikat sind überschauber. Let’s Encrypt bietet ein einfaches Domain-Validation-Zertifikat sogar kostenlos an. Aber auch kommerzielle Zertifikate bekommt bereits für unter 40€ im Jahr.

Ab sofort steht für alle Webhosting-Accounts auch die PHP-Version 7 zur Verfügung.

Hierbei handelt es sich um eine neue Hauptversion,die viele Neuerungen und einige Leistungssteigerungen mitbringt. So verringern sich die Zugriffszeiten zum Teil deutlich. Darüber hinaus wird 64-Bit ab sofort konsequent unterstützt. Außerdem haben die Entwickler Probleme der vorherigen Version behoben.

Vor einer Umstellung auf die neue PHP-Version empfiehlt es sich unbedingt zu prüfen, ob die eingesetzte CMS-Software bereits mit dieser Version zusammenarbeitet. Andernfalls kann es zu Störungen oder dem Ausfall Ihrer Webseite kommen. Gerne beraten wir Sie ob eine Umstellung für Sie machbar ist.

Selbstverständlich stehen die älteren Versionen von PHP auch weiterhin zur Verfügung. Derzeit kann zwischen den Versionen PHP4, 5.2, 5.3, 5.4, 5.5, 5.6 und 7 gewählt werden.