markob.de

LimeSurvey 7.0.11 → 7.0.12

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

Kopfdaten und Grenzen

Release: 7.0.11 → 7.0.12
Commits: 36
Geänderte Dateien: 170
Analyse: 2026-09-01
Schwerpunkt: Barrierefreiheit und Sicherheit

Nicht untersucht

Verglichen wurden die Tags 7.0.11+260821 vom 20. August 2026 und 7.0.12+260833 vom 31. August 2026 mit git log --oneline und git diff --stat. Nicht ausgewertet wurden die Übersetzungsdateien unter locale/, die Inhalte des Verzeichnisses vendor/ über die Versionszeilen der Sperrdatei hinaus sowie die minifizierten Build-Artefakte unter assets/packages/; Aussagen darüber, ob die ausgelieferten Build-Stände deckungsgleich mit den geänderten Quelldateien sind, bleiben deshalb offen. Indirekte Effekte über transitive Drittabhängigkeiten sind durch reine Diff-Analyse nicht vollständig erfassbar, weil die Sperrdatei nur die unmittelbar gebundenen Stände nennt. Die Kurzliste musste einen Eintrag geringerer Relevanz auslassen: die Umstellung der Gruppen- und Fragenkennungen auf Ganzzahlen in der JSON-Antwort des Fragenbaums.

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?

Kurs Evaluationen

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

Wer an einer Hochschule Lehrevaluationen mit LimeSurvey umsetzt, kennt das Muster: Es funktioniert – bis die Struktur komplexer wird. Eine Vorlesung mit drei Übungsgruppen und drei unterschiedlichen Lehrpersonen ist mit LimeSurvey allein kein Survey-Problem mehr, sondern ein Datenmodell-Problem, das man LimeSurvey nicht ansieht.

Das eigentliche Problem liegt vor der Umfrage

LimeSurvey ist eine ausgezeichnete Survey Engine: Gruppen, Fragen, Logik, Aktivierung, Teilnehmerverwaltung – das alles beherrscht es zuverlässig. Was LimeSurvey nicht mitbringt, ist ein Modell für die akademische Realität, die vor der Umfrage steht:

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?

LimeSurvey 7.0.10 → 7.0.11

Thu, 20 Aug 2026 00:00:00 +0000

Kopfdaten und Grenzen

Release: 7.0.10 → 7.0.11
Commits: 23
Geänderte Dateien: 200
Analyse: 20.08.2026
Schwerpunkt: Barrierefreiheit + Korrekturen

Nicht untersucht

Verglichen wurden die Tags 7.0.10+260813 und 7.0.11+260821 mit git log --oneline, git diff --stat sowie dateiweisen git show-Aufrufen je Commit; der Analysestand ist der 20. August 2026. Nicht untersucht wurden das Laufzeitverhalten einer installierten Instanz, die Übersetzungskataloge unterhalb von locale/ und die kompilierten Bundles unterhalb von editor/build/, deren Inhalt nur als Minifikat vorliegt — Aussagen über tatsächliche Bildschirmausgaben und über die Deckungsgleichheit von Editor-Quellcode und ausgelieferter Fassung bleiben daher offen. Indirekte Effekte über transitive Drittabhängigkeiten sind durch reine Diff-Analyse nicht vollständig erfassbar, weil der Diff nur die Sperrdatei und die eingecheckten Bibliotheksdateien zeigt, nicht deren Zusammenspiel zur Laufzeit. Beide Tag-Namen waren im Repository verifizierbar. Im Kapitel „Weitere relevante Änderungen“ sind drei Einträge geringerer Relevanz nicht aufgeführt: die überarbeitete Sicherheitsrichtlinie in SECURITY.md, die neu hinzugefügte Metadatendatei publiccode.yml und die Anpassungen an der CI-Konfiguration samt zugehöriger Testkorrektur.

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.

LimeSurvey 7.0.9 → 7.0.10

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

Kopfdaten und Grenzen

Release: 7.0.9 → 7.0.10
Commits: 12
Geänderte Dateien: 28
Analyse: 14.08.2026
Schwerpunkt: Sicherheit und Datenkorrektheit

Nicht untersucht

