Bricks 2.4 ist erschienen: die KI-Anbindung und alle Neuerungen im Überblick

Bricks 2.4 ist am 16. September 2026 als fertige Version erschienen, nach mehreren Betas seit Juli. Die Versionshinweise sind länger als bei jedem Update der letzten Jahre und reichen von einem neuen Medienfenster bis zu umgebauten WooCommerce-Elementen.

Die Neuerung mit der größten Tragweite ist die KI-Anbindung. Sie arbeitet anders, als der Name vermuten lässt, und Bricks selbst empfiehlt, sie vorerst nicht auf Live-Webseiten einzusetzen. Deshalb steht sie hier vorn und bekommt den meisten Platz. Für die tägliche Arbeit bringen aber die übrigen Neuerungen mehr: Builder Browser, eine anpassbare Oberfläche, der globale Export des Designsystems und Media Health.

Die Betas habe ich im Juli und im August vorgestellt. Hier geht es um den Stand der fertigen Version, und der weicht an einigen Stellen von damals ab.

Wie die KI-Anbindung in Bricks 2.4 funktioniert

Bricks enthält keine KI. Es gibt keinen Chatbot im Builder, kein Eingabefeld für Anweisungen und keinen Aufruf eines KI-Dienstes aus WordPress heraus. Das steht so auch in der Dokumentation zu den AI Abilities.

Was Bricks stattdessen liefert, ist eine Schnittstelle. Die Kette hat vier Glieder:

1. WordPress Abilities API. Seit WordPress 6.9 können Plugins im Kern anmelden, welche Aktionen sie von außen erlauben, jeweils mit festen Ein- und Ausgaben und einer Rechteprüfung.
2. Bricks meldet seine Aktionen dort an, etwa „Seite anlegen” oder „Klasse bearbeiten”.
3. Der WordPress MCP Adapter ist ein eigenes Plugin aus dem WordPress-Projekt, das WordPress im Februar vorgestellt hat. Er macht diese Aktionen über MCP erreichbar, das offene Protokoll, über das KI-Programme mit fremden Werkzeugen sprechen. Was MCP genau ist, steht in meinem Beitrag zum Model Context Protocol.
4. Ein KI-Client wie Claude Code oder Codex verbindet sich mit diesem Zugang. Das Sprachmodell im Client entscheidet, welche Aktion es aufruft, und WordPress führt sie aus.

Für dich hat das eine direkte Folge bei den Kosten. Bricks verlangt für die Funktion nichts zusätzlich, bezahlt wird beim Client, über dessen Abo oder dessen Abrechnung nach Verbrauch. Und du bist an keinen KI-Anbieter gebunden. Wechselst du von einem Client zum nächsten, bleibt auf der WordPress-Seite alles, wie es ist.

Was die KI in Bricks darf

Die Aktionen decken den größten Teil dessen ab, was man im Builder von Hand tut:

• Seiten anlegen und bearbeiten, Elemente setzen und ändern
• Vorlagen und Komponenten
• globale Klassen, Variablen und Farbpaletten
• Abfragen für Beitragslisten und Navigationsmenüs
• die Einrichtung von WooCommerce
• Import und Export
• HTML und CSS in bearbeitbare Bricks-Elemente umwandeln

Der letzte Punkt ist im Alltag der interessanteste. Ein Entwurf, der als reines HTML entstanden ist, landet damit nicht als starrer Codeblock im Builder, sondern als Elemente, die sich anschließend mit der Maus weiterbearbeiten lassen.

Jede Aktion lässt sich unter Bricks, AI, Abilities einzeln an- und abschalten. Die meisten sind ab Werk aktiv, heikle Bereiche bleiben aus, bis jemand mit Administratorrechten sie freigibt. Mein Rat dazu: nur einschalten, was der Client für die Aufgabe wirklich braucht. Wer Texte umbauen lässt, braucht keinen Zugriff auf WooCommerce.

Daneben gibt es sogenannte Skills. Die klingen nach mehr Rechten, sind aber nur Anleitungen, die dem Client erklären, wie man in Bricks sinnvoll vorgeht. Neue Befugnisse bringen sie nicht mit.

