Direkt zum Inhalt
Splash Awards Logo

vegan.at: KI-gestützter Relaunch für die Vegane Gesellschaft Österreich

Projektdetails

Übersicht Projekt anschauen
Kategorie: Non-Profit
Status: Nominee
Titel: vegan.at: KI-gestützter Relaunch für die Vegane Gesellschaft Österreich
Einreichendes Unternehmen: drunomics GmbH
Für den Kunden: Vegane Gesellschaft Österreich (VGÖ)

Zusammenfassung

vegan.at von Drupal 7 auf Drupal 11: Voll KI-gestützte Umsetzung des Relaunches und des Designs, Canvas für die Redaktion, Antwortzeiten sechsmal kürzer.

Projektbeschreibung

Zu diesem Projekt ist eine ausführliche Fallstudie mit allen Zahlen und ihren Quellen veröffentlicht: auf Deutsch unter https://drunomics.com/success-stories/vegane-gesellschaft-oesterreich-ki-gestuetzter-relaunch-von-drupal-7-auf-11-mit, auf Englisch unter https://drunomics.com/en/success-stories/vegane-gesellschaft-osterreich-ai-assisted-drupal-7-11-relaunch-mossbo-cloud. Eine gekürzte englische Fassung steht auf drupal.org: https://new.drupal.org/case-study/vegane-gesellschaft-osterreich-ai-assisted-drupal-7-to-11-relaunch-on-mossbo-cloud.

vegan.at wird von der Veganen Gesellschaft Österreich (VGÖ) betrieben, die sich selbst als Umweltschutzorganisation mit Ernährungsschwerpunkt beschreibt. Ein knapp 30-köpfiges Team begeistert Menschen für eine klimafreundliche, gesunde, pflanzliche Ernährung. Die Website bündelt Rezepte, Nährstoffinformationen, Veranstaltungen und ein österreichweites Verzeichnis vegan-freundlicher Lokale, dazu die Kampagnen-, Mitglieder- und Spendenarbeit des Vereins.

Die bisherige Website von vegan.at lief auf Drupal 7, dessen Support bereits im Jänner 2025 ausgelaufen ist. Als gemeinnütziger Verein hat die VGÖ einen Relaunch gebraucht, der leistbar ist, der ein Jahrzehnt an Inhalten und Suchmaschinen-Rankings bewahrt und der dem Team eine Seite hinterlässt, die es ohne technischen Aufwand selbst betreiben kann. Im August 2026 ist vegan.at auf die mossbo Cloud umgezogen, unser Fully Managed Cloud CMS, das Drupal 11 mit einem modernen Nuxt-Frontend verbindet: innovativ, bewährt, sorgenfrei. Das Inhaltsmodell ist rund um die tatsächliche Arbeit des Vereins neu aufgebaut und verbessert worden: Artikel, Rezepte, Veranstaltungen und redaktionell gepflegte Übersichtsseiten (Canvas-Seiten), jeweils mit einer eigenen Redaktionsansicht.

Vier Dinge unterscheiden dieses Projekt von einem herkömmlichen Relaunch:

1. KI-gestütztes Design. Der Designer der VGÖ hat das Branding geliefert, also Farben, Typografie und Logo, und Feedback zum Ergebnis gegeben. Das Design selbst ist mit Claude Design auf Basis des Komponentensatzes des mossbo Cloud Frontend-Kickstarters entstanden, ergänzt um neue Komponenten für die vegan.at-spezifischen Elemente. Drei Designentwürfe standen zur Wahl; in Abstimmung mit der VGÖ ist es eine Kombination der Entwürfe geworden. Eine einzige Feedback-Runde hat gereicht, bis der Prototyp als lauffähiges HTML und Vue.js stand. Er war danach die Referenz, gegen die jede Seite gebaut worden ist.

