WooCommerce #1 – Installation und technische Vorraussetzungen

Warum Woocommerce? Es gibt doch genug Shopsysteme

Stimmt, es gibt zahlreiche große Shopsysteme für den Einsatz im e-Commerce. Diese Systeme sind genau für diesen Einsatz gebaut und sehr leistungsstark. Ein Shopsystem aufzusetzen und korrekt einzurichten ist aber kein Kinderspiel und es bedarf einiger Arbeit und vor allem auch Know How bevor es überhaupt losgehen kann. Wenn eine externe Agentur damit beauftragt wird, ist gibt es auch noch eine hohe Anfangsinvestition nötig.

Für jemanden, der erst mit dem eCommerce beginnen möchte oder nur einen kleinen Onlinehandel nebenher betreibt ist das vielleicht eine zu große und abschreckende Hürde.

WooCommerce bietet hier eine einfache Alternative. Als WordPress-Plugin kann man den Shop z.B. in die eigene bestehende Seite integrieren oder man installiert sich einfach ein frisches WordPress für den geplanten Shop und bindet das WooCommerce-Plugin danach ein.

Woocommerce ist leicht aufzusetzen und erleichtert einem die ersten Schritte in eCommerce. Dabei ist das System kein Spielzeug. Woocommerce bietet jede Menge sehr cleverer Features und Optionen und ist über Plugins leicht zu erweitern, außerdem ist natürlich die Pflege von Contentseiten und Erlebniswelten hier absolut einfach.

Die Verwaltung der Shopkunden ist bei WooCommerce etwas gewöhnungsbedürftig, die Shopkunden werden nicht separat sondern über die Userverwaltung von WordPress verwaltet. Die Shopkunden werden als “Customer“ geführt und können sich nicht in das WordPress-Backend einloggen.

Technik

Für den Einsatz von Woocommerce sind ein paar wichtige vorbereitende Überlegungen nötig.

Technisch sollte auf jeden Fall der Einsatz von PHP 7.1 möglich sein und eine Caching-Lösung angedacht werden.

Die Wahl des richtigen Hosting-Tarifs ist ein weiterer wichtiger Faktor. Hier sollte man den zu erwartenden Traffic mit in die Wahl einbeziehen.

Da selbst in der einfachsten Shopanwendung personenbezogenen Daten und Bankdaten übermittelt werden, ist ein SSL-Zertifikat für die Shopseite ein absolutes Muss. Impressum und Datenschutzerklärung sollten rechtssicher und an den Shop angepasst sein.

Installation

Vorbereitende Arbeiten:

  • eine aktuelle Standardinstallation von WordPress
  • Maintenance installieren und aktivieren damit die Seite während des Aufbaus nicht von Suchmaschinen indiziert wird.
  • ein Caching-Tool in WordPress installieren

Wenn man möchte, kann man sich bereits ein WordPress-Theme installieren, welches die Seitengestaltung unter WooCommerce unterstützt und mit zusätzlichen Features erweitern kann.

Ein Standard-Theme kann aber auch in Zuge der WooCommerce-Einrichtung installiert werden.

Woocommerce-Installation:

  • Download und Aktivierung des WooCommerce-Plugins.
  • Germanized-Modul installieren.

  • Start des Einrichtungsassistenten von WooCommerce (die meisten Einstellungen lassen sich auch nachträglich vornehmen):

 

    • Händleradresse
    • Zahlungsweisen (wenn schon bekannt, ansonsten überspringen)
    • Versandarten
    • Theme bestätigen, Steuern und MailChimp ablehnen (kann man immer noch einstellen)
    • Jetpack nicht installieren
    • Germanized-Modul starten und die Daten ergänzen lassen.
      Mit dem kostenpflichtigen Pro-Modul kann man automatisch rechtlich relevante Seiten laden und in den Shop einbinden.

Entsprechend benötigte Plugins werden nachinstalliert.

Nach der Einrichtung von WooCommerce sollten Sie das Germanized-Plugin aufrufen. Hier wird WooCommerce um wichtige Funktionen für den deutschen Markt erweitert.

WooCommerce liefert mit Storefront von Haus aus ein funktionierendes Shop-Theme mit. Es steht aber auch frei, ein anderes geeignetes Theme zu verwenden.

Contao 4.5.8 mit Composer installieren