Was du für die Bricks-KI brauchst

Eingeschaltet ist die Anbindung nicht mit einem Häkchen. Nötig sind:

• Bricks 2.4
• WordPress 6.9 oder neuer, wegen der Abilities API
• das Plugin WordPress MCP Adapter
• ein Anwendungspasswort für einen WordPress-Benutzer
• ein Client, der MCP beherrscht. Beschrieben sind Codex und Claude Code, für andere Programme gibt es eine allgemeine JSON-Konfiguration.

Das Anwendungspasswort verdient einen zweiten Blick. Es gehört zu genau einem Benutzer und erbt dessen Rechte. Wer es für ein Administratorkonto anlegt, gibt dem Client die Rechte eines Administrators. Der Vorteil: Anwendungspasswörter lassen sich im Benutzerprofil einzeln widerrufen, ohne das eigentliche Passwort zu ändern. Wer den Client nicht mehr braucht, löscht dort den Eintrag, und der Zugang ist zu.

Warum Bricks die KI auf Live-Webseiten ausgeschaltet lässt

Die Funktion trägt in der Dokumentation den Vermerk „experimentell”. Dazu steht dort sinngemäß: zuerst auf einer lokalen Installation oder einer Staging-Kopie testen und auf Produktivseiten ausgeschaltet lassen, solange sie experimentell ist.

Das hat einen praktischen Grund. Ein Client mit Schreibrechten ändert die Seite direkt. Es gibt keine Vorschau, in der du den Vorschlag erst ansiehst. Versteht das Sprachmodell eine Anweisung falsch, steht das Ergebnis sofort auf der Webseite, die deine Kunden gerade aufrufen.

Meine Arbeitsweise ergibt sich daraus: KI-Aufträge auf einer Kopie der Webseite, das Ergebnis prüfen, dann auf dem normalen Weg übertragen. Eine Staging-Kopie ist ohnehin Teil sauberer WordPress-Wartung, und ein Backup vor jedem größeren Eingriff gehört dazu.

Die PHP-Fähigkeit in der fertigen Version von Bricks

Die Möglichkeit, dass ein Client PHP auf dem Server ausführt, gibt es weiterhin. Was sie erlaubt und warum sie heikel ist, habe ich beim Beitrag zur dritten Beta ausführlich beschrieben. Zwei Dinge haben sich seitdem geändert.

Erstens der Name der Konstante. In den Betas hieß sie BRICKS_ENABLE_EXECUTE_PHP_ABILITY, jetzt lautet die Zeile in der wp-config.php:

define( 'BRICKS_ENABLE_PHP_ABILITIES', true );

Wer die alte Zeile aus der Beta noch stehen hat, muss sie umbenennen. Sonst bleibt die Fähigkeit aus, ohne dass eine Fehlermeldung darauf hinweist.

Zweitens der Umfang. Die neue Konstante schaltet neben dem Ausführen auch das dauerhafte Anlegen und Signieren von PHP-Code frei. Setzen lässt sie sich ausschließlich in der PHP-Konfiguration, nicht im Admin-Bereich. Bricks beschränkt den Einsatz ausdrücklich auf lokale, Staging- oder anderweitig vertrauenswürdige Entwicklungsumgebungen.

Builder Browser und Seitenpanel in Bricks 2.4

Bisher lagen Vorlagen, Komponenten und Beitragstypen in getrennten Bereichen des WordPress-Admins. Der neue Builder Browser holt sie an eine Stelle im Builder, mit Suche, Filtern und direktem Sprung in die jeweilige Verwaltung. Wer an einer Webseite mit vielen Vorlagen arbeitet, spart sich damit das ständige Wechseln zwischen Builder und Admin-Bereich.

Das Seitenpanel wurde dafür neu gebaut. Häufig bearbeitete Seiten und Beiträge lassen sich als Favoriten markieren, die Liste lässt sich durchsuchen, und die Metadaten der Beiträge lassen sich ein- und ausblenden. Neue Inhalte für den gewählten Beitragstyp legst du direkt aus dem Panel an, ohne den Builder zu verlassen.

