Eigene Testinstanz

Um das Theme ausführlich zu testen oder an der Weiterentwicklung beizutragen, ist es notwendig, eine eigene WordPress-Testinstanz aufzusetzen.

Die folgenden Absätze erläutern, welche Voraussetzungen hierzu notwendig sind und welche Schritte zu befolgen sind. Außerdem werden Empfehlungen zum Setup gegeben.

Voraussetzungen

Eine Testinstanz kann auf allen gängigen Systemen eingerichtet werden: Windows, MacOS und Linux-Systeme, bei denen ein Webserver und eine MySQL-Datenbank eingerichtet werden können. Für Anwender ohne tiefergehende Systemkenntnisse ist es empfehlenswert, ein XAMPP bzw ein LAMPP-Paket zu nutzen.

Für die Entwicklung des Theme-Codes ist zusätzlich ein Ruby- oder eine NodeJS-Installation notwendig um einen SASS-Compiler zu nutzen.

Zusätzlich sollte das Versionsverwaltungssystem Git zur Verfügung stehen oder installiert werden. Git steht sowohl als Systembibliothek als auch als Client-Lösung zur Verfügung.

 

Installation und Vorbereitung der Testinstanz

Für eine Testinstanz ist zunächst die Installation von WordPress notwendig. Eine entsprechende Anleitung, sowie der aktuelle Download hierzu findet sich bei de.wordpress.org. Neben der offiziellen Quelle finden sich im Internet eine ganze Reihe von hilfreichen Anleitungen zur Installation von WordPress.

Das folgende Video erläutert die Einrichtung von WordPress auf einem Server (z.B. bei einem Provider, einer VM oder einem echten Server): „WordPress installieren – einfach und sicher in 5 Schritten – Tutorial Deutsch„

 

Das folgende Video erläutert die Installation auf XAMPP:

Die XAMPP-Installation eignet sich vor allem dafür, WordPress auf einem Laptop zu installieren, mit denen man auch unterwegs arbeiten oder präsentieren möchte.

 

Für eine Testinstanz sollte WordPress zusätzlich in Multisite Konfiguration – und zwar Domainbasiert – installiert sein. Auch hierzu gibt es Tutorials und Videos. Beispielsweise auf wpbeginners.com: How to Install and Setup WordPress Multisite Network. Die Beschreibung auf codex.wordpress.org ist jedoch die aktuellste.

Für die Entwicklung ist im späteren Verlauf die Einrichtung zweier Instanzen hilfreich. Nämlich für eine deutsche und eine englische Instanz. Möchte man zusätzlich auch die Themes der Fakultäten testen, könnte es sich sogar von Vorteil erweisen, weitere 5 WordPress-Instanzen (pro Fakultätstheme eine) anzulegen.

 

Installation vom Themes und Plugins

Nach der erfolgreichen Installation von WordPress können eigene Themes und Plugins installiert werden.

Theme FAU Einrichtungen

Das FAU-Design basiert auf dem WordPress-Theme FAU-Einrichtungen, welches auf GitHub zur Verfügung gestellt wird: github.com/RRZE-Webteam/FAU-Einrichtungen.
Um das Theme vom GitHub zu erhalten, empfiehlt es sich, den GitHub-Client zu installieren, sofern man diesen noch nicht hat. Auch benötigt man ein Account bei GitHub.

Hat man ein GitHub-Account macht man ein Clone des GitHub-Projektes RRZE-Webteam/FAU-Einrichtungen und lädt es so in ein Verzeichnis eigener Wahl runter. Theoretisch kann man das Git-Projekt direkt in das wp-content/themes/ Verzeichnis auschecken lassen. Dies kann jedoch im späteren Verlauf verschiedene Probleme machen und erfordert Aufmerksamkeit. Stattdessen ist es Empfehlenswert, für alle Git-Projekte ein eigenes Git-Projektverzeichnis zu schaffen und von diesem wiederum die Dateien über den eigenen Editor oder von Hand auf den Webserver zu kopieren.

Wichtig ist dabei, dass auf der WordPress-Installation das Theme den Projektverzeichnisnamen behält: „FAU-Einrichtungen“. Lädt man von GitHub stattdessen die ZIP-Datei herunter und entpackt diese in das WordPress-Themeverzeichnis, kann es passieren, dass der Verzeichnisname um den Branchnamen („master“, „beta“ oder „dev-1-10“) ergänzt wurde.

 

Möchte man auch die Fakultätsthemes testen, macht man dasselbe mit den GitHub-Projekten

  • FAU-Medfak
  • FAU-Natfak
  • FAU-RWFak
  • FAU-Techfak
  • FAU-Philfak

Nachdem die Themes in das wp-content/themes Verzeichnis hochgeladen wurden, können diese in der Netzwerkadministration freigeschaltet werden um danach in einer WordPress-Instanz aktiviert werden zu können.

 

Die FAU Themes sind grundsätzlich ohne weitere Plugins lauffähig. Dennoch gibt es einige Plugins, deren Installation hilfreich ist:

Plugins

Kalender rrze-calendar

Um den Kalender der FAU-Website einzubinden, verwendet man zusätzlich das Plugin
https://github.com/RRZE-Webteam/rrze-calendar
der sich die Termine über ein oder mehrere ICS-Quellen holen kann.

Kontakte fau-person

Für die Anzeige von Personen und pseudonymen Kontakten wird das Plugin
https://github.com/RRZE-Webteam/fau-person
verwendet.
Auch dies ist optional.

Workflow cms-workflow

Bei großen Websites, die zudem zweisprachig sind (wie die FAU Website) wird ein Workflow-Management verwendet:

https://github.com/RRZE-Webteam/cms-workflow

Das Workflow-Management ermöglicht auch die Darstellung des Sprachschalters, welches auf der fau.de Website oben zu sehen ist. Der Sprachschalter wird über ein Widget aktiviert.
Das Widget ist von Theme vorhanden; Wenn das Plugin vorhanden und aktiv ist und eine zweisprachige „Master-Slave““ Kombi existiert, kann man ein Sprachschalter zu dem Widget schieben.
Dies ist etwas komplex, aber dafür hier beschrieben: Fremdsprachiger Webauftritt.

Video rrze-video

Das Videoplugin sorgt für eine datenschutzfreundliche und performante Einbindung von Videos im Footer und als Shortcode in Seiten:
https://github.com/RRZE-Webteam/rrze-video

 

Arbeiten mit GitHub

Fast alle Plugins sind in der offizielle Dokumentation erläutert und via GitHub im Teamverzeichnis RRZE-Webteam erreichbar.

Auf der BETA-Plattform wird stets die letzte Version des BETA-Branches vom Theme FAU-Einrichtungen ausgecheckt: https://www.beta.wordpress.rrze.fau.de/
Auf dieser Plattform finden sich auch verschiedenste Testcases für Seiten, Beiträge, Pluginnutzung etc.

Bei allen GIT-Projekten arbeiten wir stets in eigenen oder auch gemeinsamen „DEV“-Branches.

Die tägliche Arbeit kommt jeweils in den dev-Branch. Auch wenn das was an einen Tag gemacht wurde noch nicht lauffähig oder gut ist wird es in dev commitet. (Das ist bei uns eine Ausfallsicherung gegen Krankheit etc.)
Wenn ein Entwickler/Designer denkt, dass seine Arbeit „reif“ ist, dann mergt er sie in die Beta-Branch. Dieser Branch wird danach auf der Beta-Website auscheckt und kann dort auch von anderen getestet werden.
Wenn keine Probleme auftauchen wird diese Version dann in den MASTER-Branch gemergt. Der MASTER-Branch ist der für die produktiven Websites.

Hier kann man das Prinzip ganz gut sehen: https://github.com/RRZE-Webteam/FAU-Einrichtungen/network

Das Setup kann recht schnell und einfach auf jedem Linux-Derivat und auch auf XAMPP/LAMPP-Installationen aufgespielt werden. Ich selbst hab dieses Setup auf drei verschiedenen Rechnern (mein Büro-Mac + Remote Linux-VM, mein Windows-Laptop (dann kann ich sogar im Zug programmieren) und zu Hause ein normales Windows + remote Linux VM).

Durch das tägliche einchecken der Arbeit in den dev-Branch kann ich jederzeit auf Dienstreise oder zu Hause wieder auschecken und dort weitermachen.

Gulp Skript zur Kompilierung

Zur Kompilierung der SASS Dateien befindet sich ein Gulp-Skript im Basisordner. Dieses Skript compiliert die CSS-Dateien aus den SASS, ergänzt notwendige Vendor-Prefixes und minifiziert die Ausgaben.

Im Projekt befindet sich hierzu eine package.json und ein Gulpskript gulpfile.babel.js. Durch Ausführung mit NodeJS können

  • die SASS-Dateien zu den notwendigen CSS compiliert werden.
  • Vendor-Prefixes in den CSS-Dateien ergänzt werden,
  • CSS-Dateien minifiziert werden,
  • die zentrale Sprachdatei fau.pot aktualisiert werden,
  • die Versionsnummer des Projektes (automatisch) erhöht werden, sowie weitere Tasks ausgeführt werden.

Übliche Startprozesse sind:

node run (option) mit (option)=

  • „dev“ (Erstellung der CSS Dateien aus SASS plus Autoprefixer; Zusätzlich wird die POT-File in /languages aktualisiert.)
  • „maps“ (Erstellung der CSS Dateien aus SASS plus SourceMap, ohne Autoprefixer)
  • „build“ (Erstellung der CSS Dateien aus SASS plus Autoprefixer und Minifizierer. Zusätzlich wird die Patch-Version des Projektes um eine Nummer erhöht)
  • „pot“ (Aktualisierung der POT-File in /languages )

SASS-Compiler in eigener IDE

Abseits des Gulp-Skriptes ist es auch möglich, SASS mit einer eigenen IDE zu kompilieren. Hierzu können die folgenden Parameter verwendet werden:

Im Verzeichnis /css/sass/ wurden alle notwendigen SASS und SCSS Dateien abgelegt. Die zentrale CSS-Datei style.css wird bei der SASS-Compilierung im Hauptverzeichnis des Themes unter den Namen style.css abgelegt. Die CSS-Dateien für das Backend werden dagegen im Unterverzeichnis /css abgelegt.

Optionaler SASS-Watcher:

  1. Basis Stylesheet Eingabequelle: /css/sass/base.scss
    Ausgabeort: /style.css
  2. Sonstiges Styles Eingabequelle: /css/sass/
    Ausgabeort: /css

Mit der Compiler-Option --style compressed sollen die im produktiven Betrieb erzeugten CSS-Dateien komprimiert sein. Source-Map Dateien werden nicht benötigt.

Hinweis zu Vendor-Prefixes

Neue Vendor-Prefixes sollen -sofern sie noch benötigt werden- nur noch durch einen Autoprefixer auf das style.css ergänzt werden. Das beigelegte Gulp-Skript mit den darin befindlichen Modules ergänzt die CSS-Dateien um Vendor-Prefixes.