Service-Themen

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.

Gut acht Jahre nach dem Erscheinen von Drupal 6 hat dieses nun mit der Freigabe der stabilen Version von Drupal 8 sein "End-of-Life" erreicht. Nachdem wir mit mehreren unserer Kunden darüber diskutiert haben, was dies für ihre Webseiten bedeutet, möchten hier einen Überblick über die aktuelle Situation und mögliche Optionen geben.

Das neue Drupal 8

Mit dem aktuellen Erscheinen von Drupal 8 endet der offizielle Support für Drupal 6. Das bedeutet, 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 Drupal 6 offiziell nicht länger unterstützt, upgedated oder dokumentiert werden.

Man ist also bei einer Drupal 6-Seite darauf angewiesen, dass man noch Unterstützung in der Community findet.

Für alle, die derzeit Drupal 6 einsetzen,bedeutet dies, dass es unbedingt erforderlich ist, sich Gedanken über die Zukunft der Webseite zu machen. Dabei stellen sich vor allem folgende Fragen:

  • Reicht es aus, die Sicherheit der Seite, durch zusätzliche Maßnahmen zu verbessern?

  • Ist ein Upgrade auf eine neuere Drupal-Version erforderlich?

  • Welches ist die bessere Wahl bei einem Upgrade, Drupal7 oder Drupal 8?

Viele Faktoren spielen bei der Beantwortung dieser Fragen eine Rolle. Besitzt die Webseite komplexe Funktionen, die ggf. durch speziell programmierte, eigene Module realisiert wurden? Wieviele Module müssen upgegradet werden? Ist es schwierig oder eher einfach, das verwendete Theme upzugraden oder muss ein neues verwendet werden, damit die Seite beispielsweise für Mobilgeräte optimiert wird?

In den meisten Fällen empfiehlt es sich, zunächst einmal einen Schritt zurück zu gehen und die bestehende Drupal-Webseite zu bewerten: Erfüllt sie noch alle Anforderungen, die man aktuell an seine Seite stellen würde? Nicht selten ist ein einfaches Upgrade nicht ausreichend und ein umfangreicheres Redesign empfehlenswert. Falls dieses ohnehin schon angedacht wurde, ist es kostengünstiger, dieses mit dem Upgrade zu verbinden.

Soll ich meine Webseite auf Drupal 7 oder Drupal 8 upgraden?

Auch wenn das neue Drupal 8 mit vielen neuen Funktionen glänzt, die bisher nicht oder nur durch Dritt-Module realisierbar waren, ist in vielen Fällen immer noch Drupal 7 das System der Wahl.

Zum einen handelt es sich um eine ausgereifte Software, für die es viele Dritt-Module als Erweiterungen gibt, mit denen man sehr viele Anforderungen realisieren kann, ohne eigenen Programmcode schreiben zu müssen. So kurze Zeit nach dem Erscheinen der neuen Drupal-Version stehen viele dieser Module noch gar nicht für Drupal 8 zur Verfügung. Erfahrungsgemäß kann es noch weitere 6 bis 12 Monate dauern, bis sich diese Situation entscheidend verbessert hat.

Zum anderen kann man damit rechnen, dass Drupal 7 noch weitere 4 Jahre oder (wahrscheinlich) länger supportet wird.

Ausschlaggebend für die Entscheidung, ob ein Upgrade auf Drupal 7 oder Drupal 8 erfolgen sollte, ist die Bewertung der Situation bei den eingesetzten Dritt-Modulen. Dabei sollte auch die Struktur der Inhalte analysiert werden. Häufig bietet es sich an, bei einem Upgrade die Inhaltestruktur zu vereinfachen. Dies kann auch zu einer Vereinfachung der redaktionellen Arbeiten führen.

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

Eine Drupal 6-Webseite ist in der Regel mindestens 5 Jahre alt. 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 hat. Hier sollte zumindest geprüft werden, ob man z.B. das Login-Formular stärker absichern kann oder potenziell sicherheitsrelevante Funktionen (wie Kommentare) ganz abschaltet.

