Mist. Mein Theme unterstützt WooCommerce nicht. Somit gibt es auch keinen Shopping Cart. Ich mache mich schon für eine komplizierte und langwierige Entwicklungsorgie bereit.
Ask Google: «woocommerce add cart theme» (erstaunlich, dass Google das sogar versteht.
Oh Wunder. Die erste Seite ist ein absoluter Treffer. In 5 Minuten ist alles erledigt, so dass noch Zeit bleibt mein Wissen zu teilen:
3 Steps To Add WooCommerce Cart Icon With Cart Count To Your Theme’s Header
Freund: Hilfe, meine Seite wurde gehackt. Was muss ich tun?
Ich: Hast du WordPress und die Plugins mal aktualisiert?
Freund: Das letzte Mal vor sechs Monaten.
Ich, innerlich stöhnend: Ok, dann aktualisiert mal die Seite und dann schauen wir weiter.
WordPress selber behaupten, dass 27% des Internets auf ihrem CMS läuft. Das entspricht zwar noch nicht der Dominanz, welche Windows mal auf dem Desktop hatte, aber macht diese Plattform dennoch zum lukrativen Ziel für Hacker.
WordPress ursprünglich als Blogginplattform angedacht wird heute für alle möglichen und unmöglichen Typen von Seiten eingesetzt: Von hochfrequentierten Newsseiten, über E-Commerceseiten bis hin zu kleinen Brochureware Webseiten mit einer handvoll einfachen Seiten.
Sinnvoll?
Ich glaube nicht. Daher kurz zu den Basics.
In meiner Webkarriere habe ich mit drei Arten von Systemen gearbeitet:
Mein fast 10 jähriges Blog hat in den fast 10 Jahren Lebenszeit auch schon alle Systeme durchgemacht: Drupal, WordPress, Jekyll und Grav (wobei nur als Test).
Während die Flatfile CMS sicher nicht die Eierlegendewollmilchsau sind, bieten sie doch einige herausragenden Vorteile.
Die Problemzonen von WordPress sind weder der Bauch noch die Beine. Ich sehe 5 Kernprobleme oder Herausforderungen, wenn man mit Datenbankgestützten Systemen (und im Speziellen mit WordPress) arbeitet:
1. Die ganze Deployment und Staging Sache. Inhalt auf Dev, Test und Prod ist nie wirklich synchron. Dazu kommt, dass viele Konfigurationen in der Datenbank gemacht werden. Diese über die verschiedenen Server zu ziehen ist mühsam und fehleranfällig. Dazu weiter erschwerend ist auch die Sache mit dem Inhalt. Eigentlich müsste das VCS (z.B. Git) sowohl Files als auch Datenbank beinhalten.
2. Gigantische schöne (und grosse) Themes, vor allem für WordPress. Doch mit dem Theme alleine ist nicht genug. Damit das Theme auch so funktioniert, wie es auf dem Screenshot ausschaut, muss noch Sliderplugin xy und Pagebuilder ab und Module rs installiert werden.
All diese Themes und Plugin haben meistens ein Ziel: Möglichst viele Usecases möglichst Drag’n’Drop zugänglich zu machen, damit jeder Idiot sie benutzen kann. Der Preis dafür sind komplexe und gigantische Plugins und Themes mit zum Teil kompletten Applikationen innerhalb der Webseite.
Dazu wird der Source Code mit unnötiger Divitis geflutet und die Pagebuilder führen dazu, dass Styledefinitionen pro Element gemacht werden, was wiederum zu Inkonsistenz im Design führt.
3. Backup ist teuer oder ein Gebastel. Zwar gibt es zumindest für WordPress entsprechende Plugins, aber so richtig glücklich bin ich damit nicht geworden. Kommt dazu, dass eines der Plugins, die Settings Datei per se nicht inkludiert. Viele der Plugins setzen zudem eine Pro Version voraus, welche monatlich ein paar $$ kostet (Beispiel Vaultpress).
Die zweite Option ist mit ein paar Scripten selber etwas zu bauen und das dann auf Amazon S3 zu speichern. Funktioniert gut und zuverlässig, aber ist halt ein Gebastel und für den kleinen Mann eher undenkbar.
4. Unzählige Updates. Viele Module bringen die gewünschte Funktionalität und diese läppern sich schneller zusammen als einem lieb ist: Formulare, Google Analytics, Security, S3, Slider, E-mail und und und. Je grösser die Anzahl umso regelmässiger gilt es zu aktualisieren. Mit jedem neuen Stück Code werden Sicherheitslücken gestopft und neue geöffnet.
Entweder vor jedem Update ausgiebig in einer Testumgebung testen (wobei wir wieder bei Problem 1 wären) oder auf gut Glück in der produktiven Umgebung aktualisieren und hoffen und beten, dass alles noch funktioniert.
5. Security. Ich bin bei weitem kein Security Experte, aber SQL Injections gehören zu den viel gesehen Sicherheitslücken. Die Rechnung ist daher ganz einfach: ohne Datenbank gibts auch keine SQL Injections. Weiter wenig förderlich für die Sicherheit ist der Einsatz von PHP als Template Engine.
Nachdem ich über WordPress hergezogen bin, möchte ich schauen, was die Flat File CMS so viel besser macht. Ich nehme hier insbesondere Bezug auf Grav, aber die anderen werden eine ähnliche Mechanik haben.
1. Inhalt liegt als Markdown in stinknormalen Textdateien. Metadaten können im Kopf des Files «ad-hoc» definiert werden:
---
title: Testartikel
header_image: header.jpg
taxonomy:
category: [Blog]
---
2. Templates sind einfach und direkt. Bei Grav kommt Twig zum Einsatz. In den Templates kann einfach auf diese Header Informationen zugegriffen werden. Kein PHP in Templates bedeutet mehr Sicherheit.
Theoretisch könnte jeder Artikel eigene Headerinformationen haben, was jedoch wenig förderlich für die Wiederverwendbarkeit ist. Das fehlende «DB-Schema» ersetzt die Planung nicht!
3. Von Grund auf portabel, versioniert und mit Backup: «git commit, git pull«. Sowohl der Code, als auch der Inhalt ist versioniert. Für Staging: git pull und auf einen Webserver kopieren und schon läuft die Seite 1:1, wie in der Produktion. Damit ist sowohl das Deployment Problem als auch das Backup Problem gelöst. Eine veraltete Testumgebung ist mit Grav und Git Vergangenheit.
Im Klartext: Ich kann die komplette Webseite in Git ablegen und sie auf jeden beliebigen Webserver klonen und arbeiten.
Für versionierte Gitbenutzer können alle möglichen Gimmicks eingebaut werden: Autodeployment via Webhooks, Branching Strategie …
4. Grav bietet eine möchtige Form API und ein Plugin System. Zwar gibt es noch nicht annähernd die Flut an Plugins, wie sie in der WordPress Welt vorhanden sind, aber das ist auch nicht zwingend etwas schlechtes.
Theoretisch könnte auch eine Gravseite von der Pluginseuche befallen werden, die direkte Codenähe macht es allerdings eher unwahrscheinlich oder zumindest weniger schlimm, als dies bei WordPress der Fall ist. Ein Google Analytics Tracker z.B. liesse sich mit genau zwei Zeilen (1x Config, 1x Template) einbauen.
5. Geschwindigkeit. Die Einfachheit macht die Systeme schnell. komplizierte Mechanismen, komplexe und schlechte programmierte Plugins fallen weg. Auch Anfragen an die Datenbank fallen weg. Für hohe Lasten mit vielen gleichzeitigen Zugriffen ist wahrscheinlich eine Datenbank besser, aber im Bereich von Otto-Normalsterblich sicher nicht. Für die Optimierung muss lediglich am Webserver Hand angelegt werden.
Wo Licht ist fällt auch Schatten. Grav zu skalieren wird wohl nicht ganz so einfach sein, wie das mit einer Datenbank möglich ist. Solange ein Server ausreichend ist, sicher kein Problem, aber sobald nach Loadbalancing gefragt ist, könnte es schwieriger werden. Ich kenne mich jedoch zu wenig damit aus, um eine qualifizierte Aussage zu machen.
Eine Aussage kann ich jedoch zu Content Management machen. Wenn Content aktiv verwaltet wird und damit gearbeitet wird ist Grav nicht wirklich komfortabel. Ich habe dieses Blog hier auf Grav migriert und ein wenig damit gearbeitet. Spass hat das nicht gemacht.
Es gibt ein Admininterface, aber um hunderte von Seiten zu verwalten… ich weiss nicht so recht. Da fühle ich mich mit WordPress wohler.
Für mich ist WordPress für kleine hauptsächlich statische Seiten definitiv gestorben. Der Overhead und die Risiken und damit die Wartung sind zu gross, als dass die Vorteile überwiegen würden.
Dazu hat mich die Portabilität mehr als überzeugt und bei einem schief gelaufenen Update einfach mal schnell auf eine vorherige Version zu wechseln gibt mir sehr viel Sicherheit. Auch ein Serverwechsel würde nur wenig Minuten dauern: «git clone».
Auch die mächtigen Pagebuilder können mich nicht überzeugen. Im Gegenteil: Für mich als Developer sind sie eher hinderlich, mühsam und komplex und für totale Anfänger bergen sie das Potential die Seite zu zerstören.
Kunden sind zufrieden, wenn sie Texte schnell und einfach anpassen können und sind gerne bereit für grössere Änderungen zum Profi zu gehen.
Geht es in Richtung Blog oder Community mit viel Interaktion werde ich nach wie vor auf WordPress und Co. setzen.
Vor ca. 3 Monaten habe ich mein WordPress Blog durch Jekyll abgelöst und habe das Blog auf Github verschoben. Funktioniert eigentlich wunderbar, ausser dass mir Ruby nicht sehr sympathisch ist, bzw. ich keine Zeit und Lust habe mich mit Ruby zu beschäftigen, daher die Suche nach einem anderen Static Site Generator (SSG). Es gibt anscheinend solche in PHP, aber scheint irgendwie nicht zu passen und Java gibt es sicher auch, aber nein Danke und so landete ich bei Wintersmith (node.js basierend).
Github Pages basieren auf logischerweise auf Git. Es hat mich gestört, dass ich ständig das Gitrepository haben musste und auf Github zu edtieren ist zwar möglich aber nicht wirklich eine Freude. Manuell die Seite jedes mal zu builden schien mir auch zu kompliziert, daher die Idee des Dropbox Hostings. Der Workflow dazu sieht wie folgt aus:
Als Webserver habe ich nginx. Ich habe mich seit einigen Monaten von Apache verabschiedet. Mir scheint nginx logischer und einfacher zu konfigurieren und hinzu kommt, dass er anscheinend schneller und weniger ressourcenhungrig zu sein scheint (das ist eine nicht fundierte Aussage). Es fehlt daher lediglich noch eine Regel, um subdomains automatisch auf einen Ordner zu mappen, also blog.rapsli.ch -> /vaw/www/public/blog und schon ist meine eigene Cloud ready. Die Konfiguration für nginx dafür sieht wie folgt aus (hier gefunden).
server {
listen 80;
server_name ~^(.*).nginxdomain.com$;
#if directory doesn't exist
if (!-d /home/domains/nginxdomain.com/public/$1) {
rewrite . http://www.nginxdomain.com/ redirect;
}
# Sets the correct root
root /home/domains/nginxdomain.com/public/$1;
}
Wie gesagt habe ich vorher mit Jekyll gearbeitet und ich muss sagen, der Build Prozess ist schleppend langsam. Mein Blog mit knapp 600 Einträgen hat doch eine gewisse Zeit gebraucht. Mit Node und Wintersmith geht das alles merklich schneller, doch das ist eigentlich nur der kleinere Teil der Erfolgsstory.
Die asynchrone Natur von Node.js und die damit verbundenen Vorteile kommen in diesem Szenario richtig gut zur Geltung:
Im Normalfall, z.B. mit PHP, könnte das alles nur seriell abgearbeitet werden. Dank der Asynchronität von Node.js kann das jetzt alles parallel bearbeitet werden, was sich besonders im Zusammenspiel mit der Dropbox API positiv zeigt -> die meiste Zeit muss ja eh gewartet werden.
Ich bin immer noch kein Designer, aber die aktuellen Tools (besonders die Grid Layouts) machen vieles einfacher. Des Weiteren ist man beim Design für einen Static Site Generator viel flexibler und schneller, da keine Datenbank und komplexe Logik dahinter steckt. Natürlich muss dadurch auch der eine oder andere Kompromiss eingegangen werden, doch dazu bin ich gerne bereit:
Bei Schritt 1 ist lediglich HTML, CSS und Javascript vorhanden -> ultra performant und zackig.
Zuerst habe ich mit dem Gedanken gespielt, irgend ein HTML Template zu nehmen, doch die Neugier mal wieder etwas komplett selber zu machen hat dann doch gesiegt. Da ich kein grosser Held mit Photoshop bin, wird es gezwungener Massen ein Design ohne viel Schnick Schnack und ohne aufwändige Grafiken, aber das auch auch irgendwie seinen Reiz.
Das Grundgerüst steht aber es hat noch viele Lücken. Noch länger mit der Migration warten? Nein, wollte ich dann doch nicht. So habe ich jetzt das Redesign schon mal publiziert und werde dann über die Zeit die noch offenen Lücken stopfen.
Auch hier wieder: Grid Systems (Twitter Bootstrap) seid dank, ist das eigentlich nicht allzu aufwändig. Im Detail hat es noch Potential nach oben, aber kommt Zeit kommt Rat. So wird auch hier sicher noch der eine oder andere Fehler behoben.
Die URL Struktur habe ich bei der Gelegenheit auch gleich mal angepasst. Diese war bisher: rapsli.ch/[titel] und ist jetzt neu blog.rapsli.ch/posts/[jahr]/[titel]. Damit nicht alle Links komplett kaputt gehen habe ich 600 rewrite rules gemacht, welche in der nginx Config liegen. Einzig die Migration der Kommentare habe ich leider noch verhauen, dabei wäre es so einfach gewesen, hätte ich nur 1 Minute länger gelesen, aber das kommt davon, wenn man morgens um 1 Uhr noch so etwas machen will.
Noch gibt es einige Dinge, welche ich zu erledigen habe:
In meinem Workflow setze ich die folgenden Tools ein:
Alles in Allem: Sehr zufrieden und die darunter liegende Infrastruktur ist super! Falls du interesse hast, ein Alpha Tester zu sein, darfst du dich gerne mal bei mir melden.