Alle so schön, nicht bunt … ähmm, ruhig hier

Es kam wie’s kommen musste: mit guten Vorsätzen gestartet, mit viel Enthusiasmus die ersten Beiträge reingeklopft, irgendwann mal ein paar Sachen aus der vorproduzierten Schublade gezogen oder mit schlechtem Gewissen auf den letzten Drücker was zusammen gestöpselt … und dann ist das Bloggen mehr oder minder eingeschlafen.

War es der noch sparsamere Alltagstrott in Coronazeiten in denen nur das halbe Leben passiert und ist mir deswegen die Inspriation ausgegangen? Und überhaupt: gefühlt schien ich nicht der einzige zu sein. Mein RSS-Reader zeigte immer weniger an Beiträgen. Ohne das entschuldigen zu wollen, aber rückblickend merke ich, wie mir das hilft, wenn von außen andere mit Themen kommen und mich motivieren auch mal wieder was abzusondern.

Ein Blick in den Maschinenraum brachte dann etwas mehr Klarheit: ja, es gibt wohl noch den einen oder die andere mehr, denen es ähnlich gehen mag wie mir. Aber mindestens so viel war: meine Links die ich so sorgfältig mal gesammelt hatte, funktionierten nicht mehr so wie gedacht. Umgezogene Seiten, die Ablösung von WordPress durch Ghost, die Restrukturierung von Tags und/oder Kategorien innerhalb eines Blogs oder auch mal nicht getaggte Beiträge … alles Dinge die meine RSS-Lösung natürlich aus der Kurve werfen. Ist (für mich) nachgeschliffen. Update im Gist ist auch vorhanden.

Wie schon gesagt: Nairobi hat derzeit nicht so rasend viel berichtenswert Neues zu bieten. Also: wie wäre es mal mit einem WordPress Thema?

Gutenberg freundliches Starter Theme

Nach meinem Talk auf dem Meetup Nairobi über Gutenberg vs. Pagebuilder war ich sehr ermutigt künftige Projekte nur noch mit Gutenberg anzugehen. Und die Möglichkeiten von Gutenberg sind ja seither nur besser geworden. Zusammen mit der Strategie meiner kenianischen Firma kundenspezifische Themes preislich gegen den zusammen geworfenen Kram aus Pagebuildern auf dem deutschen Markt zu positionieren ergibt sich daraus genau die Anforderung.

Ich gestehe freimütig: bislang habe ich schon das ein oder andere Mal auf Pagebuilder zurückgegriffen. Nicht aus Liebe oder gar Überzeugung, sondern mehr aus der Notwendigkeit die gestalterischen Anforderungen von Kunden (oder deren Agenturen) mit einem überschaubaren Budget zusammen zu bringen. Die Basis für derlei waren i.d.R. Childthemes, gerne von freien, im WordPress Repo gehosteten Themes. Aber auch da gab es den ein oder anderen Sündenfall, wenn der Gestalter schon mit ” … ich hab da ein ganz tolles Theme für $49, das ich ein bisschen angepasst habe …” vorne wegmarschierte. “… ich habe angepasst …” hiess dann in aller Regel: ich hab im Photoshop was aufgemalt, wie es eigentlich aussehen sollte, wie du das im Code löst, ist nicht mein Problem. Wir kennen das glaube ich alle.

Vom Child zum Starter

Der nächste logische Schritt für mich war es dann nun die wie auch immer gearteten Kinder von anderen durch eigene Zöglinge zu ersetzen. Ich hab mich also auf die Suche gemacht um rauszufinden, was denn aktuell so an Starter Themes gehandelt wird.

Click here to display content from Twitter.
Erfahre mehr in der Datenschutzerklärung von Twitter.