Verglichen wurden die Tags 7.0.9+260812 und 7.0.10+260813 mit git log --oneline 7.0.9+260812..7.0.10+260813 und git diff --stat 7.0.9+260812..7.0.10+260813; beide Tags sind im Repository vorhanden. Nicht ausgewertet wurden die binären Übersetzungskataloge unter locale/ und die daraus abgeleitete Vorlagendatei, weshalb keine Aussage darüber möglich ist, ob eine der neuen Übersetzungen bestehende Zeichenketten inhaltlich verschiebt. Es wurde nichts ausgeführt: weder die Testsuite noch ein Update gegen eine reale Datenbank, sodass alle Aussagen über Laufzeitverhalten aus dem Quelltext abgeleitet sind. Indirekte Effekte über transitive Drittabhängigkeiten sind durch reine Diff-Analyse nicht vollständig erfassbar. Ob das offizielle Release-Archiv über den Repository-Stand hinaus Bündel neu baut, ist aus dem Repository nicht bestimmbar. Die Kurzliste musste keine Einträge auslassen.

LimeSurvey 7.0.8 → 7.0.9

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

Kopfdaten und Grenzen

Release: 7.0.8 → 7.0.9
Commits: 25
Geänderte Dateien: 248
Analyse: 11.08.2026
Schwerpunkt: Sicherheit + Stabilisierung

Nicht untersucht

Verglichen wurden die Tags 7.0.8+260806 und 7.0.9+260812; beide sind im Repository vorhanden und wurden über git log --oneline 7.0.8+260806..7.0.9+260812 und git diff --stat 7.0.8+260806..7.0.9+260812 ausgewertet. Nicht untersucht wurden die Inhalte des Verzeichnisses vendor/, das den weit überwiegenden Teil der 248 geänderten Dateien ausmacht und dessen Dateien im Diff durchgängig als Binärdateien geführt werden — Aussagen über das Verhalten der aktualisierten Fremdbibliotheken selbst stützen sich daher ausschließlich auf die Metadaten in composer.lock und nicht auf deren Quelltext. Ebenfalls nicht ausgewertet wurden die Übersetzungsdateien unterhalb von locale/ sowie die Build-Artefakte des React-Editors, weshalb offenbleibt, ob eine Zeichenkettenänderung in einer bestimmten Sprache vollständig nachgezogen ist. Indirekte Effekte über transitive Drittabhängigkeiten sind durch reine Diff-Analyse nicht vollständig erfassbar, insbesondere nicht bei den in diesem Release angehobenen HTTP- und Kryptobibliotheken. Die Kurzliste musste keine Einträge auslassen.

LimeSurvey 7.0.7 → 7.0.8

Thu, 06 Aug 2026 00:00:00 +0000

Kopfdaten und Grenzen

Release: 7.0.7 → 7.0.8
Commits: 29
Geänderte Dateien: 136
Analyse: 11.08.2026
Schwerpunkt: Fehlerbehebungen und Editorarbeiten

Nicht untersucht

Verglichen wurden die Tags 7.0.7+260729 und 7.0.8+260806 mit git log --oneline 7.0.7+260729..7.0.8+260806 und git diff --stat 7.0.7+260729..7.0.8+260806; beide Tags sind im Repository vorhanden und liegen auf dem Zweig master. Nicht ausgewertet wurden die Übersetzungsdateien unterhalb von locale/, die kompilierten Bundles unterhalb von editor/build/ sowie die JavaScript-Quellkarten; Aussagen über Zeichenketten in einzelnen Sprachen und über das exakte Laufzeitverhalten der ausgelieferten Bundles bleiben deshalb offen. Die Testdateien unterhalb von tests/ wurden nur daraufhin gesichtet, welche Produktionsänderung sie begleiten, nicht auf ihre Abdeckung hin. Indirekte Effekte über transitive Drittabhängigkeiten sind durch reine Diff-Analyse nicht vollständig erfassbar, weil der Diff nur die im Repository eingecheckten Paketstände zeigt und nicht das Verhalten der Pakete untereinander. Aus dem Kapitel „Weitere relevante Änderungen" ist ein Eintrag geringerer Relevanz weggelassen, weil er sich keinem der sieben vorgegebenen Bereiche zuordnen ließ: die geänderte Fehlermeldung der Anmeldung bei abgelaufenem Benutzerkonto.