Die Befehlspalette kennt jetzt auch Komponenten. Mit der Taste * öffnest du den Bereich direkt, suchst eine Komponente und setzt sie auf die Arbeitsfläche. Für alle, die lieber tippen als klicken, ist das der schnellste Weg zu wiederkehrenden Bausteinen.

Die Bricks-Oberfläche für Kunden zuschneiden

Mit dem Interface Customiser lässt sich der Builder umbauen. Die Werkzeugleiste kann an jeder Seite der Arbeitsfläche sitzen, Panels lassen sich links, rechts oder unten andocken. Einzelne Aktionen in der Werkzeugleiste kannst du umsortieren oder ausblenden, Trennlinien setzen und Kurzbefehle anlegen, die ein bestimmtes Element einfügen.

Der eigentliche Gewinn liegt in den Profilen. Eine fertige Anordnung lässt sich als Profil speichern und einzelnen Benutzern oder ganzen Rollen zuweisen, außerdem exportieren und auf anderen Webseiten wieder importieren.

Für mich ist das der praktischste Teil des Updates. Bei einer Webseite, die ein Kunde nach der Übergabe selbst pflegt, braucht er nur einen Bruchteil der Werkzeuge. Mit einem eigenen Profil für seine Rolle bekommt er eine aufgeräumte Werkzeugleiste mit den Aktionen, die er für seine Inhalte braucht. Was er nicht braucht, blendest du aus, und er muss sich nicht durch Funktionen klicken, die für ihn nur Stolperfallen sind.

Designsystem zwischen Bricks-Webseiten übertragen

Wer mehrere Webseiten mit Bricks baut, fängt selten bei null an. Bisher hieß das, Klassen, Farben und Vorlagen einzeln zu übertragen. Der globale Import und Export erledigt das jetzt in einem Schritt und packt alles in eine ZIP-Datei:

• Theme Styles und Breakpoints
• globale Klassen und Variablen
• Farbpaletten
• Komponenten und Vorlagen
• eigene Schriften und Icons
• globale Abfragen
• die Einstellungen der Builder-Oberfläche

Sicherheitsrelevante Einstellungen bleiben dabei bewusst außen vor, nämlich API-Schlüssel, Freigaben zur Codeausführung, das Hochladen von SVG-Dateien und die Rechtesteuerung. Wer ein Designsystem von einer Testseite auf die Live-Seite überträgt, schleppt diese Freigaben also nicht versehentlich mit.

Remote Components gehen einen Schritt weiter. Im Component Manager lassen sich Komponenten direkt aus einer anderen Bricks-Installation durchsuchen und übernehmen. Mitgenommen werden verschachtelte Komponenten, die darin verwendeten globalen Klassen, Variablen und Farbpaletten, und auf Wunsch auch die Bilder. Eine Bibliothek bewährter Bausteine auf einer zentralen Webseite wird damit zur Quelle für alle weiteren Projekte.

CSS Sync und Stilübernahme im Bricks-Builder

CSS Sync ist für alle gedacht, die zwischen den Bedienfeldern und eigenem CSS hin- und herwechseln. Ändert man eine unterstützte Eigenschaft im CSS-Editor, zieht das zugehörige Bedienfeld mit. Umgekehrt schreibt eine Änderung im Bedienfeld den Wert zurück ins eigene CSS. Bisher lebten beide nebeneinander, und am Ende war oft unklar, welcher Wert gerade gilt. Die Funktion ist ab Werk aus und noch als experimentell markiert.

Beim Kopieren von Stilen gibt es jetzt deutlich feinere Möglichkeiten. Du kopierst entweder alle Stile eines Elements mit Breakpoints, Selektoren und Pseudoklassen, oder nur die des gerade bearbeiteten Breakpoints. Beim Einfügen entscheidest du, ob die Stile ihren ursprünglichen Breakpoint behalten oder auf den aktuellen übertragen werden, und ob sie bestehende Stile ergänzen oder ersetzen.

Farbpaletten stehen außerdem im Variable Manager und in der Variablenauswahl zur Verfügung. Farben lassen sich innerhalb einer Palette anlegen, umbenennen und sortieren und überall in Bricks als dieselbe Variable verwenden. Gelöschte Farben landen zuerst in einem Papierkorb, bevor sie endgültig verschwinden.

