OXID 6 im Managed Hosting mit Composer installieren

Falls noch nicht geschehen installieren Sie zuerst Composer mit PHP 7.1.x.

Eine Anleitung finden Sie hier. Bitte beachten sie die Hinweise zur Installation mit PHP 7.1.x.

OXID6 Installation mit Composer

Legen Sie das Installationsverzeichnis für OXID6 an. (Hier im Beispiel: ~/webseiten/oxid6)

Im Terminal:

mkdir ~/webseiten/oxid6

Sie müssen ggf. die Rechte für das neue Verzeichnis korrigieren:

chmod 750 -R ~/webseiten/oxid6

Alternativ können Sie diese Arbeiten auch mit dem Dateimanager in Ihrem Kundenbackend vornehmen.

Wenn Sie Composer nach der oben genannten Anleitung installiert haben können Sie nun die Installation im Terminal mit dem einfachen Befehl:

composer create-project --no-dev oxid-esales/oxideshop-project your_project_name dev-b-6.0-ce

vornehmen. Den Ausdruck „your_project_name“ bezeichnet dabei das soeben erstellte OXID6-Installationsverzeichnis.
In meinem Beispiel würde die Installation also mit folgendem Befehl gestartet werden:

composer create-project --no-dev oxid-esales/oxideshop-project ~/webseiten/oxid6/ dev-b-6.0-ce

Jetzt werden zwei Verzeichnisse in /oxid6/ installiert:

  • source
  • vendor

Es müssen noch einige Rechte (777) im Verzeichnis /source korrigiert werden:

  • source/config.inc.php
  • source/.htaccess
  • source/tmp/
  • source/log/
  • source/out/pictures/
  • source/out/media/
  • source/export

Das können Sie entweder über den Dateimanager oder über das Terminal erledigen

chmod 777 -R ~/webseiten/oxid6/source/config.inc.php ~/webseiten/oxid6/source/.htaccess ~/webseiten/oxid6/source/tmp/ ~/webseiten/oxid6/source/log/ ~/webseiten/oxid6/source/out/pictures/ ~/webseiten/oxid6/source/out/media/ ~/webseiten/oxid6/source/export

Richten Sie den Domainpfad in das Verzeichnis „source“ ein.

(hier im Beispiel also: /webseiten/oxid6/source)

Rufen Sie dann die Installationsroutine auf:

  • http://www.ihre_domain.tld/Setup

und lassen sich durch die Installation leiten.

Contao 4.4.12 mit Composer installieren

Composer installieren

Composer muss in dem jeweiligen Kundenaccount installiert werden.

Eine Anleitung für die Composer-Installation finden Sie hier.

Wenn Sie die oben stehende Installation von Composer durchgeführt haben sollte Composer jetzt ohne große PHP-Versionsangaben aufrufbar sein.

Contao installieren

Zuerst ein wichtiger Hinweis (Aufgrund eigener Erfahrung):

Verwenden Sie als PHP-Version PHP 7.0.x.
Die Installation mit PHP 7.1.x (natürlich mit Anpassung der PHP-Parameter) ist in unseren Tests fehlgeschlagen.
Allerdings lässt sich Contao 4.5.x mit PHP 7.0.x nicht installieren, es wird automatisch auf Contao 4.4.12 zurüchgegriffen.

Was brauchen Sie für die Installation:

  • ein Installationsverzeichnis: hier im Beispiel /webseiten/contaodemo
  • eine Datenbank
  • einen SSH-Zugang

Haben Sie Composer gemäß der oben genannten Anleitung installiert, reicht ein einfacher Befehl im Terminal, um Contao zu laden und zu installieren:

composer create-project contao/managed-edition <Zielverzeichnis>

Hier im Beispiel:

composer create-project contao/managed-edition $HOME/webseiten/contaodemo/

Sollte das Zielverzeichnis (hier contaodemo) nicht existieren, wird es automatisch angelegt.