Zu weiteren Schwierigkeiten kann es mit der Hosting-Umgebung bei verschiedenen Anbietern kommen. In diesem Fall kann zumindest vorübergehend Abhilfe durch die Wahl spezieller Hosting-Accounts oder einen Anbieterwechsel geschaffen werden.

Durch diese Maßnahmen läßt unter Umständen Zeit gewinnen, bis ein Budget für ein Upgrade zur Verfügung steht.

Gelingt dies nicht, sollte man die Zukunft seiner Seite nicht aus den Augen verlieren und notfalls ein Downgrading der Webseite zu einer statischen Seite oder einen Wechsel des CMS in Betracht ziehen.

Macht ein Upgrade meiner Drupal 7 Webseite auf Drupal 8 Sinn?

Da Drupal 7 noch auf Jahre hinaus supportet wird und viele neue Funktionen für Drupal 8 auf die Version 7 zurück portiert werden, ist derzeit ein Wechsel auf Drupal 8 nicht empfehlenswert. Eine Ausnahme kann sich ergeben, wenn ohnehin ein umfassender Relaunch der Seite angedacht ist. Dann sollte man die Option eines Upgrades zumindest prüfen, da das Upgrade die Lebensdauer der Seite erheblich verlängert und die Kosten u.U. geringer sind, als wenn später ein eigenständiges Upgrade erfolgt.

Womit sollte ich eine neue Webseite aufbauen?

Wenn eine völlig neue Seite geplant ist, sollte Drupal 8 gewählt werden, sofern die Anforderungen mit dieser Version und den derzeit verfügbaren Dritt-Modulen realisierbar ist. Ist dies nicht der Fall und sind die fehlenden Funktionen kritisch, empfiehlt sich in der Regel der Einsatz von Drupal 7. Zwar lassen sich fehlende Funktionen durch eigenen Programmcode nachrüsten. Die Kosten hierfür sind aber um ein Vielfaches höher, als wenn vorhandene Module zum Einsatz kommen, die nur konfiguriert werden müssen. Die längere Lebensdauer einer Drupal 8 Installation muss dabei natürlich mit einkalkuliert werden.

Fazit

Wer derzeit noch eine Webseite mit Drupal 6 betreibt sollte unbedingt die Zukunft seiner Seite planen. Momentan ist der Handlungsbedarf aber noch nicht dringend. Dies wird sich jedoch im Laufe der Zeit ändern, da die Anzahl der Drupal 6 Seiten im Einsatz ebenso abnehmen wird wie die Bereitschaft der Community, für dieses System oder die dazugehörigen Dritt-Module noch Support zu leisten.

Mit dem heutigen Tag stellt Microsoft den Support für die Internet Explorer-Versionen 8, 9 und 10 ein. Künftig gibt es Sicherheitsupdates nur noch für die Version 11. Wir empfehlen daher allen unseren Kunden, die den Internet Explorer nutzen, zu überprüfen, welche Version sie im Einsatz haben und umgehend auf die aktuelle Version 11 upzugraden. Weitere Informationen hierzu findet man auf der Webseite von Microsoft unter https://www.microsoft.com/de-de/WindowsForBusiness/End-of-IE-support

Ab sofort können viele weitere interessante Top-Level-Domains (TLDs) bestellt werden. Hier eine kleine Auswahl der neuen Domains. Hier finden Sie die vollständige Liste aller derzeit registrierbaren Domains.

  • .download
  • .win
  • .online
  • .tech
  • .news
  • .co
  • .plus
  • .one
  • .style
  • .casino
  • .ngo
  • .design
  • .money
  • .science
  • .nrw
  • .coach

Ab sofort steht für alle Webhosting-Accounts auch die neueste PHP-Version 5.6 zur Verfügung. Neben den üblichen Bugfixes und Verbesserungen gibt es eine Reihe wichtiger Sicherheitsupdates.

Zusätzlich ist ab sofort die User-Cache-Extension APCu für PHP 5.5 und PHP 5.6 erhältlich. 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 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 und 5.6 gewählt werden.