Von KleinSite nach Hugo

Thu, 06 Aug 2026 00:00:00 +0000

Als ich vor einiger Zeit KleinSite gebaut habe – eine schlanke, dateibasierte Content-Engine, die Markdown und Twig-Templates verarbeitet – war das genau das, was ich brauchte: kein CMS-Overhead, volle Kontrolle, schnell gebaut. Für eine Handvoll Artikel funktionierte das gut. Aber irgendwann kippt jedes selbstgebaute System von “praktisch” zu “Baustelle”, und genau da war ich mit KleinSite angekommen.

Der eigentliche Auslöser war keine technische Grenze

Man könnte die Geschichte technisch erzählen: KleinSite konnte dies nicht, jenes nicht, also musste ein Wechsel her. Das wäre aber nicht ehrlich. Die eigentliche Frage war eine andere: Will ich meine Zeit in die Pflege einer eigenen Content-Engine stecken – oder in Content selbst?

Die sechs Etappen erfolgreicher KI-Softwareentwicklung

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

Noch nie war es so einfach, Software zu entwickeln – und gleichzeitig so leicht, ein Projekt in eine falsche Richtung laufen zu lassen. Moderne Coding Agents erzeugen in wenigen Minuten Hunderte Zeilen Code. Was sie jedoch nicht ersetzen, ist ein gemeinsames Verständnis davon, was überhaupt gebaut werden soll.

Ein Coding Agent kann eine Aufgabe brillant lösen – aber nur die Aufgabe, die er kennt. Was er nicht kennt, entscheidet er selbst, plausibel und konsequent, und oft an drei verschiedenen Stellen unterschiedlich. Das Ergebnis sieht dann nicht nach schlechter Arbeit aus. Es sieht nach drei verschiedenen Meinungen darüber aus, was das Produkt eigentlich ist.

LimeSurvey 7.0.6 → 7.0.7

Tue, 28 Jul 2026 00:00:00 +0000

Kopfdaten und Grenzen

Release: 7.0.6 → 7.0.7
Commits: 14
Geänderte Dateien: 64
Analyse: 10.08.2026
Schwerpunkt: Editorumstellung und Massenaktionen

Nicht untersucht

Verglichen wurden die im lokalen Repository verifizierten Tags 7.0.6+260722 (22.07.2026) und 7.0.7+260729 (28.07.2026) mit git log --oneline 7.0.6+260722..7.0.7+260729 und git diff --stat 7.0.6+260722..7.0.7+260729. Nicht ausgewertet wurden die kompilierten Editor-Bundles unter editor/build/static/js, die minifizierten Stylesheets des Adminthemes sowie die binären Übersetzungskataloge und die Vorlagendatei der Übersetzungen. Dadurch bleibt offen, ob die Umstellung des Editors auf die Voreinstellung über die zitierten Quelldateien hinaus weitere Verhaltensänderungen im ausgelieferten Bundle mitbringt. Indirekte Effekte über transitive Drittabhängigkeiten lassen sich durch reine Diff-Analyse nicht vollständig erfassen. Aus dem Kapitel „Weitere relevante Änderungen" wurden zwei Einträge geringerer Relevanz weggelassen, nämlich die Stilanpassung der Blätterschaltflächen im Editor und die neu hinzugefügten Modultests für das Anlegen und Duplizieren von Fragengruppen.

LimeSurvey 7.0.5 → 7.0.6

Wed, 22 Jul 2026 00:00:00 +0000

Kopfdaten und Grenzen

Release: 7.0.5 → 7.0.6
Commits: 64
Geänderte Dateien: 1083
Analyse: 10.08.2026
Schwerpunkt: Ranking-Datenmodell, Editorausbau, Abhängigkeiten

Nicht untersucht

