LimeSurvey on markob.de

Das Framework ist nur ein Detail. Das Domainmodell ist es nicht.

Mon, 24 Aug 2026 00:00:00 +0000

In Das Framework ist nur ein Detail war unsere These: Neue Anwendungslogik sollte nicht davon abhängen, ob am äußeren Rand Yii, Slim oder ein anderes Framework HTTP-Requests verarbeitet. Das Framework sollte Adapter sein, nicht Architektur.

Daran hat sich nichts geändert. Inzwischen beschäftigt uns allerdings eine Frage, die noch eine Ebene tiefer geht: Wenn wir das Framework aus dem Zentrum von LimeSurvey entfernen – welches Domainmodell wollen wir dort eigentlich erhalten? Begriffe wie QuestionGroup, Question, SubQuestion oder QuestionType sind für LimeSurvey-Entwickler so selbstverständlich, dass man leicht vergisst, sie überhaupt noch infrage zu stellen. Aber sind das notwendige Konzepte eines Survey-Systems – oder historische Architekturentscheidungen, die uns heute nur deshalb wie Domainlogik erscheinen, weil LimeSurvey seit vielen Jahren so funktioniert?

Das Framework ist nur ein Detail

Fri, 21 Aug 2026 00:00:00 +0000

In einer LimeSurvey-Stellenanzeige für einen Full-Stack-Developer (Stand: 20. August 2026) taucht unter „Tech We Use" das „Yii-3 PHP Framework" auf – bemerkenswert, denn der aktuelle LimeSurvey-Core basiert weiterhin auf Yii 1.1. Ob damit der bestehende Core migriert werden soll, ob Yii3 nur für neue Komponenten gedacht ist oder ob lediglich einzelne Yii3-Pakete gemeint sind, wissen wir nicht. Für das Folgende spielt das auch keine große Rolle.

Denn bevor LimeSurvey entscheidet, welches Framework Yii 1.1 irgendwann ersetzt, lohnt sich eine andere Frage: Warum sollte diese Entscheidung für den Anwendungscode überhaupt von Bedeutung sein?

Zweimal `square()` - Teil 3

Wed, 19 Aug 2026 00:00:00 +0000

Im zweiten Teil dieser Geschichte ging es um eine unbequeme Erkenntnis: Zwei zehn Jahre lang getrennt gewachsene Statistics-Implementierungen lassen sich nicht einfach wieder zusammenführen. Ein Diff zeigt, dass sich Admin und Public Statistics unterscheiden – er sagt nicht, ob dieser Unterschied fachlich notwendig ist oder nur historische Drift.

Also erst verstehen, dann verändern. Characterization Tests, um vorhandenes Verhalten zu dokumentieren. Die versteckte $_POST-Abhängigkeit sichtbar machen, als ersten kleinen Schritt zu einer Trust Boundary.

Zweimal `square()` - Teil 2

Tue, 18 Aug 2026 00:00:00 +0000

Im ersten Teil dieser Geschichte führte uns eine SQL Injection zu zwei Statistics-Helpern, zwei buildSelects()-Funktionen und schließlich zu zwei Funktionen, die nichts weiter tun, als eine Zahl zu quadrieren.

function square($number)
{
 if ($number == 0) {
 $squarenumber = 0;
 } else {
 $squarenumber = $number * $number;
 }

 return $squarenumber;
}

Zweimal.

Die Git-Historie führte zurück ins Jahr 2016. Für die Public Statistics wurde damals ein großer Teil der bestehenden Statistics-Implementierung abgespalten. Seitdem entwickelten sich Admin Statistics und Public Statistics getrennt weiter – bis eine SQL Injection zehn Jahre später beide Zweige wieder einholte.

Zweimal `square()` - Teil 1

Mon, 17 Aug 2026 00:00:00 +0000

Manchmal beginnt Code-Archäologie nicht mit einem spektakulären Fund. Manchmal beginnt sie mit einem SQL-Injection-Fix – und einer Funktion, die eine Zahl quadriert.

Am 12. August 2026 wurde im LimeSurvey-Repository Pull Request #5225 eröffnet. Der Titel: “Fixed issue #20648: [security] SQL injection in statistics”.

Das Problem war ernst. In der Statistikfunktion konnten manipulierte Filterparameter dazu führen, dass vom Request stammende Feldnamen ungeprüft in SQL-Abfragen gelangten. Der Fix führte deshalb eine Allowlist ein: Nur Spalten, die tatsächlich im Schema der jeweiligen Response-Tabelle existieren, dürfen noch als Feldnamen verwendet werden¹.

Naming ist wichtig

Sat, 15 Aug 2026 00:00:00 +0000

Manchmal reicht ein einzelner Feldname, um zu zeigen, wie viel Architektur eigentlich in einer Namensentscheidung steckt. Ein aktueller Pull Request im LimeSurvey-Kernrepository liefert dafür ein besonders klares Beispiel.

Der Fall

