Du legst eine Seite programmatisch an — über die REST-API, ein Migrationsskript oder einen MCP-Connector — und packst ein Code-Element hinein. Ein eingebettetes Widget, ein Stück JSON-LD, ein kleines Skript. Im Builder ist das Element sichtbar, der Inhalt steht drin, alles sieht richtig aus.
Im Frontend erscheint nichts. Kein leerer Container, keine Konsolenmeldung, kein Eintrag im Fehlerlog. Als hättest du das Element nie angelegt.
Getestet mit
- Bricks 2.3.x
- WordPress 6.8
- PHP 8.3
- Anlage der Seiten über die REST-API beziehungsweise einen Abilities-Adapter
Was tatsächlich passiert
Bricks führt Code aus einem Code-Element nicht bedingungslos aus. Zu jedem Code-Element gehört eine Signatur — ein Hash, den Bricks beim Speichern im Builder erzeugt und in den Element-Einstellungen mit ablegt. Beim Rendern prüft Bricks, ob die Signatur zum gespeicherten Code passt.
Stimmt sie nicht, oder fehlt sie ganz, wird der Code stillschweigend übersprungen. Kein Hinweis, keine Warnung, nichts im Log.
Das ist kein Fehler, sondern Absicht: Wer Schreibzugriff auf die Datenbank hat, könnte sonst beliebiges PHP in eine Seite schreiben und ausführen lassen. Die Signatur bindet ausführbaren Code an einen bewussten Speichervorgang durch einen berechtigten Benutzer.
Die praktische Folge: Alles, was nicht der Builder selbst gespeichert hat, hat keine gültige Signatur. Migrationsskripte, REST-Aufrufe, direkte Datenbankschreibvorgänge, Connectoren — alle laufen in dasselbe Verhalten.
Der Fix
Zwei Wege, beide funktionieren.
Einzelne Seite: einmal im Builder speichern
https://DEINE-DOMAIN.AT/?page_id=SEITEN-ID&bricks=runÖffnen, Cmd+S beziehungsweise Strg+S, fertig. Bricks signiert dabei alle Code-Elemente der Seite neu. Bei einer Handvoll Seiten ist das der schnellste Weg.
Viele Seiten: Signaturen neu erzeugen
Unter Bricks → Einstellungen → Custom Code gibt es die Schaltfläche Regenerate code signatures. Sie geht über den gesamten Bestand.
Damit sie überhaupt auftaucht und wirkt, muss Code Execution für die eigene Rolle freigeschaltet sein — ebenfalls in den Bricks-Einstellungen. Ist sie es nicht, siehst du die Schaltfläche gar nicht und suchst an der falschen Stelle weiter.
Cache, Konsole, Berechtigungen — alles falsch
Ich habe überall gesucht, nur nicht bei Bricks.
Zuerst der Seiten-Cache, also geleert. Dann der Objekt-Cache, auch geleert. Dann ein JavaScript-Fehler im eingebetteten Widget — aber die Konsole blieb leer, weil ja gar nichts geladen wurde. Danach fehlende Berechtigungen des Benutzers, unter dem der Connector schreibt.
Zwischendurch habe ich die Seite mit einem Cache-Buster geladen und im HTML nachgesehen:
curl -s "https://DEINE-DOMAIN.AT/tools/DEIN-TOOL/?nocache=$(date +%s)" | grep -c 'brxe-code'Ergebnis: 0. Das Element war im Frontend-HTML überhaupt nicht vorhanden, obwohl es in der Datenbank stand. Damit war jede Cache- und JavaScript-Theorie erledigt, die Ursache aber immer noch offen.
Gefunden habe ich sie durch einen Vergleich. Ich habe auf derselben Installation ein zweites Code-Element von Hand im Builder angelegt und die gespeicherten Einstellungen beider Elemente nebeneinandergelegt:
wp post meta get SEITEN-ID _bricks_page_content_2 --format=json --path=/PFAD/ZUR/INSTALLATION
| python3 -m json.tool | grep -A5 'signature'Beim von Hand angelegten Element stand ein Signatur-Wert in den Einstellungen. Beim per API angelegten fehlte das Feld komplett.
Was davon allgemein gilt: Wenn ein Element in der Datenbank steht und im Frontend-HTML nicht auftaucht, hat es nichts mit Cache und nichts mit JavaScript zu tun. Dann filtert etwas serverseitig beim Rendern. Der schnellste Weg zur Ursache ist der direkte Vergleich mit einem funktionierenden Exemplar, nicht das Durchprobieren von Verdächtigen.
Der bessere Weg: das Code-Element vermeiden
Der Fix funktioniert, aber er hat einen Haken: Jede künftige Änderung per API entwertet die Signatur wieder. Wenn du eine Seite regelmäßig programmatisch aktualisierst, musst du nach jedem Durchlauf von Hand nachspeichern. Das ist genau die Art Handarbeit, die man mit Automatisierung loswerden wollte.
Zwei Alternativen, die das Problem gar nicht erst haben:
Shortcode statt Code-Element. Der Code lebt in einem Plugin oder im Child-Theme, in der Seite steht nur der Aufruf. Shortcodes unterliegen keiner Signaturprüfung, weil der Code nicht in der Seite gespeichert ist.
add_shortcode( 'mein_widget', function ( $atts ) {
ob_start();
include get_stylesheet_directory() . '/partials/mein-widget.php';
return ob_get_clean();
} );Natives Element statt Code. Für vieles, wofür Leute zum Code-Element greifen, gibt es in Bricks ein eigenes Element — Akkordeon, Formular, Slider, Icon. Das ist im Builder editierbar, überlebt Updates und braucht keine Sonderbehandlung.
Beim JSON-LD für strukturierte Daten gehört der Block ohnehin nicht in die Seite, sondern in den wp_head-Hook oder in ein SEO-Plugin.
Kontrolle
Nach dem Nachspeichern beides prüfen:
curl -s "https://DEINE-DOMAIN.AT/DEINE-SEITE/?nocache=$(date +%s)" | grep -c 'brxe-code'Erwartet wird eine Zahl größer als null. Danach die Seite im privaten Fenster öffnen — eingeloggt siehst du gelegentlich mehr, als ein anonymer Besucher bekommt.
Häufige Fehler
Ich habe neu signiert, es rendert trotzdem nicht.
Prüf, ob Code Execution für deine Rolle aktiv ist. Ohne die Freigabe läuft der Code auch mit gültiger Signatur nicht.
Warum sehe ich das Element im Builder, aber nicht im Frontend?
Der Builder rendert die gespeicherten Einstellungen und prüft die Signatur nicht. Das Frontend tut es. Deshalb ist die Builder-Vorschau bei diesem Problem kein verlässlicher Indikator.
Betrifft das auch Inline-SVG?
Ja. Ein SVG-Element mit der Quelle „Code“ fällt unter dieselbe Prüfung. Wenn du SVGs per API einbauen willst, nimm ein Bild aus der Mediathek oder ein natives Icon.
Kann ich die Signatur selbst berechnen und mitschreiben?
Technisch denkbar, praktisch keine gute Idee. Du würdest genau den Schutz aushöhlen, der verhindert, dass ein Datenbankzugriff zu Codeausführung wird. Nimm den Shortcode-Weg.