Strona główna → Wtyczki → Własny element Bricks Buildera
Wtyczka może trafić do Bricksa na dwa sposoby: jako shortcode wklejony w kontener albo jako własny element, który stoi na liście obok wbudowanych i ma własny panel ustawień. Pierwszy sposób jest prostszy do zrobienia, drugi wygodniejszy dla osoby, która potem składa strony. To są zapiski z drugiego — z elementu, który napisaliśmy do naszego lokalizatora.
Stoi na liście elementów z własną nazwą, ikoną i kategorią — znajduje się go tak samo jak przycisk czy suwak, bez zaglądania do dokumentacji.
Ma prawdziwy panel ustawień zamiast atrybutów wpisywanych z pamięci. Pola wyboru, przełączniki, liczby z suwakiem — wszystko z podpowiedziami i walidacją.
Rysuje się na płótnie od razu. Zmiana ustawienia przerysowuje podgląd, więc efekt widać przy każdym kliku, a nie po zapisaniu i odświeżeniu strony.
Nie da się go zepsuć literówką. Zamknięta lista opcji zamiast pola tekstowego, w którym jedna kropka rozsypuje shortcode.
Punkt wyjścia jest udokumentowany: Bricks Academy ma artykuł Create Your Own Elements z gotowym szkieletem klasy, listą właściwości i metod oraz rejestracją elementu. Reszta pochodzi z czytania kodu motywu i sprawdzania w działającym edytorze — bo tam kończy się dokumentacja, a zaczynają szczegóły, od których zależy, czy element ożyje po przerysowaniu.
Szkielet elementu składa się z artykułu w Academy w jeden wieczór. Trzy rzeczy poniżej nie są tam opisane, a to one decydują, czy element działa w praktyce.
To jest miejsce, w którym takie elementy najczęściej padają. Przy elemencie, którego treść składa PHP, zmiana ustawienia wysyła żądanie na serwer i wstawia na płótno świeży HTML — czyli nowy węzeł. Mapa Leafleta podpięta do poprzedniego nie przenosi się razem z nim i zostaje po niej martwy prostokąt. Bricks wywołuje potem funkcję startową elementu, ale robi to z niewielkim opóźnieniem i dopiero po wstawieniu węzła. Funkcja musi więc przejrzeć stronę i podpiąć się na nowo, a nie założyć, że wystarczy uruchomić się raz.
W dokumentacji stoi wśród metod frontowych i ładuje zasoby na stronach, na których element występuje. W praktyce woła ją także builder — przy otwarciu ramki podglądu i przy każdym przerysowaniu. Metoda musi więc sama wiedzieć, gdzie została wywołana; inaczej albo odwiedzający dostają rzeczy potrzebne wyłącznie w edytorze, albo edytor nie dostaje ich wcale.
Wszystkie trzynaście kontrolek ma wypisane wprost, że zmiana ma przerysować element. Uczciwie: to nie jest tym, co sprawia, że podgląd się odświeża — Bricks robi to domyślnie. To zabezpieczenie na wypadek, gdyby kontrolka kiedyś dostała własność CSS albo gdyby zmieniło się zachowanie domyślne. Jedna linia na kontrolkę, mniej niespodzianek przy kolejnej aktualizacji.
Zestaw testów pilnuje kodu i przechodzi w całości. Poniższych trzech nie złapał.
Element znikający bez śladu. Na stronie renderowanej z szablonu treści Bricksa element nie wyświetlał się w ogóle — bez HTML-a, bez błędu PHP i bez niczego w konsoli. Nie ma po czym tego szukać, dopóki nie otworzy się takiej strony.
Martwe kontrolki przy komplecie przechodzących testów. Cztery pola w panelu nie robiły nic, choć każdy test był zielony. Test sprawdza, że kontrolka jest zadeklarowana — nie że po jej kliknięciu coś się dzieje. Dlatego lista sprawdzeń ręcznych jest częścią planu wydania, a nie dobrą chęcią.
Wersja, na której faktycznie stoi strona. Numery wersji Bricksa potrafią się różnić między kopią do czytania a tą, na której wszystko ma działać. Dopóki element nie został otwarty w tym konkretnym builderze, każde zdanie o nim jest przypuszczeniem — i tak to traktujemy.
Jeśli Twoja funkcja działa dziś jako shortcode, a osoba składająca strony musi pamiętać atrybuty — to jest dokładnie ten przypadek. Napisz, co ma robić, a powiemy, ile to zajmie.
Opisz, co ma robić →Albo mailem: info@asymetria.com.pl