In dieses Verzeichnis werden mehrere Dateien und Verzeichnisse installiert, unter anderem das Verzeichnis „web“. Richten Sie den Domainpfad auf dieses Verzeichnis ein.

Für die abschließende Installation rufen Sie die Domain mit dem Anhang „/contao/install“ auf und lassen sich durch die Installation leiten.

http://contao.gn2-demo.de/contao/install

Vergeben Sie ein Installationspasswort um unberechtigte Zugriffe zu verhindern.

Richten Sie die Datenbank ein…

…und legen ein Administratorkonto an.

Verschlüsselung von MySQL-Passwörtern ab Februar 2018

MySQL-Passwörter werden in Zukunft nur noch verschlüsselt in unseren Systemen hinterlegt, hierdurch können diese im Kundenbackend nicht mehr angezeigt werden.

Vergleichbar zu der Funktionalität bei Mailpassworten stellen wir im Kundenbackend eine Funktion zur Überprüfung des Passwortes zur Verfügung, bei Bedarf kann natürlich jederzeit ein neues Passwort gesetzt werden.

 

Die Änderungen im Frontend mit den neuen Verfahren zur Anlage und Editierung von Datenbanken erfolgen am 06.02.2018 um ca. 8:00 Uhr, die endgültige Verschlüsselung erfolgt am 07.02.2018 um ca. 8:00 Uhr.

Umstellung zur Nutzung von SNI bei Bestellung neuer SSL-Zertifikate

Ab dieser Woche werden wir bei Neubestellungen von SSL-Zertifikaten SNI einsetzen, was die Vergabe eigener IPv4-Adressen für diese nicht mehr notwendig macht. Hiermit möchten wir verantwortungsvoll mit der immer knapperen Ressource IPv4-Adresse umgehen. Diese Änderung gilt nur für neue Zertifikate. Laufende und durch Sie verlängerte Zertifikate sind davon nicht betroffen. Sie behalten die vorhandenen IPv4-Adressen, damit sich für Sie keine ggf. notwendigen Änderungen ergeben.

Gerne möchten wir nachfolgend noch weitere Details dazu ausführen, um Sie genau über die Änderung zu informieren.

Wie war der bisherige Hintergrund bezüglich der Notwendigkeit eigener IPv4-Adressen bei SSL-Zertifikaten?

Um als Nutzer die Authentizität einer Webseite im Internet zu überprüfen, verwendet man in der Regel digitale Zertifikate. Da der verschlüsselte Verbindungsaufbau zum Server bereits stattfindet, bevor die angefragte URL übertragen wird, ist es mit TLS-1.0/SSL-Verschlüsselung nicht möglich, mehrere Domains unter einer IP-Adresse zu nutzen (sogenanntes Virtual Hosting). Grund für diese Einschränkung ist, dass der Server bei mehreren Zertifikaten nicht weiß, welches Zertifikat, das meist nur für eine Domain gilt, er benutzen müsste. Zum Zeitpunkt der Spezifikation von SSL/TLS wurde die Möglichkeit von Virtual Hosting nicht vorgesehen.

Was ist SNI und wie funktioniert es fortan?

Server Name Indication (SNI) ist eine Erweiterung des Standards Transport Layer Security (TLS), die es ermöglicht, dass sich mehrere verschlüsselt abrufbare Websites unterschiedlicher Domains einen Server auf dem TLS Port 443 teilen, auch wenn dieser nur eine IP-Adresse besitzt. Beim Aufbau einer TLS-Verbindung fordert der Client, der die Verbindung aufgebaut hat, vom Server ein digitales Zertifikat an, welches für die Verschlüsselung der Verbindung benötigt wird. Der Server sendet standardmäßig das mit seiner IP-Adresse verbundene Zertifikat zurück. Um unter einer IP-Adresse aber einen Server für verschiedene Hosts mit verschiedenen Zertifikaten zu betreiben, ist es erforderlich, dass der Client dem Server den gewünschten Host vor der Übermittlung des Zertifikats, also bevor über die Verbindung ein verschlüsselter Kanal aufgebaut wurde, mitteilt. SNI ist eine Erweiterung von TLS, die es dem Client erlaubt, diese Information unverschlüsselt zu übertragen.