Verglichen wurden die im lokalen Repository verifizierten Tags 7.0.5+260623 (23.06.2026) und 7.0.6+260722 (
22.07.2026) mit git log --oneline 7.0.5+260623..7.0.6+260722 und git diff --shortstat 7.0.5+260623..7.0.6+260722.
Nicht ausgewertet wurden der Inhalt des mitgelieferten vendor/-Baums (837 der 1083 geänderten Dateien), die kompilierten Bundles unter editor/build/ und assets/packages/*/build, die minifizierten Admin-Theme-Stylesheets sowie die Übersetzungsdateien. Dadurch bleibt offen, ob die Umstellung der Tabellenkalkulations-Bibliothek und der Sprung des DI-Containers über die zitierten Quelldateien hinaus weitere Verhaltensänderungen mitbringen. Indirekte Effekte über transitive Drittabhängigkeiten lassen sich durch reine Diff-Analyse nicht vollständig erfassen. Aus dem Kapitel „Weitere relevante Änderungen" wurden neun Einträge geringerer Relevanz weggelassen, darunter der Wegfall obsoleter PHP-Versionsprüfungen, die Feldnamen-Ersetzung beim Gruppenimport, der Nullwert-Umgang im SPSS-Export und der Identity-Insert-Umgang bei der Wiederherstellung archivierter Antworten unter SQL Server.

Joomla 1.0: Überraschend moderne Ideen unter 20 Jahren PHP

Tue, 07 Jul 2026 00:00:00 +0000

Vor ein paar Tagen habe ich aus reiner Neugier das GitHub-Archiv von Joomla 1.0 geöffnet. Nicht das aktuelle Joomla – das wird seit Jahren aktiv weiterentwickelt und hat mit der Version von 2005 kaum noch etwas gemeinsam. Eigentlich wollte ich nur wissen, wie sich ein CMS anfühlt, das mich vor über zwanzig Jahren begeistert hat. Am Ende blieb ich deutlich länger hängen als geplant.

Die ursprüngliche Idee war sogar, ob sich das mit vertretbarem Aufwand auf PHP 8.3 heben ließe. Der Gedanke war schnell wieder verworfen. Aber der Blick in den Code hat sich trotzdem gelohnt – nicht wegen der Nostalgie, sondern wegen dem, was er über 20 Jahre PHP-Entwicklung erzählt.

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.

LimeSurvey 7.0.4 → 7.0.5

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

Kopfdaten und Grenzen

Release: 7.0.4 → 7.0.5
Commits: 11
Geänderte Dateien: 50
Analyse: 11.08.2026
Schwerpunkt: Berechtigungsfix und Oberflächenkorrekturen

Nicht untersucht

Verglichen wurden die Tags 7.0.4+260620 und 7.0.5+260623 mit git log --oneline 7.0.4+260620..7.0.5+260623, git diff --stat 7.0.4+260620..7.0.5+260623 sowie dateiweisen Diffs; beide Tags sind im Repository vorhanden und mussten nicht ersetzt werden. Nicht ausgewertet wurden die binären Übersetzungskataloge unter locale/ und die Vorlagendatei locale/_template/limesurvey.pot, sodass über inhaltliche Änderungen an Oberflächentexten keine Aussage getroffen wird. Ebenfalls nicht auf Auswirkungen untersucht wurden die Änderungen an der Testinfrastruktur unter tests/, weil dieser Code in einer Produktivinstallation nicht ausgeführt wird; ob die dortige Anmeldelogik nach der Umstellung noch fehlerfrei arbeitet, bleibt damit offen. Die ausgelieferten JavaScript-Bündel wurden nur über den Vergleich ihrer Dateiinhalte und der inhaltsabhängigen Dateinamen geprüft, nicht durch einen eigenen Build. Für die Kurzliste mussten keine Einträge wegen der Höchstzahl entfallen. Indirekte Effekte über transitive Drittabhängigkeiten sind durch reine Diff-Analyse grundsätzlich nicht vollständig erfassbar.

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.

LimeSurvey 7.0.3 → 7.0.4

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

Kopfdaten und Grenzen

Release: 7.0.3 → 7.0.4
Commits: 6
Geänderte Dateien: 12
Analyse: 11.08.2026
Schwerpunkt: Integritätsprüfung + Migrationsfix

Nicht untersucht

Verglichen wurden die Tags 7.0.3+260618 und 7.0.4+260620 mittels git log --oneline 7.0.3+260618..7.0.4+260620 und git diff --stat 7.0.3+260618..7.0.4+260620; beide Tags sind im Repository vorhanden. Nicht ausgewertet wurde der Commit „Dev Automatic translation update" und die davon betroffene Datei locale/_template/limesurvey.pot, weshalb keine Aussage darüber möglich ist, ob einzelne Oberflächentexte über die hier beschriebenen hinaus ihre Bedeutung geändert haben. Ebenfalls nicht ausgewertet wurden die minifizierten Stylesheets themes/admin/Sea_Green/css/sea_green.min.css und themes/admin/Sea_Green/css/sea_green-rtl.min.css, da sie aus den ebenfalls im Diff enthaltenen Quelldateien erzeugt werden. Die Laufzeitwirkung der neuen Integritätsprüfungen wurde nicht in einer Installation nachvollzogen, sondern ausschließlich aus dem Quellcode abgeleitet. Indirekte Effekte über transitive Drittabhängigkeiten sind durch reine Diff-Analyse nicht vollständig erfassbar. Einträge der Kurzliste mussten nicht ausgelassen werden.

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.

LimeSurvey 7.0.2 → 7.0.3

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

Kopfdaten und Grenzen

Release: 7.0.2 → 7.0.3
Commits: 7
Geänderte Dateien: 21
Analyse: 11.08.2026
Schwerpunkt: Sicherheitsfix und Datumskorrektur

Nicht untersucht

Verglichen wurden die Tags 7.0.2+260617 (Commit vom 2026-06-16) und 7.0.3+260618 (Commit vom 2026-06-17) mit git log --oneline 7.0.2+260617..7.0.3+260618 und git diff --stat 7.0.2+260617..7.0.3+260618; beide Tags waren im Repository vorhanden. Nicht inhaltlich ausgewertet wurden die vier binären Katalogdateien locale/de/de.mo, locale/de-informal/de-informal.mo, locale/it/it.mo und locale/it-informal/it-informal.mo sowie die Änderungen an locale/_template/limesurvey.pot; die beiden Übersetzungs-Commits sind damit nur als vorhanden vermerkt, und ob dabei Texte entfallen sind, bleibt offen. Ebenfalls nicht herangezogen wurden Laufzeitumgebung, Testsuite und die externen Vorgangsnummern AT-2090, AT-2084 und #20565, weshalb Aussagen über Ausnutzbarkeit in einer konkreten Installation und über den Umfang der zugehörigen Vorgänge offenbleiben. Indirekte Effekte über transitive Drittabhängigkeiten sind durch reine Diff-Analyse nicht vollständig erfassbar. Die Kurzliste lässt keine Einträge aus.

LimeSurvey 7.0.1 → 7.0.2

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

Kopfdaten und Grenzen

Release: 7.0.1 → 7.0.2
Commits: 27
Geänderte Dateien: 687
Analyse: 11.08.2026
Schwerpunkt: Barrierefreiheit und Stabilisierung

Nicht untersucht

Verglichen wurden die Tags 7.0.1+260611 mit Commit-Datum 10. Juni 2026 und 7.0.2+260617 mit Commit-Datum 16. Juni 2026 mit den Befehlen git log --oneline 7.0.1+260611..7.0.2+260617 und git diff --stat 7.0.1+260611..7.0.2+260617; beide Tags sind im Repository vorhanden. Nicht ausgewertet wurden die minifizierten Ableitungen der geänderten Quelldateien, die Sprachdateien unter locale, der kompilierte React-Build unter editor/build sowie der Bundle-Inhalt der aktualisierten Pakete unter node_modules jenseits ihrer Versionsangaben; damit bleibt offen, ob diese Bundles Verhaltensänderungen enthalten, die über die hier beschriebenen hinausgehen. Indirekte Effekte über transitive Drittabhängigkeiten sind durch eine reine Diff-Analyse nicht vollständig erfassbar. Aus dem Kapitel „Weitere relevante Änderungen" wurden keine Einträge ausgelassen.

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.

Wann ist eine Software „stable"?

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

„Stable" klingt nach einer geprüften Eigenschaft. Tatsächlich ist es meist nur eine Selbstauskunft der Maintainer – keine Aussage über Qualität, sondern eine Behauptung über den eigenen Code.

Das wird besonders deutlich an einer unauffälligen Composer-Einstellung, die in fast jeder composer.json steht:

{
 "minimum-stability": "stable"
}

Composer unterscheidet Versionen nach einem reinen Namensschema:

1.0.0-alpha
1.0.0-beta
1.0.0-RC1
1.0.0

„Stable" bedeutet hier: kein Alpha, kein Beta, kein Release Candidate. Jede Version ohne einen solchen Suffix gilt als stabil – v1.0.0, v1.2.3, v2.0.0, alle gleichermaßen. Composer trifft damit keine Aussage über Qualität. Es trifft eine Aussage über eine Zeichenkette im Versionsnamen.

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.

LimeSurvey 7.0.0 → 7.0.1

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

Kopfdaten und Grenzen

Release: 7.0.0 → 7.0.1
Commits: 140
Geänderte Dateien: 886
Analyse: 11.08.2026
Schwerpunkt: Sicherheit und Barrierefreiheit

Nicht untersucht

Verglichen wurden die im lokalen Repository verifizierten Tags 7.0.0+260526 (26.05.2026) und 7.0.1+260611 (10.06.2026) mit git log --oneline 7.0.0+260526..7.0.1+260611 und git diff --stat 7.0.0+260526..7.0.1+260611. Nicht ausgewertet wurden der Inhalt des mitgelieferten vendor/-Baums, die kompilierten Bundles unter assets/packages/*/build und editor/build, die minifizierten Stylesheets der Adminthemes sowie die Übersetzungskataloge. Dadurch bleibt offen, ob der Austausch der Vorlagen-Bibliothek und der Umbau der Seitenleisten über die zitierten Quelldateien hinaus weitere Verhaltensänderungen mitbringen. Indirekte Effekte über transitive Drittabhängigkeiten lassen sich durch reine Diff-Analyse nicht vollständig erfassen. Aus dem Kapitel „Weitere relevante Änderungen" wurden fünf Einträge geringerer Relevanz weggelassen, darunter die zusätzlichen Besitzprüfungen des Aktualisierungswerkzeugs, die Textüberarbeitung der Sicherheitseinstellungen, die Auswahl mehrerer Antworten über Seitengrenzen im neuen Editor sowie zwei Anpassungen an der Testpipeline.

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.

