Hur du taggar om gamla inlägg på flera språk i WordPress med Codex AI

För inte så länge sedan ställdes jag inför en ny utmaning: hur man lägger till en ny tagg — i mitt fall ” science fiction” — på alla artiklar, både på spanska och på de andra språken. 

Det vill säga nästan 3 000 artiklar som behövde:

• Analyseras för att se vilka taggen faktiskt passade på.
• Få taggen på rätt språk utan att de övriga taggarna raderades.
• Kontrolleras så att allt hade gått rätt till.

Att skapa taggen på varje språk var inget problem med den speciallösning jag redan har. Problemet var att bara tagga de gamla artiklar som verkligen borde ha den.

Man kan förstås göra det för hand, men efter att ha gått igenom innehållet landade jag på en lista med 12 artiklar på spanska. Eftersom sajten är översatt till tio språk innebar det att jag totalt behövde tagga 120 inlägg.

Och att leta upp varje inlägg på rätt språk, öppna det och lägga till taggen 120 gånger i rad var inget jag direkt såg fram emot.

Då slog det mig att det här var en ganska lämplig uppgift för Codex.

Dessutom ville jag använda det här ganska enkla fallet som grund för något mycket mer generellt: att automatiskt göra ändringar i många artiklar utan att låta agenten ändra saker på eget initiativ och helt fritt.

Det är precis det jag går igenom i den här guiden.

Mål

Enkelt: lägg till en bestämd tagg på en sluten lista med WordPress-inlägg.

Inklusive rätt översättning av taggen för varje språkversion av artikeln, med Polylang, som är det flerspråkiga plugin jag använder.

Och vi ska inte göra det på måfå, utan med några försiktighetsåtgärder:

• Vi arbetar med en sluten lista med artiklar.
• Först kontrollerar vi vad Codex tänker ändra.
• Vi skapar inte nya taggar automatiskt.
• Vi behåller alla taggar som varje inlägg redan har.
• Vi gör en simulering innan vi skriver något.
• Efteråt kontrollerar vi WordPress igen för att verifiera resultatet.

Ditt fall behöver inte vara exakt som mitt. Det räcker att du vill ändra något i en bestämd serie WordPress-inlägg som skulle ta en bra stund att göra manuellt.

Jag använder själv Codex, men processen fungerar på samma sätt om du hellre använder Claude Code eller Antigravity. Verktyget ändras, inte stegen.

Steg 1. Skapa taggen innan du börjar

Det första är att taggen du vill använda redan finns skapad i WordPress.

Det är bäst att göra detta manuellt, eftersom jag inte vill att Codex ska bestämma hur sajtens taxonomi ska organiseras. Vi vill bara att den hittar något som redan finns och tilldelar det till vissa inlägg.

I WordPress kan du, som du vet, göra det via:

Inlägg > Etiketter

Om sajten bara har ett språk är du i princip klar med det här steget.

Om du använder Polylang (Pro-versionen eller egen utveckling ovanpå, som i mitt fall), skapa också taggens översättningar och kontrollera att de är korrekt länkade.

I mitt exempel hade jag till exempel:

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

Och så vidare.

WordPress lagrar dem internt som olika termer (taggar), och var och en får sitt eget ID. Det blir viktigt längre fram.

En notering: jag har ett egenutvecklat plugin som skapar dem automatiskt på alla språk, men du kommer förmodligen behöva skapa dem manuellt, ett språk i taget.

Prompt för att kontrollera taggarna

När du har skapat dem kan du be Codex att hitta dem:

Jag vill lägga till en befintlig tagg på flera WordPress-inlägg.

Huvudtaggen är:

[TAGGENS NAMN]

Ändra inga data ännu.

Hitta taggen i WordPress och, om sajten använder Polylang, alla dess översättningar.

Ge mig följande för varje språk:

– språk;

– taggens namn;

– slug;

– term ID.

Skapa inga nya taggar.

Om någon översättning saknas, om det finns dubbletter eller någon oklarhet, stoppa och säg till.