Für die einfache Installation von Contao 4.5.8 sind ein paar Vorarbeiten nötig.

So muss zuerst einmal Composer unter der richtigen PHP-Version installiert werden.

Composer installieren

Composer muss in den eigenen Kundenaccount installiert werden. Die Berechtigungen dafür haben Sie.

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

Wenn die Installation in der entsprechenden PHP-Version durchgeführt wurde, sollte Composer ab sofort ohne große PHP-Versionsangaben aufrufbar sein.

Beachten Sie bitte das Contao 4.5.x mindesten die PHP-Version 7.1.x benötigt.

Contao 4.5.8 installieren

Was brauchen Sie für die Installation

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

Wenn Sie die oben stehende Installation von Composer durchgeführt haben, reicht jetzt ein einfacher Befehl im Terminal um Contao zu laden und zu installieren:

composer create-project contao/managed-edition:4.5.x <Zielverzeichnis>

Hier im Beispiel:

composer create-project contao/managed-edition:4.5.x $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.

Rufen Sie jetzt die Installation im Webbrowser auf und lassen sich durch den Installationsvorgang leiten:

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

Vergeben Sie ein Installationspasswort um unberechtigte Zugriffe zu verhindern.

Richten Sie die Datenbank ein…

…und legen das Administratorkonto an:

WP-Performanceoptimierung #2: PHP-Version und Bildoptimierung

Dieser Test betrifft nicht nur WordPress.

Wir wollten mal testen und darstellen welchen Einfluss die verwendete PHP-Version und die Imagegröße auf die Auslieferungsgeschwindigkeit der Seite hat.

PHP-Version

Die Testbedingungen waren:

  • WordPress 4.9.4
  • Enfold-Theme 4.2.3 mit Demodaten „Startup Business Demo“
  • normaler Serverbetrieb
  • PHP 7.2.3 Fast CGI
  • PHP 7.1.10 Fast CGI
  • PHP 7.0.24 Fast CGI
  • PHP 5.6.31 Fast CGI
  • PHP 5.6.31 Extended

Es zeigt sich was wir jeden Tag bei der Arbeit beobachtet haben: die PHP 7.x Versionen arbeiten im Vergleich zu PHP 5.x rund 25% schneller.

Ein Umstieg – wenn es die eingesetzte Software erlaubt – lohnt sich.

Imagegröße

Ein weiterer wichtiger Punkt im Rennen ist die Bildgröße bzw. die Bildaufbereitung für das Web.

Hier sah die Testumgebung so aus:

  • WordPress 4.9.4
  • PHP 7.2.3 Fast CGI
  • Theme: Twenty Sixteen – Blogbeiträge
  • Bild 1: 3456 x 4608 Pixel | Bildqualität: Höchste Qualität 100% / Hohe Qualität 85% /  Mittlere Qualität 45% / Niedrige Qualität 10%
  • Bild 2:4000 x 3000 Pixel | Bildqualität: Höchste Qualität 100% / Hohe Qualität 85% /  Mittlere Qualität 45% / Niedrige Qualität 10%
  • Bild 3:1920 x 1280 Pixel | Bildqualität: Höchste Qualität 100% / Hohe Qualität 85% /  Mittlere Qualität 45% / Niedrige Qualität 10%

Die Bilder hatten das Dateiformat JPEG und wurden zudem mit unterschiedlichen Qualitätsstufen abgespeichert und in die Beiträge eingesetzt.
Die Qualitätsstufen 85 % weist nur geringe Verluste auf, bei der Stufe 45 % waren die Störungen noch im vertretbaren Rahmen (je nach Einsatzbereich den Bildes).
Die Qualitätsstufe 10% weist sowohl in Datenmenge als auch in Ladezeit keine großen Differenzen zu 45%-Stufe auf, wohl aber in der Qualität. Die Verluste sind schon gewaltig wie das Beispiel zeigt.

 

Qualitätsstufe 100%

Qualitätsstufe 45%

Qualitätsstufe 10%

Die Datenmenge und die Ladezeiten unterscheiden sich bei 100%, 85% und 45% sehr. Auch hier lohnt sich die Aufbereitung bei großen Bildmengen oder großen Bildern um der eigenen Seite einen Geschwindigkeitsschub zu verpassen.

 

WP-Performanceoptimierung #1: Caching in WordPress

Keiner will warten!