Und – wie gesagt – gerne etwas, das ohne großen Deployment Foo daherkommt. Immerhin muss ich auch meine kenianischen Kollegen noch auf dem Weg mitnehmen. Und dort sind Kaufthemes und PageBuilder noch sehr viel mehr an der Tagesordnung als bei uns. Auch weil die Budgets noch schmaler sind als bei uns.

In meiner Sammlung landeten schliesslich:

Relativ schnell aus dem Rennen – ausschliesslich aufgrund meiner Anforderungen waren z.B. WPrig oder Sage. Siehe unter Deployment. Auch das lange von mir favorisierte Bones fiel letztlich meiner Faulheit mich nebenbei auch noch in SASS einzuarbeiten zum Opfer. Die Gantry Themes waren ebenfalls relativ schnell aussortiert. Ein Theme, das nicht ohne Plugin (Gantry in dem Fall) auskommt ohne vernünftig zu arbeiten erschien mir auch im Feld als zu fehleranfällig. Nicht im Sinne von Technik, aber im Umgang von Benutzern damit.

Da das ganze auch mobile-friendly sein sollte, kam der Aspekt Dateigrößen des Themes in Spiel. Über die Spannbreite von wenigen kB bis hin zu mehreren MB war ich dann zugegebenermassen doch erstaunt. Bootstrap Basic bringt z.B. stattliche 14 MB auf die Waage, während das Naked WordPress mit schlanken 76 kB daher kam. Aber der Name war da in der Tat Programm. Etwas zu naked für meine Ansprüche. Als guten Kompromiss habe ich mich dann für das Gutenberg Starter Theme von Dessign entschieden.

Was ich am Gutenberg Starter Theme mag

Es ist mit 766 kB einigermassen schlank. Dafür sind die wesentlichen Dinge, die man in einem zeitgemässen Layout sehen will soweit drin und über den Customizer ansteuerbar. Der Code ist verständlich geschrieben. Ein paar einfache Anpassungen in einem aktuellen Projekt, wie z.B. das ummodeln des Footers in einen horizontal dreigeteilten Abschnitt (mit unterschiedlichen Backgrounds) in dem jeweils Widgets unterzubringen sind, war kein großes Problem. Oder auch den Customizer um eigene Rubriken zu erweitern oder im konkreten Projekt überflüssige rauszunehmen ist keine Raketenwissenschaft.

Was mir weniger gefiel

An ein paar Stellen hätte ich mir das Theme manchmal etwas mehr “widgetized” gewünscht. Die Abfrage von Socialmedia Links für den Footer z.B. hat da für mich, wenn überhaupt, nur dann dort etwas verloren, wenn sie über ein Menü im Widget dort hin kommt und nicht direkt über den Customizer. Auch die HTML-Struktur ist nicht immer ganz sauber. Mehrere <footer> oder <header> im Quellcode sind nicht die reine w3c Lehre, ebenso gibt es in paar Sachen, die als <div> aufgebaut sind, wo es nach meiner Meinung semantisch bessere Varianten gibt.

Aber das sind keine gravierenden Dinge, lediglich ein paar Sachen, die es im Rahmen der eigenen Entwicklung einzufangen gilt. Der nächste logische Schritt ist (wenn ich das konkrete Projekt in dem ich das Theme gerade benutze abgeschlossen ist) das in ein eigenes Repo zu überführen und die Basis, die für die spezifische Entwicklung ausgerollt wird, anzupassen.

Apropos ausrollen, also Deployment

