Es gibt Entscheidungen in der Softwareentwicklung, die man bewusst trifft. Und es gibt Entscheidungen, die man trifft, weil man keine andere Wahl hat. Die Entscheidung, mit der LimeSurvey 2012 zu Yii 1.1 gewechselt hat, war die zweite Art.
Aber fangen wir von vorne an.
Prado – der Anfang einer Linie
Im Juni 2004 veröffentlichte der chinesische Entwickler Qiang Xue die erste Version eines PHP-Frameworks namens PRADO – PHP Rapid Application Development Object-oriented. PHP 5.0 war gerade frisch erschienen, und Zend hatte einen Wettbewerb ausgeschrieben um die neue Version zu fördern. Qiang reimplementierte Prado für PHP 5 – und gewann.
Prado war von Apache Tapestry, Borland Delphi und vor allem Microsoft ASP.NET inspiriert. Das war damals ein ungewöhnlicher Ansatz in der PHP-Welt: komponentenbasiert, ereignisgesteuert, mit einem UI-Modell das an Desktop-Entwicklung erinnerte. Ein Formular war nicht einfach ein HTML-<form>, sondern eine Komponente mit State, Events und Lifecycle.
Das war modern – für 2004. Aber es hatte Nachteile:
- Langsam bei komplexen Seiten
- Steile Lernkurve – das Komponentenmodell war für PHP-Entwickler fremd
- Schwer anpassbar – viele Controls ließen sich kaum ohne Aufwand überschreiben
Prado war ein interessantes Experiment. Aber die PHP-Welt entwickelte sich in eine andere Richtung.
Qiang Xue denkt neu – die Geburt von Yii
Am 1. Januar 2008 begann Qiang Xue ein neues Projekt. Diesmal keine Komponenten, keine Events, kein ASP.NET-Denken. Stattdessen: MVC, Convention over Configuration, Geschwindigkeit.
Die Inspiration war nicht mehr Microsoft – sondern Ruby on Rails. Dazu flossen Ideen aus Symfony, CakePHP und natürlich aus den Jahren mit Prado ein.
Der Name: Yii – ausgesprochen wie "Yee". Im Chinesischen bedeutet es etwa "einfach und evolutionär". Als Akronym steht es für "Yes, It Is!" – eine Antwort auf die Fragen: Ist es schnell? Ist es sicher? Ist es professionell?
Am 3. Dezember 2008 wurde Yii 1.0.0 offiziell veröffentlicht. Viele Ideen und etwas Code wurden direkt aus Prado übernommen – darunter ActiveRecord, i18n und l10n.
Im Januar 2010 folgte Yii 1.1 mit einem Form Builder, relationalen ActiveRecord-Abfragen und einem Unit-Testing-Framework. Das war die Version, die LimeSurvey später adoptieren sollte – und die bis heute die Basis ist.
Was Yii 1.1 technisch ausmachte
Yii 1.1 war für seine Zeit außergewöhnlich schnell. Der Grund: Lazy Loading konsequent durchgezogen. Keine Klasse wurde geladen, bevor sie gebraucht wurde. Kein Objekt instanziiert, bevor es angefragt wurde.
Das Herzstück war Yii::app() – das Application-Objekt, gleichzeitig Registry, Service-Locator und Konfigurationscontainer:
// Datenbankverbindung
Yii::app()->db->createCommand($sql)->queryAll();
// Session
Yii::app()->session['key'] = 'value';
// Übersetzung via CGettextMessageSource
Yii::t('', 'My string');
ActiveRecord machte Datenbankzugriffe einfach:
$survey = Survey::model()->findByPk($id);
$survey->title = 'New Title';
$survey->save();
Und das MVC-Modell war klar strukturiert: Controllers in controllers/, Models in models/, Views in views/. Für Entwickler, die aus dem prozeduralen PHP-Zeitalter kamen, war das eine Offenbarung.
Yii 1.1 wurde schnell populär – besonders in Asien, aber auch in Europa und den USA. Große Open-Source-Projekte setzten darauf. Darunter sollte bald auch LimeSurvey sein.
LimeSurvey – die Vorgeschichte
LimeSurvey hieß ursprünglich PHPSurveyor und wurde am 20. Februar 2003 von dem australischen Entwickler Jason Cleeland als SourceForge-Projekt gestartet. Prozedurales PHP, keine Frameworks, kein MVC. Einfach Funktionen, die Formulare rendern und Antworten in die Datenbank schreiben.
2006 übernahm Carsten Schmitz die Projektleitung. 2007 folgte die Umbenennung in LimeSurvey – nicht aus Marketinggründen, sondern aus einem praktischen Problem: "PHP" im Namen kollidierte mit der PHP-Lizenz, die viele Open-Source-Bibliotheken nutzten.
Bis 2011 wuchs LimeSurvey kontinuierlich. Der Code wuchs mit – aber die Architektur blieb prozedural. Keine Klassen, keine Namespaces, kein Autoloading. loadHelper() statt Dependency Injection. Globale Funktionen statt Services.
Es war Zeit für einen Schnitt.
Oktober 2011 – der dramatische Moment
Das Team hatte sich entschieden: LimeSurvey 2.0 sollte ein modernes Framework bekommen. Die Wahl fiel auf CodeIgniter – damals eines der beliebtesten PHP-Frameworks überhaupt. Leichtgewichtig, gut dokumentiert, große Community.
Im Oktober 2011 wurde die erste Alpha-Version von LimeSurvey 2.0 veröffentlicht.
Und kurz darauf wieder zurückgezogen.
CodeIgniter stand zu dieser Zeit unter einer eigenen Lizenz, die nicht vollständig OSI-kompatibel war. Es gab Einschränkungen, die für ein Open-Source-Projekt wie LimeSurvey nicht akzeptabel waren. Das Framework war beliebt – aber die Lizenz passte nicht.
Yii 1.1 hingegen stand unter der BSD-Lizenz. Permissiv, unkompliziert, kompatibel mit allem.
Die Entscheidung war getroffen – diesmal nicht aus Begeisterung, sondern aus Notwendigkeit. Und sie hat alles verändert.
2012 – Neustart mit Yii
Das Team baute LimeSurvey 2.0 neu auf – diesmal auf Yii 1.1. MVC zog ein. Controller, Models, Views. LSYii_Application als eigene Erweiterung von Yii's CWebApplication. LSYii_Controller als Basis für alle Controller.
Am 16. August 2012 wurde der 9. Release Candidate veröffentlicht, gefolgt von der stabilen Version am 15. Oktober 2012.
Ein Jahr Verzögerung gegenüber dem ursprünglichen Plan. Aber das Ergebnis war eine deutlich sauberere Architektur als alles was LimeSurvey zuvor hatte.
Nicht perfekt – die common_helper.php mit ihren globalen Funktionen kam mit. Viele alte Muster blieben erhalten. Aber das Fundament war neu.
Was danach kam – und was nicht
Im Mai 2011 entschieden die Yii-Entwickler, neue PHP-Versionen zu nutzen und architektonische Schwächen zu beheben. Im Mai 2013 wurde der Yii 2.0-Code öffentlich, gefolgt von der ersten stabilen Version im Oktober 2014.
Yii 2 war ein kompletter Rewrite. Composer-first, Namespaces, PSR-Standards, Dependency Injection Container. Moderner PHP-Code wie er 2014 stand der Kunst war.
Aber LimeSurvey machte den Sprung nicht mit. Das ist kein Vorwurf – es ist eine nachvollziehbare Entscheidung. Ein Upgrade von Yii 1.1 auf Yii 2 ist keine Migration, es ist ein Rewrite. Die APIs sind inkompatibel, das Komponentenmodell ist anders, selbst einfache Dinge wie URL-Routing funktionieren anders. Für ein gewachsenes Projekt mit hunderttausenden Zeilen Code ist das kein Wochenendprojekt.
Yii 1.1 lebt derweil weiter – aktiver als viele erwartet hätten. Version 1.1.32 wurde im Dezember 2025 veröffentlicht. Die Community hält den Branch mit PHP 8.x-Kompatibilität und kontinuierlichen Fixes am Leben.
Yii 3 – lang erwartet, konsequent anders
Yii 3 hat sich lange Zeit gelassen. Sehr lange. Die Entwicklung begann bereits um 2019, aber das Projekt war alles andere als ein klassisches Release mit Datum und Fanfare. Es wuchs organisch, Paket für Paket.
Am 31. Dezember 2025 wurde Yii 3 schließlich offiziell veröffentlicht.
Und es ist ein anderes Framework – nicht nur eine neue Version, sondern eine andere Philosophie.
Der entscheidende Unterschied zu Yii 1.1 und Yii 2: Yii 3 besteht aus autarken Composer-Packages. Kein monolithisches Framework mehr, das man als Ganzes installiert. Stattdessen unabhängig versionierte Pakete – Routing, DI-Container, Caching, Validation – die einzeln oder zusammen genutzt werden können. Wer will, kann sich seinen eigenen Stack zusammenstellen.
Damit hat Yii 3 denselben Weg eingeschlagen wie Symfony – und es schämt sich nicht dafür. Im Gegenteil: Yii 3 verwendet selbst Symfony-Components dort wo es Sinn macht, und setzt konsequent auf PSR-Standards (PSR-7, PSR-11, PSR-15, PSR-3). Die Integration mit dem gesamten PHP-Ökosystem ist damit praktisch friktionslos.
Was die Code-Qualität betrifft, setzt Yii 3 neue Maßstäbe:
- ~100% PHPUnit-Coverage über alle Packages
- Psalm auf höchstem Level – statische Analyse ohne Kompromisse
- Infection Mutation Testing – Tests werden nicht nur auf Coverage geprüft, sondern darauf ob sie tatsächlich Fehler finden würden
Das ist eine Qualitätssicherung, die die meisten kommerziellen Projekte nicht annähernd erreichen. Für jemanden der täglich mit Legacy-Code arbeitet, ist das ein eindrucksvoller Kontrast.
Der DI-Container ist explizit und typsicher – kein Service Locator, keine versteckten Abhängigkeiten:
final readonly class UserService
{
public function __construct(
private UserRepository $users,
private LoggerInterface $logger,
private CacheInterface $cache,
) {}
}
SOLID-Prinzipien sind nicht Anspruch, sondern gelebte Praxis im gesamten Codebase.
Wo LimeSurvey in dieser Geschichte steht
LimeSurvey 6 läuft auf Yii 1.1. Das Framework, das 2008 als Reaktion auf die Schwächen von Prado entstand, das 2011 durch einen Lizenz-Zufall zum Framework der Wahl wurde, das 2014 von seiner eigenen Nachfolgeversion abgelöst wurde – es trägt heute noch eine der größten Open-Source-Umfragelösungen der Welt.
Das ist keine Schwäche. Es ist Geschichte.
Aber Geschichte erklärt nicht, was als nächstes kommt. LimeSurvey sitzt auf einem Framework dessen Nachfolger inzwischen in der dritten Generation angekommen ist – mit einer Codequalität und Architektur, die den Abstand zur eigenen Codebasis sehr deutlich macht.
Die common_helper.php mit ihren 130+ globalen Funktionen und über 11.000 Aufrufen ist nicht das einzige Relikt. Sie ist das sichtbarste.
Die Frage ist nicht ob sich das ändern muss. Die Frage ist wie – und in welcher Reihenfolge.
Das ist das Thema der gesamten Serie.
Die Linie, zusammengefasst
2004 Prado – komponentenbasiert, ASP.NET-inspiriert (Qiang Xue)
2008 Yii 1.0 – MVC, Rails-inspiriert, schnell
2010 Yii 1.1 – Form Builder, relationales ActiveRecord, Unit Testing
2011 LimeSurvey – CodeIgniter-Alpha, Lizenzproblem, sofort zurückgezogen
2012 LimeSurvey – Neustart mit Yii 1.1, stabile Version 2.0
2014 Yii 2.0 – kompletter Rewrite, LimeSurvey steigt nicht um
Dez 2025 Yii 1.1.32 – aktiv gepflegt, PHP 8.x kompatibel
Dez 2025 Yii 3.0 – autarke Composer-Packages, PSR-first, ~100% Psalm/PHPUnit
heute LimeSurvey 6 – weiterhin Yii 1.1
Ein persönliches Fazit – oder: was auf dem Weg verloren ging
Ich arbeite seit 7,5 Jahren mit LimeSurvey. Ich habe Yii 1.1 von Anfang an erlebt – und ich erinnere mich noch gut daran, wie es sich angefühlt hat.
Es war revolutionär. Nicht weil es technisch das Fortschrittlichste war, das es damals gab. Sondern weil es sich richtig anfühlte. Man öffnete einen Controller, schrieb eine actionIndex()-Methode, legte ein View-File daneben – und es funktionierte. Keine langen Konfigurationsdateien, keine Bootstrap-Ketten, kein mentaler Overhead. Das Framework verschwand hinter der Arbeit.
Mit Yii 2 änderte sich das. Plötzlich war vieles neu: Namespaces überall, Behaviors anders, Events anders verdrahtet, die Konfiguration ausführlicher. Technisch alles begründbar – aber die Intuitivität war weg. Ich musste über das Framework nachdenken, nicht mehr nur durch es hindurch arbeiten. Eine gewisse Abneigung machte sich breit – nicht weil Yii 2 schlecht war, sondern weil etwas fehlte, das vorher selbstverständlich gewesen war.
Yii 3 empfinde ich als noch einen Schritt weiter in dieselbe Richtung. Die Qualität ist beeindruckend – ~100% Psalm-Coverage, Mutation Testing, autarke Packages, konsequentes DI. Das ist Software-Engineering auf einem hohen Niveau. Aber es ist auch kompliziert. Die Zielgruppe hat sich verschoben: von "Entwickler die schnell produktiv sein wollen" zu "Entwickler die täglich über Architektur nachdenken und Psalm kennen."
Das ist kein Vorwurf an Yii 3. Es ist eine Beobachtung über einen Trend, der weit über Yii hinausgeht: Die PHP-Welt hat sich in 15 Jahren professionalisiert – PSR-Standards, Composer, statische Analyse, SOLID-Prinzipien. Das ist gut und richtig. Aber der Preis ist Komplexität. Und mit jeder neuen Version von Yii ist ein Stück von dem verloren gegangen, was Yii 1.1 so besonders gemacht hat: die Leichtigkeit.
LimeSurvey ist auf Yii 1.1 geblieben – nicht nur aus technischen Gründen, sondern vielleicht auch weil diese Leichtigkeit zum Charakter des Projekts passte. Das macht die Modernisierung nicht einfacher. Aber es macht sie verständlicher.