Der ehrlichste Satz in der Softwareentwicklung

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

Bei Legacy-Code schätzt du nicht wie lange etwas dauert. Du schätzt, wie lange es dauert, bis du weißt, wie lange es dauert.

Das klingt nach einer Ausrede. Es ist keine.

Warum Schätzungen immer falsch sind

Golo Roden hat es in seiner „Won’t fix!"-Serie auf heise online gut formuliert: Softwareentwicklung ist kein Produktionsprozess. Eine Fabrik die bereits weiß wie man ein Auto baut, kann den Aufwand präzise planen. Wer Software entwickelt, erzeugt erst das Wissen das für die Lösung nötig ist. Das lässt sich nicht im Voraus messen.

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.

„Mach mal schnell"

Mon, 25 May 2026 00:00:00 +0000

„Kannst du da mal schnell etwas ändern?" „Das ist doch nur eine Kleinigkeit." „Da muss man doch nur kurz …"

Wer länger in der Softwareentwicklung arbeitet, kennt diese Sätze. Gemeint sind sie selten böse. Trotzdem stecken darin zwei Probleme gleichzeitig: die Komplexität von Softwareänderungen wird nicht verstanden – und durch die Formulierung implizit entwertet.

Was wirklich passiert

Bevor eine einzige Zeile geändert wird, beginnt die eigentliche Arbeit. Frühere Entscheidungen verstehen. Abhängigkeiten erkennen. Risiken bewerten. Seiteneffekte vermeiden. Neue Entscheidungen treffen.

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.

Das weiße Blatt

Mon, 20 Apr 2026 00:00:00 +0000

Wer lange mit gewachsenen Systemen gearbeitet hat, entwickelt eine bestimmte Art zu denken. Man sieht nicht nur, was ein Werkzeug kann – man sieht, was es einem aufzwingt. Welche Entscheidungen es vorwegnimmt. Welche Wege es versperrt, bevor man überhaupt angefangen hat.

Das weiße Blatt ist selten. In der Praxis arbeitet man fast immer im Bestand – mit Legacy-Code, mit bestehenden Abhängigkeiten, mit Entscheidungen, die jemand anderes vor Jahren getroffen hat. Das ist der Alltag, und diese Serie handelt davon.

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.

Was bleibt vom Entwickler

Wed, 15 Apr 2026 00:00:00 +0000

Was ich nicht mehr tue

Ich schreibe heute kaum noch Code. Nicht weil ich es nicht kann – sondern weil die KI schneller, konsistenter und ohne die kleinen Flüchtigkeitsfehler arbeitet, die sich in langen Arbeitstagen einschleichen.

Ich tippe keine Boilerplate mehr, keine Konstruktoren, Getter oder wiederholenden Strukturen.

Das klingt nach Verlust. Ist es aber nicht. Das Handwerk war nie der interessante Teil. Wertvoll war immer das Verstehen des Problems und das Urteil über die Lösung – alles, was der KI nicht abgenommen werden kann.

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?

