Warum wir ein eigenes WordPress Theme entwickelt haben

Seit dem Start von fotograf.de wurde der Online-Auftritt zweimal komplett neu aufgesetzt. Zu Beginn haben wir fotograf.de tatsächlich per HTML-Editor verwaltet. Wir waren ein kleines Tech-Team und jeder konnte mal eben schnell ein paar Änderungen am Inhalt vornehmen.

Als das Team größer wurde, eine Marketing Abteilung entstand und weitere Länderseiten aufgebaut wurden, kamen wir um ein Content Management System nicht mehr drumrum. Wir hatten keine Designvorgaben und wollten schnell online sein. So haben wir ein WordPress Theme gekauft und die Seiten mit den verfügbaren Bordmitteln gestaltet. Wir schenkten der “Marketing-Seite” verhältnismäßig wenig Beachtung. Sie sollte lediglich statische Inhalte anzeigen und unser Produkt, das Shopsystem bewerben.

Das Theme brachte im Laufe der Zeit allerdings einige gravierende Nachteile ans Licht. Die Performance nahm ab und konnte kaum optimiert werden. Die Assets waren nicht modular aufgebaut und bestanden aus aus tonnenweise JS und CSS Code. Der integrierte Visual Builder generierte stark verschachtelten <div> Tags und Google warnte uns vor einem schlechten Verhältnis von Text zu Code. Zusätzliche Gestaltungselemente wurden über neue Plugins hinzugefügt. Konsistentes Design war daher kaum möglich. Nach einiger Zeit konnten weder für das Theme noch für WordPress selbst Updates eingespielt werden.

Nun stellte sich also die Frage, wie wir unsere zukünftige Internetpräsenz aufsetzen sollten. Da ein kompletter Relaunch bevorstand, waren wir Ergebnisoffen. Grob zusammengefasst lief die Entscheidungsfindung dann folgendermaßen ab:

• Grundsätzlich finden wir WordPress als CMS gut. Der neue Gutenberg Editor (damals noch in beta Version) sieht spannend aus. Außerdem hat das Marketing Team bereits Erfahrung mit WordPress.
• Die Option fertiges Theme kaufen fällt raus. Erstens möchten wir nicht wieder in eine wie oben beschriebene Sackgasse geraten. Zweitens finden auch keins, mit dem wir unser spezielles Screendesign umsetzen können.
• Ist bestimmt nicht so schwer, ein eigenes Theme zu entwickeln?

Wie sich herausgestellt hat, ist es in der Tat nicht schwer. Im Gegenteil, alles ist gut dokumentiert und zu jeder Frage findet sich schnell eine Antwort.

Bootstrap, Gutenberg und ACF

Das Twitter-Framework Bootstrap nutzen wir schon viele Jahre als Grundlage für die meisten Web-Projekte und auch hier war es unsere erste Wahl. Bootstrap 4 liefert eine Menge nützlicher Elemente und insbesondere ein sinnvolles Grid. Die Entwicklung von Seiten und Inhalten wird deutlich komfortabler – und schneller. Insbesondere die Gestaltung für unterschiedliche Browser-Breiten. Also wie und ob Elemente auf Smartphones, Tablets oder Desktop angezeigt werden.

Ende 2018 stand WordPress kurz vor dem Release des neuen Editors namens Gutenberg. Wir waren fasziniert über die komfortable Bedienung. Es gibt bereits eine Reihe vorgefertigter Inhaltsblöcke, die man einfach “Out-of-the-box” hinzufügen kann. Außerdem sieht man schon im Editor, wie es später auf der Seite aussehen wird. Inhalte und Texte können damit komfortabel bearbeitet werden. So entschieden wir uns, das Theme schon für Gutenberg zu entwickeln – obwohl WordPress 5 zu dem Zeitpunkt noch nicht veröffentlicht war.

Dann kam allerdings das große Erwachen. Individuelle Blöcke für Gutenberg zu entwickeln stellte sich als extrem Zeitaufwendig heraus – und wir brauchten viele individuell gestaltete Blöcke um unserem Screendesign gerecht zu werden. Intern haben wir Entwickler, die auf PHP spezialisiert sind – aber wenige Javascript Experten, geschweige denn REACT. Unsere externen (indischen) Entwickler haben Wochen für die Umsetzung eines einzigen Block benötigt. Späterer Anpassungen durch uns war schlicht unmöglich. Was nun?

