Jak ponownie otagować stare wpisy w wielu językach w WordPressie za pomocą AI Codex

Niedawno stanąłem przed nowym dla mnie wyzwaniem: jak dodać nowy tag — w moim przypadku „ science fiction” — do wszystkich artykułów, zarówno po hiszpańsku, jak i w pozostałych językach. 

Czyli prawie 3.000 artykułów, które trzeba było:

• Przeanalizować, aby sprawdzić, do których tag faktycznie pasuje.
• Dodać każdemu tag w odpowiednim języku bez usuwania pozostałych tagów.
• Sprawdzić, czy wszystko poszło dobrze.

Utworzenie tagu w każdym języku nie było żadnym problemem przy moich własnych rozwiązaniach. Problemem było otagowanie tylko tych starych artykułów, które rzeczywiście powinny go mieć.

Można to oczywiście zrobić ręcznie, ale po przejrzeniu treści zostałem z listą 12 artykułów po hiszpańsku. To oznacza, że ponieważ strona ma tłumaczenia na dziesięć języków, musiałem otagować łącznie 120 wpisów.

A wyszukiwanie każdego wpisu w jego języku, otwieranie go i dodawanie tagu 120 razy z rzędu zupełnie mi się nie uśmiechało.

Uznałem więc, że to całkiem odpowiednie zadanie dla Codex.

Poza tym chciałem wykorzystać ten dość prosty przypadek jako podstawę czegoś znacznie bardziej ogólnego: automatycznego wprowadzania zmian w wielu artykułach, ale bez pozwalania agentowi na samodzielne i chaotyczne modyfikowanie wszystkiego.

Dokładnie to wyjaśniam w tym poradniku.

Cel

Prosty: dodać określony tag do zamkniętej listy konkretnych wpisów WordPress.

W tym odpowiednie tłumaczenie tego tagu dla każdej wersji językowej artykułu, z użyciem Polylang, czyli wielojęzycznego pluginu, którego używam.

I nie będziemy robić tego na żywioł, tylko z kilkoma zabezpieczeniami:

• Będziemy pracować na zamkniętej liście artykułów.
• Najpierw sprawdzimy, co Codex zamierza zmienić.
• Nie będziemy automatycznie tworzyć nowych tagów.
• Zachowamy wszystkie tagi, które każdy wpis już ma.
• Przed zapisaniem zmian wykonamy symulację.
• Po wszystkim ponownie sprawdzimy WordPress, aby zweryfikować wynik.

Twój przypadek nie musi być identyczny z moim. Wystarczy, że chcesz zmienić coś w konkretnej serii wpisów WordPress, co ręcznie zajęłoby ci sporo czasu.

Ja używam Codex, ale możesz przejść przez ten sam proces, jeśli wolisz Claude Code lub Antigravity. Zmienia się narzędzie, nie kroki.

Krok 1. Utwórz tag przed rozpoczęciem

Najpierw tag, który chcesz zastosować, musi już istnieć w WordPressie.

Warto zrobić to ręcznie, bo nie chcę, aby Codex decydował, jak ma być zorganizowana taksonomia strony. Chcemy tylko, żeby znalazł coś, co już istnieje i przypisał to do określonych wpisów.

W WordPressie, jak wiesz, możesz zrobić to tutaj:

Wpisy > Tagi

Jeśli twoja strona ma tylko jeden język, praktycznie kończysz ten krok.

Jeśli używasz Polylang (wersji Pro lub własnych rozszerzeń ponad nim, jak u mnie), utwórz też tłumaczenia tagu i sprawdź, czy są poprawnie powiązane.

Na przykład u mnie wyglądało to tak:

• Ciencia Ficción.
• Science Fiction.
• Science-fiction.
• Science-Fiction.
• Fantascienza.
• …

I tak dalej.

WordPress zapisuje je wewnętrznie jako różne termy (tagi), a każdy z nich ma własne ID. To będzie ważne później.

Mała uwaga: mam własny plugin, który automatycznie tworzy je we wszystkich językach, ale ty prawdopodobnie będziesz musiał tworzyć je ręcznie, po jednym na każdy język.

Prompt do sprawdzenia tagów

Gdy już je utworzysz, możesz poprosić Codex, aby je odnalazł:

Chcę dodać istniejący tag do kilku wpisów WordPress.

Główny tag to:

[NAZWA TAGU]

Na razie nie modyfikuj żadnych danych.

Znajdź tag w WordPressie i, jeśli strona używa Polylang, wszystkie jego tłumaczenia.

Zwróć dla każdego języka:

– język;

– nazwę tagu;

– slug;

– term ID.

Nie twórz nowych tagów.

Jeśli brakuje jakiegoś tłumaczenia, są duplikaty lub istnieje jakakolwiek niejednoznaczność, zatrzymaj się i mnie o tym poinformuj.

Ten term ID to po prostu numer, którym WordPress wewnętrznie identyfikuje ten tag. Najważniejsze, aby Codex wiedział, które ID odpowiada każdemu językowi.

Krok 2. Przygotuj zamkniętą listę artykułów

Teraz musimy zdecydować, które wpisy chcemy zmodyfikować.

Tutaj radzę nie dawać agentowi zbyt dużej swobody.

Moglibyśmy poprosić:

Znajdź wszystkie artykuły związane z science fiction i dodaj im tag.

Ale wtedy mieszalibyśmy dwa bardzo różne zadania:

1. Redakcyjne decydowanie, które treści powinny dostać tag.
2. Wykonanie tej samej zmiany 20, 100 lub 500 razy w WordPressie.

Wolę rozdzielić te dwie rzeczy, aby kontrolować każdy krok.

Listę możesz przygotować ręcznie, jeśli liczba artykułów nie jest bardzo duża.

Możesz też użyć ChatGPT lub Codex, aby pomóc sobie znaleźć kandydatów.

W moim przypadku skala była duża, więc przekazałem trzy sitemap’y artykułów i poprosiłem ChatGPT, aby na podstawie URL zaproponował kandydatów.

Niezależnie od tego, jak to zrobisz, przed jakąkolwiek modyfikacją powinieneś mieć konkretną listę artykułów.

Na przykład:

• Blade Runner: recenzja i analiza.
• Najlepsze komiksy science fiction.
• Akira: manga i film.
• El Eternauta: recenzja serialu.
• …

Jak mówiłem, ostatecznie miałem 12 artykułów na język, po usunięciu kilku kandydatów, których ChatGPT uznał za właściwych, a ja nie.

Prompt do przygotowania zakresu pracy

Gdy masz już listę, podaj Codexowi to:

Przekażę ci zamkniętą listę artykułów WordPress.

Pracuj wyłącznie na tych artykułach.

Nie dodawaj innych treści, nawet jeśli uważasz, że również mogłyby pasować do tagu.

Lista:

[WKLEJ TUTAJ TYTUŁY LUB URL]

Na razie nie wprowadzaj żadnych zmian.

Znajdź każdy wpis i zwróć:

– tytuł;

– URL;

– post ID;

– status;

– język.

Jeśli któregoś nie da się jednoznacznie zidentyfikować, zatrzymaj się i go wskaż.

W ten sposób mamy już zdefiniowane oba końce operacji:

1. Które wpisy chcemy otagować
2. Jaki tag chcemy dodać.

Krok 3. Skonfiguruj dostęp Codex do WordPressa

Aby odczytywać określone właściwości WordPressa, a przede wszystkim modyfikować wpisy, Codex musi się uwierzytelnić.

Są różne metody, mniej lub bardziej bezpieczne. Dość wygodną opcją jest użycie WordPress Application Password.

To nie jest zwykłe hasło do panelu. To dodatkowe hasło stworzone specjalnie po to, aby aplikacja mogła łączyć się z WordPressem przez REST API. 

Tak jak możesz je utworzyć, możesz je w każdej chwili unieważnić bez zmiany zwykłego hasła.

Tworzy się je tutaj:

Użytkownicy > Profil > Hasła aplikacji

Nadaj mu nazwę, po której później je rozpoznasz, na przykład “Codex”.

WordPress wygeneruje hasło.

Jak przekazać hasło do Codex

Nie wklejaj hasła bezpośrednio do promptu

Mogłoby zadziałać, ale wysyłanie haseł do chmury nie jest dobrym nawykiem.

Najlepiej przechowywać je lokalnie jako zmienną środowiskową albo w pliku .env który nie jest wysyłany do repozytorium, jeśli pracujesz z Git.

Na przykład możesz zapisać plik .env zawierający tylko te trzy linie:

WP_URL=https://tudominio.com

WP_USERNAME=tu_usuario

WP_APP_PASSWORD=tu_application_password

Zapisz go w C:UsersTU_USUARIO_WINDOWS.codex.env

I dodaj .env do .gitignore, żeby nie był wysyłany.

Chodzi o to, aby Codex mógł korzystać z danych dostępowych bez konieczności ciągłego ich wyświetlania lub kopiowania.

Po utworzeniu odpowiedniego pliku musisz zamknąć Codex i uruchomić go ponownie, aby go odczytał.

Dwie ważne rzeczy: 

1. Nazwa użytkownika WordPress nie musi być taka sama jak publiczna nazwa wyświetlana jako autor. W pliku wpisz faktyczną nazwę użytkownika.
2. Klucz generowany przez WordPress zawiera spacje. Usuń je podczas zapisywania w .env. Inaczej nie zadziała.

Prompt do tej części

Po poprzednim kroku podaj Codexowi ten prompt:

Użyj danych dostępowych WordPress dostępnych w lokalnych zmiennych środowiskowych.

Nie pokazuj, nie drukuj ani nie kopiuj haseł, tokenów ani innych sekretów w wyniku.

Jeszcze nie modyfikuj żadnych treści.

Sprawdź wyłącznie, czy wymagane zmienne są dostępne.

Dzięki temu dowiesz się, czy zostały poprawnie odczytane, co jest niezbędne przed przejściem dalej.

Krok 4. Sprawdź, czy Codex może się połączyć

Następny krok to sprawdzenie, czy połączenie działa.

REST API to w praktyce interfejs, przez który Codex może pytać WordPress o rzeczy takie jak Jakie tagi ma ten wpis? albo Dodaj ten tag i zapisz artykuł.

Na tym etapie chcemy zrobić tylko pierwszą rzecz. Poproś więc o zapytanie tylko do odczytu:

Sprawdź uwierzytelnienie wobec WordPress REST API.

Wykonuj wyłącznie żądania GET.

Potwierdź:

– że połączenie działa;

– który użytkownik WordPress jest uwierzytelniony;

– że ten użytkownik ma uprawnienia do edytowania wpisów, z którymi będziemy pracować.

Jeśli występuje jakikolwiek błąd uwierzytelnienia lub uprawnień, zatrzymaj się.

Nie wykonuj żądań zapisu.

Jeśli wszystko jest w porządku, mamy dostęp. Jeśli otrzymasz błąd 401, zwykle trzeba sprawdzić dane dostępowe.

Krok 5. Znajdź tłumaczenia każdego wpisu

Ten krok jest potrzebny tylko wtedy, gdy masz stronę wielojęzyczną.

Jeśli używasz Polylang, nie chcemy, aby Codex szukał tłumaczeń przez porównywanie tytułów, ponieważ tytuł może bardzo różnić się między językami.

Chcemy, aby używał relacji tłumaczeń już istniejących w WordPress/Polylang.

Zaczynamy od każdego oryginalnego artykułu i odnajdujemy jego wersje językowe.

Prompt

Opierając się wyłącznie na wpisach z zatwierdzonej listy, znajdź ich tłumaczenia za pomocą relacji Polylang.

Nie wyszukuj tłumaczeń na podstawie podobieństwa tytułu.

Dla każdego artykułu zwróć:

– oryginalny wpis;

– język;

– tytuł tłumaczenia;

– post ID;

– URL.

Strona używa tych języków:

[LISTA JĘZYKÓW]

Każdy artykuł powinien mieć:

[LICZBA WERSJI]

wersji łącznie.

Jeśli brakuje jakiegoś tłumaczenia albo znajdziesz niespójną relację, zatrzymaj się i niczego nie modyfikuj.

Tu mamy bardzo prostą kontrolę, którą warto wykonać.

Jeśli masz 25 artykułów × 5 języków = 125 wpisów Codex powinien znaleźć dokładnie 125.

Jeśli znajdzie 124, nie powinien kontynuować.

Krok 6. Wykonaj pełny dry run

Teraz mamy wystarczająco dużo informacji, aby zbudować właściwą operację, ale nadal jej nie uruchamiamy.

Najpierw wykonamy dry run, czyli po prostu symulację tego, co wydarzyłoby się po zezwoleniu na zmiany.

Chcemy, aby Codex zbudował tabelę łączącą wpis > język > odpowiedni tag > obecny status.

Prompt

Wykonaj teraz pełny dry run operacji.

Nie wykonuj żądań POST, PUT, PATCH ani DELETE.

Dla każdego wpisu z zatwierdzonej listy:

1. Pobierz jego aktualne tagi.

2. Zidentyfikuj język wpisu.

3. Znajdź tłumaczenie nowego tagu odpowiadające dokładnie temu samemu językowi.

4. Pobierz term ID tego tagu.

5. Sprawdź, czy ten term ID jest już przypisany do wpisu.

6. Oblicz, jak wyglądałaby końcowa tablica tagów po dodaniu go, zachowując wszystkie istniejące term IDs.

Relacja musi zawsze wyglądać tak:

wpis w języku X → tag w języku X → term ID tego tagu.

Nigdy nie przypisuj term ID hiszpańskiego tagu do wpisu w innym języku i nie używaj tagu, którego język nie odpowiada dokładnie językowi wpisu.

Zwróć tabelę zawierającą:

– post ID;

– język wpisu;

– tytuł;

– aktualne tagi;

– nazwę tagu odpowiadającego temu językowi;

– język tagu;

– term ID, który należałoby dodać;

– czy już jest obecny;

– przewidywane końcowe tagi.

Wyraźnie sprawdź, czy język wpisu i język tagu zgadzają się we wszystkich przypadkach.

Jeśli znajdziesz wpis, dla którego nie możesz jednoznacznie zidentyfikować tagu w tym samym języku, jeśli brakuje tłumaczenia tagu albo język wpisu i tagu nie są zgodne, zatrzymaj się i niczego nie modyfikuj.

Na końcu podaj:

– łączną liczbę wpisów;

– wpisy wymagające modyfikacji;

– wpisy, które już zawierają tag;

– błędy lub niespójności.

Jeszcze niczego nie zapisuj.

Ten krok ma dwie zalety.

Pierwsza jest oczywista: możemy dokładnie zobaczyć, co Codex zamierza zrobić.

Druga jest taka, że znajdziemy wpisy, które już mają tag.

Tych artykułów nie trzeba ponownie modyfikować.

W moim przypadku było 120 wpisów, ale 2 były już poprawnie otagowane (zrobiłem to wcześniej ręcznie).

Krok 7. Sprawdź, czy żadne tagi nie zostaną usunięte

Na ten punkt zwróciłbym największą uwagę.

Wyobraź sobie, że artykuł ma już takie tagi:

• Bitcoin.
• Inwestycje.
• Tutorial.

A chcemy dodać “Podatki”.

