
Wordpress ist das meistgenutzte CMS der Welt. Dennoch gibt es zahlreiche Diskussionen, ob WordPress eine technisch „seriöse“ Lösung ist. Es scheint als hätte WordPress den Ruf ein „Bastler-Set“ für Jedermann zu sein, welches aber technologisch nicht ausgereift ist. Kritisierte Punkte sind unter anderem Performance, Sicherheit und Einschränkung des Designs. Eine Frage mit der wir öfters konfrontiert sind lautet: „Ist WordPress gut genug für meine Anwendung?“

Von vorne Weg: WordPress und FORTIX waren lange auf Kriegsfuß miteinander. Aufgrund der großen Verbreitung stoßt man in Web-Projekten regelmäßig auf das CMS. Deshalb setzten wir uns verstärkt mit dem CMS auseinander. Je mehr wir in die Tiefe abtauchten, wo der sagenumwobene WP-Core wartete, desto leichter fiel es uns, WordPress zu schätzen.

### Wie man WordPress nicht verwenden sollte:

Eine Website kann mit wenig technischem Knowhow „entwickelt“ werden. Frei nach dem Motto „Heutzutage kann jeder Web-Entwicklung“. Oft werden fertige Templates oder Page-Builder wie [Elementor](https://elementor.com) herangezogen. Für einen Basisfall (One-Pager mit statischen Informationen) mag das auch funktionieren, allerdings läuft der ungezielte Einsatz von solchen Instrumenten oft auf unterirdische Werte im Bezug auf Performance, Wartbarkeit, Erweiterbarkeit und Modularität hinaus. Hier noch ein Plugin und dort noch eines und schwups – das Chaos ist perfekt. Manche Plugins werden in weiterer Folge gar nicht mehr gewartet (führt zu Sicherheitslücken), manche Updates gehen schief und irgendwann weiß man gar nicht mehr, welches Plugin welchen Anwendungsfall erfüllt. Fällt dann auch noch der über 3-Ecken bekannte „Entwickler“ weg, wird es kritisch. Spätestens dann sucht man sich Hilfe vom professionellen Entwickler. Die Empörung der Seitenbetreiber ist dann oft groß, wenn die Diagnose heißt: „[Sie reiten hier ein totes Pferd.](https://www.youtube.com/watch?v=RaTxNCQcYis&ab_channel=%C3%96sterreichischeAlternative) Da kann man nichts mehr machen. Ich rate die Website neu zu entwickeln.“

Heißt das man soll keine Page-Builder verwenden? Nein! Der richtige Anwendungsfall muss gegeben sein und zumindest ein Grundverständnis für Web-Entwicklung sollte vorhanden sein. Das Weiße Haus setzt auf der Seite den klassischen [Gutenberg-Editor](https://de.wordpress.org/gutenberg/) ein, während bei einigen unserer Projekte Elementor zum Einsatz kommt (z.B. Website [Hagen Management](https://hagen.management/), [Gerd am Herd](https://gerd-am-herd.at/), und teilweise auch bei unserer eigenen Seite).

Und was ist mit Plugins? Auch hier ist es ähnlich. Der gezielte Einsatz ist entscheidend. Die WordPress-Community ist riesig. Dementsprechend werden sowohl gute als auch schlechte Plugins angeboten. Hier heißt es abwägen und recherchieren. Wer steckt hinter dem Plugin? Hobby-Coder oder Unternehmen? Bei wie vielen Seiten ist das Plugin im Einsatz? Wird das Plugin gewartet? Gibt es regelmäßige Updates? Und und und. Ein Klassiker bei uns ist z.B. das SEO-Plugin Yoast. Auch die neue White House Seite hat [Yoast](https://yoast.com/) in Verwendung.

Wir kratzen hier noch an der Oberfläche. Sobald der Anwendungsfall komplexer wird, muss gesondert evaluiert werden, ob bzw. wie WordPress eingesetzt werden kann. Grundsätzlich ist WordPress sehr flexibel und bietet Entwicklern gut dokumentierte [APIs](https://developer.wordpress.org/rest-api/) und [Hooks](https://developer.wordpress.org/plugins/hooks/) an. Somit stehen konzeptionell einige Türen offen, wie z.B. die Trennung zwischen Front- und Backend. Dabei nutzt man die Stärken von WordPress und kombiniert diese mit Technologien wie beispielsweise Angular, Vue oder React. Wer mehr darüber erfahren will, sollte sich mit dem Thema Headless-CMS auseinandersetzen. Speziell um [Gatsby](https://www.gatsbyjs.com/) entwickelte sich in den letzten Monaten ein Hype.

Tiefer will ich hier nicht gehen, sonst sprengt es den Rahmen. Das Fazit lautet: WordPress ist das meistverwendete CMS der Welt. Das heißt schon mal was. Zunächst von uns kritisch beäugt, entwickelte sich WordPress mit fortlaufendem Wissenstand zu einer technischen Variante, auf die wir oft und gerne zurückgreifen. Wie WordPress eingesetzt wird, hängt dabei immer vom Anwendungsfall ab. Pauschale Aussagen sind nicht möglich und unseriös. Wie immer in der Entwicklung ist der Schlüssel zum Erfolg das einhalten von Best-Practices und [Standards](https://fortix.io/die-12-faktoren-app/). Das gilt auch im WordPress-Umfeld. Abschließend zurück zur Frage, ob WordPress nicht zu „schwach“ für das eigene Vorhaben ist? Wenn Joe Biden und das Weiße Haus auf WordPress setzen, dann stehen die Chancen nicht schlecht, dass WordPress auch für Dein digitales Projekt eine spannende Alternative bietet.


US-Wahl 2020 aus technischer Sicht: Was Joe Biden mit WordPress zu tun hat


Die Twelve-Factor App Methode lässt sich auf Software anwenden, die in jeder beliebigen Programmiersprache (C#, Java, TypeScript, PHP, Python, …) entwickelt wird. Die Methode unterstützt zudem eine beliebige Kombination von Diensten (Datenbank, Message Queue, Cache, …). Die Konzepte können ebenfalls auf jedes beliebige Framework, wie das Web-Framework [Angular](https://angular.io/) oder das Mobile-Framework [Flutter](https://flutter.dev/), angewendet werden.

Wir haben die 12 Faktoren in einer Checkliste zusammengefasst:

### 1. Codebasis

Änderungen am Code sollen mit Hilfe von Versionsverwaltung getrackt werden. Mit Tools wie [Git](https://git-scm.com/) wird die Zusammenarbeit im Team erst ermöglicht. Dabei hat jeder Entwickler seine eigene Version des Codes und der Single-Point-of-Truth ist der Code in der Versionsverwaltung (repository). Für einen Release der Software wird der Code im Repository dann kompiliert, getestet und in der Cloud bereitgestellt.

### 2. Abhängigkeiten

Softwareabhängigkeiten (dependencies) sind externe Bibliotheken, die in vielen verschiedenen Apps verwendet werden können. Falls externe Bibliotheken verwendet werden, müssen diese explizit in einem „package manager“ spezifiziert werden. Es darf nie die Annahme getroffen werden das eine Abhängigkeit auf einem System schon vorhanden ist.

### 3. Konfiguration

Die Konfiguration einer App ist alles was sich wahrscheinlich zwischen verschiedenen Bereitstellungen (dev, test, staging, production) verändert. Konfigurationen dürfen nicht als Konstanten im Code gespeichert werden. Konfiguration und Code müssen immer strikt getrennt sein. Am besten wird die Konfiguration in Umgebungsvariablen (env) gespeichert. Dadurch wird ausgeschlossen, dass versehentlich [Zugangsdaten](https://dzone.com/articles/git-secrets-api-keys) in die Versionsverwaltung eingecheckt werden 😉

### 4. Unterstützende Dienste

Ein unterstützender Dienst ist jeglicher Dienst, den die App über das Netzwerk abruft. Dazu zählen zum Beispiel Datenspeicher (SQL/No-SQL Datenbanken, Objektspeicher), Message-Queue Systeme (RabbitMQ, Google Cloud Pub/Sub, …) oder SMTP-Dienste für das Senden von E-Mails (Sendgrid, [Mailchimp](https://mailchimp.com/de/), …). Jeder Dienst soll über eine URL, die in der Konfiguration gespeichert ist, erreichbar sein. Wenn z.B. eine Datenbank ausgetauscht wird, soll keine Änderung am Code erfolgen. Änderungen sollen lediglich über die Konfiguration gemacht werden.

### 5. Build, Release, Run

Jede Codeänderung muss diese drei Phasen durchlaufen. Es soll nicht möglich sein, Änderungen am Code während der Laufzeit zu machen. Um diese Phasen zu automatisieren soll ein CI/CD Tool (Travis CI, Jenkins, Bitrise, …) verwendet werden. Neue Build‘s werden durch die Entwickler der App ausgelöst, indem sie neuen Code in die Versionsverwaltung einchecken. Somit ist jeder Build eindeutig auf eine bestimmte Version des Codes zurückzuführen.

### 6. Prozesse

Die App sollte auf einer [„Shared Nothing“](https://de.wikipedia.org/wiki/Shared_Nothing_Architecture) Architektur aufgebaut werden. D.h. die App ist unabhängig von anderen Apps und kann einen eigenen Prozessor und Speicher verwenden. Ein Abstürzen der Applikation darf nie dazu führen das andere Services beeinträchtigt werden. Alle Daten, die von der App verwendet werden, müssen in einer Datenbank gespeichert werden. Dies garantiert die Skalierung unter hoher Last, da nahezu unbegrenzt neue Instanzen der App gestartet werden können. 🚀

### 7. Bindung an Ports

Eine Zwölf-Faktoren-App soll nicht an einen Anwendungscontainer wie Apache Tomcat gebunden sein. Die Anwendung soll einen eigenen Web Server o.ä. integrieren, damit diese über einen bestimmten Port erreichbar ist.

### 8. Nebenläufigkeit

Die Anwendung soll anhand von Prozesstypen wie Hintergrund-, Web- und Worker-Prozessen in unabhängige Prozesse aufgeteilt werden. Somit kann eine einfache Skalierung garantiert werden. Falls ein Teil der Anwendung eine hohe Auslastung widerfährt, können von diesem Prozesstyp mehrere Instanzen gestartet werden.

### 9. Einweggebrauch

Prozesse einer App sollen schnell gestartet und gestoppt werden können. Dies erleichtert schnelles skalieren während Belastungsspitzen und ein schnelles Bereitstellen von Code. Die Startzeit eines Prozesses sollte so gering wie möglich sein. Zusätzlich sollten Prozesse auch schnell gestoppt werden können, damit sie die verwendeten Ressourcen wieder für andere Services zur Verfügung stellen.

### 10. Dev-Prod-Vergleichbarkeit

Die Entwicklungsumgebung sollte so sehr wie möglich der Produktionsumgebung ähneln. Unterschiede zwischen den verwendeten Diensten können Inkompatibilitäten verursachen, die erst beim Bereitstellen in der Produktionsumgebung erkennbar werden. Eine Zwölf-Faktoren-App ist auf [Continuous Deployment](https://www.dev-insider.de/was-ist-continuous-deployment-a-652804/) ausgelegt, indem sie die Unterschiede zwischen Entwicklung und Umgebung klein hält.

### 11. Logs

Logs sind ein Datenstrom von Ereignissen, die das Verhalten einer laufenden App sichtbar machen. Eine Zwölf-Faktoren-App soll sich nicht selbst um Logs kümmern und diese z.B. in eine Datei schreiben. Es sollte ein separater Service verwendet werden, der diese Logs verwaltet und übersichtlich darstellt.

### 12. Admin-Prozesse

Verwaltungsprozesse wie das Erstellen von Berichten oder die Migration von Datenbankschemas müssen von der Anwendung selbst entkoppelt sein. Die Ausführung eines Admin-Prozess darf die eigentliche Anwendung in keiner Weise beeinflussen.

Das Zwölf-Faktoren-Modell deckt also viele Aspekte der Entwicklung einer Anwendung ab. Das Modell ist gut dazu geeignet, zukunftsorientierte Anwendungen für die Cloud zu entwickeln. 👍

Je nach Anwendungsfall müssen die Methoden angepasst werden, für Internet-of-Things Anwendungen gelten natürlich andere Regeln wie für Web-Anwendungen. Dennoch stellt diese Methode eine gute Basis dar, um einen Überblick an die Anforderungen moderner App-Entwicklung zu bekommen.

**[FORTIX](https://fortix.io)** hat die Methode für Zwölf-Faktoren-Anwendungen verinnerlicht und entwickelt für Sie moderne Software die nahtlos skaliert werden kann. 💪💻

Dabei halten wir uns an eine Vielzahl von Best Practices, um die Wartbarkeit und Erweiterbarkeit des Codes zu verbessern. Wir entwickeln Cloud native und Internet-of-Things (IoT) Anwendungen die auf jedem beliebigen Cloud Provider (AWS, Azure, Google Cloud, Software AG, …) ausgeführt werden können.

Wenn Sie mehr über den Entwicklungsprozess bei FORTIX erfahren wollen können Sie uns gerne [kontaktieren](https://fortix.io/die-12-faktoren-app/#). Wir freuen uns! 🎉

### Links

- [Twelve-Factor App](https://12factor.net/)
- [Twelve-factor app development on Google Cloud](https://cloud.google.com/solutions/twelve-factor-app-development-on-gcp)
- [Applying the Twelve-Factor App Methodology to Serverless Applications](https://aws.amazon.com/de/blogs/compute/applying-the-twelve-factor-app-methodology-to-serverless-applications/)
- [Twelve-Factor WordPress App](https://roots.io/twelve-factor-wordpress/)


The Twelve-Factor App


Flutter-Programme bestehen aus vielen verschiedenen Widgets. Ein Widget bündelt die Logik, Interaktion und die Darstellung eines Objekts. Flutter bringt eine Reihe von vordefinierten Widgets mit. Dadurch kann schnell ein MVP entwickelt und veröffentlicht werden.

Ein weiteres Feature, das die Entwicklungszeit stark verringert, ist Flutter’s Hot Reload . Mithilfe des Hot Reloads lassen sich Änderungen im UI oder in der Business Logik in Sekundenschnelle auf das Smartphone übertragen. Dabei wird der neue Sourcecode in eine virtuelle Dart Umgebung geladen, die auf dem Gerät läuft. Das Entwickeln und Testing wird dadurch stark vereinfacht.

![Flutter logo](/images/flutter.png 'Flutter Logo')

Der Dart Code wird je nach Plattform unterschiedlich kompiliert. Auf Mobilen, Desktop und Servergeräten wird der Code nativ in Maschinencode übersetzt. Dies lässt die Applikation performant mit mindestens 60 Hz pro Sekunde auf dem Gerät laufen. Wenn die Anwendung für das Web veröffentlicht wird, wird der Code mit dem Dart-to-JavaScript Compiler ([dart2js](https://dart.dev/tools/dart2js)) kompiliert. Die Anwendung kann dann ganz einfach im Browser ausgeführt werden.

Mit Flutter ist es also möglich mit einer einzigen Codebasis für mehrere Betriebssysteme bzw. Plattformen zu entwickeln. Derzeit wird Web, Android, iOS, Windows, Linux, macOS und das neue Betriebssystem von Google – [Fuchsia OS](https://de.wikipedia.org/wiki/Google_Fuchsia) unterstützt. Das Framework ist schon bei vielen großen Softwareprojekten im Einsatz, unter anderem wird Flutter bei Google Ads eingesetzt. Es bleibt spannend wie sich das Framework weiterentwickelt. Zurzeit ist Flutter das einzige Framework, das so eine große Anzahl von Plattformen nativ unterstützt.

Google und die stetig wachsende Community entwickeln Flutter rasant weiter. Wir bei FORTIX setzen speziell bei der Entwicklung von Mobile Apps auf Flutter. Durch die sogenannte Single-Codebase ist es möglich, eine App zu entwickeln, die sowohl auf Android als auch auf iOS nativ dargestellt wird. Man erspart sich daher viel Aufwand in der Entwicklung und Wartung einer App, was wiederum in geringeren Projektkosten resultiert. Auch deshalb ist Flutter nicht nur für die Entwickler eine sehr spannende Option, sondern auch für diejenigen, die mit dem Gedanken spielen, eine App entwickeln zu lassen.

Bei Fragen bezüglich App-Entwicklung, Flutter und alternativen Technologien stehen wir gerne zur Verfügung!


Flutter – Das Werkzeug für native Apps in Rekordzeit


Wieviel kostet eine Webseite im Jahr 2020? Soviel wie ein Auto oder ein Haus. Kurz gesagt, es ist unmöglich einen pauschalen Preis für eine Webseite zu nennen. Genau wie bei einem Auto kommt es unter anderem auf die Zusatzleistungen an. Möchte ich ein Auto in Standardausführung ohne großem Schnick-Schnack oder möchte ich das Topmodell mit Fahrassistent und autonomen Parkassistent? Bei einer Webseite muss man sich analog dazu überlegen ob ich eine Webseite mit Standardtemplate möchte oder ob ich durch grafische Schmankerln meine Besucher überzeugen will. Dabei muss man wissen: Der erste Eindruck zählt. Eine professionelle Webseite suggeriert unterbewusst ein professionelles Unternehmen. Der Anspruch an sich selbst und das eigene Unternehmen entscheidet schlussendlich darüber, wie der Webauftritt aussieht und was er kostet – „You get what you pay for“.

![Wieviel kostet eine Webseite? Soviel wie ein Auto...](/images/carchassis.png)

Um dennoch eine annähernd reale Kostenschätzung für eine Webseite zu erstellen müssen einige Faktoren geklärt werden:

- Verwendet die Seite ein Template oder ein maßgeschneidertes Design?
- Wie soll der Inhalt verwaltet werden?
- Wird der Inhalt durch den Auftraggeber erstellt?
- Werden Stockbilder oder professionelle Bilder eines Fotografen verwendet?
- Müssen Daten von einem internen System angezeigt werden?

Es muss also einiges im Vorhinein geklärt werden bevor einer Webseite ein Preisschild angehängt werden kann. Eine direkte Antwort bzw. ein Pauschalangebot auf die Frage: „Wie viel kostet eine Webseite?“ ist unseriös. Zusätzlich zu den initialen Kosten muss auch noch Budget für die laufenden Kosten eingeplant werden. Eine Webseite benötigt Hosting, Updates und regelmäßige Backups. Sonst wird aus dem neuen schönen Webauftritt bald ein gefundenes Fressen für Sicherheitswarnungen, Spammer und Hacker. Hierfür sollten je nach Umfang und gewünschter Ausfallsicherheit ein Wartungsvertrag abgeschlossen werden. Zusätzlich muss auch ein Werbebudget eingeplant werden. Denn was nutzt mir ein Sportwagen ohne Benzin?

![Selbst der beste Sportwagen fährt ohne Benzin keinen Meter...](/images/supercar-unsplash.jpg)

Warum sollte man sich das alles antun, wenn man einfach ein Webseiten-Baukastensystem à la Squarespace verwenden kann? Für einfache Webseiten die lediglich Kontaktinformationen beinhalten ist das sicherlich eine interessante Variante. Man sollte allerdings bedenken, dass sobald etwas nicht mit den Vorlagen des Baukastensystems gelöst werden kann, einige Herausforderungen warten. Abweichen vom Baukasten-Standard ist oft schmerzhaft – für den Entwickler, die Wartung, das SEO-Ranking und das Portemonnaie.

Man kann folgendes festhalten: Die Preisspanne für eine Website ist kaum einzugrenzen. Um ein seriöses Angebot zu erhalten, sollte man die genauen Anforderungen beschreiben. Kritische Fragen seitens der Entwickler sind ein gutes Zeichen, da somit der Scope abgeschätzt wird. Schnelle und kostengünstige Angebote – ohne Details zu kennen – sind unglaubwürdig und können in die Kategorie „Foot-in-the-door“ eingeordnet werden. Auch wenn es verlockend klingen mag, kann sich so ein „Schnäppchen“ im Nachhinein als böse Überraschung entlarven.