Medienverwaltung und Media Health in Bricks

Der Media Browser ersetzt das Standardfenster von WordPress durch ein eigenes. Dateien lassen sich durchsuchen und filtern, mehrere auf einmal auswählen, hochladen, mit Metadaten versehen und in Sammelaktionen bearbeiten. Du siehst außerdem, wo eine Datei überall verwendet wird. Das beantwortet die Frage, die sich vor jedem Löschen stellt. Auch per Tastatur geht es: Pfeiltasten wechseln zwischen den Dateien, die Leertaste wählt aus, Strg und Enter fügen ein, am Mac Cmd und Enter.

Media Health ist für die meisten Webseiten der nützlichste Teil. Die Prüfung meldet:

• defekte Dateien
• fehlende Alt-Texte oder Bildgrößen
• zu große Dateien
• veraltete Formate

Das sind genau die Schwachstellen, die sich über Jahre unbemerkt in einer Mediathek sammeln. Fehlende Alt-Texte schaden der Barrierefreiheit und der Sichtbarkeit in der Bildersuche, zu große Bilder verlängern die Ladezeit. Bisher brauchte man für diese Übersicht ein zusätzliches Plugin oder einen manuellen Durchgang.

Neu ist außerdem ein natives File-Element für Dokumente. Die Datei kommt aus der Mediathek, von einer externen Adresse oder aus einem eigenen Feld. Angezeigt wird sie als Link oder als Download-Schaltfläche, PDFs auf Wunsch mit einer Vorschau direkt im Browser. Für Preislisten, Speisekarten oder Formulare zum Herunterladen braucht es damit kein eigenes Plugin mehr.

WooCommerce in Bricks 2.4

Für Shops hat Bricks 2.4 drei größere Neuerungen.

Der Einrichtungsassistent listet alle WooCommerce-Seiten und die zugehörigen Vorlagen auf, verlinkt sie direkt zum Bearbeiten und legt auf Wunsch die Grundstrukturen für Warenkorb, Kasse, Kundenkonto, Shop-Übersicht und Produktseite an. Wer einen neuen Shop aufsetzt, spart sich damit das Zusammensuchen der einzelnen Seiten.

Die modularen Elemente in Version 2 bauen Warenkorb, Kasse und Kundenkonto neu auf:

• Warenkorb mit getrennten Layouts für gefüllt und leer
• Kasse mit Layouts für Bestellung, Bezahlung und Danke-Seite, außerdem mit mehrstufigem Checkout
• Kundenkonto mit Layouts für Anmeldung, vergessenes Passwort, Passwort zurücksetzen, Übersicht und Unterseiten

Diese Elemente sind noch experimentell und müssen ausdrücklich eingeschaltet werden.

Dazu kommt ein Mini-Warenkorb, dessen Inhalt sich per AJAX ändern lässt, ohne dass die Seite neu lädt. Neu sind auch das dynamische Tag {woo_product_gtin} für die GTIN eines Produkts und der Interaktions-Auslöser „Bricks cart contents changed”, mit dem du auf Änderungen im Warenkorb reagieren kannst. Wer einen Shop mit WooCommerce betreibt, sollte die neuen Elemente wegen des experimentellen Status zuerst auf einer Kopie ausprobieren.

Weitere Neuerungen in Bricks 2.4

Bedingte Formularaktionen. Einzelne Aktionen eines Formulars laufen nur noch dann, wenn bestimmte Feldwerte zutreffen. Geprüft wird mit „ist”, „ist nicht”, „enthält”, „enthält nicht”, „ist leer” und „ist nicht leer”, verknüpft mit UND oder ODER. So geht eine Anfrage je nach gewähltem Thema an eine andere Adresse, ohne dass du dafür zwei Formulare bauen musst.

Sichtbarkeit bei Interaktionen. Für die Auslöser beim Betreten und Verlassen des sichtbaren Bereichs lässt sich einstellen, wie viel eines Elements zu sehen sein muss, von 0 Prozent für jeden sichtbaren Teil bis 100 Prozent für das ganze Element. Animationen starten damit nicht mehr, sobald eine Kante ins Bild rutscht.