Oczywiście oczekiwany wynik to artykuł z wszystkimi czterema tagami, a nie tylko z Podatkami.

To wydaje się oczywiste, ale gdy pracujesz przez REST API, musisz pamiętać, że pole tags reprezentuje pełny zestaw tagów, które wpis powinien mieć.

Dlatego Codex musi najpierw odczytać istniejące ID, dodać nowe, a potem wysłać cały zestaw.

Nie chcemy zastępować, chcemy dodawać.

Możesz wzmocnić to osobnym promptem:

Przed wykonaniem zmian sprawdź tę zasadę:

NIGDY nie zastępuj obecnych tagów wpisu wyłącznie nowym tagiem.

Dla każdego wpisu:

1. Odczytaj bieżącą tablicę term IDs.

2. Zachowaj wszystkie istniejące IDs.

3. Sprawdź, czy nowy term ID już istnieje.

4. Jeśli nie istnieje, dodaj go do tablicy.

5. Nie usuwaj ani nie modyfikuj żadnego innego term ID.

Pokaż mi każdy przypadek, w którym nie możesz zagwarantować tej operacji.

Jeszcze niczego nie zapisuj.

Jeśli automatyzujesz taką operację, nie pomijałbym tej kontroli.

Krok 8. Ponownie zweryfikuj wszystko tuż przed modyfikacją WordPressa

Mamy już zatwierdzony dry run. Moglibyśmy od razu wykonać operację, ale prawie nic nie kosztuje ponowne odczytanie WordPressa tuż przed zapisem.

Powód jest prosty: stan wpisu mógł się zmienić między jednym zapytaniem a drugim. Być może sam edytowałeś go w różne dni albo zrobił to ktoś inny. Chcemy mieć pewność, że Codex pracuje na aktualnej wersji.

Prompt

Wykonaj ponowną walidację bezpośrednio przed wykonaniem zmian.

Ponownie odczytaj WordPress i potwierdź:

– że wszystkie planowane wpisy nadal istnieją;

– że relacje tłumaczeń się nie zmieniły;

– że term IDs tagu nadal są prawidłowe;

– że aktualne tagi odpowiadają stanowi, który zamierzasz zmodyfikować.

Jeśli istnieje jakakolwiek różnica względem dry run, zatrzymaj się.

Jeśli wszystko się zgadza, podaj:

– łączną liczbę wpisów;

– wymagane modyfikacje;

– wpisy, które już są poprawne.

Nie wykonuj jeszcze zmian, dopóki nie dam ci zgody.

W ten sposób znacznie zmniejszamy ryzyko.

Krok 9. Wykonaj modyfikację

Jeśli wszystko powyżej jest OK, możemy teraz zezwolić na zapis.

Na tym etapie warto bardzo precyzyjnie określić, co może, a czego nie może zmienić.

Prompt

Zezwalam na wykonanie zmian.

Modyfikuj wyłącznie wpisy znajdujące się na zatwierdzonej liście.

Dla każdego wpisu:

1. Odczytaj jego aktualne tagi.

2. Zidentyfikuj język wpisu.

3. Użyj wyłącznie tłumaczenia nowego tagu, którego język dokładnie odpowiada językowi tego wpisu.

4. Pobierz term ID tego tagu.

5. Sprawdź, czy ten term ID już jest obecny.

6. Jeśli go nie ma, dodaj go do aktualnej tablicy tagów.

7. Zachowaj wszystkie pozostałe istniejące term IDs.

8. Zapisz całą wynikową tablicę.

Relacja musi zawsze wyglądać tak:

wpis w języku X → tag w języku X → term ID tego tagu.

Nigdy nie przypisuj term ID hiszpańskiego tagu do wpisu w innym języku i nie używaj tagu, którego język nie odpowiada dokładnie językowi wpisu.

