feat: Gutenberg-Block „Datensatz-Karte" (v2.38.0) - #101
Merged
Conversation
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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ältblock.jsonund ein Editor-Skript in schlichtem JavaScript statt JSX — wie vorab abgestimmt. Der Preis ist das ausgeschriebenecreateElement(); 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 bewusstshow_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.csslädt im Beitragseditor ohnehin nicht.Der Fallstrick, der fast durchgerutscht wäre
bin/build-release.shkopiert eine Allowlist von Verzeichnissen. Ohne die Ergänzung umblocks/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.jsonals JSON, Syntax des Build-Skripts,bin/check-i18n.pybei 0 (7 neue Zeichenketten ergänzt,.moneu 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