Wie lief eine Bestellung eines SSL-Zertifikats bisher bei uns ab?

  1. Sie bestellten bei uns ein SSL-Zertifikat für Domain www.domain.tld im Kundenmenü.
  2. Wir nahmen die Bestellung an und kümmerten uns um die Bereitstellung durch unsere Partner.
  3. Wir oder Sie als Kunde bekamen abhängig vom gewählten Zertifikatstyp eine Aufforderung zur Validierung der Bestellung mittels Approver-E-Mail oder DNS-Approval.
  4. Nach erfolgreicher Validierung bekamen wir von unseren Partnern das neue Zertifikat zugesandt.
  5. Falls das Zertifikat direkt aus Ihrem Webserver bei uns gehostet werden sollte, benötigte es nun eine neue IPv4-Adresse.
  6. Auf dem betroffenen Webserver aktivierten wir die IPv4-Adresse und passten die Konfiguration des Webservers an.
  7. Wir erstellen für die betroffenen Sub-Domains entsprechende Nameserver A-Einträge, die auf die neue IPv4 Adresse verwaisten.
  8. Das Zertifikat wurde in Rechnung gestellt.

Wie läuft zukünftig eine Bestellung eines SSL-Zertifikats ab?

Schritt 1-4 bleiben gleich!

  1. Sie bestellen bei uns ein SSL-Zertifikat für Domain www.domain.tld im Kundenmenü.
  2. Wir nehmen die Bestellung an und kümmern uns um die Bereitstellung durch unsere Partner.
  3. Wir oder Sie als Kunde bekommen abhängig vom gewählten Zertifikatstyp eine Aufforderung zur Validierung der Bestellung mittels Approver-E-Mail oder DNS-Approval.
  4. Nach erfolgreicher Validierung bekommen wir von unseren Partnern das neue Zertifikat zugesandt.
  5. Auf dem Webserver wird die Konfiguration so angepasst, das Aufrufe auf (www.)domain.tld ein SSL-Zertifikat verwenden. Falls es nicht bei uns gehostet werden soll, stellten wir es im Kundenmenü zum Download bereit.
  6. Grundsätzlich müssen wir nun keine eigenen Nameserver A-Einträge mehr erstellen, da ‚domain.tld‘ und ‚*.domain.tld‘ schon auf den jeweiligen Webserver (Ziel ‚auto‘) zeigen. Sollte dies in Ausnahmefällen nicht so sein, wird ein neuer A-Record mit Ziel ‚auto‘ erstellt.
  7. Das Zertifikat wird in Rechnung gestellt.

Was ändert sich für Sie als Kunde?

Von den nachfolgenden Änderungen sind nur neu bestellte SSL-Zertifikate betroffen:

  • Da das Zertifikat nun über die IP des Webservers aufgerufen wird und jeder Webserver bei uns auch eine IPv6 -Adresse hat, können die neuen Zertifikate direkt über IPv6 aufgerufen werden.
  • In der SSL-Zertifikatsübersicht im Kundenmenü zeigen wir die IP des betroffenen Webservers an.
  • Sie sehen bei den Nameservereinträgen zur jeweiligen Domain für das neue SSL-Zertifikat keinen zusätzlichen Nameserver-Eintrag mehr.

Weiterführende technische Erklärungen zu SNI: https://de.wikipedia.org/wiki/Server_Name_Indication

Mehr Performance durch APCu für PHP7