Am 14. August 2026 wurde im LimeSurvey-Repository der Pull Request #5236 eingereicht: ein neues Feature, das Surveys um einen zusätzlichen, sprachunabhängigen Titel erweitert – gedacht als interne Bezeichnung zur Identifikation im Administrationsbereich, unabhängig vom öffentlich sichtbaren, lokalisierten Umfragetitel.

Technisch ist das ein sinnvolles Feature. Der bestehende Titel einer Survey (survey_languagesettings.surveyls_title) ist an eine Sprache gebunden und für interne Zwecke – etwa das Wiederfinden einer Umfrage in einer langen Liste – oft ungeeignet. Ein zweites, sprachneutrales Feld schließt eine echte Lücke.

Report-driven Survey Design

Sat, 27 Jun 2026 00:00:00 +0000

Ich wollte eine Treiberanalyse bauen. Dafür brauchte ich eine Matrixfrage – mehrere Aspekte als Subquestions, einheitliche Skala. Dazu eine separate Gesamtbewertung als Zielgröße. Erst nachdem diese Struktur stand, habe ich überlegt, welche Aspekte ich überhaupt abfragen wollte.

Irgendwann fiel mir auf:

Ich entwerfe gar keine Umfragen mehr. Ich entwerfe Reports.

Das Problem mit der klassischen Reihenfolge

Der übliche Weg beim Fragebogendesign: Was wollen wir wissen? Welche Fragen stellen wir? Welcher Fragetyp passt? Der Report kommt am Ende – als Auswertung dessen, was die Daten hergeben.

Warum Vergütung auf Platz 7 landet

Tue, 23 Jun 2026 00:00:00 +0000

In einer Employee Retention Survey hat Vergütung & Benefits den größten Gap zum Zielwert. Score 2,6, Zielwert 4,2 – eine Lücke von 1,6 Punkten. Kein anderer Bereich liegt weiter vom Ziel entfernt.

Trotzdem landet Vergütung auf Platz 7 von 8.

Das ist kein Fehler. Es ist das Ergebnis einer bewussten Designentscheidung: nicht die Größe der Lücke allein bestimmt die Priorität, sondern die Lücke gewichtet nach strategischer Relevanz.

Das Problem mit dem rohen Gap

Wer acht Dimensionen einer Mitarbeiterbefragung nach dem Gap zum Zielwert sortiert, bekommt eine Liste. Führung mit Score 2,8 liegt 1,4 Punkte unter dem Ziel. Vergütung mit Score 2,6 liegt 1,6 Punkte darunter. Vergütung hätte also Priorität.

Wo eine Verbesserung die meisten Menschen erreicht

Tue, 23 Jun 2026 00:00:00 +0000

Im vorigen Artikel wurde gezeigt warum Vergütung trotz des größten Gaps auf Platz 7 landet: der Priority Score gewichtet nach strategischer Bedeutung, nicht nach Lückengröße. Führung mit 18 % Gewicht schlägt Vergütung mit 5 %.

Aber der Priority Score hat einen blinden Fleck.

Er fragt nicht: wie viele Mitarbeitende betrifft das Problem überhaupt?

Was PRI nicht sieht

Nehmen wir zwei Treiber aus dem Beispiel:

Treiber	Score	Gap	Gewicht	PRI
Führung	2,8	1,4	18 %	0,252
Vergütung	2,6	1,6	5 %	0,080

PRI sagt: Führung zuerst. Das Modell argumentiert dass Führung strategisch wichtiger ist als Vergütung – und das stimmt.

Der NPS ist keine Zahl

Fri, 19 Jun 2026 00:00:00 +0000

NPS = 32. Gut oder schlecht?

Die Frage klingt sinnvoll. Sie ist es nicht – zumindest nicht so gestellt.

Ein Net Promoter Score ist mehr als eine Kennzahl im klassischen Sinne. Er ist eine verdichtete Verteilung. Hinter jedem NPS-Wert stecken drei Gruppen: Promotoren (Wertung 9–10), Passive (7–8) und Kritiker (0–6). Aus deren Anteilen ergibt sich die Formel:

NPS = % Promotoren − % Kritiker

Zwei völlig unterschiedliche Verteilungen können deshalb exakt denselben NPS erzeugen.

Likert-Skalen richtig einsetzen und auswerten

Fri, 19 Jun 2026 00:00:00 +0000

Wer eine Umfrage baut, kommt an Likert-Skalen kaum vorbei. Zustimmung zu einer Aussage von 1 bis 5, Zufriedenheit von „sehr unzufrieden" bis „sehr zufrieden", Wichtigkeit von „unwichtig" bis „sehr wichtig" – das Grundprinzip ist immer dasselbe. Und doch entstehen bei der Umsetzung und Auswertung immer wieder dieselben Fehler.

Dieser Artikel ist kein Statistik-Lehrbuch. Er beantwortet die Fragen, die sich beim Bauen und Interpretieren von Umfragen tatsächlich stellen.

Das Schulnotenproblem

Beginnen wir mit dem häufigsten Missverständnis.

Treiberanalyse: Welche Frage wirklich zählt

Wed, 17 Jun 2026 00:00:00 +0000