2. KI-gestützte Migration unter menschlicher Kontrolle. Inhalte und Seiten sind beide von KI-Agenten migriert worden, wobei ein Mensch die Richtung für die korrekte Umsetzung vorgegeben und jedes sichtbare Ergebnis freigegeben hat. Das Verfahren ist in diesem Projekt entstanden und inzwischen zu einem wiederverwendbaren Satz von Agent-Skills verallgemeinert, sodass die nächste Migration am selben Punkt startet.

3. KI-gestützte Umsetzung. Neben Design-Entwurf und Migration haben die Agenten auch die Drupal-Konfiguration (Inhaltstypen, Felder, Suche) übernommen und bei der Design-Implementierung im Nuxt-Frontend unterstützt. Eigener Backend-Code war nicht nötig: Die mossbo-Architektur trennt Plattform und Projekt, das Projekt besteht aus Konfiguration und Frontend-Komponenten, und genau das macht die KI-gestützte Umsetzung so effizient.

4. Canvas-basierte Übersichtsseiten. vegan.at hat für jede Rubrik, etwa Rezepte oder Infos, und für jedes Thema, etwa Gesundheit oder Umwelt, eine Übersichtsseite. Auf der alten Seite waren das starre Templates. Jetzt sind es redaktionell gewartete Seiten, gebaut mit Drupal Canvas: Die Redaktion setzt sie aus wiederverwendbaren Komponenten zusammen und sieht dabei direkt im Editor, was die Besucher:innen sehen, statt ein abstraktes Layout zu befüllen. Dasselbe Muster trägt die Kampagnen- und Landingpages, und der Verein verwaltet sie ohne Entwickler:in.

Die Migration im Überblick

Die Migration ist mit Hilfe von zwei parallelen Arbeitssträngen umgesetzt worden, beide über den default_content-Mechanismus von Drupal Core. Das Ablaufdiagramm dazu: https://cp.drunomics.com/files/2026-09/migration-flow.png

Seitenmigration. Über die Canvas-Unterstützung von Lupus Decoupled lassen sich Vue-Komponenten direkt mit Drupal Canvas verwenden. Coding-Agenten schreiben modernes JavaScript wie Vue.js-Komponenten recht mühelos, deshalb war es einfach, in Phase 1 erste statische Seiten zu erstellen. In Phase 2 sind die Vue-Komponenten in Drupal registriert worden, sodass sich die Seiten bauen und importieren ließen. Am Ende ist derselbe Komponentenbaum, der in Phase 1 freigegeben worden war, über Lupus Decoupled gerendert worden, jetzt als vollständig redaktionell verwaltete Seite.
Die Seitenmigration selbst ist Ticket für Ticket abgewickelt worden und dadurch messbar: 48 Tickets in 15 Kalendertagen, umgesetzt von Coding-Agenten, jedes mit menschlicher Freigabe.

Die Korrekturrunden sind dabei der Punkt und kein Makel. Zurückgewiesen worden ist fast immer wegen Designtreue oder weil der Code noch nicht so wartbar war, wie er sein sollte, selten weil etwas nicht funktioniert hatte. Agenten liefern schnell etwas Vollständiges, aber Menschen müssen vorgeben, wie es gut gelöst wird, und die Ergebnisse evaluieren.

Inhaltsmigration. Mit Hilfe eines Coding-Agenten sind das Zieldatenmodell und die Zuordnung zur zuvor anonymisierten Drupal-7-Datenbank geplant worden. Anschließend haben die Agenten die Extraktionsskripte geschrieben, die importierbare YAML-Dateien für den Default-Content-Importer erzeugen. Entscheidend: Die Skripte laufen deterministisch. Derselbe Dump ergibt denselben Inhaltsbaum, und kein Inhalt wird über einen Live-Aufruf eines Sprachmodells transformiert. Fehlende Rezept-Teaser sind einmal vorab per KI erzeugt worden, sodass ein erneuter Import exakt denselben Text wiederherstellt.

  • Artikel: 970 Quelldatensätze, rund 13.000 erzeugte Entitäten, 6 Tage, 17 Feedback-Runden, Entwicklungsaufwand rund 1 Tag, überwiegend QA.
  • Rezepte: 1.012 Quelldatensätze, 19.431 erzeugte Entitäten, 6 Tage, 21 Feedback-Runden, Entwicklungsaufwand rund 1 Tag, überwiegend QA.