Ab sofort stellen wir APCu als vorkompiliertes Modul für PHP7 unter folgenden Pfaden zur Verfügung:

 /usr/local/lib/php_modules/7-70LEGACY/apcu.so
 /usr/local/lib/php_modules/7-70STABLE/apcu.so
 /usr/local/lib/php_modules/7-70LATEST/apcu.so
 /usr/local/lib/php_modules/7-71STABLE/apcu.so
 /usr/local/lib/php_modules/7-71LATEST/apcu.so

Wie man vorkompilierte Module einbindet, haben wir in unserer FAQ beschrieben.

Content-Builder für WordPress Teil 2: Der Visual Composer

Der Visual Composer von WPBakery wird in diesem Beispiel im Paket des Themes Savoy verwendet.

Im Grunde funktionieren alle Content Builder gleich. Die Begriffe bzw. die Anzahl der einzelnen Features können sich unterscheiden.

Wie schon im ersten Teil geschrieben, braucht man für diese Tools eine Einarbeitung- und Experimentierphase – und ggf. mehrere WordPress-Installationen zum testen.

Visual Composer ist aber nicht Divi ein Theme sondern ein Plugin das auch eigenständig erworben werden kann. Visual Composer kann in jedem Theme eingesetzt werden. Es gibt aber auch Themes in die Visual Composer schon direkt eingebaut ist.
Bei diesen Bundles ist der Funktionsumfang von Visual Composer an das Theme angepasst und kann sich von dem des „reinen“ Plugins unterscheiden.
Beim Start solcher Bundles kann es auch sein, dass gleich noch eine ganze Reihe an weiteren Plugins gewünscht werden, die aber für den grundsätzlichen Einsatz nicht unbedingt notwendig sind.

Wie bei Divi auch, ist man beim Einsatz von Visual Composer an daran gebunden. Ein Wechsel auf ein anderes Theme kann unter Umständen nicht klappen, da der Content durch Visual Composer kontrolliert wird und nicht mehr „standardkonform“ abgelegt wird.

Wie funktioniert Visual Composer?

Beim Visual Composer – wie auch bei Divi – wird die Seite in einer Struktur angelegt.

Beim Visual Composer wird diese Struktur in folgender Reihenfolge angelegt:

  • Page-Settings,
  • Zeilen-Settings (inc. Spalten)
  • Elemente (die eigentlichen Tools)

Bei Visual Composer können die Elemente direkt auf der Seite platziert werden, die übergeordneten Settings werden dann automatisch dazu eingerichtet.

Die einzelnen Bausteine können durch Verschieben neu angeordnet werden und auch bei Visual Composer gibt es einen Front-End-Editor, hier WPBakery Page Builder genannt.
In meinen Tests gab es allerdings einige interessante optische Effekte beim Einsatz des Front-End-Editors.

Bei Divi werden alle Einstellungen und Daten direkt in den eingesetzten Modulen eingegeben und verwaltet. Bei Visual Composer müssen einige Elemente mit anderen kombiniert werden. So werden z.B. beim Element Akkordion die Inhalte über zusätzlich eingefügte Textbereiche (normalerweise ein eigenes Element) realisiert.

Visual Composer bietet, wie Divi, die Möglichkeit Seitenvorlagen selber zu erstellen oder auf fertige Vorlagen zurückzugreifen.

Vor- und Nachteile

Wie bei Divi gibt es auch bei Visual Composer gute Gründe für aber auch gegen den Einsatz.

Vorteile:

  • geringere Entwicklungszeit
  • geringere Entwicklungskosten
  • großer Funktionsumfang…
  • …der durch Zukauf von Plugins noch erweiterbar ist
  • Änderungen und Korrekturen können direkt im Seitenlayout vorgenommen werden.
  • vielseitig einsetzbar
  • als Plugin nicht an ein Theme gebunden
  • Import von Seiten-Vorlagen
  • Erstellen eigener Seiten-Vorlagen
  • Responsives Design

Nachteile:

  • Lernkurve, Einarbeitungszeit
  • komplexes System
  • Bindung an das Tool, Content wird anders abgespeichert und kann nicht mehr über den Standard-Editor bearbeitet werden
  • Visual Composer ist kostenpflichtig
  • Overhead: Ladezeit der Seite

Brute-Force-Attacken auf WordPress-Instanzen

Aufgrund einer sehr hohen Anzahl von Brute-Force-Attacken auf WordPress-Instanzen, wie auch bereits durch heise Security berichtet, wurde soeben durch die technische Abteilung eine sicherheitsrelevante Änderung für unsere SharedHosting und ManagedServer durchgeführt. Somit erfolgt nach 10 fehlerhaften Logins innerhalb von 3 Minuten eine Sperrung der IP-Adresse für 5 Minuten. Der Apache sendet hierbei den Fehlercode 429, was für Sie im Errorlog (CGI-Debugger) ersichtlich ist.

Diese sicherheitsrelevante Änderung war hierbei zwingend notwendig, um die Systemstabilität der Server nicht zu beeinträchtigen.

Content-Builder für WordPress Teil1: Der Divi-Builder

Was ist ein Content-Editor?

Ein Content-Editor bietet mir viele Erweiterungen zusätzlich zum WordPress-Standard-Editor, sogenannte Module.

Ok, um mit so einem Tool effektiv arbeiten zu können braucht es etwas Zeit, aber danach lassen sich Webseiten mit geringer Entwicklungszeit  – und damit auch mit geringen Kosten – erstellen.

Am Besten, man macht eine WordPress-Testinstallation (oder mehrere), probiert erstmal mit Divi rum, testet alle möglichen Module durch und lernt so die Eigenarten von Divi kennen.

Wie funktioniert Divi?

Bei Divi heißen die Werkzeuge in Reihenfolge: Sektion, Zeile, Spalte, Modul.

Zuerst muss eine Sektion angelegt werden. Jede Sektion beinhaltet mindestens eine Zeile (die auch mehrzeilig seien können) und jede Zeile mindestens eine Spalte.
In diese Spalte(n) werden die Module eingebettet.

Die Module sind die eigentlichen Funktionsträger. Jedes Modul hat verschiedensten Parameter, die sich allerdings auch untereinander beißen können.

Die Optik der Seite unterscheidet sich im Backend erheblich vom Standard-Editor.
Hier wird der strukturelle Aufbau gezeigt, nicht der Inhalt. Den Inhalt sieht man erst, wenn man die Module bearbeitet.

Das Spannende ist jetzt, dass die Module, die Zeilen und die Sektionen untereinander verschoben werden können und so die Seite schnell neu strukturiert werden kann. Copy-Paste-Orgien sind hier überflüssig.

Schaut man sich gerade die eigentliche Seite an und findet doch noch etwas zum Ändern, dann gibt es dort den Visuellen Builder. Ist dieses Tool aktiviert, hat man die gleichen Möglichkeiten wie im Backend. Schnelle Textkorrekturen sind möglich, aber auch komplexere Umbauarbeiten sind machbar.

Obendrein kann man auf Seiten-Vorlagen zurück greifen und so schon mal ein Gerüst aufbauen, oder selber ein Seiten-Gerüst als Vorlage abspeichern.

 

 

Vor- und Nachteile

Vorteile:

  • geringere Entwicklungszeit
  • geringere Entwicklungskosten
  • großer Funktionsumfang
  • Änderungen und Korrekturen können direkt im Seitenlayout vorgenommen werden.
  • vielseitig einsetzbar
  • Import von Seiten-Vorlagen
  • Erstellen eigener Seiten-Vorlagen
  • Responsives Design

Nachteile:

  • Lernkurve, Einarbeitungszeit
  • komplexes System
  • Bindung an das Tool, Content wird anders abgespeichert und kann nicht mehr über den Standard-Editor bearbeitet werden
  • Divi ist kostenpflichtig
  • Overhead: Ladezeit der Seite