WordPress powiedział, że jestem offline.
Skłamał.

Ciao! 🇵🇱🇮🇹

18 lipca znajoma napisała, przekonana, że WordPress właśnie zjadł jej pracę.

Nic nie zginęło, tylko komunikat błędu kłamał lepiej niż niejeden prawdziwy problem.

Lecimy z tematem 🚀

Kliknij jeszcze raz

18 lipca znajoma napisała, przekonana, że WordPress właśnie zjadł jej pracę. Dostała komunikat: „Aktualizacja nie powiodła się, ponieważ użytkownik był offline”. Bała się, że tekst, nad którym siedziała, po prostu zniknął.

Sprawdziłem to bez zgadywania. Zalogowałem się na jej konto, wszedłem w historię wersji przez REST API i zobaczyłem coś, czego się nie spodziewałem: jej tekst tam był, cały, z nagłówkiem i podnagłówkiem dokładnie takim, jaki napisała. Problem leżał gdzie indziej. Strona była zbudowana w Elementorze, a Elementor pokazuje odwiedzającym wyłącznie to, co siedzi w jego własnym, osobnym polu w bazie danych, nie to, co widać w standardowym edytorze WordPressa. Jej praca czekała bezpiecznie jako wersja robocza. Publikacja po prostu nie przechodziła, a komunikat o offline nie miał nic wspólnego z prawdziwym internetem.

Zanim cokolwiek kliknąłem, zduplikowałem całą stronę jako osobny szkic. Nie dlatego, że coś wskazywało na ryzyko, tylko dlatego, że samo wytłumaczenie rzadko wystarcza komuś przestraszonemu. Czasem trzeba dać namacalny dowód, że nawet gdyby coś poszło nie tak, jest z czego wrócić.

Kliknąłem „Opublikuj” jeszcze raz. Dokładnie ten sam przycisk, dokładnie ta sama treść. Zadziałało.

Nie zmieniłem nic. Żadnego kodu, żadnej konfiguracji, żadnej poprawki, którą dałoby się opisać w trzech krokach. Ten sam klik, drugi raz, i strona wygląda tak, jak powinna.

To zabawne, bo dokładnie ten sam wzorzec widuję non stop przy pracy z Claude Code. Coś nie działa, wracasz z tą samą prośbą po chwili, bez żadnej zmiany w promptcie, i nagle działa. Nie dlatego, że model zrozumiał coś lepiej za drugim razem. Częściej dlatego, że pierwsza próba trafiła na chwilową usterkę, wygasłą sesję albo zwykły przypadek, a błąd, który to opisuje, brzmi dużo groźniej niż to, co faktycznie się stało. Ufam mu mniej niż powinienem, a i tak wracam po chwili z tym samym pytaniem, licząc, że tym razem się uda.

Najtrudniejsza część dzisiejszej pracy nie była techniczna. Było nią przekonanie kogoś przestraszonego, że strach jest większy niż realny problem.

🛠️ Narzędzie

WordPress REST API

Wbudowany interfejs, przez który można odpytać każdą stronę WordPress o jej prawdziwy stan, bez logowania się do panelu i klikania po ekranach. Używam go zawsze, gdy ktoś mówi mi, że coś zniknęło albo się zepsuło, bo pokazuje twardy dowód zamiast tego, co akurat wyświetla przeglądarka. Tego dnia dzięki niemu zobaczyłem w kilka sekund, że tekst znajomej istnieje w bazie, zanim jeszcze dotknąłem czegokolwiek w interfejsie. Polecam każdemu, kto zarządza cudzą stroną WordPress i chce mieć fakty zamiast domysłów.

developer.wordpress.org/rest-api

🌍 Ze świata

• Newer AI Coding Assistants Are Failing in Insidious Ways. Kiedyś zły kod AI wyglądał źle. Teraz wygląda dobrze i to jest dużo gorsze.

• Developers still don’t trust AI-generated code. Nieufność rośnie razem z jakością, co brzmi jak paradoks, dopóki nie spróbujesz przeczytać cudzego promptu o trzeciej w nocy.

• Revisiting Using AI Coding Assistants: You’re Holding It Wrong Edition. Tytuł żartobliwy, ale teza poważna: większość porażek z AI to porażki procesu, nie modelu.

😄 Na koniec


Dzisiejsza wersja tego mema brzmiała: „Strona nie chce się zaktualizować, zmieńmy nic, kliknijmy Opublikuj jeszcze raz”. Zadziałało.

Jeśli ktoś w Twoim otoczeniu powinien to przeczytać, prześlij mu ten numer. To najlepsza forma wsparcia.