Ett term ID är helt enkelt numret som WordPress använder för att identifiera taggen internt. Det viktiga är att Codex vet vilket ID som hör till varje språk.

Steg 2. Förbered en sluten lista med artiklar

Nu måste vi bestämma vilka inlägg vi vill ändra.

Här rekommenderar jag att inte ge agenten för stor frihet.

Vi skulle kunna be den:

Hitta alla artiklar som handlar om science fiction och tagga dem.

Men då blandar vi två helt olika uppgifter:

1. Redaktionellt besluta vilket innehåll som ska ha taggen.
2. Göra samma ändring 20, 100 eller 500 gånger i WordPress.

Jag föredrar att separera dem så att jag kan kontrollera varje steg.

Du kan skapa listan manuellt om antalet artiklar inte är särskilt stort.

Du kan också använda ChatGPT eller Codex för att hjälpa dig hitta kandidater.

I mitt fall var mängden stor, så jag gav den mina tre artikel-sitemaps och bad ChatGPT föreslå kandidater utifrån URL:en.

Oavsett hur du gör, bör du ha en konkret lista med artiklar innan du ändrar något.

Till exempel:

• Blade Runner: recension och analys.
• De bästa science fiction-serierna.
• Akira: manga och film.
• El Eternauta: recension av serien.
• …

Som jag sa slutade jag med 12 artiklar per språk, efter att ha tagit bort några kandidater som ChatGPT tyckte passade men som jag inte höll med om.

Prompt för att förbereda arbetsmängden

När du har listan skickar du detta till Codex:

Jag kommer att ge dig en sluten lista med WordPress-artiklar.

Arbeta uteslutande med dessa artiklar.

Lägg inte till annat innehåll även om du tycker att det också skulle kunna passa taggen.

Lista:

[KLISTRA IN TITLARNA ELLER URL:ERNA HÄR]

Gör inga ändringar ännu.

Hitta varje inlägg och returnera:

– titel;

– URL;

– post ID;

– status;

– språk.

Om något inte kan identifieras entydigt, stoppa och markera det.

Nu har vi definierat operationens båda ändar:

1. Vilka inlägg vi vill tagga
2. Vilken tagg vi vill lägga till.

Steg 3. Konfigurera Codex åtkomst till WordPress

För att läsa vissa WordPress-egenskaper och framför allt för att ändra inlägg måste Codex autentisera sig.

Det finns olika sätt, mer eller mindre säkra. Ett ganska smidigt sätt är att använda ett WordPress Application Password.

Det är inte ditt vanliga lösenord till adminpanelen. Det är ett extra lösenord som skapas särskilt för att en applikation ska kunna ansluta till WordPress via REST API. 

Precis som du kan skapa det kan du återkalla det när som helst utan att ändra ditt vanliga lösenord.

Det skapas via:

Användare > Profil > Applikationslösenord

Ge det ett namn som gör det lätt att känna igen senare, till exempel “Codex”.

WordPress genererar då ett lösenord.

Så ger du lösenordet till Codex

Lägg inte lösenordet direkt i prompten

Det skulle kunna fungera, men att skicka dina lösenord till molnet är ingen bra vana.

Det bästa är att lagra det lokalt som en miljövariabel eller i en .env fil som inte laddas upp till repositoryt, om du arbetar med Git.

Du kan till exempel spara en .env-fil med bara dessa tre rader:

WP_URL=https://tudominio.com

WP_USERNAME=tu_usuario

WP_APP_PASSWORD=tu_application_password

Spara den i C:UsersTU_USUARIO_WINDOWS.codex.env

Och lägg till .env i .gitignore så att den inte laddas upp.

Poängen är att Codex kan använda uppgifterna utan att behöva visa eller kopiera dem hela tiden.

När du har skapat filen måste du stänga Codex och öppna det igen så att filen läses in.

Två viktiga saker: 

1. WordPress-användarnamnet behöver inte vara samma som det offentliga namn som visas som författare. Skriv det riktiga användarnamnet i filen.
2. Nyckeln som WordPress genererar innehåller mellanslag. Ta bort dem när du sparar den i .env. Annars fungerar den inte.