Eine Mitarbeiterbefragung mit zwanzig Zufriedenheitsfragen liefert zwanzig Balkendiagramme. Frage 7 schneidet schlecht ab, Frage 14 hervorragend, der Rest irgendwo dazwischen. Was macht man mit dieser Liste?

Die naheliegende Reaktion ist: an den schlechtesten Werten ansetzen. Frage 7 verbessern, weil sie am schlechtesten bewertet wurde.

Das ist oft die falsche Priorität.

Das Problem mit reiner Bewertung

Eine niedrig bewertete Frage ist nicht automatisch ein Problem das sich zu lösen lohnt. Es kommt darauf an, ob diese Frage überhaupt etwas bewegt.

Faker: Reproduzierbare Testdaten für LimeSurvey

Tue, 16 Jun 2026 00:00:00 +0000

Eine Umfrage ist fertig konzipiert, aber noch nicht live. Trotzdem soll bereits ein Report dafür entstehen – Trendcharts, KPI-Karten, Segmentierungen. Die Frage die sich sofort stellt: woher kommen die Daten, an denen man das alles testet?

Die ehrliche Antwort war bei mir lange Zeit: ich habe sie von Hand erzeugt. Umfrage öffnen, durchklicken, Antworten setzen, abschicken. Wieder von vorne. Zwanzig, dreißig, manchmal fünfzig Mal – je nachdem wie überzeugend die Demo aussehen sollte.

Survey as Code: Umfragen versionieren, reviewen und wiederverwenden

Mon, 15 Jun 2026 00:00:00 +0000

Früher war ich Software-Entwickler, heute bin ich Survey-Entwickler.

Als Software-Entwickler schreibe ich Code. Ich committe ihn, ich reviewe ihn, ich rolle ihn zurück wenn etwas schiefgeht. Jede Änderung hat eine Historie. Jede Funktion lässt sich wiederverwenden.

Als Survey-Entwickler klicke ich Dropdown-Menüs.

Das war zumindest bis vor kurzem so.

Das Problem mit dem Klicken

Eine LimeSurvey-Umfrage entsteht klassisch im Browser. Frage anlegen, Antwortoptionen eintippen, Fragengruppe verschieben, Bedingung setzen. Das funktioniert – bis die Umfrage zum zweiten Mal gebraucht wird.

Visualisierung allein reicht nicht mehr

Thu, 11 Jun 2026 00:00:00 +0000

Die meisten Umfragereports beantworten die Frage: „Was zeigen die Daten?" Die eigentlich wichtigere Frage lautet: „Was bedeuten die Daten?"

Das ist kein semantischer Unterschied. Es ist der Unterschied zwischen einem Bericht, den jemand liest, und einem Bericht, den jemand versteht.

Visualisierung bleibt wichtig. Sie ist jedoch nicht mehr ausreichend.

Das Visualisierungsproblem

Vor fünfzehn Jahren war das beeindruckend:

Frage 1 ██████████ 42 %
Frage 2 ███████ 31 %
Frage 3 █████████ 58 %

Heute kann das jede Software. LimeSurvey. Excel. SPSS. PowerBI. Tableau. ChatGPT. Ein Balkendiagramm pro Frage ist kein Mehrwert mehr – es ist der Mindeststandard.

Vom Fragebogen zum fertigen Report

Sun, 31 May 2026 00:00:00 +0000

Im ersten Artikel habe ich gezeigt was das Report-Plugin produziert. Dieser Artikel zeigt den kompletten Weg dorthin – von der Umfrage bis zum fertigen Report, Schritt für Schritt.

Als Beispiel dient eine Restaurant-Feedback-Umfrage. Ein alltagsnahes Szenario: Gäste bewerten ihren Besuch, das Restaurant will verstehen was gut läuft und wo Verbesserungsbedarf besteht.

Die Umfrage

Die Umfrage besteht aus neun Fragen – kompakt, aber ausreichend für einen differenzierten Report.

Code	Typ	Frage
`q1`	L – Radio List	Wie bewerten Sie Ihren Restaurantbesuch insgesamt? (1–6)
`nps`	L – Radio List	Wie wahrscheinlich würden Sie uns weiterempfehlen? (0–10)
`matrix`	F – Array	Wie bewerten Sie die folgenden Aspekte? (9 Subfragen, Skala 1–6)
`anlass`	L – Radio List	Aus welchem Anlass waren Sie bei uns?
`besuchszeit`	L – Radio List	Wann haben Sie uns besucht?
`frequency`	L – Radio List	Wie häufig besuchen Sie unser Restaurant?
`strengths`	M – Multiple Choice	Welche Punkte sind Ihnen besonders positiv aufgefallen?
`potentials`	O – List with Comment	Wo sehen Sie Verbesserungsbedarf?
`freetext`	T – Long Text	Möchten Sie uns noch etwas mitteilen?

Wichtig dabei: die Fragen-Codes – q1, nps, matrix und so weiter. Diese Codes vergebe ich beim Anlegen der Fragen in LimeSurvey bewusst und sprechend. Sie sind der Ankerpunkt für das Mapping im nächsten Schritt.