Bei den Rezepten war außerdem eine bereinigte Zutatenliste nötig, die zu einem kontrollierten Vokabular zusammengeführt worden ist: 2.820 Rohbegriffe wurden zu 923. 42 Kategoriebegriffe aus Drupal 7 sind auf zwei Vokabulare umgestellt worden, Rubriken und Themen, und bei 269 Artikeln sind Zweitzuordnungen erhalten geblieben, die eine naive Ein-Feld-Zuordnung verloren hätte. 6.458 Mediendatensätze sind mitgekommen.

Mehr als die Hälfte der Projektzeit ist in den Prozess und seine Werkzeuge geflossen, nicht in die Seite selbst. Genau diese Investition macht das Verfahren wiederverwendbar.

Restaurantfinder. Eine eigens entwickelte Funktion, die vegan.at abhebt, ist der österreichweite Restaurantfinder, den drunomics in Nuxt neu gebaut hat. Die Daten leben nicht in Drupal, sondern in der intern genutzten API des Vereins. Statt die Funktion wie in Drupal 7 an die Seite anzuflanschen, ist sie jetzt eine Canvas-Seite, die eine eigene Vue-Komponente platziert; ein kleiner API-Proxy im Frontend holt die Daten und hält die Anfragen zwischengespeichert und schnell. Das Resultat verfügt über eine Volltextsuche über Lokalnamen und Gerichte, eine Suche nach Ort oder Postleitzahl, eine Option „in meiner Nähe“, Filter nach Ausstattung und eine Karte der aktuellen Ergebnisse. Gefilterte Ansichten lassen sich teilen, weil die aktiven Filter in der URL der Seite stehen.

Rezept- und Seitensuche. Rezepte werden in Drupal verwaltet und liegen in großer Zahl vor, deshalb nutzt die Rezeptsuche den OpenSearch-Server, den die mossbo Cloud bereitstellt: Search API indexiert, eine Drupal-Views-Konfiguration liefert die Suchoberfläche, und dank der Views-Unterstützung in Lupus Decoupled ist sie im Frontend mit interaktiven Vue-Elementen aufgewertet. Die Seitensuche läuft über dieselbe OpenSearch-Basis, ist auf die deutsche Sprache eingestellt und wendet eine eigene Ranking-Logik per Boosting an. Die dafür nötigen Korrekturen sind an das Modul Search API OpenSearch zurückgegeben worden. Die Redaktion kann das Ranking über den Boost einzelner Artikel selbst beeinflussen.

Webformulare, in der Hand des Vereins. Für eine NGO ist es entscheidend, Formulare ohne fremde Hilfe anlegen und anpassen zu können, und genauso entscheidend ist das Modul Webform. Lupus Decoupled unterstützt Webform seit Langem, aber JavaScript-basierte Funktionen wie bedingte Felder und AJAX-Datei-Uploads haben im Headless-Aufbau gefehlt. Gelöst worden ist das nun im zugrunde liegenden Modul Custom Elements, das jetzt das Library-System von Drupal unterstützt; damit funktionieren bedingte Felder und AJAX-Uploads in Webformularen einfach, wie auf einer klassisch gerenderten Drupal-Seite. Von rund 60 Formularen der alten Seite waren etwa 50 nahezu identische Anfragen nach Aufzeichnungen von Online-Talks; daraus ist ein Inhaltstyp mit einem gemeinsamen Formular geworden. Die übrigen Formulare, von der Magazinbestellung über Anmeldungen zu Veranstaltungen wie der Veganmania bis zu Feedback-Umfragen mit Bewertungsskalen, hat die VGÖ selbst mit Webform nachgebaut, ohne Entwickler:in. Die Seite trägt heute über 50 Formulare, alle vom Verein gepflegt.