Jeder möchte seine aufgerufene Seite jetzt und sofort!

Die Anforderung an Webseiten lautet Geschwindigkeit, besonders auch, weil immer mehr Zugriffe von mobilen Endgeräten kommen und diese ja sowieso schon mit einer reduzierten Bandbreite auskommen müssen. Mittlerweile ist die Ladezeit auch eine Ranking-Faktor von Google.

Aber wie kann die Seite schneller ausliefert werden?

Eine Antwort heißt Caching.

Wie funktioniert Caching?

Bei jedem Seitenaufruf erstellt WordPress diese dynamisch. PHP-Skripte werden ausgeführt, Inhalte aus einer Datenbank geladen und dann zu einer statischen HTML-Seite verpackt die dann an den Browser ausgeliefert wird. Diese Prozedur wird bei jedem Aufruf erneut ausgeführt was auf die Performance drückt und solange sich der Inhalt nicht ändert, auch überflüssig ist.

Beim Caching werden diese statischen HTML-Seiten generiert und im Cache zwischengespeichert. Die Seite wird jetzt bei einem Aufruf nicht mehr neu generiert, sondern gleich aus dem Cache geliefert was eine deutliche Steigerung der Auslieferungsgeschwindigkeit zur Folge hat.

Wie kann ich meine Seiten cachen?

Es gibt für WordPress etliche Plugins, die diese Funktion für ihre Seite einrichten. Wir haben mal vier bekannte Kandidaten herausgesucht und in einem Test gegenüber gestellt.

Drei der Tools sind über die WordPress-Plugin-Installation verfügbar und lassen sich entsprechend einfach installieren, WP-Rocket muss über die Entwicklerseite käuflich erworben werden

W3 Total Cache

+ einfache Installation
+ einfache Aktivierung
+ kostenloses Plugin (mit kostenpflichtiger Upgrade-Möglichkeit)
+ viele Einstellungsmöglichkeiten
–  wegen der vielen Einstellungsmöglichkeiten für Anfänger nur bedingt zu empfehlen

WP Fastest Cache

+ einfache Installation
+ einfache Aktivierung
+ für Anfänger gut geeignet
+ kostenloses Plugin (mit kostenpflichtiger Upgrade-Möglichkeit)
+ gute Performance
–  geringe Einstellmöglichkeiten

WP Super Cache

+ einfache Installation
+ einfache Aktivierung
+ für Anfänger gut geeignet
+ kostenloses Plugin
+ zeigt die Liste der gecachten Seiten an
–  gute Performance

WP Rocket

Das einzige Plugin, dass nicht über die WordPress-Plugin-Installation erhältlich ist, sondern direkt über die Entwicklerseite bezogen werden muss.

+ gute Performance
+ gute Bedienung
+ guter Support
+ Funktion: Cache füllen
–  kostenpflichtig (39,00 EUR/Jahr)

Der Test…

Die Testparameter waren:

  • die GN2-Hosting Seite
  • ohne Cache
  • mit W3 Total Cache
  • mit WP Fastest Cache
  • mit WP Super Cache
  • mit WP Rocket

Alle Cache-Plugins wurden Out-of-the-Box (ggf. wurde generell das Caching eingeschaltet) getestet.

Die Testergebnisse sind dynamisch im laufenden Serverbetrieb gewonnen worden und können schwanken.
Sie geben keine Laborbedingungen wieder.

Content-Builder für WordPress Teil 3: Enfold/Avia

 

In diesem Teil der WordPress-Content-Builder wird Enfold von Christian Budschedl vorgestellt.

Wie in den vorangegangenen Artikeln geht es auch hier um einen Content Builder, der den Funktionsumfang des WP-Standard-Editors gehörig erweitert.

Im Grund ähneln sich alle Content Builder. Jedes dieser Werkzeuge hat Stärken und Schwächen. Sie sind z.T. spezialisiert auf bestimmte Bereiche (e-Commerce, Business, Blog, …) und haben entsprechend spezielle Tools.
Einige Tools fehlen in einem, dafür haben diese andere Werkzeuge, die bei anderenContent Builder nicht zu finden sind.

Wie funktioniert Enfold?

Enfold macht in der Layoutarbeit im Backend einen schnellen und schlanken Eindruck. Die Elemente sehen nicht so massiv aus wie bei Divi und werden kompakter Dargestellt als bei Visual Composer.

