Im April 2026 traf sich die Neos-Community in Rotkreuz in der Schweiz zum Sprint an der neuen Media-UI. Wir von 3m5. waren zwei Tage dabei. Hier erzählen wir, woran wir gemeinsam mit der Community in dieser Zeit gearbeitet haben.
Wir flogen von Dresden nach Zürich, dann ging es mit dem Zug nach Rotkreuz. In den nächsten Tagen sollte unser Fokus auf der neuen Media-UI von Neos liegen, die gerade die gesamte Neos-Community umtrieb.
Der Sprint startete klassisch: Kurzes Stand-Up, alle sagten zwei, drei Sätze zu sich. Danach teilten wir uns in zwei Themenbereiche auf.
Die eine Gruppe nahm sich die UI/UX der neuen Media-UI vor. Nach einer kurzen technischen Einführung wurde direkt an Issues und Features programmiert.
Die zweite Gruppe – zu der auch ich gehörte sowie rund 9 weitere Leute – ging einen Schritt zurück und diskutierte die neue Architektur der Media-UI. Die Frage, die wir uns stellten: Wie baut man eine High-Level-API, auf der sich die Media-UI in Zukunft sauber entwickeln lässt?
Flipchart und Post-Its waren schnell organisiert und wir machten Event Storming. Die Leitfrage: „Welche Events und Aktionen können mit Assets durchgeführt werden?"
Das führte schnell in spannende Ecken:
- geschützte Assets, bei denen ein Bild nur mit Login heruntergeladen werden darf
- zeitlich begrenzte Assets
Zwischendurch gab es technischere Deep Dives. Dabei zeigte sich: Das Zusammenspiel von Assets, Resources, Storages und Targets im Neos-Kosmos ist für viele nicht auf Anhieb glasklar. Genau deshalb sind solche Sprints wertvoll – gemeinsam werden Begriffe geschärft, Missverständnisse ausgeräumt und ein gemeinsames Bild aufgebaut, auf dem man später sauber weiterentwickeln kann.
Drei Bereiche kristallisierten sich heraus:
1. DAM – die Verwaltung der Assets selbst, inklusive Anbindung externer Asset-Sources
2. Verwendung – das Zuweisen von Asset an Nodes, den Inhaltselementen in Neos
3. Rendering – die Erstellung von Renditions, zum Beispiel web-optimierten Bildern
Besonders der Rendering-Bereich war spannend: Dieser sollte künftig austauschbar und erweiterbar werden, pipeline-artig aufgebaut. Renderer für YouTube-Embeds, eigene DAMs, abstraktere Konvertierungen wie Word zu PDF oder PDF zu Bild – all das sollte möglich sein. Und natürlich die Anbindung externer Services wie Cloudinary, Imagor oder Cloudflare Images, wenn Performance und Delivery der Knackpunkt ist.
Der Abend endete mit Pizza und Pasta und einem Abstecher ins Gameorama, dem lokalen Videospielmuseum. Wer Sprints nur als Dauer-Coderei kennt, unterschätzt den Effekt, den ein halber Abend vor einem Arcade-Automaten auf die nächste Diskussion am Whiteboard hat.
Neun Uhr, neuer Tag, neues Stand-Up. Die UI/UX-Gruppe war im Flow: Code schreiben, Issues lösen, weitermachen.
In der Architektur-Gruppe zogen wir einen kurzen Recap und stiegen dann tiefer ein. Mit zehn Leuten gleichzeitig an einer Spezifikation zu arbeiten ist ehrlich gesagt zäh. Lesson Learned: Ab sechs, sieben Leuten wird jede Gruppe zum Kompromiss-Generator. Wir teilten uns deshalb in zwei Untergruppen auf:
- Untergruppe 1 nahm sich das DAM weiter zur Brust und konzeptionierte
- Untergruppe 2 schaute sich eine konkrete Beispielimplementierung an, die ein Kollege der Agentur Sitegeist vorbereitet hatte: einmal mit Imagor (externer Service, Go-basiert) und einmal mit Imagine (PHP-Library, lokal)
Das hat doppelt geholfen: Zum einen wurde die theoretische Architektur sofort gegen reale Code-Entscheidungen gedrückt, zum anderen wurden Konzepte, die auf dem Flipchart noch abstrakt wirkten, durch den Blick in echten Code auf einmal greifbar und deutlich verständlicher.
In den zwei Tagen, die wir dabei waren, ist keine große Architektur-Entscheidung gefallen – und das war auch nicht das Ziel. Es ging darum, ein gemeinsames Bild aufzubauen, Begriffe zu schärfen und die richtigen Fragen zu finden. Ein paar Dinge sind mir aus diesen Tagen besonders hängen geblieben:
Vieles, was in Release Notes später in einem Halbsatz auftaucht, entsteht auf einem Post-It in Rotkreuz. Wer das Framework ernsthaft nutzt, profitiert direkt davon, dass so ein Format existiert.
Gerade bei unscharfen Domänen wie „Wie soll das Asset-Handling im Jahr 2026 aussehen?" ist es ein ehrlicher Weg, Komplexität sichtbar zu machen, statt sie in einer schönen Architekturfolie zu verstecken.
Bildverarbeitung ist nichts, was man für immer in Neos gießen sollte. Wenn Renderer austauschbar sind, kann jedes Projekt das integrieren, was es wirklich braucht – vom lokalen Imagine bis zum gehosteten Cloudinary.
Zwei Tage mit Entwicklerinnen und Entwicklern aus anderen Agenturen und Inhouse-Teams zu verbringen, Probleme zu diskutieren, Pasta zu essen – das ist am Ende das, was ein Open-Source-CMS und die Community dahinter trägt.
Für uns bei 3m5. ist der Neos Sprint keine Pflichtveranstaltung. Er ist der Ort, an dem wir technisch mitgestalten – und bei der die Liste an Ideen beim Heimkommen jedes Mallänger ist als beim Losfahren.
Vom offenen Office mit Kaffee, Mittagessen und ausreichend Whiteboards bis zur durchdachten Agenda und der gemeinsamen Abendplanung in Luzern – es hat an nichts gefehlt. Diese Gastfreundschaft trägt maßgeblich dazu bei, dass die Neos-Community-Formate funktionieren. Wir freuen uns schon auf den nächsten Sprint!
Wie wir uns in der Neos Community einbringen und weiterbilden? Davon erzählen wir hier: https://www.neos.io/blog/the-first-neos-media-sprint.html
Wenn im Betrieb Ihrer TYPO3 Website der Hinweis „503 Oops, an error occurred“ erscheint, handelt es sich um einen generischen Fehler.