Beiträge zurück an die Community. Die Arbeit hat 18 Verbesserungen für Upstream-Projekte hervorgebracht, die meisten für Drupal Canvas und den Datei-Upload-Pfad, von dem eine Canvas-Seite im Headless-Aufbau abhängt: zwei Issues in Drupal Core, drei in Canvas, neun in Custom Elements, dazu Search API OpenSearch, Geocoder, Address Suggestion und Lupus Custom Elements Renderer. Jede Verbesserung ist upstream als Merge Request eingebracht worden, die meisten davon sind bereits gemerged. Die vollständige Liste steht in der Case Study auf drupal.org.

Projektziele und -ergebnisse

Wichtige Aspekte für den Kunden

  • Relaunch der Drupal-7-Seite auf Drupal 11 aus Sicherheitsgründen.
  • Mehr Beteiligung und Interesse der Leser:innen durch ein moderneres, responsives und schnelleres System.
  • Erfüllung der Governance-Anforderungen: Barrierefreiheit, Datenschutz und DSGVO-Konformität.
  • Einhaltung eines knappen Budgetrahmens.

 

Wichtige Aspekte für drunomics als umsetzende Agentur

  • Aufbau einer langfristigen, guten Zusammenarbeit.
  • Innovativer Einsatz und Erprobung von KI-Assistenten, um gute Ergebnisse im Budgetrahmen des Kunden zu liefern.
  • Ausbau des Kundenstamms der mehrfach ausgezeichneten SaaS-Lösung mossbo Cloud (Splash Awards 2025, Sieger national und international in der Kategorie Lösungen sowie „Innovativstes Projekt“, Quelle: APA-OTS, 30.12.2025).

 

Die sieben Ziele des Relaunches, und wie wir sie gemessen haben:

1. Weg von Drupal 7, das seit Januar 2025 keine Sicherheitsupdates mehr bekommt.
✅ Die Seite läuft auf Drupal 11.4 und ist am 27.08.2026 live gegangen. Updates und Sicherheits-Patches laufen automatisiert über die mossbo Cloud.