Die Schnecke

Wed, 01 Apr 2026 00:00:00 +0000

Ich habe heute zufällig eine Grafik gesehen, die oft gezeigt wird, wenn jemand Scrum erklärt.
Ein großer Kreis mit einem kleineren Kreis darin, der sich hineinschraubt. Der Sprint dreht sich, der Daily Stand-Up dreht sich darin.
Darunter ein Fließband: Backlog, Planning, Sprint-Backlog, Sprint, Finished Work. Von links nach rechts.

Eine Schnecke.

Die Schnecke ist kein schlechtes Tier. Sie ist beständig, anpassungsfähig, kommt ans Ziel. Aber agil?
Nicht das erste Wort, das einem einfällt. Und doch trägt die bekannteste Visualisierung eines der einflussreichsten
agilen Frameworks ihr Bild.

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.

Archiv

Mon, 01 Jan 0001 00:00:00 +0000

Herausforderungen

Mon, 01 Jan 0001 00:00:00 +0000

Viele Probleme rund um Befragungen zeigen sich nicht als eine Frage, sondern als ein Gefühl: die Auswertung dauert zu lange, das Plugin ist gewachsen, aber niemand traut sich mehr, es anzufassen, oder die Ergebnisse liegen vor, aber die eigentliche Entscheidung ist trotzdem nicht klarer geworden.

Im Folgenden typische Herausforderungen, denen ich in Projekten immer wieder begegne. Vielleicht erkennen Sie eine davon wieder.

Die Befragung liefert Antworten, aber keine Entscheidungsgrundlage

Der Fragebogen ist fertig, die Daten kommen rein – aber am Ende steht trotzdem die Frage: Und was folgt jetzt daraus? Häufig wurde die Umfrage aus der Frage heraus entworfen, nicht aus der Entscheidung, die sie eigentlich stützen sollte.

Impressum

Mon, 01 Jan 0001 00:00:00 +0000

Anbieter

Marko Bischof
Nordfeldstr 21
30459 Hannover

Kontakt

E-Mail: marko.bischof@gmail.com
Website: https://markob.de

Verantwortlich für den Inhalt nach § 18 Abs. 2 MStV

Marko Bischof
Nordfeldstr 21
30459 Hannover

Haftung für Inhalte

Die Inhalte unserer Seiten wurden mit größter Sorgfalt erstellt. Für die
Richtigkeit, Vollständigkeit und Aktualität der Inhalte können wir jedoch keine
Gewähr übernehmen. Als Diensteanbieter sind wir gemäß § 7 Abs.1 TMG für eigene
Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach
§§ 8 bis 10 TMG sind wir als Diensteanbieter jedoch nicht verpflichtet,
übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach
Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen.

Lösungen

Mon, 01 Jan 0001 00:00:00 +0000

Jedes Unternehmen, jede Behörde und jede Forschungseinrichtung hat andere Anforderungen an Online-Befragungen. Manche möchten die Zufriedenheit ihrer Mitarbeitenden messen, andere benötigen automatisierte Reports oder individuelle Erweiterungen für LimeSurvey.

Im Folgenden finden Sie typische Anwendungsfälle. Vielleicht ist Ihrer bereits dabei – und falls nicht, entwickeln wir gemeinsam eine passende Lösung.

Automatische Ergebnisberichte

Aus den Antworten Ihrer Umfrage entstehen automatisch professionell gestaltete Berichte – abgestimmt auf die Entscheidung, die sie stützen sollen, nicht nur auf die Rohdaten.

Marko Bischof

