Startseite → Plugins → Eigenes Bricks-Builder-Element
Ein Plugin kann Bricks auf zwei Wegen erreichen: als Shortcode, den man in einen Container legt, oder als eigenes Element, das neben den eingebauten in der Liste steht und ein eigenes Einstellungspanel hat. Das Erste ist schneller gebaut, das Zweite ist für die Person leichter, die danach die Seiten zusammensetzt. Dies sind Notizen zum zweiten Weg — zu dem Element, das ich für meinen Filialfinder geschrieben habe.
Es steht in der Elementliste mit eigenem Namen, Symbol und eigener Kategorie — zu finden wie eine Schaltfläche oder ein Slider, ohne Umweg über die Dokumentation.
Es hat ein echtes Einstellungspanel statt aus dem Gedächtnis getippter Attribute. Auswahlfelder, Schalter, Schieberegler — alles mit Hinweisen und Prüfung.
Es zeichnet sofort auf der Arbeitsfläche. Eine geänderte Einstellung zeichnet die Vorschau neu, das Ergebnis ist also bei jedem Klick sichtbar und nicht erst nach Speichern und Neuladen.
Ein Tippfehler kann es nicht zerlegen. Eine geschlossene Liste von Optionen statt eines Textfelds, in dem ein verirrter Punkt den Shortcode ruiniert.
Der Ausgangspunkt ist dokumentiert: Die Bricks Academy hat einen Artikel, Create Your Own Elements, mit einem fertigen Klassengerüst, der Liste der Eigenschaften und Methoden und dem Weg, das Element zu registrieren. Der Rest kommt aus dem Lesen des Theme-Codes und aus Prüfungen im laufenden Builder — dort hört die Dokumentation auf und dort fangen die Details an, die darüber entscheiden, ob das Element ein Neuzeichnen übersteht.
Das Gerüst entsteht an einem Abend aus dem Academy-Artikel. Die folgenden drei Dinge stehen dort nicht, und sie entscheiden darüber, ob das Element in der Praxis funktioniert.
Hier sterben solche Elemente üblicherweise. Bei einem Element, dessen Markup PHP erzeugt, schickt eine geänderte Einstellung eine Anfrage an den Server und legt frisches HTML auf die Arbeitsfläche — einen neuen Knoten. Eine Leaflet-Karte, die am vorherigen hing, wandert nicht mit und hinterlässt ein totes Rechteck. Bricks ruft die Startfunktion des Elements danach zwar auf, aber mit kurzer Verzögerung und erst, wenn der Knoten steht. Diese Funktion muss deshalb die Seite durchgehen und neu binden, statt anzunehmen, ein einziger Durchlauf genüge.
Die Dokumentation führt sie unter den Frontend-Methoden, und sie lädt Assets auf Seiten, auf denen das Element vorkommt. In der Praxis ruft der Builder sie ebenfalls auf — wenn der Vorschaurahmen öffnet und bei jedem Neuzeichnen. Die Methode muss also wissen, woher sie aufgerufen wurde; sonst bekommen entweder Besucherinnen Dinge, die nur im Editor nötig sind, oder der Editor bekommt gar nichts.
Alle dreizehn Bedienelemente geben ausdrücklich an, dass eine Änderung das Element neu zeichnen soll. Ehrlich gesagt ist das nicht der Grund, warum die Vorschau sich aktualisiert — das macht Bricks ohnehin. Es ist eine Versicherung für den Fall, dass ein Bedienelement später eine CSS-Eigenschaft bekommt, und dafür, dass sich der Standard ändert. Eine Zeile pro Bedienelement, weniger Überraschungen beim nächsten Update.
Die Testsuite sichert den Code ab und läuft vollständig durch. Keines der folgenden drei Dinge hat sie gefunden.
Ein Element, das spurlos verschwindet. Auf einer Seite, die aus einer Bricks-Inhaltsvorlage gerendert wurde, erschien es überhaupt nicht — kein HTML, kein PHP-Fehler, nichts in der Konsole. Es gibt nichts, wonach man suchen könnte, bis man so eine Seite öffnet.
Tote Bedienelemente bei voll durchlaufender Suite. Vier Felder im Panel taten nichts, während alle Tests grün blieben. Ein Test prüft, dass ein Bedienelement deklariert ist — nicht, dass ein Klick darauf etwas bewirkt. Deshalb gehört eine Liste manueller Prüfungen zum Release-Plan und bleibt kein guter Vorsatz.
Die Version, die auf der Website wirklich läuft. Die Versionsnummern von Bricks können sich zwischen der Fassung, die man liest, und der unterscheiden, auf der alles funktionieren muss. Solange das Element nicht in genau diesem Builder geöffnet wurde, ist jeder Satz darüber eine Vermutung — und so behandle ich ihn auch.
Wenn Ihre Funktion heute als Shortcode ausgeliefert wird und die Person, die die Seiten baut, sich deren Attribute merken muss, ist das genau dieser Fall. Schreiben Sie, was es können soll, und ich sage Ihnen, was dafür nötig ist.
Schreiben, was es können soll →Oder per E-Mail: info@asymetria.com.pl