ACF Pro jako warstwa treści: jak dać klientowi edycję bez ryzyka rozjechanej strony

Problem, który wraca po każdym wdrożeniu

Najczęstszy telefon po oddaniu strony zbudowanej na page builderze brzmi mniej więcej tak: „chciałam tylko poprawić literówkę i teraz cała sekcja zjechała na dół”. Czasem to literówka, czasem podmiana zdjęcia, czasem przypadkowe przeciągnięcie kolumny o dwa piksele. Skutek bywa ten sam, bo w builderze treść i układ leżą w jednym miejscu. Klikając w tekst, klikasz też w pojemnik, w którym ten tekst siedzi.

Przez piętnaście lat pracy z WordPressem widziałem to na tyle razy, że traktuję to jako problem projektowy, nie problem użytkownika. Jeśli interfejs pozwala zepsuć stronę jednym przeciągnięciem, to prędzej czy później ktoś ją zepsuje. Nie dlatego, że jest nieostrożny, tylko dlatego, że taka jest statystyka.

Druga strona tego samego problemu to strony zabezpieczone tak, że klient nie może zmienić nic. Każda zmiana ceny czy godzin otwarcia to mail do wykonawcy, faktura i trzy dni czekania. To też nie jest rozwiązanie, tylko przeniesienie kosztu.

Jak działa strona zbudowana na polach

W podejściu, które stosuję, szablon strony to zwykły plik PHP. Ten plik wie, że sekcja „usługi” składa się z nagłówka, krótkiego wprowadzenia i listy kart, a każda karta ma ikonę, tytuł, opis i link. Wie też, jak to ma wyglądać na telefonie i jak na monitorze. Tego klient nie widzi i nie musi widzieć.

W panelu WordPressa ta sama sekcja wygląda jak formularz. Pole „Nagłówek sekcji”. Pole „Wprowadzenie”. Powtarzalna grupa „Karty usług” z przyciskiem „Dodaj kartę”. Klient wpisuje tekst, wybiera zdjęcie z biblioteki, zapisuje. Strona przeładowuje się z nową treścią w dokładnie tym samym układzie, bo układ nigdy nie był edytowalny.

Ważny szczegół, który decyduje o jakości takiego rozwiązania: pola powinny nazywać się językiem klienta, nie językiem programisty. „Trzy powody, dla których warto” jest dobrą nazwą pola. „section_3_repeater_items” nie jest, nawet jeśli tak nazywa się w kodzie. Panel, w którym trzeba zgadywać, co robi dane pole, jest tak samo bezużyteczny jak brak panelu.

Co klient może, a czego nie może zepsuć

Podział wygląda w praktyce tak:

Klient zmienia sam: wszystkie teksty, zdjęcia, ceny, dane kontaktowe, kolejność elementów w listach, liczbę kart czy pozycji w cenniku, treść przycisków i to, dokąd prowadzą, wpisy na blogu, opisy produktów, sekcje FAQ.

Klient nie ruszy nawet przypadkiem: siatki, odstępów, typografii, kolorów, zachowania na telefonie, kolejności sekcji na stronie głównej, jeśli tak ustaliliśmy, oraz wszystkiego, co decyduje o wyniku w PageSpeed.

To rozgraniczenie da się przesuwać. Jeśli klient chce sam decydować o kolejności sekcji, robi się elastyczną zawartość, gdzie każda sekcja to klocek do wstawienia, ale wygląd klocka nadal siedzi w kodzie. Widziałem projekty, gdzie taka swoboda była potrzebna, i takie, gdzie tylko rozpraszała. To pytanie do klienta, nie założenie z góry.

Ile to kosztuje i kiedy się zwraca

Zbudowanie warstwy pól to realna praca. Trzeba zaprojektować strukturę treści, nazwać pola po ludzku, obsłużyć przypadki brzegowe, na przykład to, co ma się stać, gdy klient nie wgra zdjęcia albo zostawi pustą sekcję. W wycenie strony wizytówkowej to zwykle jeden do dwóch dni pracy na całym projekcie, w większym serwisie więcej.

W moim cenniku strona wizytówkowa na kilka podstron zaczyna się od 10 000 zł i warstwa pól jest w tej cenie, bo nie traktuję jej jako dodatku. Strona bez sensownego panelu to strona, która wróci do mnie za każdą zmianą, a to jest kłopot dla obu stron.

Zwrot liczy się prosto. Jeśli firma zmienia coś na stronie raz w miesiącu i każda taka zmiana to godzina pracy wykonawcy po 180 zł, robi się 2 160 zł rocznie. Przez trzy lata życia strony to około 6 500 zł, czyli więcej niż koszt zaprojektowania panelu. A to przy założeniu, że zmiany są drobne i że ktoś ma czas je zrobić w tym tygodniu.

