feat: Usability-Test — Gliederung, Verständlichkeit, Datei-Upload (v2.35.8)

[daimpad]

Setzt die vier Punkte um, die aus dem Usability-Test noch offen waren.

Tab-Zuschnitt nach inhaltlicher Zusammengehörigkeit

Schlagworte stehen jetzt in Tab 1 bei Thema, CESSDA-Klassifikation und Engagementfeld — alle vier beschreiben, worum es geht. Bei Sprache und Datumsangaben waren sie fehl am Platz. Sie bleiben oberhalb der aufklappbaren Untergruppe sichtbar; an ihnen hängen 30 MQA-Punkte, sie gehören nicht ins Optionale.

Die Erstveröffentlichung ist nach Tab 4 zur Aktualisierungsfrequenz gewandert — beide beschreiben die Aktualität des Datensatzes.

Tab 2 heißt „Sprache & Übersetzungen" und trägt jetzt sämtliche Übersetzungs-Repeater. Titel- und Beschreibungsübersetzungen standen vorher in Tab 1, die Schlagwortübersetzungen in Tab 2 — getrennt von ihresgleichen.

Zugriffsrechte vorbelegt

Neue Datensätze starten mit „Öffentlich" — sichtbar im Formular, jederzeit änderbar. Für ein Open-Data-Plugin ist das der Normalfall.

Bewusst kein Automatismus aus dem Beitragsstatus, obwohl der Tester das vorschlug: Das würde Metadaten im Hintergrund schreiben und nebenbei 20 MQA-Punkte vergeben — dasselbe Muster, das in v2.35.5 als Ursache des unerklärlichen Startwerts von 2 % behoben wurde.

HVD-Felder nennen ihre Geltung

High-Value-Datensätze sind eine Rechtskategorie der EU-Durchführungsverordnung 2023/138 und richten sich an öffentliche Stellen. Beschriftung und Hilfetext sagen das jetzt ausdrücklich, damit Vereine und Verbände die Felder überspringen können, ohne zu rätseln. Für Kommunen — ebenfalls Zielgruppe und öffentliche Stellen — bleiben sie unverändert nutzbar.

CESSDA-Feld war zu schmal

Das Eingabefeld war rund ein Fünftel so breit wie alle anderen und schnitt seinen Platzhalter ab. Ursache: Das Widget wird als Geschwister neben das ausgeblendete Carbon-Fields-Feld gesetzt und steht damit außerhalb von .cf-field. Dessen Breitenregeln greifen dort nicht, und der Browser fiel auf die Standardbreite eines Textfelds zurück (size=20, ~250 px). Die neue Selektorkette setzt die Breite unabhängig davon.

Mitgezogen

Feld-Katalog (Tab-Zuordnung, Reihenfolge, sowie die Engagementfeld-Frage, die noch die in v2.35.5 korrigierte alte Formulierung trug), Validierungs-Tabname, Einstiegsseite, E2E-Spec, README, CLAUDE.md, docs/FELD-REFERENZ.md neu generiert.

Neu: bin/check-i18n.py — vergleicht alle übersetzbaren Zeichenketten des Quellcodes gegen den Katalog und meldet Lücken mit Exit-Code 1. Bei elf umformulierten Zeichenketten in einem Durchgang ist Nachhalten von Hand unzuverlässig; das Skript hat prompt zwei Stellen gefunden, die ich übersehen hatte.

Zur Prüfung

Der lokale Composer-Toolchain ist weiterhin nicht herstellbar (der Proxy blockt api.github.com und codeload.github.com, dort holt Composer jede Dist-Datei). Lokal verifiziert wurden:

• php -l über alle geänderten PHP-Dateien, node --check für JS
• Die Logik von test_catalog_covers_all_form_fields nachgestellt — beide Richtungen leer
• docs/FELD-REFERENZ.md deckungsgleich mit dem Generator (erneuter Lauf erzeugt keine Änderung)
• bin/check-i18n.py meldet 0 fehlende Übersetzungen; .mo per gettext geprüft

PHPUnit, PHPCS und PHPStan laufen in der CI. Bei Rot bessere ich anhand des Logs nach.

Nicht in diesem PR

Der Umzug des Upload-Buttons aus der Seitenleiste ins Formular folgt separat. Er berührt wp.media, Nonce und Speicherpfad einer Kernfunktion, und ob die Skript-Bindung ein React-gerendertes Feld übersteht, lässt sich nur in einer laufenden Instanz feststellen — als eigener PR ist ein Fehler dort isoliert und leicht rückgängig zu machen.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JB1xUQM892bVZ4Yv3MZjvq

---

Generated by Claude Code

[daimpad]

Nachtrag: Datei-Upload ins Formular geholt (v2.35.8)

Der Upload-Umzug ist als eigener Commit (f554d41) hinzugekommen — nicht als separater PR, wie ursprünglich angekündigt. Grund ist banal: Diese Sitzung ist auf einen Branch festgelegt, ein zweiter PR hätte einen zweiten Branch gebraucht. Der Commit ist aber sauber isoliert und lässt sich einzeln zurücknehmen, falls beim Test etwas klemmt.

Was sich ändert

Der Upload stand als eigene Meta-Box in der Seitenleiste, die Zugriffs-URL in Tab 3 — zwei Orte für denselben Sachverhalt, ohne dass die Oberfläche den Zusammenhang zeigte. Das Widget steht jetzt unmittelbar unter der Zugriffs-URL, die Hilfetexte verweisen aufeinander.

Wie

• render_file_meta_box() → file_upload_html(), liefert Markup als String statt es auszugeben.
• Eingehängt als Carbon-Fields-html-Feld mit Callback. Html_Field::to_json() ruft ihn erst beim Rendern des Containers auf — dort steht der Beitragskontext zur Verfügung, der Dateizustand kommt also weiterhin vom Server. Hätte ich die Zustandswiederherstellung JavaScript überlassen, wäre bei deaktiviertem oder fehlgeschlagenem JS beim Speichern eine bestehende Verknüpfung verloren gegangen.
• odw-file-upload.js nutzt jetzt durchgehend delegierte Handler an document. Carbon Fields hängt seine Felder erst nach DOMContentLoaded ein und kann sie neu rendern; die bisherige direkte Bindung beim Laden hätte ins Leere gegriffen.
• save_file_attachment() ist unverändert und bricht weiterhin ab, wenn die Nonce fehlt — sollte das Widget einmal nicht rendern, geht nichts verloren.

Was ich nicht prüfen konnte

Die Interaktion mit wp.media — Frame öffnen, Auswahl übernehmen, Entfernen — lässt sich nur in einer laufenden Instanz testen. Bitte einmal manuell durchspielen: Datei auswählen, speichern, Seite neu laden (bleibt die Verknüpfung?), dann entfernen und erneut speichern.

Ein Restrisiko bleibt benennbar: Sollte Carbon Fields das html-Feld nach einer Auswahl neu rendern, würde die Anzeige auf den serverseitigen Stand zurückspringen. Beobachtet habe ich das nicht, und die Sektion hat keine Conditional Logic, die ein Re-Rendering auslösen würde — falls es doch auftritt, ist es genau bei diesem Test zu sehen.

---

Generated by Claude Code