Professionelle Reports für LimeSurvey

Sat, 30 May 2026 00:00:00 +0000

LimeSurvey sammelt Daten. Was danach kommt, ist meistens bekannt: CSV-Export, Excel, PowerPoint, Eigenentwicklung. Jedes Mal manuell, jedes Mal außerhalb von LimeSurvey, jedes Mal von vorne.

Das Plugin erzeugt keine generischen Statistiken. Es erzeugt Reports.

Das ist die Lücke zwischen zu wenig und zu viel. Auf der einen Seite die eingebaute Statistikansicht – immer verfügbar, kein Aufwand, aber generisch und nicht anpassbar. Auf der anderen Seite die vollständig externe Lösung – maximale Flexibilität, aber ohne direkten Bezug zur Umfrage. Dazwischen war bisher nichts.

LimeSurvey Fragetypen – Einordnung aus der Praxis

Thu, 21 May 2026 00:00:00 +0000

Die vollständige Referenz listet alle 28 Fragetypen auf. Dieser Artikel bewertet sie – aus der Perspektive von jemandem der seit Jahren LimeSurvey-Umfragen entwickelt, pflegt und erweitert.

Die Frage ist nicht: Was kann dieser Typ? Die Frage ist: Wann ist er wirklich der richtige Ansatz?

Die unverzichtbaren Typen

Das sind die Typen die in der Praxis fast immer ausreichen – und die man wirklich verstehen muss.

Liste (Radio) · `L`

Der vielseitigste Einzelfragentyp. Vollständig konfigurierbare Antwortoptionen, optionale „Sonstige"-Option, gut für jede Einfachauswahl geeignet.

LimeSurvey Fragetypen – die vollständige Referenz

Wed, 20 May 2026 00:00:00 +0000

LimeSurvey kennt 28 Fragetypen. Jeder Typ wird intern durch ein einzelnes Zeichen identifiziert – ein Erbe aus der frühen Entwicklungsgeschichte des Systems, das bis heute in der Datenbank, im Code und in der RemoteControl-API sichtbar ist.

Diese Referenz listet alle Typen mit ihrem internen Kürzel, ihrer Struktur und einem typischen Anwendungsfall. Eine Einordnung – welche Typen in der Praxis tragen und welche nicht – folgt in einem separaten Artikel.

Aufbau der Tabelle

Kürzel – das interne Zeichen wie es in der Datenbank (questions.type) und im Code (Question::QT_*) steht.

Asymmetrische Modernisierung

Tue, 12 May 2026 00:00:00 +0000

Wer sich mit der composer.json im develop-major-Branch von LimeSurvey beschäftigt, findet dort folgendes Detail:

"config": {
 "vendor-dir": "vendor",
 "bin-dir": "vendor/bin",
 "platform": {
 "php": "8.1.29"
 }
}

Gleichzeitig fehlt eine explizite PHP-Anforderung:

"require": {
 "php": ">=8.1"
}

Auf den ersten Blick ein kleines technisches Detail. Tatsächlich illustriert diese Konstellation ein Muster, das man in jedem langlebigen PHP-System findet – und das erklärungsbedürftiger ist als es aussieht.

Was `config.platform.php` sagt

Die platform-Konfiguration sorgt dafür, dass Composer die Dependency-Auflösung gegen eine festgelegte PHP-Version durchführt – unabhängig davon was tatsächlich auf dem System läuft. Reproduzierbare Builds, konsistente Paketversionen, keine Überraschungen zwischen Entwicklungs- und Produktionsumgebung. Das ist vernünftig.

20 Jahre LimeSurvey – eine Entwicklungsgeschichte in drei Phasen

Sun, 10 May 2026 00:00:00 +0000

Die Release Notes von LimeSurvey sind öffentlich zugänglich. Sie beginnen mit Changes from 0.98 to 0.99 und enden – Stand heute – bei 7.0.0-RC1 vom 30. April 2026. Über 11.000 Zeilen, die niemand vollständig liest – und die zusammen eine Geschichte erzählen, die so komprimiert nirgendwo steht.

Diese Geschichte hat drei Phasen. Sie erklärt, warum LimeSurvey so ist wie es ist – und was LimeSurvey 7 jetzt konkret bedeutet.

Phase 1: Der Aufbau (0.99 bis ~1.90, 2006–2012)

Die frühe Phase ist bemerkenswert dicht. Innerhalb weniger Jahre entstand das konzeptuelle Fundament, auf dem LimeSurvey bis heute steht.

Die LimeSurvey RemoteControl API – eine kritische Betrachtung

Sun, 10 May 2026 00:00:00 +0000

LimeSurvey bietet seit Version 2.0 eine Fernsteuerungsschnittstelle: die RemoteControl 2 API, kurz LSRC2. Über JSON-RPC oder XML-RPC lassen sich Umfragen anlegen, aktivieren, Teilnehmer einladen, Antworten exportieren – praktisch alles, was auch über das Webinterface möglich ist. Die Schnittstelle ist funktional, breit eingesetzt und für viele Integrationen die einzige Option.