Lizenzschlüssel per Konstante. Mit BRICKS_LICENSE_KEY in der wp-config.php hinterlegst du die Lizenz, ohne sie im Admin-Bereich einzugeben. Gedacht ist das für Vorlagen-Webseiten, geklonte Installationen und automatisierte Deployments.

Automatische Code-Signierung. Zwei neue Konstanten signieren eigenen Code beim Speichern oder beim Neuzeichnen im Builder automatisch. Sie heißen BRICKS_DANGEROUSLY_AUTO_SIGN_CODE_ON_BUILDER_SAVE und BRICKS_DANGEROUSLY_AUTO_SIGN_CODE_ON_BUILDER_RERENDER und sind ab Werk aus. Das Wort im Namen ist ernst gemeint: Die Signierung ist ein Schutz davor, dass fremder Code unbemerkt ausgeführt wird, und wer sie automatisiert, hebt diesen Schutz teilweise auf. Auf eine Live-Webseite gehören die beiden nicht.

Daneben gibt es eine Reihe kleinerer Verbesserungen:

• Die Admin-Seiten für Einstellungen, Elemente und KI teilen sich jetzt einen einheitlichen Aufbau mit Suche und schwebender Speichern-Leiste.
• Farbpaletten aus Bricks stehen auch im Block-Editor zur Verfügung.
• Schriftfelder akzeptieren eigene Werte für die Schriftfamilie.
• Die Richtung eines Offcanvas-Menüs lässt sich je Breakpoint einstellen.
• Flex- und Grid-Layouts teilen sich jetzt dieselben Felder für Zeilen- und Spaltenabstand.
• 43 mitgelieferte Sprachen wurden aktualisiert.

Bei der Leistung nennt Bricks eine kürzere Ladezeit beim Öffnen des Builders und einen schnelleren Mini-Warenkorb nach dem Ändern einer Menge.

Solltest du auf Bricks 2.4 aktualisieren?

Für die meisten Webseiten ja. Die experimentellen Teile, also KI-Anbindung, CSS Sync und die neuen WooCommerce-Elemente, sind ab Werk aus und bleiben es, bis du sie selbst einschaltest. Wer das Update einspielt, bekommt die übrigen Neuerungen, ohne dass sich an der laufenden Webseite von allein etwas umstellt.

Vor dem Update gilt dieselbe Reihenfolge wie bei jedem größeren Versionssprung:

1. Ein vollständiges Backup, das sich auch zurückspielen lässt.
2. Bei Shops, bei viel eigenem CSS oder bei selbst geschriebenen Erweiterungen zuerst auf einer Staging-Kopie testen.
3. Wer in einer Beta die PHP-Konstante gesetzt hatte, benennt sie in BRICKS_ENABLE_PHP_ABILITIES um.
4. Nach dem Update die wichtigsten Seiten durchklicken, bei Shops einmal einen Testkauf bis zur Danke-Seite.

Wenn du diese Schritte nicht selbst übernehmen willst, gehört genau das zur Betreuung einer WordPress-Webseite.

Mein Fazit zu Bricks 2.4

Die Bauweise der KI-Anbindung halte ich für richtig. Bricks hängt sich an einen offenen Standard statt an einen einzelnen KI-Anbieter, die Kosten liegen sichtbar beim Client, und jede Aktion lässt sich einzeln abschalten. Das ist eine solide Grundlage, auf der die Funktion reifen kann. Auf einer Live-Webseite bleibt sie bei mir aus, bis der Vermerk „experimentell” verschwindet.

Den größeren Nutzen im Alltag haben die anderen Neuerungen. Die Profile für die Oberfläche machen die Übergabe an Kunden sicherer, der globale Export spart bei jedem neuen Projekt Stunden, und Media Health zeigt Probleme, die bisher erst auffielen, wenn jemand danach suchte. Das Update lohnt sich deshalb auch dann, wenn du mit KI im Builder vorerst nichts anfangen willst.