Mon, 01 Jan 0001 00:00:00 +0000

Ich entwickle seit über 20 Jahren PHP-Systeme. Nicht weil ich nichts anderes kenne, sondern weil es ein Handwerk ist, das Tiefe verlangt — und weil gewachsene Anwendungen eine eigene Intelligenz haben, die man erst mit der Zeit versteht.

Seit knapp acht Jahren arbeite ich im LimeSurvey-Ökosystem: Plugin-Entwicklung, Datenbankmodell, Expression Manager, die Grenzen der Plattform und die Stellen, an denen Modernisierung realistisch ansetzt.

Wie ich arbeite

Ich glaube nicht an den großen Rewrite. Gewachsene Systeme tragen akkumuliertes Wissen in sich — in jeder seltsamen Konstruktion steckt eine Geschichte, ein Grenzfall oder eine Entscheidung unter echten Produktionsbedingungen. Dieses Wissen wegzuwerfen ist teuer.

markob.de

LimeSurvey 7.0.11 → 7.0.12

Kopfdaten und Grenzen

Nicht untersucht

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

Kurs Evaluationen

Das eigentliche Problem liegt vor der Umfrage

Das Framework ist nur ein Detail

LimeSurvey 7.0.10 → 7.0.11

Kopfdaten und Grenzen

Nicht untersucht

Zweimal `square()` - Teil 3

Zweimal `square()` - Teil 2

Zweimal `square()` - Teil 1

Naming ist wichtig

Der Fall

LimeSurvey 7.0.9 → 7.0.10

Kopfdaten und Grenzen

Nicht untersucht

LimeSurvey 7.0.8 → 7.0.9

Kopfdaten und Grenzen

Nicht untersucht

LimeSurvey 7.0.7 → 7.0.8

Kopfdaten und Grenzen

Nicht untersucht

Von KleinSite nach Hugo

Der eigentliche Auslöser war keine technische Grenze

Die sechs Etappen erfolgreicher KI-Softwareentwicklung

LimeSurvey 7.0.6 → 7.0.7

Kopfdaten und Grenzen

Nicht untersucht

LimeSurvey 7.0.5 → 7.0.6

Kopfdaten und Grenzen

Nicht untersucht

Joomla 1.0: Überraschend moderne Ideen unter 20 Jahren PHP

Report-driven Survey Design

Das Problem mit der klassischen Reihenfolge

LimeSurvey 7.0.4 → 7.0.5

Kopfdaten und Grenzen

Nicht untersucht

Warum Vergütung auf Platz 7 landet

Das Problem mit dem rohen Gap

Wo eine Verbesserung die meisten Menschen erreicht

Was PRI nicht sieht

LimeSurvey 7.0.3 → 7.0.4

Kopfdaten und Grenzen

Nicht untersucht

Der NPS ist keine Zahl

Likert-Skalen richtig einsetzen und auswerten

Das Schulnotenproblem

LimeSurvey 7.0.2 → 7.0.3

Kopfdaten und Grenzen

Nicht untersucht

LimeSurvey 7.0.1 → 7.0.2

Kopfdaten und Grenzen

Nicht untersucht

Treiberanalyse: Welche Frage wirklich zählt

Das Problem mit reiner Bewertung

Faker: Reproduzierbare Testdaten für LimeSurvey

Wann ist eine Software „stable"?

Survey as Code: Umfragen versionieren, reviewen und wiederverwenden

Das Problem mit dem Klicken

LimeSurvey 7.0.0 → 7.0.1

Kopfdaten und Grenzen

Nicht untersucht

Visualisierung allein reicht nicht mehr

Das Visualisierungsproblem

Der ehrlichste Satz in der Softwareentwicklung

Warum Schätzungen immer falsch sind

Vom Fragebogen zum fertigen Report

Die Umfrage

Professionelle Reports für LimeSurvey

„Mach mal schnell"

Was wirklich passiert

LimeSurvey Fragetypen – Einordnung aus der Praxis

Die unverzichtbaren Typen

Liste (Radio) · L

LimeSurvey Fragetypen – die vollständige Referenz

Aufbau der Tabelle

Asymmetrische Modernisierung

Liste (Radio) · `L`

Was `config.platform.php` sagt

Wie `newDirectRequest` funktioniert