Jak podłączyliśmy Claude do produkcyjnej Joomli

Czym to nie jest

Zacznijmy od tego, czego w tej historii nie ma — inaczej łatwo uznać, że mowa o kolejnej wtyczce z przyciskiem „wygeneruj tekst".

To nie wtyczka do CMS-a. To nie serwis, do którego wrzuca się słowa kluczowe i dostaje artykuły. I to nie autopilot: żadna zmiana nie trafia na stronę bez człowieka, który powiedział, co dokładnie ma zostać zrobione. Asystent pracuje tu jak podwykonawca z dostępem do strony — szybki, drobiazgowy i całkowicie nieobrażalny, ale podwykonawca, a nie właściciel.

Pięć kanałów dostępu i po co ich aż tyle

Pierwsze odkrycie: jeden sposób dotarcia do strony nie wystarcza. Każdy kolejny kanał pojawiał się wtedy, gdy poprzedni trafiał na ścianę.

• Konektor MCP. Warstwa między asystentem a standardowym API Joomli: około dwustu pięćdziesięciu operacji — artykuły, kategorie, menu, moduły, tagi, pliki mediów. Podstawowy kanał roboczy.
• Standardowe API bezpośrednio. Gdy konektor czegoś nie potrafi. Na przykład metatagi pozycji menu leżą wewnątrz pola parametrów i zapisać je da się wyłącznie bezpośrednim żądaniem.
• Baza danych. Odczyt — stale, punktowy zapis — rzadko i świadomie. Są rzeczy, które API po cichu odfiltrowuje: blok danych strukturalnych w treści artykułu wycina, odpowiadając „sukces".
• System plików hostingu. Zamontowany jako dysk sieciowy. Szablon, robots.txt, logi serwera, źródła wtyczek. To właśnie czytanie kodu źródłowego Joomli kilka razy dawało odpowiedź szybciej niż szukanie w dokumentacji.
• Prawdziwa przeglądarka z otwartym panelem. Do tego, czego w API nie ma w ogóle. Dziś przydało się dwa razy: wyczyścić pamięć podręczną i zapisać ponownie ustawienia komponentu, bez czego parametr wpisany wprost do bazy nie działał.

Dlaczego jeden kanał nie wystarcza — konkretny przypadek

Dzisiejsze zadanie: usunąć identyfikator liczbowy z adresów artykułów, żeby zamiast /pl/blog/94-japanese-keyword-hack otwierało się /pl/blog/japanese-keyword-hack.

Przez API ustawienie jest niedostępne: na zewnątrz wystawianych jest tylko dwadzieścia jeden parametrów i tego wśród nich nie ma. Wpisaliśmy wartość wprost do bazy — i nic się nie zmieniło: adresy bez identyfikatora dalej zwracały 404. Pełne czyszczenie pamięci podręcznej też nie pomogło. Zadziałało dopiero po ponownym zapisaniu ustawień komponentu z panelu w przeglądarce: ustawienia rozszerzeń żyją osobno od zwykłej pamięci podręcznej.

Trzy kanały, żeby przestawić jeden przełącznik. Za to teraz jest to zapisane w pamięci projektu i następnym razem zadanie zajmie minutę.

Pamięć — bez niej całość jest bezużyteczna drugiego dnia

Model językowy nie pamięta wczoraj. Jeśli każdą sesję zaczynać od zera, asystent będzie od nowa ustalał, jaki identyfikator ma artykuł, gdzie leży szablon i dlaczego nie wolno zapisywać stylu bez listy podstron. Za trzecim razem przestaje się to opłacać.

Dlatego wiedza o projekcie leży w plikach obok asystenta:

• Mapa serwisu — pięć i pół tysiąca wierszy: identyfikatory wszystkich artykułów, pozycji menu, kategorii, stylów szablonu, modułów. Nie „mniej więcej", tylko dokładne wartości sprawdzone na żywej stronie.
• Podręcznik API — działające przepisy i pola obowiązkowe: co trzeba przesłać, żeby żądanie nie skasowało sąsiednich danych.
• Wymagania wobec tekstów — kim jest czytelnik, jakim językiem z nim rozmawiać, jakie zwroty są zakazane.
• Pięćdziesiąt dwie notatki o tym, co już się zdarzyło: incydenty, ustalone przyczyny, podjęte decyzje.

To jest główna wartość, która się kumuluje. Model jest wymienny, mapa projektu — nie.

Bezpieczniki: historia o czterdziestu sześciu przypisaniach

Dwudziestego pierwszego sierpnia zwykły zapis stylu szablonu przez API po cichu odpiął od niego czterdzieści sześć podstron językowych z sześćdziesięciu jeden. Odpowiedź serwera: 200 OK, żadnych błędów, strona wizualnie cała, a połowa podstron straciła oprawę.

Przyczyna tkwiła w budowie Joomli: lista przypisanych podstron jest częścią formularza stylu, więc przy zapisie system najpierw zeruje przypisania, a potem ustawia je na nowo według tego, co przyszło w żądaniu. Nie wysłałeś listy — przypisania zniknęły.

Wniosek nie brzmiał „na przyszłość być uważniejszym", tylko był techniczny: powstał moduł, który blokuje taki zapis, zanim ten się wykona. Od tego czasu ten błąd jest po prostu niemożliwy. To ważna zasada: każda kosztowna pomyłka ma się zamieniać w bezpiecznik, a nie w przypomnienie.

Jak wygląda dzień pracy

Dzisiejszy, bez upiększeń. Rano komputer wstał po awaryjnym wyłączeniu z poprzedniego wieczoru i wszystkie wczorajsze sesje okazały się martwe. Odtworzenie kontekstu zajęło jakieś dziesięć minut: z dzienników systemowych wynikało, co się stało, a niedokończona praca znalazła się w plikach.