Und sie trägt dieselben Merkmale wie der Rest des Systems.

Was die API kann

Der Funktionsumfang ist beeindruckend. Umfragen anlegen, importieren, kopieren, aktivieren und löschen. Gruppen und Fragen verwalten. Teilnehmer hinzufügen, einladen, erinnern. Antworten lesen, schreiben, exportieren. Benutzer und Berechtigungen abfragen. Quoten verwalten. Feldkarten abrufen.

Ein typisierter LimeSurvey API-Client

Sun, 10 May 2026 00:00:00 +0000

Im vorherigen Artikel haben wir drei grundlegende Probleme der LSRC2-API identifiziert: ein zustandsbehaftetes Session-Modell, das der Aufrufer selbst verwalten muss, ein inkonsistentes Rückgabeformat das Erfolg und Fehler nicht unterscheidet, und einen empfohlenen Client, der LimeSurvey-Konzepte nicht kennt.

Dieser Artikel zeigt, wie ein typisierter Client diese Probleme löst – nicht als vollständige Implementierung, sondern als Lösungsvorschlag anhand konkreter Beispiele.

Die Ausgangslage

Ein typischer Aufruf mit dem rohen JsonRPCClient sieht so aus:

$client = new JsonRPCClient('https://example.com/index.php/admin/remotecontrol');

$sessionKey = $client->get_session_key('admin', 'password');

$result = $client->add_survey($sessionKey, 0, 'Meine Umfrage', 'de');

if (is_array($result) && isset($result['status'])) {
 // Fehler
 echo $result['status'];
} else {
 // Erfolg – $result ist ein int
 $surveyId = $result;
}

$client->release_session_key($sessionKey);

Drei Probleme in acht Zeilen: Der Session-Key muss manuell übergeben und am Ende freigegeben werden. Der Rückgabetyp ist unbekannt bis man ihn prüft. Und was genau in $result['status'] steht, weiß man erst zur Laufzeit.

Das LimeSurvey Plugin-Event-System – eine kritische Betrachtung

Sat, 09 May 2026 00:00:00 +0000

LimeSurvey verfügt über ein event-basiertes Plugin-System. Plugins abonnieren Events, reagieren darauf, und können Daten zurückgeben. Das Konzept ist solide – und weit verbreitet in modernen Frameworks. Die Implementierung erzählt eine andere Geschichte.

Was ein Event-System leisten soll

Ein Event kommuniziert, dass etwas passiert ist oder passieren wird. Der Name beschreibt das Ereignis. Die Parameter sind bekannt und garantiert. Der Empfänger reagiert – er fragt nicht erst nach, ob die Daten überhaupt vorhanden sind.

newDirectRequest – vollständige Webanwendungen im LimeSurvey-Plugin

Sat, 09 May 2026 00:00:00 +0000

Der direct-Event ist der CLI-Einstiegspunkt für LimeSurvey-Plugins. newDirectRequest ist sein HTTP-Pendant: ein Plugin wird über den Browser angesprochen, bekommt einen vollständigen HTTP-Request, und kann eine vollständige HTTP-Response zurückgeben.

Was LimeSurvey dabei nicht mitliefert, ist Routing. Der Event landet im Plugin – was danach passiert, ist vollständig in der Verantwortung des Plugin-Entwicklers.

Wie `newDirectRequest` funktioniert

Die URL, unter der ein Plugin erreichbar ist, folgt diesem Schema:

https://example.com/index.php/plugins/direct/plugin/MeinPlugin

Das Plugin abonniert den Event in init() und prüft das Target – analog zu direct, aber case-insensitiv, da URL-Parameter in der Praxis nicht immer exakt geschrieben werden:

Yii commands in LimeSurvey-Plugins

Sat, 09 May 2026 00:00:00 +0000

Der direct-Event ist der offizielle CLI-Einstiegspunkt für LimeSurvey-Plugins – schlank, gezielt, gut für einfache Cronjobs. Aber er hat eine feste Grenze: drei Parameter, kein Routing, keine Argument-Validierung. Wer komplexere Kommandos braucht, stößt schnell an diese Grenze.

Yii 1.1 bringt ein eigenes Command-System mit, das deutlich mächtiger ist. Und es lässt sich so in ein Plugin integrieren, dass die Plugin-Kapselung vollständig erhalten bleibt.

Was Yii Commands können

Ein Yii Command ist eine Klasse, die von CConsoleCommand erbt. In der einfachsten Form überschreibt sie run():

Der direct-Event, gezielter CLI-Einstieg für LimeSurvey-Plugins

Fri, 08 May 2026 00:00:00 +0000

Wenn ein Plugin nicht auf eine Benutzeraktion im Browser reagieren soll, sondern auf der Kommandozeile aufgerufen werden – für einen Cronjob, einen Datenexport, eine nächtliche Bereinigung –, dann ist direct der richtige Einstiegspunkt.

Das Minimalbeispiel

Ein LimeSurvey-Plugin besteht aus mindestens zwei Dateien:

upload/plugins/HelloWorld/
 config.xml
 HelloWorld.php

Der Verzeichnisname, der Klassenname und der <name>-Eintrag in der config.xml müssen identisch sein.

<?xml version="1.0" encoding="UTF-8"?>
<config>
 <metadata>
 <name>HelloWorld</name>
 <type>plugin</type>
 <version>1.0.0</version>
 <author>My Name</author>
 <description><![CDATA[Hello World via CLI]]></description>
 </metadata>
 <compatibility>
 <version>6.0</version>
 <version>5.0</version>
 </compatibility>
</config>

class HelloWorld extends PluginBase
{
 protected $storage = 'LimeSurvey\PluginManager\DbStorage';
 static protected $description = 'HelloWorld';
 static protected $name = 'HelloWorld';

 public function init(): void
 {
 $this->subscribe('direct');
 }

 public function direct(): void
 {
 $event = $this->getEvent();
 if ($event->get('target') !== get_class($this)) {
 return;
 }

 echo 'HELLO WORLD' . PHP_EOL;
 exit;
 }
}

Nach der Aktivierung im Plugin-Manager wird das Plugin so aufgerufen:

LimeSurvey und Composer – eine ungewöhnliche Beziehung

Fri, 08 May 2026 00:00:00 +0000

Wer aus moderner PHP-Entwicklung kommt, hat bestimmte Erwartungen. Ein Projekt hat eine composer.json. Der vendor/-Ordner ist in .gitignore. Nach einem git clone folgt composer install – erst dann läuft etwas. Das ist der Standard, den Composer seit über zehn Jahren etabliert hat.

Bei LimeSurvey funktioniert das anders.

Der erste Hinweis

Eine lokale LimeSurvey-Installation beginnt typischerweise so:

git clone https://github.com/LimeSurvey/LimeSurvey.git

Danach folgt der webbasierte Installer im Browser – Datenbankverbindung einrichten, Tabellen anlegen, Admin-Account erstellen. Fertig. Ein composer install ist zu keinem Zeitpunkt nötig.

SurveyIndex + SurveyRuntimeHelper – Anatomie eines God Flow

Wed, 06 May 2026 00:00:00 +0000

Wenn zu viel Verantwortung nicht in einer Klasse steckt, sondern in einem Ablauf

In den letzten Artikeln dieser Serie haben wir zwei bekannte Antipattern betrachtet: createFieldMap() als Beispiel einer Funktion, die zu viele Verantwortlichkeiten in sich vereint, und LimeMailer als Beispiel einer Klasse, die zu viel weiß, zu viel hält und zu viel tut. Beide Diagnosen folgten derselben Logik: Zu viel Verantwortung an einer Stelle.

Diesmal geht es um etwas anderes. Nicht eine Funktion. Nicht eine Klasse. Sondern einen Ablauf.

LimeSurvey neu gedacht

Tue, 05 May 2026 00:00:00 +0000

Dieser Artikel ist ein Gedankenexperiment. Er setzt voraus, was in der Realität selten gegeben ist: ausreichend Zeit, ausreichend Ressourcen und das Mandat, wirklich neu zu denken – nicht nur neu zu schreiben.

Wir haben in dieser Serie viel über Geduld gesprochen. Über schrittweise Migration, über Composer Packages, über den Wert des akkumulierten Wissens. Über createFieldMap() und ihre 13 Jahre alten Kommentare. Über den Expression Manager, der 15 Jahre unberührt blieb, weil ihn niemand anfassen konnte.

Wenn „never" die richtige Antwort ist

Sun, 03 May 2026 00:00:00 +0000

Im Artikel Der Rewrite-Reflex haben wir argumentiert, warum der Impuls neu zu schreiben meistens falsch ist. Akkumuliertes Wissen geht verloren. Die neuen Entwickler treffen dieselben alten Entscheidungen – diesmal ohne den Kontext der sie damals erklärt hätte. Ein Rewrite beginnt bei null. Sauber. Modern. Ohne dieses Wissen.

Im Artikel Refactoring – was kostet es, was kostet es nicht? haben wir gesagt: „Later braucht einen Termin." Technische Schulden akkumulieren stille Kosten. Wer nie neu bewertet, trifft keine Entscheidung – er lässt die Entscheidung treffen.

Refactoring – was kostet es, was kostet es nicht?

Thu, 30 Apr 2026 00:00:00 +0000

Im Artikel über createFieldMap() haben wir gesehen was eine GodFunction ist, wie sie entsteht, und wie ein Weg heraus aussehen könnte: ein sauberes Composer Package, vollständige QA-Kette, 100% Testbarkeit.

Der Plan ist klar. Die Frage die danach kommt, ist schwieriger:

Was kostet das? Und was kostet es, es nicht zu tun?

Das ist keine technische Frage mehr. Das ist eine unternehmerische. Und sie landet früher oder später auf dem Tisch des CTOs oder Lead Developers – meistens dann wenn das Budget knapp ist und die Roadmap voll.

createFieldMap() – die God Function