Wie schon eingangs erwähnt wollte ich bewusst etwas haben, dass nicht vorher npm, SASS, composer und weiss ich nicht was abverlangt. Der Grund: mein Setup ist einigermassen schmal, weil es auch meinen kenianischen Kollegen leicht zu vermitteln sein muss:

  • Für die lokale Entwicklung habe ich Local im Einsatz
  • das kundenspezifische Theme oder Plugin wird über ein privates GitHub Repo verwaltet. Sehr erfreulich, dass diese vor nicht all zu langer Zeit aus der kostenpflichtigen Version losgelöst wurden und nun frei zur Verfügung stehen.
  • für die Anbindung Mac zu GitHub ist bei mir Tower zuständig – ja, sorry … ich bin halt im Tiefsten meines Herzens doch noch der Klicki-Bunti-Typ
  • der zu entwickelnde Teil (Theme oder Plugin) wird vom entsprechenden lokalen Code Ordner (Tower) in die Local Sites (Local) per Symlink eingehangen (nicht das ich das mit dem Terminal nicht könnte). Auf die Art und Weise kann ich meine Änderungen im Code sofort in der lokalen Entwicklung nachvollziehen. Hat das eine gewisse Reife erlangt, wird via Tower die Version commited, getaggt und der Push zum privaten GitHub Repo ausgelöst
  • Auf der Seite des Kunden läuft für den Bezug der aktuellen Version Andy Fragens GitHub Updater, so dass unsere Eigenentwicklungen über den normalen Updatemechanismus von WordPress eingespielt werden können.

Diese Entwicklungsumgebung ist für hiesige Verhältnisse komplex genug und dennoch immer noch leicht genug zu vermitteln. Das Thema Tower muss ich ggf. nochmal auflösen, weil die wenigsten mal eben bereit sind $69 pro Jahr in ihre Werkzeugkiste zu investieren. Ich verstehe, wenn Sie die bei mir verdiente Kohle lieber in andere, für Sie notwendigere Dinge stecken wollen. Vielleicht mache ich auch irgendwann mal ein Incentive daraus oder kalkuliere mal einen Schwung Lizenzen in ein Projektangebot ein. Zum Glück gibt’s aber auch genügend freie Alternativen. Ich hab vor einiger Zeit nach 3 oder 4 Enttäuschungen aufgehört alle durchzutesten und habe Geld auf der Problem geworfen. Mir taugt’s.

Wie heisst Euer Favorit, wenn’s an Starter Themes geht?

Schreibt mir gerne in Eure Kommentare, wenn ihr für Euch andere, vielleicht bessere Starter Themes entdeckt habt. Auch gerne warum die für Euch besser funktionieren. Oder wenn ihr sachdienliche Hinweise für die Entwicklungsumgebung habt um das weiter zu verschlanken, bin natürlich dankbar.

3 Kommentare zu „Alle so schön, nicht bunt … ähmm, ruhig hier“

  1. Hallo Stefan,

    vielen Dank für den Einblick in dein Setup, sehr spannend!

    Ich finde übrigens, dass Page Builder auf jeden Fall ihre Berechtigung haben – aus den genannten Gründen, aber auch, weil der Gutenberg Editor in meinen Augen nach wie vor ziemliche Interface-Schwächen hat. Für mich ist es immer noch ein absolutes Gehampel, bei ineinander verschachtelten Blöcken den richtigen Group-, Column- oder Parent-Block zu erwischen. Auch die jeweiligen Block-Einstellungen sind zum Teil sehr unterschiedlich gelöst. Und dann bringen verschiedene Block-Erweiterungen alle lustig ihre verschiedenen Paddings mit, sodass es in Gefummel ausarten kann, alles auf eine Linie zu kriegen.

    Der Vergleich hinkt, aber das alles ist in Elementor so viel klarer gelöst.

    1. Ich geb Dir recht – das darf alles noch sehr viel besser werden in Gutenberg. Wird es aber auch. Was mich – da komme ich wieder auf die Mobiltauglichkeit zurück – am meisten an durchgehend allen Pagebuildern stört ist der überbordende Code den die allesamt produzieren. Ich glaube das könnte mein nächster Artikel werden: ein Shootout zwischen verschiedenen Pagebuildern und Gutenberg um mal eine gleichaussehende Seite zu produzieren und dann draufzuschauen, wer welchen Code – Größe und Semantik – produziert hat.

Kommentarfunktion geschlossen.

Nach oben scrollen