Die Lösung fanden wir mit ACF. Das Plugin Advanced Custom Fields. Nicht in der Standard-Variante – sondern eine Beta-Version, die mittlerweile offiziell verfügbar ist.
Die Idee von ACF ist so simpel wie genial, die Entwicklungsphase verlief völlig reibungslos. Über ACF kann strukturierter Inhalt definiert, in Feldgruppen zusammengefasst und mittels PHP einfach ausgegeben werden. Zum Beispiel definiert man eine Feldgruppe, angefangen mit einem einzeiligen Eingabefeld, einem Texteditor und anschließend ein Bild. Diese Elemente können dann im Theme an gewünschter Stelle auf der Seite ausgegeben werden. Mit ACF 5.8.0 geht das auch für Blöcke – die mit Hilfe des Gutenberg Editors beliebig oft und an beliebiger Stelle auf der Seite platziert werden können.

Die Entwicklung neuer Blöcke dauert mit PHP Kenntnissen nur noch ein paar Stunden (oder Minuten je nach Komplexität).

Kleiner Nachteil: das Editieren ist nicht direkt im “Design” möglich. Es gibt aber eine Vorschau der Blöcke und Änderungen werden automatisch neu geladen.

Größter Vorteil: nachträgliche Änderungen. “Können wir den Text vielleicht doch unter dem Bild anzeigen?” Mit ACF ist das kein Problem. Einfach im Template die beiden Zeilen tauschen und die Ausgabe wird auf allen Seiten angepasst. Wohingegen bei Standard-Gutenberg Blöcken der Inhalt per HTML auf der Seite gespeichert wird. Dort müssten Änderungen durch eine aufwendige Migration auf allen Seiten angepasst werden.

Workshop(s) & Launch

Neben der Seite www.fotograf.de gibt es auch weitere Länderseiten, zum Beispiel www.gotphoto.com für die USA, www.gotphoto.co.uk für UK, www.gotphoto.at für Österreich, usw. Die Seiten unterscheiden sich sprachlich aber auch inhaltlich. Das bedeutete, dass wir unser Team vergrößern mussten, um die Seiten anzulegen und zeitnah zu launchen. So sind wir dabei vorgegangen:  

1. Ausführliche Dokumentation erstellt
2. Workshops durchgeführt um Mitarbeiter zu schulen
3. Grafiken exportiert und aufbereitet
4. Seiten erstellt
5. Redirects eingestellt
6. URL’s und DNS umgestellt

Nützliche Hinweise zu Punkt 3 – Grafiken

Die Seiten leben von Grafiken. Für Mockups und Fotos, die auch auf hochauflösenden Retina Displays scharf sein sollen verwenden wir das Plugin Lazysizes. Das sorgt dafür, dass Bilder zum einen “nachgeladen” werden. Sie blockieren also nicht den initialen Ladevorgang der Seiten. Außerdem werden sinnvolle Bildgrößen geladen – abhängig von der benötigten Größe bzw. Auflösung des Displays.

Der Vorteil von SVGs ist, dass sie auf jedem Display scharf angezeigt werden. Schließlich ist es ein vektorbasiertes Format. SVGs die wir aus Sketch exportiert haben, waren jedoch verhältnismäßig groß und enthielten Informationen, die wir so nicht auf veröffentlichen wollten. Schließlich kann der XML code der SVGs auch von Google indiziert werden. Deshalb ist meine Empfehlung ein Tool wie SVGOMG zu nutzen – damit wird die Größe deutlich reduziert und unnötige Informationen werden entfernt.

Redirects (Punkt 4)

Vor einem Relaunch sollten unbedingt alle bestehenden URLs überprüft und ggf. Redirects eingestellt werden. Damit Besucher, die über alte Links kommen, keinen 404 Error erhalten und der SEO Wert nicht negativ beeinflusst wird. Wir hatten eine ganze Menge alter, nicht mehr verwendeter URLs. Redirects können mit diversen Plugins verwaltet werden – zum Beispiel mit YOAST, ein weit verbreitetes SEO Plugin. Ich empfehle jedoch das Plugin Redirection – da zum einen Redirects gezählt werden und auch 404 Fehler gespeichert werden. Aus diesen können dann einfach Redirects erstellt werden.

URL’s umstellen

Zum Schluss mussten nur noch die URLs umgestellt (mit dem Plugin GoLive) und die DNS Einstellungen der Domain geändert werden – und endlich war (eine) Seite live.