Sun, 26 Apr 2026 00:00:00 +0000

Im Artikel über die Helper-Funktionen haben wir common_helper.php als Ganzes betrachtet – 130+ globale Funktionen, über 11.000 Aufrufe im Code, ein Relikt aus der prozeduralen Ära. In einem anderen Artikel haben wir LimeMailer als GodClass analysiert: eine Klasse die zu viel weiß, zu viel tut, und deshalb praktisch nicht testbar ist.

Heute schauen wir auf etwas das noch subtiler ist: eine GodFunction.

Keine Klasse. Eine einzelne Funktion. Mit über 600 Zeilen Code.

Wann hört Legacy auf, Legacy zu sein?

Sun, 19 Apr 2026 00:00:00 +0000

Im Artikel Der Rewrite-Reflex haben wir uns gefragt, warum Entwickler beim Anblick einer gewachsenen Codebasis sofort neu schreiben wollen – und warum das meistens ein Fehler ist. Die Alternative lautet: verstehen statt ersetzen. Schrittweise Entflechtung. Abhängigkeiten sichtbar machen. Vorhandenes Wissen bewahren.

Das ist der Weg. Aber wohin führt er?

Wann ist man fertig? Wann hört Legacy auf, Legacy zu sein?

Ich habe lange gebraucht um zu merken, dass ich diese Frage nie wirklich gestellt hatte. Und als ich sie stellte, merkte ich: die meisten können sie nicht beantworten.

LimeSurvey und Yii – eine Framework-Geschichte

Sun, 12 Apr 2026 00:00:00 +0000

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.

Wie PHPStan Legacy-Code sichtbar macht

Sun, 05 Apr 2026 00:00:00 +0000

Im ersten Artikel haben wir uns angesehen, was Yii::app()->loadHelper() eigentlich macht, warum die common_helper.php architektonisch ein Problem ist und wie der Weg heraus aussehen könnte: Composer Autoloading, Service-Klassen, saubere Abhängigkeiten.

Was wir damals nicht hatten: Zahlen.

Wie oft wird eine Funktion aus common_helper.php eigentlich aufgerufen? Welche Funktionen sind so gut wie tot und können sofort gelöscht werden? Und welche sind so tief im Code verwurzelt, dass eine Migration echte Arbeit bedeutet?

LimeSurvey und die Helper-Funktionen

Sun, 29 Mar 2026 00:00:00 +0000

Wer LimeSurvey als Plugin-Entwickler nutzt oder in der Codebasis arbeitet, begegnet früher oder später diesem Muster:

Yii::app()->loadHelper('common');
Yii::app()->loadHelper('surveytranslator');
Yii::app()->loadHelper('replacements');

Dahinter steckt ein einfacher Mechanismus: loadHelper('common') lädt die Datei application/helpers/common_helper.php und macht ihre Funktionen im globalen Scope verfügbar. Dasselbe Muster findet sich auch bei loadLibrary(), das auf application/libraries/ zeigt:

public function loadHelper($helper)
{
 Yii::import('application.helpers.' . $helper . '_helper', true);
}

public function loadLibrary($library)
{
 Yii::import('application.libraries.' . $library, true);
}

Der konzeptuelle Unterschied zwischen Helper und Library ist dabei in der LimeSurvey-Codebasis kaum greifbar – beide Mechanismen lösen dasselbe Problem auf dieselbe Art. Das war in einer Zeit sinnvoll, als PHP noch kein Autoloading kannte und Funktionen manuell eingebunden werden mussten. PHP 5.1 war 2005. Composer erschien 2012.

LimeMailer - Anatomie einer God Class

Sun, 22 Mar 2026 00:00:00 +0000

LimeMailer ist die zentrale E-Mail-Komponente von LimeSurvey. Sie erbt von PHPMailer, der weit verbreiteten PHP-Mailer-Bibliothek, und erweitert diese um LimeSurvey-spezifische Logik: Umfrage-Templates, Token-Ersetzungen, Anhänge nach E-Mail-Typ, Plugin-Events und vieles mehr.

Dieser Artikel betrachtet die Klasse nicht als Fehler ihrer Entwickler. Wer in einem laufenden Open-Source-Projekt unter Zeitdruck Features liefert, trifft Entscheidungen, die im Moment vernünftig sind. Technische Schulden entstehen nicht durch Unwissenheit, sondern durch die Realität von Softwareentwicklung. Was hier analysiert wird, ist das Muster – nicht die Person dahinter.

LimeSurvey und wie Antworten gespeichert werden

Fri, 20 Mar 2026 00:00:00 +0000

Die Art, wie LimeSurvey Umfrageantworten speichert, gehört zu den ältesten und fundamentalsten Architekturentscheidungen der Plattform. Sie beeinflusst alles, was darüber liegt: Plugins, Integrationen, Reporting und die Erweiterbarkeit des Systems.

Wer mit LimeSurvey arbeitet, kommt früher oder später mit dieser Struktur in Berührung – spätestens dann, wenn Antwortdaten außerhalb der Plattform ausgewertet oder in eigene Systeme integriert werden sollen.