Die Anordnung und Strukturierung der Tools, bei Enfold Elemente genannt, ist grob in die Bereiche Layout-, Inhalt- und Media-Elemente eingeteilt und macht einen aufgeräumten Eindruck.

Layout-Elemente regeln die Aufteilung der Seite, Inhalts-Elemente sind eher für Text und die Media-Elemente steuern – wie der Name schon sagt – Bilder, Filme, Slider,…

Ein angeklicktes Element wird automatisch immer unten auf der Seite angefügt und kann dann entsprechend verschoben werden.

Bei Enfold der erweiterte Layout-Editor auch im Blogbeitrag verwendet werden.

Das Standard-Footer-Menü ist sehr klein rechts unten auf der Seite. Es besteht die Möglichkeit Sondermenüs auf einzelnen Seiten einzusetzen.

Vor- und Nachteile

Vorteile

  • schlank und übersichtlich
  • geringere Entwicklungszeit
  • geringere Entwicklungskosten
  • großer Funktionsumfang
  • vielseitig einsetzbar
  • Import von Seiten-Vorlagen
  • Erstellen eigener Seiten-Vorlagen
  • Import von kompletten Beispielvorlagen
  • 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
  • Enfold ist kostenpflichtig
  • Overhead: Ladezeit der Seite

 

Frontend-Editor?

Enfold unterscheidet sich gegen über den beiden vorherig besprochenen Content Builder weil Enfold keinen Frontend Editor aufweist. Das mag vielleicht einige stören, aber der Frontend Editor beansprucht viel Leistung und hat manchmal auch sehr seltsame Effekte aufzuweisen (siehe Visual Composer).

(Demo-)Vorlagen

Eins schönes Feature bei Enfold sind die Demo-Vorlagen. Diese Demos beinhalten nicht nur eine Vorlage für einen bestimmten Einsatzbereich (z.B. Restaurant), sondern liefern gleich einen kompletten Auftritt incl. Demobilder und Seitenstruktur.

Dieser Auftritt kann als Ein- oder Mehrseiter angelegt sein. Die Seiten sind komplett, bis auf evtl. noch nicht installierte Plugins.

Man kann sich im Backend das Seitendesign ansehen und für eigene Projekte adaptieren. Allerdings sollte man sich nicht zu viele Demos in die Installation laden, das würde zu viel Datenmüll erzeugen.

Beim Import der Demoseiten ist allerdings auch Vorsicht geboten. Wird ein Demo installiert, werden dabei die bisherigen Theme-Einstellungen gelöscht.

Es lassen sich in Enfold aber auch eigene Seitenvorlagen erstellen, die dann im Projekt verwendet werden können.

Auch hier kann ich nur den Tipp aus den letzten beiden Artikeln dieser Themenreihe wiederholen: Lieber eine zweite Testseite aufsetzen, die hinterher wieder gelöscht werden kann.

#1 SEO Grundlagen für WordPress: Yoast-SEO-Plugin, Grundinstallation und Basis-Setup

Warum Yoast SEO?

  • Title und Description kann bei der Google-Suchausgabe gesteuert für eine optimale Information über die eigene Webseite.
  • Title und Description lassen sich sowohl global als auch für jede Seite steuern.
  • Eine google-optimierte Ausgabe der Webseite zu ermöglichen.

Vorarbeiten

Für den Einsatz von Yoast SEO wird ein Google-Account benötigt, da Yoast SEO auf die Google Search Console zugreift.

Dieser Account wird bei der Einrichtung von Yoast SEO benötigt, also besser vorher schon anlegen.

Installation

Das Yoast SEO Plugin von Team Yoast lässt sich einfach über das WordPress-Backend installieren.

Nach der Aktivierung sind die Yoast SEO Tools in der linken Spalte zu finden – allerdings noch mit reduzierten Einstellungsmöglichkeiten.

Die Einstellungen lassen sich im SEO Dashboard / Funktionen / Erweiterte Einstellungen aktivieren. Danach stehen weitere Menüpunkte zur Verfügung.

Verifizierung bei der Google Search Console

Verifizieren Sie am Besten gleich Ihre Seite bei der Google Search Console. Das wird zwar bei der geführten Einrichtung durch den Konfigurations-Assistenten auch abgefragt, es ist aber aus eigener Erfahrung bequemer, wenn die Verifizierung vorher erledigt und der Konfigurations-Assistent ohne große Unterbrechung durchlaufen kann.

