Was ist Sitebuilding - für mich!
An dieser Stelle möchte ich gar nicht so sehr eine Begriffsdefinition aufschreiben, sondern vielmehr erzählen, was für mich wichtige und unwichtige Teile des Prozesses sind. Das mag jeder für sich individuell anders definieren und das ist vollkommen in Ordnung, denn jeder Sitebuilder hat ein anderes Stack an Fähigkeiten zur Verfügung oder setzt seine Schwerpunkte anders. Was ich hier im Folgenden also beschreibe ist mein persönlicher Weg, mit dem ich bisher viele Projekte erfolgreich umsetzen konnte.
Fangen wir also an: Als Sitebuilder kann ich, mit dem richtigen Content-Management-System, komplexe Website-Strukturen aufbauen und benötige dazu im besten Fall keinen technischen Background über das System selbst, eingesetzte Server- oder andere Third-Party-Technologien. Man nutzt dieses System also mit allen seinen Möglichkeiten, wie es zu einem bestimmten Zeitpunkt (dem der Projektumsetzung) existiert.
Um das deutlicher zu machen, kann man das mit einem Autokauf vergleichen: Ich konfiguriere mir das Auto mit all seinen Motorisierungs-Optionen und Ausstattungsmerkmalen, die vom Händler angeboten werden. Ich nehme aber kein Werkzeug in die Hand und schraube am Motor, dem Auspuff oder der Scheibenwischeranlage rum, weil diese mir in den falschen zeitlichen Abständen wischt. Hätte der Autobauer seinen Job gut gemacht, könnte ich das Intervall ohne Probleme über den Bordcomputer an meine Bedürfnisse einstellen.
Um die einzelnen Konfigurations-Optionen zu verstehen, gehört beim Autokauf nicht viel zusätzliches Verständnis dazu. Anders ist das bei einem CMS. Stand Februar 2023 gibt es auf drupal.org insgesamt 49.723 zusätzliche Module, die die Kernfunktionalität von Drupal erweitern. Davon sind 9.394 für die letzte Drupal Version 9 einsetzbar und immerhin schon 3.912 Module wurden bislang auf die aktuellste Drupal Version 10 portiert. Das sind eine Menge Module, die man kennen und können müsste. Um dabei überhaupt zielgerichtet das richtige zu finden, muss man viel Recherche betreiben und unzählige Tutorials lesen. Darauf gehe ich aber später noch genauer ein.
Ein ebenso wichtiger, wie auch problematischer Punkt ist, dass man auch mal “Nein” sagen muss. Dazu ist es wichtig mit dem Kunden gemeinsam einen Weg zu skizzieren, wie das Ziel so angepasst werden kann, dass alle damit zufrieden sind. Im Idealfall ist das neue Ziel noch besser als das bisherige. In solchen Momenten sind alle Beteiligten gezwungen über den Tellerrand hinauszusehen und eigene Denkmuster zu durchbrechen. Aber natürlich kann es dann an dieser Stelle auch heißen, dass die Zusammenarbeit nicht fortgeführt werden kann. Das ist mir bislang aber noch nicht passiert. Drupal bietet hier einfach zu viele alternative Wege, um ein Ziel zu erreichen oder ein neues, verändertes Ziel zu definieren.
Grundlagen in PHP von vorteil
Des Weiteren hilft es sehr, sich ein paar Grundlagen in PHP anzueignen. Damit wird man definitiv keine komplexen Probleme lösen und das ist auch nicht der eigentliche Grund. Manchmal kommt man als Sitebuilder an einen Punkt, an dem man auf externe Hilfe angewiesen ist. Meistens ist das der Fall, wenn ein eingesetztes Modul einen Bug hat oder man den Maintainer um ein bestimmtes Feature bitten will. Dann hilft es, wenn man grob die technischen Anforderungen beschreiben kann oder im Code schon die Stelle gefunden hat, die zu einem Fehler führt.
Mit der Ablösung von PHP durch Twig im Frontend-Template-System in Drupal 8, muss man hier heutzutage kein tiefergehendes Wissen mit sich bringen. Das bringt mich zum nächsten Punkt: das Frontend bzw. Website-Theming.
Website-Theming
Für mich gehört es zwingend zum Prozess dazu, das Layout einer Website als Sitebuilder umsetzen zu können. Ein Layout von der Stange kommt für mich einfach nicht in Frage. Da ich einen grafischen Background habe, gehört die Erstellung des Website-Layouts zu meinem Sitebuilder-Stack dazu. Das vereinfacht in der Praxis sehr viele Abstimmungsprozesse, da ich bei der Layouterstellung parallel die Funktionalität der Website mitdenken kann.
Die Umsetzung des Layouts, also das Theming, ist somit die einzige Stelle im Prozess, an der ich mit Code in Form von HTML, CSS und Javascript zu tun habe.
Zusammenfassend kann man also sagen, dass ich - mit Ausnahme des Themings und Twig-Templatings - fast ausschließlich mit dem User Interface von Drupal arbeite. Und da kommen wir zu dem Punkt, was Sitebuilding für mich nicht ist: Code!
Wie viel habe ich also mit dem Code zu tun?
Im Idealfall habe ich mit Code nichts zu tun. Ebenso sind mir die technischen Aspekte im ersten Schritt egal. Was für mich zählt ist, dass das System funktioniert und die Entwickler einen guten Job gemacht haben. Ich muss (und will) nicht wissen, WIE das System technisch aufgebaut ist, aber ich muss wissen, WAS ich damit machen kann.
Ein paar Worte zu den angesprochenen Hürden, will ich auch noch ergänzen. Mit der Einführung von Drupal 8 hat sich für Sitebuilder leider viel ins Negative gekehrt. Und nicht wenige von uns haben damals das Handtuch geworfen oder sind bei Drupal 7 geblieben. Man wurde gezwungen, sich mit Technologien auseinanderzusetzen, mit denen man noch nie etwas zu tun hatte und für deren Funktionsweise das technische Grundverständnis fehlt. Man benötigte als Sitebuilder plötzlich eine Entwicklungsumgebung. Ich kann mich erinnern, dass ich damals über 6 Monate gebraucht habe, um ein System zu etablieren, mit Drupal 8 einigermaßen sinnvoll zu arbeiten. Aus ein paar tausend Dateien in Drupal 7, die man mittels FTP-Client problemlos hin- und herschieben konnte, sind unter Drupal 8 zehntausende Dateien geworden. Das ist mittels FTP-Client nicht mehr zu bewerkstelligen und benötigt dafür eine ganz andere Arbeitsweise.
Diese Hürden sind bis heute existent und stellen für jeden Sitebuilder, der sich Drupal anschauen möchte, ein fast unlösbares Problem dar.
Hat man sich aber einmal durchgekämpft, wird man mit einem beeindruckenden System belohnt!
Von der Idee zur fertigen Website
Auf die grundlegenden Schritte einer Projektumsetzung möchte ich hier gar nicht im Detail eingehen, da sie in vielen Projekten identisch funktionieren. Ich picke mir hier nur die Sitebuildingrelevanten Sonderwege raus, die sich unterscheiden können.
Spannend wird es vor allem dann, wenn Kundenanforderungen nicht oder nicht wie gewünscht umgesetzt werden können. Das kann z.B. der Fall sein, wenn ein entsprechendes Modul nicht oder mit einem anderen Funktionsumfang zur Verfügung steht. So manches Projekt steht damit auf der Kippe oder kann tatsächlich nicht umgesetzt werden. Das Wissen darüber muss aber schon in der Angebotsphase existieren, denn als Sitebuilder kann ich mir die fehlende Komponente nicht selbst programmieren. In einem solchen Fall die Programmierung, während der Umsetzung extern beauftragen zu müssen, übersteigt meistens den zeitlichen und finanziellen Rahmen. Ich muss in der Angebotsphase also schon sehr genau darüber Bescheid wissen, ob und wie ich einen Auftrag umsetzen kann. Und das führt direkt zu einem zentralen Bestandteil in der Arbeit eines Sitebuilders: Recherche, Recherche, Recherche!
Wie die Recherche zum Ziel führt
Wie oben schon beschrieben, ist die Drupal-Welt riesig. Deshalb ist es wichtig, sehr gut darüber Bescheid zu wissen, wie ich an relevante Informationen komme. Hier hat jeder seine ganz eigene Vorgehensweise. Für mich hat es sich bewährt, die Anforderung in verschiedene Schlagwörter und Fragestellungen zu überführen. Dabei darf man ruhig kreativ sein, denn die große Herausforderung ist oftmals an dieser Stelle, wie ein Entwickler zu denken. Module werden schließlich von Entwicklern programmiert und auf drupal.org eingestellt. Deshalb ist die Beschreibung der Module teilweise sehr technisch oder mit einem anderen Vokabular geschrieben, wie man es als Sitebuilder erwarten würde. Von der Benennung der Module ganz zu schweigen.
Meine erste Anlaufstelle ist nicht die Modul-Übersicht auf drupal.org, sondern Google. Gerade hier habe ich die Möglichkeit, Ergebnisse zu finden, die die Modulbeschreibungen in anderen Worten wiedergeben, als der Module-Maintainer. Somit erhöht sich die Chance schneller fündig zu werden.
Grundsätzlich sollte man sich vor Augen führen, dass fast immer jemand schonmal dieselbe oder eine sehr ähnliche Anforderung lösen wollte und darüber geschrieben hat. Man muss es nur finden. Dazu lohnt es sich immer auch, Ergebnisse zu lesen, die scheinbar nur am Rande das eigene Thema streifen. Denn gerade hier verbergen sich Anregungen und Ideen, an die man selbst noch nicht gedacht hat. Ganz nebenbei bekommt man viele neue Anregungen für kommende Projekte.
Sitebuilding im Agenturalltag bei arocom
Nachdem ich viele Jahre als Einzelkämpfer unterwegs war und mir mein Sitebuilding-Stack aufgebaut habe, ist der Prozess, dieses Wissen in den Alltag einer Drupal Agentur zu überführen, sehr spannend.
Schnell hat sich gezeigt, dass Entwickler und Sitebuilder viel voneinander lernen können. Die offene Arbeitskultur, die bei arocom herrscht, macht es für alle einfach, sich auf Neues einzulassen.
So konnte ich schnell mein reines Sitebuildung-Stack um ein paar neue Fähigkeiten erweitern. Auf der anderen Seite profitieren die Entwickler von neuen Anregungen, wie sie ohne Custom Code Aufgaben lösen können.
Es ist schön zu sehen, wie schnell beide Seiten voneinander lernen und profitieren wollen. Eine klassische Win-Win-Situation.
Fazit
Das Leben als Sitebuilder ist sehr spannend und vielfältig. Die weitverbreitete Meinung, dass man ja nur ein bisschen umherklickt, stimmt hier mitnichten. Um erfolgreich zu sein und langfristig Spaß daran zu haben, ist es natürlich wichtig, sein ganz eigenes Stack an Fähigkeiten zusammenzustellen und sich darin zu professionalisieren.
Mit Drupal hat man ein großartiges System zur Hand, um nahezu jede Herausforderung zu meistern.