Prompt för den här delen

Efter föregående steg ger du Codex den här prompten:

Använd WordPress-uppgifterna som finns i de lokala miljövariablerna.

Visa, skriv ut eller kopiera inte lösenord, tokens eller andra hemligheter i utdata.

Ändra inget innehåll ännu.

Kontrollera bara att de nödvändiga variablerna finns tillgängliga.

På så sätt vet du om Codex har läst in dem korrekt, ett nödvändigt steg innan du fortsätter.

Steg 4. Kontrollera att Codex kan ansluta

Nästa steg är att kontrollera att anslutningen fungerar.

REST API är i princip gränssnittet som gör att Codex kan fråga WordPress saker som Vilka taggar har det här inlägget? eller Lägg till den här taggen och spara artikeln.

Just nu vill vi bara göra det första. Be därför Codex göra en läsfråga:

Kontrollera autentiseringen mot WordPress REST API.

Gör endast GET-anrop.

Bekräfta:

– att anslutningen fungerar;

– vilken WordPress-användare som är autentiserad;

– att användaren har behörighet att redigera de inlägg vi ska arbeta med.

Om det uppstår något autentiserings- eller behörighetsfel, stoppa.

Gör inga skrivanrop.

Om allt är rätt har vi åtkomst. Om du får ett 401-fel behöver du normalt kontrollera uppgifterna.

Steg 5. Hitta översättningarna av varje inlägg

Det här steget behövs bara om du har en flerspråkig.

Om du använder Polylang vill vi inte att Codex hittar översättningar genom att jämföra titlar, eftersom en titel kan skilja sig mycket mellan språk.

Vi vill att den använder de översättningsrelationer som redan finns i WordPress/Polylang.

Vi utgår från varje originalartikel och hittar dess språkversioner.

Prompten

Utgå enbart från inläggen i den godkända listan och hitta deras översättningar med Polylangs relationer.

Sök inte efter översättningar baserat på liknande titlar.

För varje artikel, returnera:

– originalinlägg;

– språk;

– översatt titel;

– post ID;

– URL.

Webbplatsen använder dessa språk:

[LISTA ÖVER SPRÅK]

Varje artikel bör ha:

[ANTAL VERSIONER]

versioner totalt.

Om någon översättning saknas eller du hittar en inkonsekvent relation, stoppa och ändra ingenting.

Här har vi en mycket enkel kontroll som är värd att göra.

Om du har 25 artiklar × 5 språk = 125 inlägg bör Codex hitta exakt 125.

Om den hittar 124 bör den inte fortsätta.

Steg 6. Gör en fullständig dry run

Nu har vi tillräckligt med information för att bygga den riktiga operationen, men vi ska fortfarande inte köra den.

Först gör vi en dry run, som inte är något annat än en simulering av vad som skulle hända om vi tillät ändringarna.

Vi vill att Codex bygger en tabell som kopplar ihop inlägg > språk > motsvarande tagg > aktuell status.

Prompt

Gör nu en fullständig dry run av operationen.

Gör inga POST-, PUT-, PATCH- eller DELETE-anrop.

För varje inlägg i den validerade listan:

1. Hämta dess nuvarande taggar.

2. Identifiera inläggets språk.

3. Hitta översättningen av den nya taggen som exakt motsvarar samma språk.

4. Hämta taggens term ID.

5. Kontrollera om detta term ID redan är tilldelat inlägget.

6. Beräkna hur den slutliga arrayen med taggar skulle se ut efter att den lagts till, med alla befintliga term IDs bevarade.

Relationen ska alltid vara:

inlägg på språk X → tagg på språk X → taggens term ID.

Tilldela aldrig den spanska taggens term ID till ett inlägg på ett annat språk och använd aldrig en tagg vars språk inte exakt motsvarar inläggets språk.

Returnera en tabell med:

– post ID;

– inläggets språk;

– titel;

– nuvarande taggar;

– namnet på taggen som motsvarar det språket;

– taggens språk;

– term ID som skulle behöva läggas till;

– om det redan finns;

– förväntade slutliga taggar.

Kontrollera uttryckligen att inläggets språk och taggens språk överensstämmer i samtliga fall.

Om du hittar ett inlägg där du inte entydigt kan identifiera taggen på samma språk, om en översättning av taggen saknas eller om inläggets och taggens språk inte stämmer överens, stoppa och ändra ingenting.

Ange i slutet:

– totalt antal inlägg;

– inlägg som behöver ändras;

– inlägg som redan innehåller taggen;

– fel eller inkonsekvenser.

Skriv ingenting ännu.

Det här steget har två fördelar.

Den första är uppenbar: vi kan se exakt vad Codex tänker göra.

Den andra är att vi upptäcker inlägg som redan har taggen.

De artiklarna behöver inte ändras igen.

I mitt fall fanns 120 inlägg, men 2 var redan korrekt taggade (det hade jag gjort manuellt).

Steg 7. Kontrollera att inga taggar kommer att raderas

Det här är den punkt jag skulle vara mest uppmärksam på.

Föreställ dig att en artikel redan har dessa taggar:

• Bitcoin.
• Investering.
• Tutorial.

Och vi vill lägga till “Beskattning”.

Resultatet vi vill ha är förstås att artikeln innehåller alla fyra, inte bara Beskattning.

Det låter självklart, men när du arbetar via REST API måste du komma ihåg att fältet tags representerar hela uppsättningen taggar som inlägget ska ha.

Därför måste Codex först läsa de befintliga ID:na, lägga till det nya och sedan skicka hela uppsättningen.

Vi vill inte ersätta, vi vill lägga till.

Du kan förstärka det med en särskild prompt:

Kontrollera den här regeln innan du kör ändringarna:

ERSÄTT ALDRIG inläggets nuvarande taggar med enbart den nya taggen.

För varje inlägg:

1. Läs den nuvarande arrayen med term IDs.

2. Behåll alla befintliga IDs.

3. Kontrollera om det nya term ID redan finns.

4. Om det inte finns, lägg till det i arrayen.

5. Ta inte bort och ändra inte något annat term ID.

Visa mig varje fall där du inte kan garantera denna operation.

Skriv inte ännu.

Om du ska automatisera en sådan här operation skulle jag inte hoppa över den här kontrollen.

Steg 8. Validera allt igen precis innan WordPress ändras

Vi har redan godkänt dry run. Vi skulle kunna köra direkt, men det kostar väldigt lite att läsa WordPress en gång till precis innan vi skriver.

Anledningen är enkel: ett inläggs tillstånd kan ha ändrats mellan två förfrågningar. Kanske har du själv redigerat det olika dagar, eller så har någon annan gjort det. Vi vill vara säkra på att Codex arbetar med den aktuella versionen.

Prompt

Gör en omvalidering omedelbart innan ändringarna körs.

Fråga WordPress igen och bekräfta:

– att alla planerade inlägg fortfarande finns;

– att översättningsrelationerna inte har ändrats;

– att taggens term IDs fortfarande är korrekta;

– att de nuvarande taggarna motsvarar det tillstånd du ska ändra.

Om det finns någon skillnad jämfört med dry run, stoppa.

Om allt stämmer, ange:

– totalt antal inlägg;

– nödvändiga ändringar;

– inlägg som redan är korrekta.

Kör inga ändringar ännu förrän jag ger dig tillstånd.

Så minskar vi risken rejält.

Steg 9. Kör ändringen

Om allt ovan är OK kan vi nu godkänna skrivningen.

Nu är det klokt att vara mycket exakt med vad som får och inte får ändras.

Prompt

Jag godkänner att ändringarna körs.

Ändra uteslutande inläggen i den validerade listan.

För varje inlägg:

1. Läs dess nuvarande taggar.

2. Identifiera inläggets språk.