Survey-spezifische Antworttabellen

Für jede Umfrage legt LimeSurvey eine eigene Datenbanktabelle an. Der Tabellenname folgt dem Schema

LimeSurvey und die Hungarian Notation

Sun, 15 Mar 2026 00:00:00 +0000

Wer schon einmal einen Blick in den Quellcode von LimeSurvey geworfen hat, dem begegnet unweigerlich Folgendes:

$iSurveyId = 42;
$sLanguage = 'de';
$oSurvey = Survey::model()->findByPk($iSurveyId);
$aQuestions = $oSurvey->getQuestions();
$bActive = true;

Das Präfix verrät den Typ: i für Integer, s für String, o für Object, a für Array, b für Boolean. Diese Konvention nennt sich Hungarian Notation – und sie stammt aus einer Zeit, in der PHP noch keinerlei Typisierung kannte. LimeSurvey existiert seit über 20 Jahren, und manche dieser Muster sind genauso alt.

Der Rewrite-Reflex

Sun, 08 Mar 2026 00:00:00 +0000

Wer zum ersten Mal in eine gewachsene Codebasis eintaucht – unbekannte Strukturen, kryptische Bezeichner, Abhängigkeiten, die sich wie ein Geflecht durch das System ziehen – kennt den Impuls: neu schreiben. Sauber. Modern. Diesmal richtig.

Dieser Reflex ist verständlich. Er ist menschlich. Und er ist einer der teuersten Fehler, den ein Entwicklungsteam machen kann.

Was ist Legacy-Code überhaupt?

Bevor man über Rewrite oder Modernisierung spricht, lohnt sich ein Blick auf die Frage: Was ist Legacy-Code?

LimeSurvey - ein System im Übergang

Sun, 01 Mar 2026 00:00:00 +0000

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.

LimeSurvey on markob.de

Das Framework ist nur ein Detail. Das Domainmodell ist es nicht.

Das Framework ist nur ein Detail

Zweimal `square()` - Teil 3

Zweimal `square()` - Teil 2

Zweimal `square()` - Teil 1

Naming ist wichtig

Der Fall

Report-driven Survey Design

Das Problem mit der klassischen Reihenfolge

Warum Vergütung auf Platz 7 landet

Das Problem mit dem rohen Gap

Wo eine Verbesserung die meisten Menschen erreicht

Was PRI nicht sieht

Der NPS ist keine Zahl

Likert-Skalen richtig einsetzen und auswerten

Das Schulnotenproblem

Treiberanalyse: Welche Frage wirklich zählt

Das Problem mit reiner Bewertung

Faker: Reproduzierbare Testdaten für LimeSurvey

Survey as Code: Umfragen versionieren, reviewen und wiederverwenden

Das Problem mit dem Klicken

Visualisierung allein reicht nicht mehr

Das Visualisierungsproblem

Vom Fragebogen zum fertigen Report

Die Umfrage

Professionelle Reports für LimeSurvey

LimeSurvey Fragetypen – Einordnung aus der Praxis

Die unverzichtbaren Typen

Liste (Radio) · L

LimeSurvey Fragetypen – die vollständige Referenz

Aufbau der Tabelle

Asymmetrische Modernisierung

Was config.platform.php sagt

20 Jahre LimeSurvey – eine Entwicklungsgeschichte in drei Phasen

Phase 1: Der Aufbau (0.99 bis ~1.90, 2006–2012)

Die LimeSurvey RemoteControl API – eine kritische Betrachtung

Was die API kann

Ein typisierter LimeSurvey API-Client

Die Ausgangslage

Das LimeSurvey Plugin-Event-System – eine kritische Betrachtung

Was ein Event-System leisten soll

newDirectRequest – vollständige Webanwendungen im LimeSurvey-Plugin

Wie newDirectRequest funktioniert

Yii commands in LimeSurvey-Plugins

Was Yii Commands können

Der direct-Event, gezielter CLI-Einstieg für LimeSurvey-Plugins

Das Minimalbeispiel

LimeSurvey und Composer – eine ungewöhnliche Beziehung

Der erste Hinweis

SurveyIndex + SurveyRuntimeHelper – Anatomie eines God Flow

LimeSurvey neu gedacht

Wenn „never" die richtige Antwort ist

Refactoring – was kostet es, was kostet es nicht?

createFieldMap() – die God Function

Wann hört Legacy auf, Legacy zu sein?

LimeSurvey und Yii – eine Framework-Geschichte

Prado – der Anfang einer Linie

Wie PHPStan Legacy-Code sichtbar macht

LimeSurvey und die Helper-Funktionen

LimeMailer - Anatomie einer God Class

LimeSurvey und wie Antworten gespeichert werden

Survey-spezifische Antworttabellen

LimeSurvey und die Hungarian Notation

Der Rewrite-Reflex

Was ist Legacy-Code überhaupt?

LimeSurvey - ein System im Übergang

Was ist LimeSurvey?

Liste (Radio) · `L`

Was `config.platform.php` sagt

Wie `newDirectRequest` funktioniert