Gdzie to podejście nie ma sensu

Nie każda strona potrzebuje rozbudowanego panelu. Jednostronicowa wizytówka, która przez trzy lata nie zmieni ani słowa, świetnie poradzi sobie z treścią wpisaną prosto w szablon. Podobnie strona wydarzenia, które odbędzie się raz.

Nie ma też sensu robić pola na wszystko. Widziałem panele z siedemdziesięcioma polami na jednej podstronie, gdzie edytowalny był każdy piksel. Klient otwierał to raz, zamykał i dzwonił z prośbą o zmianę. Panel, który przytłacza, jest funkcjonalnie tym samym co brak panelu. Dobra miara: jeśli nie potrafisz wytłumaczyć, po co jest dane pole, w jednym zdaniu, to tego pola nie powinno być.

Uczciwie trzeba dodać, że ACF Pro to płatna wtyczka. Licencja to wydatek rzędu kilkuset złotych rocznie, w zależności od wariantu. Przy stronie firmowej, która zarabia, to koszt pomijalny, ale warto o nim wiedzieć, zamiast odkryć go przy pierwszym odnowieniu.

Checklista: czy Twój panel jest dobrze zrobiony

• Otwierasz edycję strony i od razu wiesz, które pole odpowiada za który fragment na stronie.
• Nazwy pól są po polsku i mówią o treści, nie o kodzie.
• Pola mają krótkie podpowiedzi, na przykład zalecaną długość tekstu albo proporcje zdjęcia.
• Zostawienie pustego pola nie wysypuje strony, tylko chowa sekcję albo pokazuje sensowną wartość domyślną.
• Nie ma pola, którego przeznaczenia nie umiesz wytłumaczyć w jednym zdaniu.
• Zapisanie strony bez żadnej zmiany nie powoduje, że coś znika z frontu. To brzmi absurdalnie, ale to realna pułapka przy źle ustawionych wartościach domyślnych.
• Masz dostęp do biblioteki mediów i możesz wgrać zdjęcie bez pytania nikogo o zgodę.

Najczęstsze pytania

Czy da się przenieść stronę z Elementora na pola ACF bez pisania treści od zera?

Da się, ale nie automatycznie. Treść wyciąga się z bazy, natomiast układ trzeba odtworzyć w szablonie, bo builder zapisuje go w formacie, którego nie da się sensownie przetłumaczyć na czysty HTML. W praktyce to znaczy: teksty i zdjęcia przenoszą się szybko, wygląd jest robiony na nowo. Przy okazji zwykle warto uporządkować strukturę, bo w builderze rzadko jest ona przemyślana.

Czy strona na ACF jest szybsza od strony na page builderze?

Zwykle tak, choć nie dlatego, że ACF jest magicznie wydajny. Powód jest prostszy: page builder dokłada własny kod CSS i JavaScript, który musi obsłużyć wszystkie możliwe układy, także te, których na Twojej stronie nie ma. Szablon pisany pod konkretny projekt ładuje tylko to, co jest potrzebne. Różnica bywa spora, ale zależy od tego, jak mocno builder był rozbudowany dodatkami.

Co się stanie, jeśli przestanę opłacać licencję ACF Pro?

Strona działa dalej, treść nie znika, bo siedzi w bazie WordPressa. Tracisz dostęp do aktualizacji i wsparcia, co po jakimś czasie robi się ryzykiem przy nowych wersjach PHP. Traktowałbym to jak licencję na antywirusa: brak opłaty nie kasuje danych, ale zostawia Cię z oprogramowaniem, które się nie rozwija.

Czy mogę dać dostęp do panelu pracownikowi bez ryzyka?

Tak i to jest jeden z ważniejszych argumentów za tym podejściem. Konto redaktora widzi tylko treść, nie widzi ustawień motywu ani wtyczek. W builderze granica jest bardziej płynna, bo edycja układu i edycja treści to często ten sam ekran.

Podsumowanie

Warstwa pól to sposób na rozdzielenie dwóch rzeczy, które w page builderach są sklejone: tego, co na stronie jest napisane, i tego, jak strona wygląda. Klient dostaje pełną kontrolę nad pierwszym i zero możliwości popsucia drugiego. Koszt to jeden, dwa dni pracy przy projekcie. Zysk to spokój przez kolejne lata i brak faktur za poprawianie literówek.

Jeśli masz stronę, w której boisz się cokolwiek zmienić, to nie jest Twoja wina. To znak, że warstwy treści nikt nie zaprojektował.