Skip to content

feat: Gutenberg-Block „Datensatz-Karte" (v2.38.0) - #101

Merged
daimpad merged 2 commits into
mainfrom
claude/fix-data-prep-errors-kJYpl
Aug 7, 2026
Merged

feat: Gutenberg-Block „Datensatz-Karte" (v2.38.0)#101
daimpad merged 2 commits into
mainfrom
claude/fix-data-prep-errors-kJYpl

Conversation

@daimpad

@daimpad daimpad commented Aug 7, 2026

Copy link
Copy Markdown
Owner

Alternative zum Shortcode [odw_dataset id="123"]: Im Editor über das Plus-Symbol einfügen und den Datensatz aus einer Liste wählen, statt eine ID abzutippen. Der Shortcode bleibt unverändert nutzbar — für klassische Editoren und Widgets.

Umsetzung

Dynamischer Block. Gespeichert wird ausschließlich die Datensatz-ID; das Markup entsteht beim Ausliefern über ODW_Shortcode::render(). Zwei Vorteile: Es gibt genau eine Quelle für die Karte, Änderungen daran wirken auf Block und Shortcode gleichermaßen. Und ein später umbenannter Datensatz erscheint mit seinem aktuellen Titel, statt eine eingefrorene HTML-Kopie im Beitrag zu hinterlassen.

Kein Build-Schritt. blocks/dataset-card/ enthält block.json und ein Editor-Skript in schlichtem JavaScript statt JSX — wie vorab abgestimmt. Der Preis ist das ausgeschriebene createElement(); der Gegenwert ist, dass das Projekt keine JS-Build-Kette für einen einzelnen Block einführen muss.

Auswahlliste über wp_localize_script, nicht über den Core-Datenspeicher. Der Custom Post Type ist bewusst show_in_rest => false — im Code ausdrücklich vermerkt, weil REST über die eigenen Endpunkte läuft. Diese Entscheidung wollte ich nicht für Editor-Bequemlichkeit umstoßen. Die Abfrage läuft nur im Editor (enqueue_block_editor_assets), begrenzt auf 200 Einträge.

Platzhalter statt Live-Vorschau. Eine serverseitig gerenderte Vorschau bekäme das Frontend-Stylesheet im Editor-Rahmen nicht mit und sähe dort kaputt aus. Der Platzhalter nutzt WordPress' eigene Placeholder-Komponente und braucht deshalb gar kein eigenes CSS — assets/css/admin.css lädt im Beitragseditor ohnehin nicht.

Der Fallstrick, der fast durchgerutscht wäre

bin/build-release.sh kopiert eine Allowlist von Verzeichnissen. Ohne die Ergänzung um blocks/ wäre der Block im Repository vorhanden, in jeder Installation aber schlicht nicht da — und in der CI wäre nichts aufgefallen, weil kein Check das Release-Paket auf Vollständigkeit prüft. Ich verifiziere das nach dem Release am heruntergeladenen ZIP.

Verifiziert

PHP-Syntax, JS-Syntax, block.json als JSON, Syntax des Build-Skripts, bin/check-i18n.py bei 0 (7 neue Zeichenketten ergänzt, .mo neu kompiliert auf 634 Einträge), Katalog-Abdeckung beidseitig leer.

Was ich nicht prüfen konnte

Das Verhalten im Editor — Block einfügen, Datensatz wählen, speichern, im Frontend prüfen. Dafür braucht es eine laufende Instanz. Bitte einmal durchspielen, zusammen mit dem noch offenen Test des Datei-Uploads.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JB1xUQM892bVZ4Yv3MZjvq


Generated by Claude Code

claude added 2 commits August 7, 2026 14:29
Alternative zum Shortcode [odw_dataset id="123"]: Im Editor über das
Plus-Symbol einfügen und den Datensatz aus einer Liste wählen, statt eine
ID abzutippen. Der Shortcode bleibt unverändert nutzbar.

Umsetzung:
- Dynamischer Block. Gespeichert wird nur die Datensatz-ID, das Markup
  entsteht beim Ausliefern über ODW_Shortcode::render(). Genau eine Quelle
  für die Karte, und ein später umbenannter Datensatz erscheint mit
  aktuellem Titel statt als eingefrorene Kopie im Beitrag.
- Kein Build-Schritt: block.json plus Editor-Skript in schlichtem JS statt
  JSX. Eine JS-Build-Kette allein für einen Block wäre viel Apparat für
  wenig Ertrag.
- Auswahlliste über wp_localize_script statt über den Core-Datenspeicher.
  Der CPT ist bewusst show_in_rest => false — dafür gibt es die eigenen
  Endpunkte. Die Abfrage läuft nur im Editor
  (enqueue_block_editor_assets), begrenzt auf 200 Einträge.
- Platzhalter statt Live-Vorschau: Eine serverseitig gerenderte Vorschau
  bekäme das Frontend-Stylesheet im Editor-Rahmen nicht mit. Der
  Platzhalter nutzt die Placeholder-Komponente von WordPress und braucht
  deshalb kein eigenes CSS — assets/css/admin.css lädt im Beitragseditor
  ohnehin nicht.
- bin/build-release.sh kopiert blocks/ mit. Ohne diese Ergänzung wäre der
  Block in der Installation schlicht nicht vorhanden gewesen.

i18n: 7 neue Zeichenketten, .mo neu kompiliert (634 Einträge).

Verifiziert: PHP-Syntax, JS-Syntax, block.json, Build-Skript-Syntax,
check-i18n.py bei 0, Katalog-Abdeckung beidseitig leer. Das Verhalten im
Editor lässt sich nur in einer laufenden Instanz prüfen.

https://claude.ai/code/session_01JB1xUQM892bVZ4Yv3MZjvq
WPCS verlangt das Literal links. Die Stelle dabei auseinandergezogen — der
Ternär über einen mehrzeiligen sprintf war schwer zu lesen — und den Grund
für den Ersatztitel als Kommentar festgehalten.

https://claude.ai/code/session_01JB1xUQM892bVZ4Yv3MZjvq
@daimpad
daimpad merged commit 3fa59aa into main Aug 7, 2026
12 checks passed
@daimpad
daimpad deleted the claude/fix-data-prep-errors-kJYpl branch August 7, 2026 15:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants