Was ist LimeSurvey?
LimeSurvey gehört seit vielen Jahren zu den meistverbreiteten Open-Source-Umfragelösungen im PHP-Ökosystem. Die Plattform ermöglicht die Erstellung, Verwaltung und Auswertung von Online-Umfragen und richtet sich sowohl an einzelne Anwender als auch an Organisationen mit komplexen Anforderungen. Mit einer großen aktiven Installationsbasis und kontinuierlicher Weiterentwicklung ist LimeSurvey ein Projekt, das seit langem produktiv eingesetzt wird. Für Umfragen im akademischen oder organisatorischen Kontext gibt es kaum eine vergleichbare Open-Source-Alternative mit diesem Funktionsumfang.
Gleichzeitig ist LimeSurvey ein System, das sich sichtbar im Übergang befindet: stabil im Betrieb, gewachsen über viele Jahre – und architektonisch zwischen historisch gewachsenen Strukturen und schrittweiser Modernisierung.
Dieser Artikel richtet sich nicht an Entscheider, die evaluieren möchten, ob sie LimeSurvey einsetzen sollen. Er richtet sich an Entwicklerinnen und Entwickler, die bereits mit LimeSurvey arbeiten oder es schrittweise modernisieren wollen. Der Blickwinkel ist der eines Legacy-Modernizers – also eines Entwicklers, der bestehende Systeme nicht neu schreibt, sondern evolutionär weiterentwickelt. Aus dieser Perspektive zeigt sich LimeSurvey als ein System, das funktioniert, gewachsen ist und dessen Architektur die Spuren dieser Entwicklung deutlich trägt.
Der Tech-Stack im Überblick
LimeSurvey 6 setzt PHP 7.4 als Mindestanforderung voraus. Diese Entscheidung ist aufschlussreich: PHP 7.4 erhält seit November 2022 keinen aktiven Support mehr. LimeSurvey lässt sich zwar mit neueren PHP-Versionen betreiben – verlangt dies jedoch nicht zwingend. Das Minimum signalisiert, dass Stabilität und Abwärtskompatibilität für die Zielgruppe derzeit höher gewichtet werden als ein erzwungener Modernisierungsschritt.
Das zentrale Framework ist Yii 1.1. Zu seiner Zeit war Yii ein solides und performantes Framework, erhält jedoch seit 2019 keine aktive Weiterentwicklung mehr. Sicherheitsupdates werden weiterhin gepflegt, strukturelle Weiterentwicklungen hingegen nicht. LimeSurvey baut damit auf einem Fundament, das technisch stabil ist, strategisch jedoch kaum noch Entwicklungsspielraum bietet.
Daneben finden sich modernere Abhängigkeiten im Stack:
- php-di 6.4 stellt einen vollwertigen Dependency-Injection-Container bereit. Seine Existenz im Projekt zeigt deutlich, dass der Wunsch nach moderner Architektur vorhanden ist. Die Nutzung erfolgt jedoch nicht konsequent: In vielen Teilen der Codebasis dominieren weiterhin globale Service-Locator-Aufrufe statt expliziter Abhängigkeitsinjektion.
- Twig 3.11.3 ist eine moderne und ausgereifte Template-Engine. Ihr Einsatzbereich ist jedoch klar begrenzt: Twig wird ausschließlich für Umfrage-Themes verwendet, nicht für Backend-Ansichten. Das Rendering im übrigen System folgt weiterhin älteren Mechanismen. Twig stellt somit keine systemweite Modernisierung des Templatings dar, sondern eine saubere Lösung für einen klar abgegrenzten Teilbereich.
Alt und neu nebeneinander
Nach einem Blick auf den Stack ergibt sich ein präziseres Gesamtbild: LimeSurvey ist kein klassisches Legacy-System, sondern ein System im Übergang.
Moderne Werkzeuge wurden eingeführt, ohne dass die darunterliegende Architektur vollständig nachgezogen wurde. Dadurch entstehen charakteristische Spannungen innerhalb der Codebasis. Ein DI-Container, der nur teilweise genutzt wird, führt nicht automatisch zu Dependency Injection, sondern zu zwei koexistierenden Mustern. Twig modernisiert das Templating für Themes, während andere Bereiche weiterhin historisch gewachsene Rendering-Wege nutzen.
Das ist kein Widerspruch, sondern ein typisches Modernisierungsmuster langlebiger Software: Veränderung geschieht inkrementell und unter Produktionsbedingungen, nicht durch radikale Neuentwürfe.
Für Entwickler entsteht daraus die eigentliche Herausforderung. Es geht weniger darum, ein einheitliches Legacy-System zu verstehen, sondern die Grenzen zwischen alten und neuen Architekturmuster zu erkennen – und bewusst zu entscheiden, welchem Ansatz man in einer konkreten Situation folgt.
Das Datenbankmodell
Wie tief historische Entscheidungen in die Architektur hineinreichen, zeigt sich besonders deutlich im Datenbankdesign.
Für jede Umfrage wird eine eigene Tabelle angelegt, beispielsweise survey_112233, wobei die Zahl der Survey-ID entspricht. Die Antworten aller Teilnehmer dieser Umfrage werden in genau dieser Tabelle gespeichert.
Die Spaltennamen folgen einem internen Schema, das Survey-ID, Group-ID und Question-ID kombiniert. Für Außenstehende wirken diese zunächst kryptisch; ihre Struktur erschließt sich erst mit Verständnis der internen Datenlogik.
Diese Entscheidung hat weitreichende Konsequenzen. Die Anzahl der Spalten in einer MySQL-Tabelle ist begrenzt. Bei großen Umfragen – insbesondere mit Mehrfachantworten und Subquestions – kann diese Grenze erreicht werden. Fragetypen, die zusätzliche Spalten benötigen, lassen sich dadurch strukturell nur eingeschränkt erweitern. LimeSurvey kennt derzeit rund 30 Fragetypen, die im Datenbankschema fest verankert sind. Ob neue Fragetypen ohne Eingriff in den Core realisierbar sind, führt unmittelbar zu grundlegenden Architekturfragen – und bleibt an dieser Stelle bewusst offen.
Randnotiz: In extrem großen Umfragen kann MySQL tatsächlich an seine Spaltenlimitierung stoßen und die Tabellenerstellung verweigern. Ein Grenzfall, aber ein realer.
Auch für Reporting und externe Datenanalyse ergibt sich zusätzlicher Aufwand. Wer Antwortdaten außerhalb von LimeSurvey auswerten möchte, muss das interne Schema verstehen und interpretieren können.
Das Plugin-System
LimeSurvey verfügt über ein eventbasiertes Plugin-System, das Erweiterungen ohne Änderungen am Core ermöglicht. Plugins reagieren auf definierte Events und können so Verhalten anpassen – vom E-Mail-Versand bis zur Verarbeitung von Antworten.
Konzeptionell ist dieses System sehr wertvoll und wird aktiv genutzt. Gleichzeitig trägt es selbst Spuren historischen Wachstums, die eine genauere Betrachtung verdienen. Genau diesem Thema widmet sich ein separater Artikel dieser Serie.
Einordnung
LimeSurvey ist ein produktives, verbreitetes und funktionales System – und gerade deshalb lohnt es sich, seine Architektur zu verstehen. Es ist jedoch kein System, das sich ohne Weiteres in eine moderne Zielarchitektur überführen lässt, ohne die gewachsenen Strukturen mitzudenken.
Die Herausforderung für einen Legacy-Modernizer besteht nicht im Rewrite, sondern in der schrittweisen Entflechtung: Abhängigkeiten sichtbar machen, vorhandene Werkzeuge konsequent einsetzen und die Grenzen zwischen alten und neuen Mustern klären. LimeSurvey bringt dafür bereits Teile der notwendigen Infrastruktur mit – sie müssen lediglich systematisch genutzt werden.
In den folgenden Artikeln zerlegen wir diese Übergangsarchitektur schrittweise und betrachten einzelne Komponenten im Detail – beginnend mit dem Plugin-System, das exemplarisch zeigt, wie Modernisierung und historisches Wachstum innerhalb eines langlebigen Open-Source-Projekts ineinandergreifen.