Die Verifizierung wird im SEO Dashboard / Webmaster Tools mit einem Klick auf den Link zur Goole Search Console gestartet.

In einem neuen Tab / Fenster wird die Google Search Console aufgerufen, Sie müssen ggf. Ihr Login zu Ihrem Google-Account eingeben.

Wählen Sie erst einmal die Methode HTML-Tag, kopieren Sie den Meta-Tag und fügen diesen dann im WordPress im Feld für die Google Search Console ein.

Später können Sie dann noch weitere Verifizierungsmethoden hinzufügen.

Der Konfigurations-Assistent

Der Konfigurations-Assistent wir unter SEO Dashboard / Allgemein gestartet.

Im Dialog werden die grundlegenden Einstellungen abgefragt.

XML-Sitemaps

Damit die Google Search Console richtig und schnell arbeiten kann, kann man die XML-Sitemap der WordPress-Seite weitergeben.

Die XML-Sitemap können im WordPress unter SEO XML-Sitemaps / Allgemein Link XML-Sitemap aufgerufen werden. Es reicht aus, wenn nur die /page-sitemap.xml weitergegeben wird.

Diese Information wird dann in der Google Search Console unter Crawling / Sitemaps eingetragen.

Die Seitenstruktur kann so von Google schneller gescannt und die Ergebnisse angezeigt werden.

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.

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

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

 

Terminalsitzung mit screen

Eine Terminalsitzung durch widrige Umstände abgestorben und alle Anwendungen gleich mit?

Der Terminal-Multiplexer screen gestattet es, Sitzungen jederzeit zu unterbrechen oder fortzusetzen.

screen kann mit Ihren Berechtigungen in den eigenen Account kompiliert werden.

Für diese Demo gibt es folgende Randbedingungen:

  • die verwendete Verwendete Version: screen-4.6.2
  • es wird ein Verzeichnis „tools“ als „Sammelbehälter“ für alle Installationen und externen Module angelegt. In dieses Verzeichnis wird auch screen installiert.
    Laden Sie die aktuelle Version von screen hier herunter und machen dann einen Upload per ftp in das Auftragsrootverzeichnis.

Loggen Sie sich per SSH in Ihren Account und legen zuerst einmal das „tools“ Verzeichnis an und wechseln dann in dieses neue Verzeichnis:

mkdir tools
cd tools

Laden Sie die aktuelle Version von screen per FTP hier herunter, lassen sich den Inhalt auflisten, laden dann die aktuellste Version herunter (hier screen-4.6.2.tar.gz) und entpacken das Archiv:

ftp ftp://ftp.gnu.org/gnu/screen/
ls
get screen-4.6.2.tar.gz screen-4.6.2.tar.gz
tar -xvf screen-4.6.2.tar.gz

Das benennen Sie das entpackte Archiv wegen der weiteren Tipparbeit einfach in „screen“ um, geben erweiterte Berechtigungen auf das Verzeichnis und wechseln dann in selbiges:

mv screen-4.6.2/ screen
chmod -R 777 screen/
cd screen/

Starten Sie die Installation:

./configure --prefix=$HOME/tools/screen/ --with-socket-dir=$HOME/tools/screen/
make
make install

Wechseln Sie anschließend in ihr Auftragsroot zurück:

cd $HOME

screen kann jetzt gestartet werden:

tools/screen/screen

eleganter geht es aber mit einem Eintrag in der Datei .bashrc. Falls die Datei noch nicht existiert, wird sie im nächsten Schritt automatisch angelegt. (Wichtig: die .bashrc muss im Auftragsroot liegen)

nano .bashrc

Tragen Sie folgende Zeile in der Datei ein:

export PATH=$HOME/tools/screen/:$PATH

Speichern Sie die Datei ab und laden die Umgebungsvariablen neu! (Wichtig – aus eigener Erfahrung…):

source .bashrc

Danach sollte die Pfadvariable das Installationsverzeichnis an erster Stelle anzeigen und screen sollte auch direkt aufrufbar sein:

echo $PATH
screen

Jetzt noch das Tar-Archiv aufräumen:

rm tools/screen-4.6.2.tar.gz

Fertig.