Jeśli dla dowolnego wpisu nie możesz jednoznacznie zidentyfikować tagu w tym samym języku, jeśli brakuje tłumaczenia tagu albo język wpisu i tagu nie są zgodne, nie modyfikuj tego wpisu i zapisz błąd.

NIE modyfikuj:

– tytułu;

– treści;

– excerpt;

– slugu;

– kategorii;

– autora;

– daty;

– statusu;

– obrazka wyróżniającego;

– pól ACF;

– SEO;

– żadnych innych danych wpisu.

Nie modyfikuj wpisów spoza zatwierdzonej listy.

Zapisuj dla każdej operacji:

– post ID;

– język wpisu;

– nazwę przypisanego tagu;

– język tagu;

– dodany term ID;

– tagi przed;

– tagi po;

– kod odpowiedzi WordPress;

– wynik.

Jeśli operacja się nie powiedzie, zapisz błąd i nie próbuj go naprawiać przez modyfikowanie innych pól.

Teraz Codex wykona potrzebne żądania do WordPressa.

Ale została nam jeszcze jedna kontrola.

Krok 10. Ponownie odczytaj wszystkie wpisy

Poprawna odpowiedź API oznacza, że WordPress zaakceptował żądanie.

Jeśli jednak pracujemy z dziesiątkami lub setkami artykułów, warto sprawdzić stan końcowy, zamiast po prostu zakładać, że wszystko poszło dobrze.

Robimy więc kolejną serię zapytań tylko do odczytu.

Prompt

Po zakończeniu modyfikacji wykonaj niezależną weryfikację za pomocą nowych żądań GET.

Dla każdego wpisu z listy sprawdź:

1. Czy zawiera term ID nowego tagu odpowiadającego jego językowi.

2. Czy zachowuje wszystkie term IDs, które miał wcześniej.

3. Czy nie dodano żadnego nieoczekiwanego tagu.

4. Czy nie zmodyfikowano żadnego wpisu spoza listy.

Zwróć końcowe podsumowanie zawierające:

– sprawdzone wpisy;

– wykonane modyfikacje;

– wpisy, które już były poprawnie otagowane;

– błędy REST;

– utracone wcześniejsze tagi;

– wpisy nieoczekiwanie zmodyfikowane;

– końcowe rozbieżności.

Uznaj zadanie za zakończone tylko wtedy, gdy występuje 0 rozbieżności.

Na tym kończymy proces.

Nie tylko wykonaliśmy zmiany, ale też sprawdziliśmy co faktycznie zostało poprawnie zapisane w WordPressie.

Wnioski

Po pierwsze, przy kilku wpisach prawdopodobnie nadal szybciej będzie zrobić to ręcznie. Skala zmienia się jednak bardzo szybko, zwłaszcza przy wielu językach:

• 10 artykułów × 10 języków = 100 wpisów
• 30 artykułów × 10 języków = 300 wpisów
• 50 artykułów × 10 języków = 500 wpisów

W tym momencie nie chodzi już tylko o oszczędzanie kliknięć, ale przede wszystkim o ograniczenie błędów.

Najważniejsza idea, którą chcę, żebyś z tego wyniósł, bo uważam ją za naprawdę przydatną, jest taka: Codex nie decyduje swobodnie i nie modyfikuje samodzielnie twojego WordPressa:

• Najpierw buduje system.
• Potem symuluje.
• Następnie ponownie waliduje.
• Dopiero wtedy zapisuje.
• A na końcu jeszcze raz wszystko sprawdza.

Przy masowym utrzymaniu redakcyjnym wydaje mi się to znacznie rozsądniejszym sposobem korzystania z agentów takich jak Codex.

Co więcej, mam już w głowie kolejną zmianę obejmującą ponad 500 wpisów, którą planowałem zrobić ręcznie przez SQL. 

Po przetestowaniu tej metody mam jasność, że jest dużo lepsza i znacząco zmniejsza prawdopodobieństwo błędów.

To była droga w jedną stronę.