Dalej po kolei: dokończone trzy tłumaczenia rozpoczętego wczoraj artykułu, włączone adresy bez identyfikatorów z kontrolnym przebiegiem sześćdziesięciu adresów z mapy strony, napisane i opublikowane cztery nowe artykuły, każdy w czterech językach. Szesnaście tekstów, każdy z własnymi metatagami, danymi strukturalnymi i powiązaniami językowymi. Do tego znaleziony i naprawiony błędny link wewnętrzny, który trafił do już opublikowanego materiału.

Sprawdzenie wyniku to nie „serwer odpowiedział 200", tylko żywa strona i walidator danych strukturalnych. Na wszystkich szesnastu artykułach: zero błędów, zero ostrzeżeń.

Co naprawdę przyspiesza

• Powtarzalna praca w kilku językach. Cztery wersje językowe z poprawnymi powiązaniami i znacznikami to dokładnie to miejsce, w którym człowiek myli się ze zmęczenia, a maszyna nie.
• Sprawdzenia. Przejechać sześćdziesiąt adresów przed zmianą i po niej, porównać kody odpowiedzi, znaleźć rozbieżność — minuty zamiast godziny.
• Diagnostyka. Przeczytać źródło wtyczki, znaleźć potrzebny parametr, sprawdzić logi serwera, zestawić z bazą. Tu różnica w tempie wobec pracy ręcznej jest wielokrotna.
• Analiza incydentów. We wrześniu czyściliśmy u klienta zainfekowaną stronę: siedemset siedemdziesiąt siedem obcych plików, najstarsza furtka z grudnia 2022 roku. Znalezienie i usunięcie tego ręcznie to tygodnie.

Czego nie przyspiesza

Tu trzeba być uczciwym, inaczej omówienie zamienia się w reklamę.

Decyzje. Co pisać, jakim tonem, jaka cena, czy w ogóle brać się za temat — to nadal człowiek. Asystent świetnie wykonuje i słabo decyduje.

Smak. Projekt graficzny, kompozycja strony, wrażenie „wygląda tanio albo drogo" — to nie jego mocna strona. Składa siatkę według reguł, ale reguły podaje człowiek.

Odpowiedzialność. Strona jest produkcyjna, zmiany widać od razu, automatycznych migawek nie ma. Każda poprawka to poprawka na żywym organizmie. Dlatego kolejność jest niezmienna: najpierw odczytać stan bieżący, potem zapisać, potem sprawdzić na żywej stronie.

Trzy pułapki, które kosztowały czas

Najbardziej przydatne okazały się nie sukcesy, tylko miejsca, w których wszystko wyglądało na udane, a nie działało.

• Data ucieka o dwie godziny. Każda aktualizacja artykułu przez API cofała czas utworzenia o dwie godziny — system brał zapisaną wartość za czas lokalny i przeliczał ją na UTC po raz drugi. Cztery poprawki z rzędu przesunęły datę o osiem godzin. Leczy się przesyłaniem czasu w formacie lokalnym przy każdym żądaniu.
• Odpowiedź „sukces" bez efektu. Blok danych strukturalnych w treści artykułu wycina filtr przy zapisie przez API. Odpowiedź 200, błędów brak, znaczników brak. Sprawdzać trzeba nie odpowiedź, tylko pole w bazie.
• Pamięć podręczna ukrywa zmianę. Rano włączono na stronie buforowanie na dziesięć godzin. Zmiana się zapisała, strona oddawała stare i pierwszy wniosek był błędny — uznałem, że problem tkwi w szablonie. Prawidłowy wniosek: „nie widać poprawki" oznacza teraz pamięć podręczną, dopóki nie udowodni się czegoś innego.

Czy warto powtarzać to u siebie

Uczciwa odpowiedź: zależy, ile masz pracy powtarzalnej.

Jeśli strona ma pięć podstron w jednym języku i zmienia się raz na kwartał — nie warto. Konfiguracja zajmie więcej czasu, niż oszczędzi.

Układ zwraca się tam, gdzie jest objętość i powtarzalność: kilka języków, regularne publikacje, katalog, integracje, cykliczne kontrole. I tam, gdzie ktoś w firmie jest gotów formułować zadania na piśmie i sprawdzać wynik. Bez drugiego warunku wyjdzie generator wiarygodnie wyglądających śmieci.

Jeszcze jedna obserwacja: prawie cała wartość okazała się nie w modelu, tylko w oprzyrządowaniu — w dostępach, podręcznikach, bezpiecznikach i zgromadzonej pamięci projektu. Model da się wymienić na kolejną wersję w jeden wieczór. Półtora miesiąca zebranej wiedzy o konkretnej stronie wymienić się nie da.

W skrócie

Pięć kanałów dostępu do strony, bo jeden nie wystarcza. Mapa projektu w plikach, bo model nie pamięta wczoraj. Bezpieczniki na kosztownych pomyłkach, bo „być uważniejszym" nie działa. Sprawdzenie na żywej stronie, a nie po odpowiedzi serwera. Wynik: dziewiętnaście artykułów w czterech językach w jeden dzień i analiza zainfekowanej strony w dobę zamiast tygodni.

I to, co się nie zmienia: decyduje wciąż człowiek, a strona pozostaje produkcyjna, gdzie każda poprawka jest od razu widoczna dla klientów. Jeśli chcesz omówić, czy da się to zastosować u ciebie — napisz do nas. Jak w ogóle pracujemy nad stronami, opisano na stronie Etapy pracy.

Victor Parhimchik, założyciel studia webowego IT Deweloper