3. Använd uteslutande översättningen av den nya taggen vars språk exakt motsvarar det inläggets språk.

4. Hämta taggens term ID.

5. Kontrollera om detta term ID redan finns.

6. Om det inte finns, lägg till det i den nuvarande arrayen med taggar.

7. Behåll alla övriga befintliga term IDs.

8. Spara hela den resulterande arrayen.

Relationen ska alltid vara:

inlägg på språk X → tagg på språk X → taggens term ID.

Tilldela aldrig den spanska taggens term ID till ett inlägg på ett annat språk och använd aldrig en tagg vars språk inte exakt motsvarar inläggets språk.

Om du för något inlägg inte entydigt kan identifiera taggen på samma språk, om en översättning av taggen saknas eller om inläggets och taggens språk inte stämmer överens, ändra inte det inlägget och logga felet.

ÄNDRA INTE:

– titel;

– innehåll;

– excerpt;

– slug;

– kategorier;

– författare;

– datum;

– status;

– utvald bild;

– ACF-fält;

– SEO;

– inga andra uppgifter om inlägget.

Ändra inga inlägg utanför den godkända listan.

Logga för varje operation:

– post ID;

– inläggets språk;

– namnet på den tilldelade taggen;

– taggens språk;

– tillagt term ID;

– taggar före;

– taggar efter;

– WordPress svarskod;

– resultat.

Om en operation misslyckas, logga felet och försök inte rätta det genom att ändra andra fält.

Nu kommer Codex att göra de nödvändiga anropen mot WordPress.

Men vi har fortfarande en kontroll kvar.

Steg 10. Läs alla inlägg igen

Ett korrekt API-svar betyder att WordPress har accepterat förfrågan.

Men om vi arbetar med tiotals eller hundratals artiklar är det värt att kontrollera det slutliga tillståndet, i stället för att bara anta att allt gick bra.

Så vi gör en ny omgång läsförfrågningar.

Prompt

När ändringarna är klara, gör en oberoende verifiering med nya GET-anrop.

Kontrollera för varje inlägg i listan:

1. Att det innehåller term ID för den nya taggen som motsvarar dess språk.

2. Att det behåller alla term IDs som det hade tidigare.

3. Att ingen oväntad tagg har lagts till.

4. Att inget inlägg utanför listan har ändrats.

Returnera en slutlig sammanfattning med:

– granskade inlägg;

– genomförda ändringar;

– inlägg som redan var korrekt taggade;

– REST-fel;

– tidigare taggar som gått förlorade;

– oväntat ändrade inlägg;

– slutliga avvikelser.

Anse uppgiften som slutförd endast om det finns 0 avvikelser.

Därmed avslutar vi processen.

Vi har inte bara gjort ändringarna, vi har också kontrollerat vad som faktiskt har sparats korrekt i WordPress.

Slutsatser

Den första är att det för ett fåtal inlägg sannolikt fortfarande går snabbare att göra det manuellt. Men skalan förändras snabbt, särskilt på flerspråkiga sajter:

• 10 artiklar × 10 språk = 100 inlägg
• 30 artiklar × 10 språk = 300 inlägg
• 50 artiklar × 10 språk = 500 inlägg

Då handlar det inte längre bara om att spara klick, utan framför allt om att minska fel.

Idén jag vill att du tar med dig, eftersom jag tycker att den här modellen är genuint användbar, är att Codex inte fritt bestämmer och ändrar din WordPress:

• Först bygger den systemet.
• Sedan simulerar den.
• Därefter validerar den igen.
• Först då skriver den.
• Och när den är klar kontrollerar den allt igen.

För storskaligt redaktionellt underhåll tycker jag att det här är ett mycket vettigare sätt att använda agenter som Codex.

Jag har faktiskt redan helt klart för mig en annan ändring som påverkar fler än 500 inlägg och som jag tänkte göra manuellt med SQL. 

Efter att ha testat den här vägen är det uppenbart för mig att den är mycket bättre och att risken för fel minskar avsevärt.

Det här blev en enkelbiljett.