2. Zehn Jahre Inhalte und die dazugehörigen Rankings erhalten.
✅ Rund 2.173 Seiten sind migriert, die alten URLs leiten weiter, und die Sitemap ist noch am Umstellungstag von der Google Search Console angenommen worden. Die Einstiegs-Weiterleitung ist von zwei Sprüngen (http://vegan.at → http://www.vegan.at → https) auf einen gekürzt. Der Indexierungsbericht der Search Console hatte seit Juni eine flache Linie von rund 3.900 indexierten Seiten gezeigt; wenige Tage nach der Umstellung sprang sie auf 4.725, der gemeinsame Effekt von Go-live und der am selben Tag eingereichten Sitemap.

3. Eine Redaktionsoberfläche, die wenig technisches Wissen braucht.
✅ Startseite, Rubriken-, Themen- und Kampagnenseiten sind Canvas-Seiten. Die Redaktion setzt sie aus Komponenten zusammen und sieht dabei, was die Besucher:innen sehen. Artikel, Rezepte und Veranstaltungen haben je ein eigenes Formular, das sich am Inhalt orientiert und nicht an Drupal.

4. Einen kleinen Verein von der Wartungslast befreien.
✅ Betrieb auf mossbo Cloud, dem Fully Managed Cloud CMS, bei einem DSGVO-konformen Hosting-Anbieter mit Rechenzentrum in Deutschland, ISO/IEC 27001-zertifiziert, hinter einem CDN, mit Monitoring. Alle Updates und Sicherheits-Patches übernimmt die Plattform, inklusive der Upgrades auf neue Drupal-Hauptversionen. Lighthouse „Best Practices“: 100 (mobil, 08.09.2026).

5. Barrierefreiheit nach WCAG 2.2 AA prüfen und die gesetzlich verlangte Erklärung liefern.
✅ Die Seite ist gegen WCAG 2.2 AA geprüft: 14 Seiten in drei Viewports (375, 768 und 1440 px), axe-core plus manueller Prüfung, zuletzt am 13.08.2026. Die Barrierefreiheitserklärung ist aus den Befunden erstellt, benennt die verbleibenden Verbesserungsmöglichkeiten und ist mit dem Launch an die VGÖ übergeben worden, samt der zwei Entscheidungen, die nur der Verein selbst treffen kann. Die alte Seite hatte weder eine Erklärung noch einen geprüften Stand.

6. Die Seite für Besucher:innen spürbar schneller machen.
✅ Mehr als sechsmal so schnell. Am aussagekräftigsten ist Googles eigene Messung, weil sie vor und nach dem Relaunch nach derselben Methode erhoben wird: Die Crawling-Statistik der Search Console zeigt die durchschnittliche Antwortzeit am Umstellungstag von rund 900 ms auf etwa 130 ms fallen, der Sprung liegt genau am Tag des Relaunches. Die Grafik der Search Console dazu: https://cp.drunomics.com/files/2026-09/gsc-response-time-graph-cropped.jpg

Ergänzend eine eigene Messung vom 11.08.2026, neun repräsentative Seiten, je fünf Abrufe, Median, von einem Standort in Österreich:

  • Startseite: TTFB 0,784 s vorher, 0,046 s nachher, −94 %
  • Artikel: 0,730 s vorher, 0,045 s nachher, −94 %
  • Restaurantsuche: 0,629 s vorher, 0,043 s nachher, −93 %
  • Spendenseite: 0,587 s vorher, 0,044 s nachher, −92 %
  • Rezept: 0,905 s vorher, 0,119 s nachher, −87 %

Über alle neun Seiten hinweg: TTFB −84 % bis −94 %, Gesamtzeit −68 % bis −92 %. Die Restaurantsuche liefert dabei 27 % weniger HTML als zuvor, und das bei mehr Einträgen (714 statt 711). Gemessen ist dabei nur das HTML-Dokument, ohne Bilder, CSS, JavaScript und Hydration; die neue Seite liegt hinter einem CDN, die alte hat direkt vom Origin ausgeliefert.

7. Das Ganze zu Kosten, die ein gemeinnütziger Verein tragen kann.
✅ Umgesetzt hat das Projekt ein kleines Team mit KI-gestützten Arbeitsabläufen.
KI-gestütztes Design und KI-gestützte Migration haben die Lieferzeit verkürzt und damit Zeit und Kosten für den Verein gespart.

Ein Ergebnis, das niemand als Ziel gesetzt hatte: strukturierte Daten. Die alte Seite hat keine strukturierten Daten ausgeliefert. Die neue gibt Schema.org-Markup über Schema.org Metatag aus, und die Search Console hat es ab dem ersten Crawl erkannt: Am 3. September meldete sie 1.153 gültige Navigationspfade, 529 gültige Rezepte und 3 Veranstaltungen, null Fehler. Rezepte mit gültigem Markup sind für Rich Results bei Google qualifiziert, und genau dort verdient eine Rezeptseite ihre Klicks.

Vorher / Nachher

  • Drupal: vorher 7.105 (End of Life seit 01/2025), nachher 11.4 mit automatisierten Updates.
  • Einstiegs-Weiterleitung: vorher zwei Sprünge (http://vegan.at → http://www.vegan.at → https), nachher ein Sprung.
  • Barrierefreiheit: vorher keine Erklärung und kein geprüfter Stand, nachher nach WCAG 2.2 AA geprüft, die Erklärung benennt die verbleibenden Verbesserungsmöglichkeiten.
  • Strukturierte Daten: vorher keine, nachher Schema.org-Navigationspfade, Rezepte und Events mit 0 Fehlern.
  • Übersichtsseiten: vorher fest verdrahtete Templates, nachher Canvas-Seiten, von der Redaktion zusammensetzbar.
  • Reichweitenmessung: vorher Matomo Cloud plus Google Tag Manager, nachher Plausible, cookielos, lädt vor der Einwilligung; GA4 nur nach Einwilligung.

„Mit der Neuentwicklung von vegan.at haben wir unsere historisch gewachsene Drupal-7-Website in eine moderne, leistungsfähige und zukunftssichere Plattform überführt. Das neue System ermöglicht es uns, Inhalte wie Artikel, Rezepte und Veranstaltungen deutlich flexibler und effizienter zu verwalten. Besonders wertvoll ist für uns, dass Betrieb, Monitoring und Sicherheitsupdates in einer Managed-Cloud-Lösung gebündelt sind. Dadurch kann sich unser Team stärker auf die redaktionelle Arbeit konzentrieren und vegan.at kontinuierlich weiterentwickeln.“
- Fabian Plank, Informationstechnik, Vegane Gesellschaft Österreich

Weitere Informationen

Herausforderungen

Drupal 7 am Ende seiner Lebensdauer. Der Umzug war keine Kür, sondern Pflicht. Gleichzeitig durfte nichts verloren gehen: Inhalte, URLs und Rankings mussten den Wechsel überstehen.

Strukturierte Inhalte statt Seiten. Rezepte, Veranstaltungen, Restaurants und Artikel verhalten sich unterschiedlich. Jeder dieser Typen hat ein eigenes Datenmodell und eine eigene Redaktionsansicht bekommen, statt alles in ein Seitenformat zu pressen.

Restaurantfinder außerhalb von Drupal. Die Lokaldaten leben in der internen API des Vereins, nicht im CMS. Der Finder musste trotzdem Teil der Seite sein, auf jedem Gerät bedienbar, mit Umkreissuche, Filtern und Karte, und ohne die Daten zu duplizieren. Lösung: eine Vue-Komponente in Nuxt hinter einem kleinen API-Proxy, platziert auf einer Canvas-Seite.

Webform-Funktionen im Headless-Frontend. Bedingte Felder und AJAX-Datei-Uploads brauchen Drupals JavaScript-Bibliotheken, die ein Headless-Frontend bisher nicht geladen hat. Die Lücke ist als Verbesserung im Modul Custom Elements geschlossen worden, nicht per Sonderlösung für vegan.at.

Qualität von KI-Agenten sichern. Agenten liefern schnell etwas Vollständiges, aber nicht automatisch Designtreue und wartbaren Code. Die Antwort war ein Verfahren mit klaren Freigabepunkten: Nuxt-Prototyp je Seite, Freigabe durch den Kunden, erst dann Canvas-Registrierung und Import.

Barrierefreiheit nachträglich. Die Anforderungen sind gegen einen bestehenden Markenauftritt geprüft und umgesetzt worden, nicht auf der grünen Wiese.

Community-Beiträge

Die Arbeit an vegan.at hat 18 Verbesserungen für Upstream-Projekte hervorgebracht, die meisten für Drupal Canvas und den Datei-Upload-Pfad, von dem eine Canvas-Seite im Headless-Aufbau abhängt. Jede Verbesserung ist als Merge Request eingebracht worden, die meisten davon sind bereits gemerged. Einige Beispiele:

  • Drupal Core: AJAX-MessageCommand für Datei-Uploads, damit ein entkoppeltes Frontend Upload-Meldungen als strukturierte Daten statt geparstem HTML erhält (https://www.drupal.org/project/drupal/issues/3618230).
  • Drupal Canvas: Upload von Dateien mit Leerzeichen, der für die ganze Seite gebrochen war (https://git.drupalcode.org/project/canvas/-/issues/3591986), und Formular-AJAX-Fehler, die von Canvas verschluckt worden sind (https://git.drupalcode.org/project/canvas/-/issues/3591989).
  • Custom Elements: Laden von Drupal-JavaScript-Bibliotheken über Custom Elements, wodurch bedingte Felder und AJAX-Uploads in Webformularen im Headless-Aufbau funktionieren (https://www.drupal.org/project/custom_elements/issues/3568233), dazu Formatter für Smart Date, Geofield und Address für Veranstaltungen und Restaurants.
  • Search API OpenSearch: Boosting je Inhaltstyp korrigiert und multiplikativ angewendet, die Grundlage für die redaktionell steuerbare Suche (https://www.drupal.org/project/search_api_opensearch/issues/3616474).
  • Geocoder und Address Suggestion: Geokodierung reiner Länderadressen abschaltbar gemacht und Warnungen bei Nominatim-Ergebnissen ohne Straße behoben, beides aus dem Restaurantfinder heraus.

Die vollständige Liste aller 18 Issues mit Links steht in der Case Study auf drunomics.com, Abschnitt „Community-Beiträge": https://drunomics.com/success-stories/vegane-gesellschaft-oesterreich-ki-gestuetzter-relaunch-von-drupal-7-auf-11-mit

Darüber hinaus wartet drunomics die Module Lupus Decoupled Drupal, Custom Elements, Lupus Custom Elements Renderer, Config Preview Deploy, Lupus Stark, OhDear Integration und Request Info und trägt zu AI, Experience Builder, OpenAI Provider und OpenID Connect / OAuth Client bei.

Warum sollte dieses Projekt bei den Splash Awards gewinnen?

Nicht „ein weiterer D7-Umzug", sondern der Nachweis, dass ein gemeinnütziger Verein mit knappem Budget heute eine Seite bekommen kann, die technisch und gestalterisch auf der Höhe ist.

  1. Ein KI-generiertes Design nach einer einzigen Feedback-Runde, mit Claude Design auf Basis des mossbo Cloud Kickstarts erstellt; die VGÖ hat Branding und Feedback beigesteuert, und der Prototyp war zugleich lauffähiges HTML und Vue.js.
  2. Eine KI-gestützte Umsetzung, die messbar und wiederholbar ist. Deterministische Extraktionsskripte, 970 Artikel und 1.012 Rezepte zu rund 32.000 Entitäten in je 6 Tagen, 48 Seiten-Tickets in 15 Kalendertagen, jedes von einem Menschen freigegeben, und das ohne eine Zeile eigenen Backend-Codes: Drupal-Konfiguration und Frontend-Komponenten reichen auf mossbo Cloud aus. Das Verfahren ist inzwischen als Agent-Skills verallgemeinert und steht für die nächste Migration in die mossbo Cloud bereit.
  3. Fachfunktionen, die über eine Standard-Website hinausgehen. Der Restaurantfinder als Vue-Komponente in Nuxt mit Volltext-, Orts- und Umkreissuche, Filtern und Karte über mehr als 700 Lokale, teilbar über die URL. Rezept- und Seitensuche über OpenSearch mit redaktionell steuerbarem Boosting. Über 50 Webformulare, vom Magazinabo bis zur Feedback-Umfrage mit Bewertungsskalen, die der Verein selbst betreibt.
  4. Alle sieben Ziele erreicht, und jedes davon gemessen. Drupal 11 statt 7, 2.173 Seiten samt Rankings und Weiterleitungen erhalten, indexierte Seiten von rund 3.900 auf 4.725, Canvas für die Redaktion, sorgenfreier Betrieb auf mossbo Cloud, WCAG-2.2-AA-Audit samt Erklärung, Antwortzeiten mehr als sechsmal schneller, und das zu Kosten, die ein Verein tragen kann.
  5. Was zurück an die Community geht. 18 Verbesserungen für Drupal Core, Canvas, Custom Elements, Search API OpenSearch und weitere Module, alle als Merge Request eingebracht und die meisten bereits gemerged; die JavaScript-Unterstützung bei Webform im Headless-Aufbau ist eine generelle Verbesserung von Custom Elements, nicht ein Projekt-Hack.