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.
Executive Summary
Dieses Release enthält keine im Diff erkennbaren Sicherheitsbehebungen und keine Datenbankmigration, dafür drei Änderungen, die ohne Fehlermeldung wirksam werden: die Sortierung der Unterfragen in der RemoteControl-Schnittstelle, den Wegfall der 64-Bit-Prüfung beim Start und einen neuen Suffix in der Feldabbildung. Am ehesten unbemerkt bleibt die erste davon, weil sie weder einen Fehler auslöst noch die Menge der gelieferten Daten verändert, sondern allein deren Reihenfolge. Den größten zusammenhängenden Block der 23 Commits bildet mit sieben Einträgen ein externes Barrierefreiheits-Audit, das ARIA-Attribute, Überschriftenstruktur und Fokusverhalten im Administrationsbereich überarbeitet. Dessen Änderungen am ausgelieferten Markup wirken über die Barrierefreiheit hinaus: Sie treffen jede Anpassung, die auf der bisherigen DOM-Struktur aufsetzt.
- Unterfragen in der RemoteControl-Schnittstelle werden sortiert
- Standard-Unterfragen bei neuen Fragen unabhängig vom Editor
- Feldabbildung erhält Suffixe für Sonstiges und Kommentar
- Composer-Umgebung neu erzeugt und 64-Bit-Prüfung entfallen
- Rückgabetyp der Benutzeranlage und Härtung des Benutzerimports
- Tastatur- und Klickverhalten in Administrations-Gridviews
- ARIA- und Überschriftenstruktur in ausgelieferten Views
- Fokus- und Hoverzustände im Sea Green Theme neu kompiliert
Upgrade-Empfehlung
🧪 Vorher testen. Das Release enthält keine im Diff erkennbaren Sicherheitsbehebungen, aber mehrere Änderungen, die Datenreihenfolge, Exportspalten und ausgeliefertes Markup betreffen und ohne Fehlermeldung wirksam werden. Wer eigene Integrationen, Themes oder Plugins betreibt, sollte zuerst in einer Kopie der Produktivumgebung prüfen.
Lesepfad
| Zielgruppe | Relevante Kennungen und Kapitel |
|---|---|
| Administratoren | A2, A4, A5, A6, A8, Weitere relevante Änderungen, Empfehlung |
| Plugin-Entwickler | A3, A5, A6, A7, Weitere relevante Änderungen, Empfehlung |
| Theme-Entwickler | A6, A7, A8, Weitere relevante Änderungen, Empfehlung |
| Integratoren | A1, A2, A3, A5, Weitere relevante Änderungen, Empfehlung |
| API-Nutzer | A1, A3, Empfehlung |
Die wichtigsten Änderungen
A1: Unterfragen in der RemoteControl-Schnittstelle werden sortiert
Hintergrund: In der Behandlungsroutine der RemoteControl-Schnittstelle liest die Abfrage der Fragen-Eigenschaften die Unterfragen einer Frage über das aktive Datensatzmodell. Bisher wurde die Sortierangabe als dritter Parameter an findAll übergeben, also außerhalb der beiden Argumente, die diese Methode entgegennimmt. Mit der Änderung wandert die gesamte Abfragebeschreibung in ein Kriterien-Array, das Bedingung, Parameter und Sortierung gemeinsam trägt, und die Sortierspalte wird zusätzlich mit dem Tabellen-Alias qualifiziert.
Konsequenz: Die Eigenschaften available_answers und subquestions liefern ihre Einträge nach der Änderung in einer nach dem Fragentitel sortierten Reihenfolge zurück. Ob die vorherige Fassung überhaupt eine Sortierung angewandt hat, ist aus dem Diff nicht bestimmbar; belegt ist nur, dass die Sortierangabe nun an der Stelle steht, an der die Abfrage sie auswertet. Für aufrufende Systeme bedeutet das: Wer sich bisher auf die zurückgelieferte Reihenfolge verlassen hat — etwa beim Zuordnen von Unterfragen zu Spaltenpositionen in einem nachgelagerten System —, erhält möglicherweise eine andere Anordnung, ohne dass ein Fehler gemeldet wird. Die Änderung greift nicht für Aufrufe, die andere Eigenschaften als die beiden genannten abfragen, und nicht für Codepfade außerhalb der RemoteControl-Schnittstelle.
Vorher / Nachher:
// Vorher (application/helpers/remotecontrol/remotecontrol_handle.php)
$oSubQuestions = Question::model()->with('questionl10ns')
->findAll(
't.parent_qid = :parent_qid and questionl10ns.language = :language',
array(':parent_qid' => $iQuestionID, ':language' => $sLanguage),
array('order' => 'title')
);
// Nachher
$oSubQuestions = Question::model()->with('questionl10ns')
->findAll(array(
'condition' => 't.parent_qid = :parent_qid and questionl10ns.language = :language',
'params' => array(':parent_qid' => $iQuestionID, ':language' => $sLanguage),
'order' => 't.title',
));
Nach dem Update testen: Rufe get_question_properties für eine Frage mit mehreren Unterfragen einmal gegen die alte und einmal gegen die neue Installation auf und vergleiche die Reihenfolge der Einträge in subquestions und available_answers. Prüfe anschließend im nachgelagerten System, ob dessen Zuordnung über Schlüssel oder über Position erfolgt.
Betroffene Dateien: application/helpers/remotecontrol/remotecontrol_handle.php
Relevante Commits: f8c12d3892
A2: Standard-Unterfragen bei neuen Fragen unabhängig vom Editor
Hintergrund: Beim Anlegen einer neuen Frage erzeugt der Umfragen-Controller zwei Beispiel-Unterfragen. Diese Erzeugung war an eine Konfigurationsabfrage gebunden: War der Schlüssel editorEnabled gesetzt, unterblieb sie. Die Änderung entfernt Abfrage und Bedingung, sodass die beiden Aufrufe von createSampleSubquestion in jedem Fall ausgeführt werden.
Konsequenz: Neu angelegte Fragen erhalten künftig auch dann zwei vorbelegte Unterfragen, wenn die Oberfläche des neuen Editors verwendet wird. Für Redakteure ist das der beabsichtigte Effekt — sie starten nicht mehr mit einer leeren Antwortliste. Für automatisierte Abläufe, die Fragen anlegen und anschließend Unterfragen aus einer eigenen Quelle einspielen, bedeutet es, dass zwei zusätzliche Datensätze vorhanden sind, die zuvor nicht entstanden. Sie werden nicht überschrieben, sondern kommen hinzu, und sie erscheinen ohne Fehlermeldung in Vorschau, Export und Datenmodell. Betroffen ist der Pfad über den Umfragen-Controller; ob andere Anlagepfade dieselben Beispieldaten erzeugen, ist aus dem Diff nicht bestimmbar.
Vorher / Nachher:
// Vorher (application/controllers/SurveyAdministrationController.php)
$editorEnabled = Yii::app()->getConfig('editorEnabled') ?? false;
if (!$editorEnabled) {
$this->createSampleSubquestion(
1,
$iSurveyID,
$iGroupID,
$oQuestion->qid,
$sLanguage,
gT('Option A')
);
...
}
// Nachher
$this->createSampleSubquestion(
1,
$iSurveyID,
$iGroupID,
$oQuestion->qid,
$sLanguage,
gT('Option A')
);
...
Nach dem Update testen: Lege im neuen Editor eine Frage eines Typs mit Unterfragen an und prüfe, ob die Unterfragenliste mit zwei vorbelegten Einträgen erscheint. Lasse anschließend eine bestehende Automatisierung eine Frage anlegen und zähle die danach vorhandenen Unterfragen.
Betroffene Dateien: application/controllers/SurveyAdministrationController.php
Relevante Commits: f8c12d3892
Sammel-Commit f8c12d3892; umfasst die 2 vorstehenden Einträge.
A3: Feldabbildung erhält Suffixe für Sonstiges und Kommentar
Hintergrund: Die Funktion createFieldMap baut die Abbildung zwischen Fragen und Spalten der Antworttabelle auf. Für die Zusatzfelder „Sonstiges“ und „Kommentar“ enthielt der erzeugte Eintrag bisher die Schlüssel für Umfrage, Gruppe, Frage und Antwort-Kennung, aber keinen Suffix-Schlüssel. Die Änderung ergänzt genau diesen Schlüssel mit den Werten _Cother beziehungsweise _Ccomment; laut Commit-Betreff betrifft das die Fragetypen L, ! und O.
Konsequenz: Code, der die Feldabbildung ausliest und den Suffix eines Feldes auswertet, findet dort nun einen Wert, wo zuvor kein Schlüssel vorhanden war. Das betrifft in erster Linie Exporte und eigene Auswertungen, die Spaltenbezeichner aus der Feldabbildung zusammensetzen, sowie Plugins, die auf dieser Struktur aufsetzen. Wer die fehlende Angabe bisher durch eigene Logik ersetzt hat — etwa durch ein hart kodiertes Anhängen der Endung —, erzeugt nach dem Update möglicherweise doppelte Endungen. Ob und wie sich die Spaltenüberschriften der ausgelieferten Exportformate dadurch verändern, ist aus diesem Diff allein nicht bestimmbar, weil die auswertenden Stellen nicht mitgeändert wurden. Für Fragetypen ohne Zusatzfelder „Sonstiges“ oder „Kommentar“ greift die Änderung nicht.
Vorher / Nachher:
// Vorher (application/helpers/common_helper.php)
"aid" => "other");
...
"aid" => "comment");
// Nachher
"aid" => "other",
"suffix" => "_Cother");
...
"aid" => "comment",
"suffix" => "_Ccomment");
Nach dem Update testen: Exportiere die Antworten einer Umfrage mit einer Liste mit „Sonstiges“ und einer Frage mit Kommentarfeld vor und nach dem Update und vergleiche die Spaltenüberschriften zeichengenau. Prüfe zusätzlich eigene Plugins, die den Suffix-Schlüssel der Feldabbildung lesen, auf doppelte Endungen.
Betroffene Dateien: application/helpers/common_helper.php
Relevante Commits: 60e0f63795
A4: Composer-Umgebung neu erzeugt und 64-Bit-Prüfung entfallen
Hintergrund: Der Abhängigkeitsstand wurde aktualisiert und die von Composer erzeugten Dateien im Verzeichnis vendor/composer neu geschrieben. Dabei hat die Datei, die beim Start jeder Anfrage die Plattformvoraussetzungen prüft, die bisherige Prüfung auf eine 64-Bit-Installation von PHP verloren, während die Prüfung auf die PHP-Mindestversion unverändert bestehen bleibt. Der Grund dafür steht in der Sperrdatei selbst: Sie hält fest, welche Plugin-API-Version die schreibende Composer-Instanz gemeldet hat, und dieser Wert ist von 2.6.0 auf 2.3.0 zurückgegangen. Die Release-Artefakte wurden also von einer älteren Composer-Fassung erzeugt als die des Vorgängerreleases. Der Changelog von Composer — eine Quelle außerhalb dieses Diffs — führt die Laufzeitprüfung der Anforderung php-64bit unter der Fassung 2.6.0 vom 1. September 2023 als Neuerung auf, mit dem Eintrag „Added runtime platform check to verify the php-64bit requirement is met (#11334)“; eine ältere Instanz erzeugt sie folglich nicht. Im selben Zug haben zwei produktiv genutzte Bibliotheken eine neue Fassung erhalten.
Konsequenz: Auf einer 32-Bit-Installation von PHP brach LimeSurvey bisher beim Start mit einer eindeutigen Meldung ab. Nach dem Update entfällt dieser Abbruch, und die Anwendung startet — obwohl mindestens eine eingebundene Bibliothek eine 64-Bit-Umgebung weiterhin als Anforderung deklariert. Für die überwiegende Mehrheit der Installationen, die ohnehin 64-bittig laufen, ändert sich dadurch nichts. Wer auf einer 32-Bit-Umgebung betreibt, verliert eine harte Startbedingung und bemerkt Folgefehler erst dort, wo große Ganzzahlen verarbeitet werden; ob es solche Stellen im Produktivbetrieb gibt und wie sie sich äußern, ist aus dem Diff nicht bestimmbar. Ebenfalls geändert hat sich die Art, wie die Autoloader-Datei einen zu alten PHP-Interpreter meldet: statt einer Ausnahme wird ein Fehler vom Typ E_USER_ERROR ausgelöst, was bei unterdrückter Fehleranzeige zu einer leeren Seite statt zu einer Ausnahme führen kann — ein Verhalten, das zur älteren erzeugenden Fassung passt. Über die einzelne Prüfung hinaus bedeutet der Befund, dass die ausgelieferten Composer-Artefakte dieses Release nicht mit derselben Werkzeugfassung entstanden sind wie die des Vorgängers; welche weiteren Unterschiede daraus folgen, ist aus dem Diff nicht bestimmbar.
Vorher / Nachher:
// Vorher (vendor/composer/platform_check.php)
if (!(PHP_VERSION_ID >= 80100)) {
$issues[] = 'Your Composer dependencies require a PHP version ">= 8.1.0". You are running ' . PHP_VERSION . '.';
}
if (PHP_INT_SIZE !== 8) {
$issues[] = 'Your Composer dependencies require a 64-bit build of PHP.';
}
// Nachher
if (!(PHP_VERSION_ID >= 80100)) {
$issues[] = 'Your Composer dependencies require a PHP version ">= 8.1.0". You are running ' . PHP_VERSION . '.';
}
Die Ursache lässt sich an einer einzigen Zeile der Sperrdatei ablesen.
composer.lock, vorher:
"plugin-api-version": "2.6.0"
composer.lock, nachher:
"plugin-api-version": "2.3.0"
Im selben Commit wurden zwei produktiv eingebundene Pakete angehoben.
composer.lock, vorher:
"name": "paragonie/sodium_compat",
"version": "v1.24.0",
...
"name": "shardj/zf1-future",
"version": "1.25.0",
composer.lock, nachher:
"name": "paragonie/sodium_compat",
"version": "v1.24.2",
...
"name": "shardj/zf1-future",
"version": "1.25.1",
Neuer Bezugswert: Die Anforderung an eine 64-Bit-Umgebung wird beim Start nicht mehr geprüft. Sie ist weiterhin in der Sperrdatei dokumentiert und dort abzulesen; das folgende Zitat stammt aus dem Stand des Zielreleases und nicht aus dem Diff.
composer.lock, Stand 7.0.11+260821:
"require": {
"ext-mbstring": "*",
"ext-zlib": "*",
"php-64bit": "^8.1"
Nach dem Update testen: Prüfe auf dem Zielsystem die Wortbreite des Interpreters, etwa über den Wert von PHP_INT_SIZE in der PHP-Info-Ausgabe, und stelle sicher, dass er 8 beträgt. Rufe anschließend die Startseite der Administration auf und kontrolliere das Fehlerprotokoll des Webservers auf neu auftretende Meldungen vom Typ E_USER_ERROR. Vergleiche zusätzlich den Wert von plugin-api-version in der Sperrdatei mit dem des vorherigen Releases, um einen Wechsel der Bauumgebung zu erkennen.
Betroffene Dateien: vendor/composer/platform_check.php, vendor/autoload.php, composer.lock
Relevante Commits: 5458c1a200
A5: Rückgabetyp der Benutzeranlage und Härtung des Benutzerimports
Hintergrund: Die öffentliche Methode createNewUser des Benutzerverwaltungs-Controllers gab bisher zwingend ein Array zurück. Sie kann nun null liefern, wenn sie eine Fehlerantwort selbst ausgibt; der deklarierte Rückgabetyp wurde entsprechend auf einen optionalen Typ erweitert. Der aufrufende Code wurde an zwei Stellen angepasst: Beim Import wird das Ergebnis nun auf ein Array mit gesetztem Schlüssel uid geprüft, und in der Speicherroutine führt ein null-Ergebnis zu einer strukturierten Fehlermeldung statt zu einem Weiterlauf. Zusätzlich normalisiert der Import den Benutzernamen vor der Suche und überspringt Datensätze ohne verwertbaren Namen.
Konsequenz: Eigener Code, der createNewUser aufruft und das Ergebnis ohne Prüfung als Array weiterverarbeitet, kann nach dem Update auf null treffen und mit einem Typfehler abbrechen. Das betrifft Plugins und Erweiterungen, die die Benutzeranlage nachnutzen; wer den Controller ausschließlich über die Oberfläche bedient, merkt davon nichts. Beim Import einer Benutzerliste werden Zeilen ohne Benutzernamen nicht mehr stillschweigend an das Modell weitergereicht, sondern übersprungen und am Ende in einer Warnung gemeldet — importierte Listen können daher weniger Datensätze erzeugen als bisher, dafür mit sichtbarem Hinweis. Der Fehlercontainer wurde aus der Importansicht entfernt, während das gemeinsam genutzte Skript der Benutzerverwaltung ihn weiterhin adressiert und ihm den Fokus gibt; welche Fehleranzeige die Importmaske dadurch verwendet, ist aus dem Diff nicht bestimmbar.
Vorher / Nachher:
// Vorher (application/controllers/UserManagementController.php)
public function createNewUser(array $aUser): array
// Nachher
public function createNewUser(array $aUser): ?array
// Neu (application/controllers/UserManagementController.php)
$aNewUser['users_name'] = flattenText($aNewUser['users_name'] ?? '');
if (empty($aNewUser['users_name'])) {
$hasInvalidUsername = true;
continue;
}
Nach dem Update testen: Importiere eine Benutzerliste, die absichtlich eine Zeile ohne Benutzernamen enthält, und prüfe, ob die übrigen Zeilen angelegt werden und die Warnung erscheint. Lege anschließend über die Oberfläche einen Benutzer mit bereits vergebener E-Mail-Adresse an und kontrolliere, dass eine Fehlermeldung im Dialog erscheint statt einer leeren Antwort.
Betroffene Dateien: application/controllers/UserManagementController.php, application/views/userManagement/partial/importuser.php, application/views/userManagement/partial/addedituser.php, assets/packages/usermanagement/js/usermanagement.js
Relevante Commits: dc3d1e64c1
A6: Tastatur- und Klickverhalten in Administrations-Gridviews
Hintergrund: Das Skript für Zeilenverweise macht Tabellenzeilen der Administrationslisten anklickbar. Bisher erhielt jede Zeile mit dem Attribut data-rowlink zusätzlich ein tabindex von null sowie einen Tastaturhandler, der bei Eingabe- oder Leertaste zur hinterlegten Adresse navigierte. Beides ist entfallen; im neuen Code steht an dieser Stelle ein Kommentar, der die Abwesenheit des Attributs festhält. Gleichzeitig kam eine Behandlung deaktivierter Verweise hinzu, die diesen das href-Attribut entfernt und sie über aria-disabled und ein negatives tabindex aus der Tabulatorreihenfolge nimmt. Die Erkennung interaktiver Kindelemente wurde von einer Prüfung des Klickziels auf eine Suche über dessen Vorfahren umgestellt.
Konsequenz: Wer die Administrationslisten bisher per Tastatur bedient hat, indem er eine Zeile fokussierte und die Eingabetaste drückte, kann das nicht mehr; die Navigation muss über die Verweise innerhalb der Zeile erfolgen. Ein Fehler wird dabei nicht angezeigt — die Zeile nimmt schlicht keinen Fokus mehr an. Für eigene Skripte, Oberflächentests und Theme-Anpassungen ist die zweite Hälfte wichtiger: Deaktivierte Verweise in Gridviews besitzen zur Laufzeit kein href mehr, sodass Selektoren und Prüfungen, die auf dessen Vorhandensein oder Inhalt aufbauen, ins Leere greifen. Die Umstellung auf die Vorfahrensuche bedeutet außerdem, dass Klicks auf ein Symbol innerhalb eines Verweises nicht mehr die Zeilennavigation auslösen. Die Änderung wirkt nur in Tabellen mit der Klasse grid-view-ls.
Vorher / Nachher:
// Vorher (application/extensions/admin/grid/assets/rowLink.js)
let link = tr.getAttribute('data-rowlink');
tr.setAttribute('tabindex', '0');
...
tr.addEventListener('keydown', function (e) {
...
if (e.key === 'Enter' || e.key === ' ') {
e.preventDefault();
window.location.href = link;
}
});
// Nachher
const link = tr.getAttribute('data-rowlink');
// No tabindex on <tr>
// Neu (application/extensions/admin/grid/assets/rowLink.js)
document.querySelectorAll('.grid-view-ls a.disabled').forEach(link => {
link.setAttribute('aria-disabled', 'true');
link.setAttribute('tabindex', '-1');
link.removeAttribute('href');
...
});
Nach dem Update testen: Öffne eine Umfragenliste, wandere mit der Tabulatortaste durch die Tabelle und prüfe, ob jede Aktion einer Zeile über einen fokussierbaren Verweis erreichbar bleibt. Lasse anschließend vorhandene Oberflächentests laufen, die auf Verweise mit der Klasse disabled zugreifen, und passe Selektoren an, die das href-Attribut voraussetzen.
Betroffene Dateien: application/extensions/admin/grid/assets/rowLink.js, application/libraries/MenuObjects/views/_extraMenu.php, tests/functional/acceptance/19201-user-status/UserStatusTest.php
Relevante Commits: 2da6f52e2b
A7: ARIA- und Überschriftenstruktur in ausgelieferten Views
Hintergrund: Ein externes Barrierefreiheits-Audit hat über mehrere Commits hinweg das ausgelieferte Markup des Administrationsbereichs überarbeitet. Betroffen sind das Hilfe- und das Konfigurationsmenü, die Ansichten der Benutzergruppen, die Theme-Auswahl, die Vorschau im Theme-Editor und die Leiste der Massenaktionen. Container mit der Klasse h4 wurden zu echten h2-Elementen, dekorative Symbole erhielten aria-hidden, externe Verweise ein rel-Attribut und einen nur für Vorlesesysteme sichtbaren Hinweistext, und mehrere Gridviews bekamen über die Widget-Option caption eine Tabellenbeschriftung. Zusätzlich überschreibt die Gridview-Klasse nun die Methode renderEmptyText und gibt die Leermeldung als fokussierbaren Statusbereich aus, den ein neues Skript nach jeder Aktualisierung anspringt.
Konsequenz: Eigene Themes und Erweiterungen, deren Stilregeln oder Skripte an der bisherigen Struktur hängen, greifen an den betroffenen Stellen ins Leere. Konkret betrifft das Regeln, die auf div.h4 zielen, Selektoren auf die bisherigen Symbol-Elemente ohne aria-hidden und Code, der die Leermeldung eines Gridviews anhand ihres bisherigen Aufbaus findet — sie trägt nun zusätzlich die Klasse grid-empty-message, eine aus der Grid-Kennung abgeleitete Kennung und ein negatives tabindex. Wer die Gridview-Klasse ableitet und renderEmptyText selbst überschrieben hat, überschreibt jetzt eine tatsächlich vorhandene Implementierung statt der geerbten. Ein sichtbarer Fehler entsteht in keinem der Fälle; die Abweichung zeigt sich als verschobene Darstellung oder als nicht mehr gefundenes Element. Für Installationen ohne eigene Anpassungen am Administrations-Markup ist die Änderung folgenlos.
Vorher / Nachher:
// Vorher (application/views/admin/super/_help_menu.php)
<a href="http://manual.limesurvey.org/" target="_blank" class="dropdown-item">
<!-- <i class="ri-question-fill"></i> -->
<?php eT('LimeSurvey Manual');?>
<i class=" ri-external-link-fill float-end"></i>
</a>
// Nachher
<a href="http://manual.limesurvey.org/" target="_blank" rel="noopener noreferrer" class="dropdown-item">
<!-- <i class="ri-question-fill"></i> -->
<?php eT('LimeSurvey Manual');?>
<span class="visually-hidden">(<?php eT('Link opens in a new tab'); ?>)</span>
<i aria-hidden="true" class="ri-external-link-fill float-end"></i>
</a>
// Neu (application/extensions/admin/grid/CLSGridView.php)
public function renderEmptyText()
{
...
echo CHtml::tag(
$this->emptyTagName,
[
'class' => trim($this->emptyCssClass . ' grid-empty-message'),
'id' => $this->getId() . '-empty-message',
'role' => 'status',
'aria-live' => 'polite',
...
Nach dem Update testen: Öffne die Benutzergruppen-, Theme- und Fragetheme-Listen und prüfe, ob eigene Stilregeln für Überschriften und Tabellenköpfe weiterhin greifen. Filtere anschließend eine Liste auf ein leeres Ergebnis und kontrolliere, ob die Leermeldung erscheint und die Seite dabei nicht ungewollt springt.
Betroffene Dateien: application/views/admin/super/_help_menu.php, application/views/admin/super/_configuration_menu.php, application/extensions/admin/grid/CLSGridView.php, application/views/userGroup/usergroups_view.php, application/extensions/admin/grid/FloatingActionsWidget/views/floating_bar.php
Relevante Commits: 909c8b23aa, 7979b3357f, 80f40c0f25
A8: Fokus- und Hoverzustände im Sea Green Theme neu kompiliert
Hintergrund: Die Quellen des Administrations-Themes wurden an mehreren Stellen überarbeitet: Der Schließen-Knopf von Hinweisleisten erhält eine an den Hintergrund angepasste Farbe, eine feste Schriftgröße und eine vertikale Zentrierung, und sein Fokusrahmen wird über focus-visible statt über focus gesetzt. Die Marke in der Navigationsleiste bekommt einen eigenen Rahmen für Hover und Fokus sowie geänderte Innenabstände. Aus diesen Quelldateien wurden die ausgelieferten Stylesheets neu erzeugt, wodurch sich die kompilierten Dateien in beiden Laufrichtungen auf mehreren hundert Zeilen unterscheiden.
Konsequenz: Wer das Administrations-Theme nur verwendet, sieht deutlichere Fokusrahmen und einen anders positionierten Schließen-Knopf. Wer eigene Stilregeln darüberlegt, muss zwei Dinge beachten: Die bisherige Regel für den Fokuszustand des Schließen-Knopfs greift nicht mehr, weil der Zustand jetzt an focus-visible hängt und ein reiner Mausfokus ausdrücklich ohne Rahmen bleibt; und die Marke in der Navigationsleiste hat andere Abstände, was auf schmalen Ansichten zu einem veränderten Umbruch führen kann. Da die kompilierten Stylesheets vollständig neu erzeugt wurden, gehen lokale Änderungen an diesen Dateien beim Update verloren. Wer das Theme aus den Quellen baut, muss den Bauschritt wiederholen — die dafür nötigen Befehle haben sich in diesem Release ebenfalls geändert, siehe Weitere relevante Änderungen.
Vorher / Nachher:
/* Vorher (assets/admin_themes/Sea_Green/alert/alert.scss) */
.alert-dismissible {
.btn-close {
padding: 1rem 1rem;
&:focus {
box-shadow: none;
color: $black;
opacity: 0.75;
}
}
}
/* Nachher */
.alert-dismissible {
.btn-close {
font-size: 9px;
opacity: 1;
top: 50%;
transform: translateY(-50%);
&:focus-visible {
outline: 2px solid $g-900;
outline-offset: -12px;
box-shadow: none;
}
...
Nach dem Update testen: Löse eine Hinweisleiste aus, fokussiere den Schließen-Knopf einmal per Tastatur und einmal per Maus und prüfe, dass nur die Tastaturbedienung einen Rahmen zeigt. Kontrolliere anschließend die Navigationsleiste bei schmaler Fensterbreite auf Umbrüche und vergleiche eigene Anpassungen mit den neu erzeugten Stylesheets.
Betroffene Dateien: assets/admin_themes/Sea_Green/alert/alert.scss, assets/admin_themes/Sea_Green/navbar/navbar.scss, themes/admin/Sea_Green/css/sea_green.css, themes/admin/Sea_Green/css/sea_green-rtl.css
Relevante Commits: 3e6d2f2980
Weitere relevante Änderungen
Gulp-Aufgaben umbenannt und Bauanleitungen ergänzt
Themes und Rendering · Fehler beim Start · Theme-Entwickler, Administratoren
Bestehende Bauskripte, die die bisherigen Aufgabennamen aufrufen, schlagen fehl und müssen auf die neuen Namen umgestellt werden. (35b7ab55c3)
Beschriftung der Select2-Auswahlfelder nachgerüstet
Themes und Rendering · Stiller Fehler · Theme-Entwickler, Plugin-Entwickler
Das Skript vergibt fehlende Kennungen an zugehörige Beschriftungselemente und ändert damit deren id-Attribut zur Laufzeit. (10e16ec848)
Editor-Bundle mit Korrekturen am Bildupload neu gebaut
Themes und Rendering · Kein Bruch · Administratoren, Theme-Entwickler
Die ausgelieferten Editor-Dateien tragen neue Namen, weshalb Zwischenspeicher und Auslieferungsregeln für statische Dateien zu prüfen sind. (6c23b3eb55)
Kartenposition im Antwortdetail auswählbar
Survey Runtime · Kein Bruch · Administratoren
Die eingebettete Karte zeigt nun die gespeicherte Koordinate und erlaubt deren Änderung per Klick oder Ziehen des Markers. (f0202ef81b)
HTML-Editor im Fragen-Dialog umgestaltet
Themes und Rendering · Kein Bruch · Theme-Entwickler
Der Dialog erhält eine eigene Container-Klasse und einen erklärenden Titel statt einer festen Breitenangabe. (de7b0e2039)
Anzeige von IP und Referrer an Umfrageeinstellung gekoppelt
Survey Runtime · Kein Bruch · Administratoren, Integratoren
Die Quelldatei entscheidet nun anhand der Umfrageeinstellung statt anhand des Datensatzwerts, ohne dass der Diff ein passend neu gebautes Bundle enthält. (4bc4642e6a)
Demo-Umfrage verweist auf neues Standard-Theme
Themes und Rendering · Kein Bruch · Administratoren
Die mitgelieferte Beispielumfrage referenziert ein anderes Umfrage-Theme samt zugehöriger Logodatei. (0e01ea590c)
Zuordnung nach Bereich
| Bereich | Vollständig beschrieben | Weitere Einträge |
|---|---|---|
| Sicherheit | keine | – |
| Datenbank | keine | – |
| RemoteControl API | A1 | – |
| Survey Runtime | A2, A3, A4 | ja |
| Themes und Rendering | A6, A7, A8 | ja |
| Plugin-Kompatibilität | A3, A5, A6, A7 | ja |
| Performance | keine | – |
Nicht betroffene Bereiche
Der Diff enthält keine Datei unterhalb von application/helpers/update/ und keine Änderung an der internen Datenbank-Versionsnummer; Struktur-, Spalten-, Index- oder Constraint-Änderungen sind daraus nicht ablesbar. Die Versionsdatei zeigt den Wert vor und nach dem Update unverändert:
// Vorher (application/config/version.php)
$config['versionnumber'] = '7.0.10';
$config['dbversionnumber'] = 710;
...
$config['assetsversionnumber'] = '30498';
// Nachher
$config['versionnumber'] = '7.0.11';
$config['dbversionnumber'] = 710;
...
$config['assetsversionnumber'] = '30499';
Die Twig-Vorlagen der Umfragedarstellung sind im Diff nicht enthalten: Er führt keine Datei mit der Endung .twig und keine Datei unterhalb von themes/survey/. Ebenso wenig enthält er eine Datei unterhalb von application/libraries/PluginManager/, sodass sich aus ihm keine Änderung an der Registrierung von Plugins oder an der Auslösung von Plugin-Ereignissen ablesen lässt. Auch die aktiven Datensatzklassen unterhalb von application/models/ sind nicht Teil des Diffs; Änderungen an Validierungsregeln oder Beziehungen der Modelle sind darin nicht erkennbar.
Empfehlung
Administratoren
Vor dem Update: Sichere Datenbank und Dateisystem wie üblich und prüfe, ob der eingesetzte PHP-Interpreter 64-bittig ist, da die entsprechende Startprüfung entfällt (A4). Erzeuge zusätzlich einen Referenzexport der Antworten einer Umfrage mit Zusatzfeldern „Sonstiges“ und „Kommentar“, um die Spaltenüberschriften später vergleichen zu können (A3). Notiere, ob deine Redaktionsabläufe darauf beruhen, dass neue Fragen ohne Unterfragen entstehen (A2).
Unmittelbar nach dem Update: Erzwinge im Browser ein Neuladen, da die Kennung der ausgelieferten statischen Dateien angehoben wurde, und prüfe die Administrationsoberfläche auf Darstellungsfehler (A8). Bediene eine Umfragenliste einmal ausschließlich per Tastatur und stelle sicher, dass alle Aktionen erreichbar bleiben (A6). Importiere testweise eine kleine Benutzerliste und kontrolliere die Meldungen (A5). Sieh anschließend das Fehlerprotokoll des Webservers auf neue Meldungen durch (A4).
Rollback: Das Release enthält keine Datenbankmigration — die interne Datenbank-Versionsnummer ist vor und nach dem Update identisch, wie oben zitiert. Ein Rückschritt auf den vorherigen Dateistand ist damit ohne Rückabwicklung von Schemaänderungen möglich. Zu beachten ist, dass die kompilierten Stylesheets des Administrations-Themes und die Dateien des Editor-Bundles ersetzt wurden; lokale Änderungen an diesen Dateien sind aus der Sicherung zurückzuholen (A8). Ob Daten, die nach dem Update entstanden sind — insbesondere die zusätzlich angelegten Standard-Unterfragen (A2) —, von der älteren Fassung unverändert verarbeitet werden, ist aus dem Diff nicht bestimmbar; prüfe das vor einem Rückschritt in einer Testumgebung.
Plugin-Entwickler
Prüfe zuerst jeden Aufruf von createNewUser in deinen Erweiterungen und ergänze eine Prüfung auf null, bevor du das Ergebnis als Array weiterverarbeitest (A5). Sieh anschließend Code durch, der die Feldabbildung ausliest, und entferne eigene Ergänzungen der Endungen für Zusatzfelder, sofern du sie bisher selbst angehängt hast (A3). Kontrolliere danach eigene Skripte, die in Administrationslisten auf Verweise mit der Klasse disabled oder auf das Fokusverhalten der Zeilen zugreifen (A6), und passe Selektoren an, die auf die geänderte Überschriften- und ARIA-Struktur der Views treffen (A7).
Theme-Entwickler
Stelle deine Bauskripte auf die umbenannten Gulp-Aufgaben um, bevor du irgendetwas anderes tust — sonst schlägt der erste Bauversuch fehl; die neuen Namen und Voraussetzungen stehen in den mitgelieferten Anleitungen, siehe Weitere relevante Änderungen. Baue anschließend dein Theme neu und gleiche eigene Regeln gegen die überarbeiteten Fokus- und Hoverzustände ab, insbesondere für den Schließen-Knopf von Hinweisleisten und die Marke der Navigationsleiste (A8). Prüfe dann Stilregeln und Skripte, die auf Container mit der Klasse h4, auf dekorative Symbolelemente oder auf die Leermeldung eines Gridviews zielen (A7), sowie Anpassungen, die von der Fokussierbarkeit ganzer Tabellenzeilen ausgehen (A6).
Integratoren
Vergleiche zuerst die Reihenfolge der Unterfragen, die deine Integration aus der Schnittstelle bezieht, mit dem Stand vor dem Update und stelle sicher, dass die Zuordnung über Schlüssel und nicht über die Position erfolgt (A1). Prüfe danach die Spaltenüberschriften deiner Exportverarbeitung gegen den vor dem Update erzeugten Referenzexport (A3). Kontrolliere anschließend Abläufe, die Fragen automatisiert anlegen, auf die nun zusätzlich entstehenden Standard-Unterfragen (A2), sowie Abläufe, die Benutzer anlegen oder importieren, auf das geänderte Fehlerverhalten (A5).
API-Nutzer
Passe deine Auswertung von get_question_properties so an, dass sie die Einträge in subquestions und available_answers über deren Schlüssel identifiziert und nicht über ihre Position in der Antwort (A1). Prüfe zusätzlich, ob deine Verarbeitung Spaltenbezeichner aus der Feldabbildung ableitet, und gleiche die Endungen der Zusatzfelder für „Sonstiges“ und „Kommentar“ gegen den neuen Stand ab (A3).