Hvordan retagge gamle innlegg på flere språk i WordPress med Codex AI

For ikke lenge siden støtte jeg på en ny utfordring: hvordan legge til en ny tagg — i mitt tilfelle «science fiction» — i alle artiklene, både på spansk og på de andre språkene. 

Det vil si nesten 3 000 artikler som måtte:

• Analyseres for å se hvilke taggen faktisk passet på.
• Få taggen på riktig språk uten at de øvrige taggene ble slettet.
• Kontrolleres for å se at alt hadde gått bra.

Å opprette taggen på hvert språk var ikke noe problem med spesialutviklingen jeg allerede har. Problemet var å tagge bare de gamle artiklene som faktisk burde ha den.

Det kunne selvsagt gjøres manuelt, men etter å ha gått gjennom innholdet endte jeg med en liste på 12 artikler på spansk. Det betyr at siden nettstedet er oversatt til ti språk, måtte jeg tagge totalt 120 innlegg.

Og å finne hvert innlegg på riktig språk, åpne det og legge til taggen 120 ganger etter hverandre, det fristet ærlig talt ikke.

Så slo det meg at dette var en ganske passende oppgave for Codex.

I tillegg ville jeg bruke dette ganske enkle tilfellet som grunnlag for noe mye mer generelt: å gjøre endringer automatisk i mange artikler, uten å la agenten gjøre endringer på egen hånd og helt fritt.

Det er nettopp det jeg forklarer i denne guiden.

Mål

Enkelt: legg til en bestemt tagg på en lukket liste med WordPress-innlegg.

Inkludert riktig oversettelse av taggen for hver språkversjon av artikkelen, med Polylang, som er flerspråk-pluginen jeg bruker.

Og vi skal ikke gjøre dette på måfå, men med noen forholdsregler:

• Vi jobber ut fra en lukket liste med artikler.
• Først kontrollerer vi hva Codex skal endre.
• Vi oppretter ikke nye tagger automatisk.
• Vi beholder alle taggene hvert innlegg allerede har.
• Vi gjør en simulering før vi skriver noe.
• Etterpå sjekker vi WordPress på nytt for å verifisere resultatet.

Tilfellet ditt trenger ikke være helt likt mitt. Det holder at du vil endre noe i en bestemt serie WordPress-innlegg som ville tatt deg en god stund å gjøre manuelt.

Jeg bruker selv Codex, men prosessen kan følges på akkurat samme måte hvis du heller bruker Claude Code eller Antigravity. Verktøyet endres, ikke trinnene.

Trinn 1. Opprett taggen før du begynner

Det første er å sørge for at taggen du vil bruke allerede er opprettet i WordPress.

Dette bør gjøres manuelt, fordi jeg ikke vil at Codex skal bestemme hvordan taksonomien på nettstedet skal organiseres. Vi vil bare at den skal finne noe som allerede finnes og tilordne det til bestemte innlegg.

I WordPress kan du, som du vet, gjøre dette via:

Innlegg > Stikkord

Hvis nettstedet bare har ett språk, er du praktisk talt ferdig med dette trinnet.

Hvis du bruker Polylang (Pro-versjonen eller egen utvikling oppå den, slik jeg gjør), opprett også oversettelsene av taggen og kontroller at de er koblet riktig.

For eksempel hadde jeg dette i mitt tilfelle:

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

Og så videre.

WordPress lagrer dem internt som ulike termer (tagger), og hver får sin egen ID. Det blir viktig senere.

En kommentar: Jeg har en egenutviklet plugin som oppretter dem automatisk på alle språk, men du må sannsynligvis opprette dem manuelt, ett språk om gangen.

Prompt for å kontrollere taggene

Når du har opprettet dem, kan du be Codex om å finne dem:

Jeg vil legge til en eksisterende tagg på flere WordPress-innlegg.

Hovedtaggen er:

[NAVN PÅ TAGGEN]

Ikke endre noen data ennå.

Finn taggen i WordPress og, hvis nettstedet bruker Polylang, alle oversettelsene.

Returner dette for hvert språk:

– språk;

– navn på taggen;

– slug;

– term ID.

Ikke opprett nye tagger.

Hvis en oversettelse mangler, det finnes duplikater eller noe er uklart, stopp og gi meg beskjed.

Et term ID er ganske enkelt nummeret WordPress bruker til å identifisere taggen internt. Det viktige er at Codex vet hvilken ID som tilhører hvert språk.

Trinn 2. Lag en lukket liste med artikler

Nå må vi bestemme hvilke innlegg vi vil endre.

Her anbefaler jeg å ikke gi agenten for stor frihet.

Vi kunne bedt den:

Finn alle artiklene som handler om science fiction og tagg dem.

Men da ville vi blandet to svært forskjellige oppgaver:

1. Redaksjonelt bestemme hvilket innhold som bør ha taggen.
2. Gjøre den samme endringen 20, 100 eller 500 ganger i WordPress.

Jeg foretrekker å skille de to, slik at jeg kan kontrollere hvert trinn.

Du kan lage listen manuelt hvis antallet artikler ikke er så stort.

Du kan også bruke ChatGPT eller Codex til å hjelpe deg med å finne kandidater.

I mitt tilfelle var volumet stort, så jeg ga den de tre artikkel-sitemapene og ba ChatGPT foreslå kandidater basert på URL-en.

Uansett hvordan du gjør det, bør du ende med en konkret liste over artikler før du endrer noe.

For eksempel:

• Blade Runner: anmeldelse og analyse.
• De beste science fiction-tegneseriene.
• Akira: manga og film.
• El Eternauta: anmeldelse av serien.
• …

Som sagt endte jeg med 12 artikler per språk, etter å ha fjernet noen kandidater ChatGPT mente passet, men som jeg ikke var enig i.

Prompt for å forberede arbeidssettet

Når du har listen, gir du Codex dette:

Jeg kommer til å gi deg en lukket liste med WordPress-artikler.

Arbeid utelukkende med disse artiklene.

Ikke legg til annet innhold selv om du mener at det også kunne passe til taggen.

Liste:

[LIM INN TITLENE ELLER URL-ENE HER]

Ikke gjør noen endringer ennå.

Finn hvert innlegg og returner:

– tittel;

– URL;

– post ID;

– status;

– språk.

Hvis noe ikke kan identifiseres entydig, stopp og marker det.

Med dette har vi definert begge endene av operasjonen:

1. Hvilke innlegg vi vil tagge
2. Hvilken tagg vi vil legge til.

Trinn 3. Konfigurer Codex-tilgang til WordPress

For å lese enkelte WordPress-egenskaper og særlig for å endre innlegg må Codex autentisere seg.

Det finnes ulike måter, mer eller mindre sikre. En ganske praktisk metode er å bruke et WordPress Application Password.

Det er ikke det vanlige passordet ditt til kontrollpanelet. Det er et ekstra passord som opprettes spesielt slik at en applikasjon kan koble seg til WordPress via REST API. 

På samme måte som du kan opprette det, kan du når som helst tilbakekalle det uten å endre det vanlige passordet.

Det opprettes via:

Brukere > Profil > Applikasjonspassord

Gi det et navn som gjør det lett å kjenne igjen senere, for eksempel “Codex”.

WordPress genererer et passord.

Slik gir du passordet til Codex

Ikke legg passordet direkte i prompten

Det kunne fungert, men å sende passordene dine til skyen er ingen god vane.

Det beste er å lagre det lokalt som en miljøvariabel eller i en .env fil som ikke lastes opp til repositoryet, hvis du jobber med Git.

Du kan for eksempel lagre en .env-fil med bare disse tre linjene:

WP_URL=https://tudominio.com

WP_USERNAME=tu_usuario

WP_APP_PASSWORD=tu_application_password

Lagre den i C:UsersTU_USUARIO_WINDOWS.codex.env

Og legg til .env i .gitignore slik at den ikke lastes opp.

Poenget er at Codex kan bruke innloggingsopplysningene uten å måtte vise eller kopiere dem hele tiden.

Når du har opprettet filen, må du lukke Codex og åpne det igjen slik at filen blir lest.

To viktige ting: 

1. WordPress-brukernavnet trenger ikke være det samme som det offentlige navnet som vises som forfatter. Skriv det faktiske brukernavnet i filen.
2. Nøkkelen som WordPress genererer inneholder mellomrom. Fjern dem når du lagrer den i .env. Ellers fungerer det ikke.

Prompt for denne delen

Etter forrige trinn gir du Codex denne prompten:

Bruk WordPress-innloggingsopplysningene som er tilgjengelige i de lokale miljøvariablene.

Ikke vis, skriv ut eller kopier passord, tokens eller andre hemmeligheter i resultatet.

Ikke endre noe innhold ennå.

Kontroller bare at de nødvendige variablene er tilgjengelige.

Da vet du om Codex har lest dem riktig, et nødvendig trinn før du går videre.

Trinn 4. Kontroller at Codex kan koble til

Neste trinn er å kontrollere at forbindelsen fungerer.

REST API er i praksis grensesnittet som gjør at Codex kan spørre WordPress om ting som Hvilke tagger har dette innlegget? eller Legg til denne taggen og lagre artikkelen.

På dette tidspunktet vil vi bare gjøre det første. Be derfor Codex om en ren leseforespørsel:

Kontroller autentiseringen mot WordPress REST API.

Gjør bare GET-forespørsler.

Bekreft:

– at forbindelsen fungerer;

– hvilken WordPress-bruker som er autentisert;

– at denne brukeren har rettigheter til å redigere innleggene vi skal arbeide med.

Hvis det finnes noen autentiserings- eller rettighetsfeil, stopp.

Ikke gjør skriveforespørsler.

Hvis alt er i orden, har vi tilgang. Hvis du får en 401-feil, må du vanligvis kontrollere innloggingsopplysningene.

Trinn 5. Finn oversettelsene av hvert innlegg

Dette trinnet er bare nødvendig hvis du har et flerspråklig.

Hvis du bruker Polylang, vil vi ikke at Codex skal finne oversettelser ved å sammenligne titler, fordi en tittel kan endre seg mye mellom språk.

Vi vil at den bruker oversettelsesrelasjonene som allerede finnes i WordPress/Polylang.

Vi starter fra hver originalartikkel og finner språkversjonene.

Prompten

Ta utgangspunkt utelukkende i innleggene i den godkjente listen og finn oversettelsene deres ved hjelp av Polylang-relasjonene.

Ikke søk etter oversettelser basert på likhet i tittelen.

For hver artikkel, returner:

– originalinnlegg;

– språk;

– tittel på oversettelsen;

– post ID;

– URL.

Nettstedet bruker disse språkene:

[LISTE OVER SPRÅK]

Hver artikkel bør ha:

[ANTALL VERSJONER]

versjoner totalt.

Hvis en oversettelse mangler eller du finner en inkonsistent relasjon, stopp og ikke endre noe.

Her har vi en veldig enkel kontroll som er verdt å gjøre.

Hvis du har 25 artikler × 5 språk = 125 innlegg bør Codex finne nøyaktig 125.

Hvis den finner 124, bør den ikke fortsette.

Trinn 6. Kjør en fullstendig dry run

Nå har vi nok informasjon til å bygge den faktiske operasjonen, men vi skal fortsatt ikke kjøre den.

Først gjør vi en dry run, som ikke er noe annet enn en simulering av hva som ville skjedd hvis vi tillot endringene.

Vi vil at Codex bygger en tabell som kobler innlegg > språk > tilsvarende tagg > nåværende status.

Prompt

Kjør nå en fullstendig dry run av operasjonen.

Ikke gjør POST-, PUT-, PATCH- eller DELETE-forespørsler.

For hvert innlegg i den validerte listen:

1. Hent de nåværende taggene.

2. Identifiser språket til innlegget.

3. Finn oversettelsen av den nye taggen som nøyaktig tilsvarer det samme språket.

4. Hent term ID for den taggen.

5. Kontroller om dette term ID allerede er tilordnet innlegget.

6. Beregn hvordan den endelige arrayen med tagger ville sett ut etter at den ble lagt til, samtidig som alle eksisterende term IDs beholdes.

Forholdet skal alltid være:

innlegg på språk X → tagg på språk X → term ID for den taggen.

Tildel aldri term ID for den spanske taggen til et innlegg på et annet språk, og bruk aldri en tagg hvis språk ikke nøyaktig samsvarer med språket til innlegget.

Returner en tabell med:

– post ID;

– språket til innlegget;

– tittel;

– nåværende tagger;

– navnet på taggen som tilsvarer det språket;

– språket til taggen;

– term ID som måtte legges til;

– om den allerede finnes;

– forventede endelige tagger.

Kontroller uttrykkelig at språket til innlegget og språket til taggen samsvarer i alle tilfeller.

Hvis du finner et innlegg der du ikke entydig kan identifisere taggen på samme språk, hvis en oversettelse av taggen mangler eller hvis språket til innlegget og taggen ikke samsvarer, stopp og ikke endre noe.

Oppgi til slutt:

– totalt antall innlegg;

– innlegg som krever endring;

– innlegg som allerede inneholder taggen;

– feil eller inkonsistenser.

Ikke skriv noe ennå.

Dette trinnet har to fordeler.

Den første er åpenbar: vi kan se nøyaktig hva Codex har tenkt å gjøre.

Den andre er at vi finner innlegg som allerede har taggen.

Disse artiklene trenger ikke endres på nytt.

I mitt tilfelle var det 120 innlegg, men 2 var allerede korrekt tagget (det hadde jeg gjort manuelt).

Trinn 7. Kontroller at ingen tagger blir slettet

Dette er punktet jeg ville fulgt aller nøye med på.

Se for deg at en artikkel allerede har disse taggene:

• Bitcoin.
• Investering.
• Tutorial.

Og vi vil legge til “Skatt”.

Resultatet vi åpenbart ønsker, er at artikkelen inneholder alle fire, ikke bare Skatt.

Det virker selvsagt, men når du jobber via REST API må du huske at feltet tags representerer hele settet med tagger som innlegget skal ha.

Derfor må Codex først lese de eksisterende ID-ene, legge til den nye og deretter sende hele settet.

Vi vil ikke erstatte, vi vil legge til.

Du kan understreke dette med en egen prompt:

Kontroller denne regelen før du kjører endringene:

ERSTATT ALDRI de nåværende taggene til innlegget med bare den nye taggen.

For hvert innlegg:

1. Les den nåværende arrayen med term IDs.

2. Behold alle eksisterende IDs.

3. Kontroller om den nye term ID allerede finnes.

4. Hvis den ikke finnes, legg den til i arrayen.

5. Ikke slett eller endre noen annen term ID.

Vis meg ethvert tilfelle der du ikke kan garantere denne operasjonen.

Ikke skriv ennå.

Hvis du skal automatisere en slik operasjon, ville jeg ikke hoppet over denne kontrollen.

Trinn 8. Valider alt på nytt rett før du endrer WordPress

Vi har allerede godkjent dry run. Vi kunne kjørt direkte, men det koster svært lite å lese WordPress på nytt rett før vi skriver.

Grunnen er enkel: tilstanden til et innlegg kan ha endret seg mellom to forespørsler. Kanskje du har redigert det selv på ulike dager, eller noen andre har gjort det. Vi vil være sikre på at Codex jobber med den aktuelle versjonen.

Prompt

Gjør en ny validering umiddelbart før endringene kjøres.

Spør WordPress på nytt og bekreft:

– at alle planlagte innlegg fortsatt finnes;

– at oversettelsesrelasjonene ikke har endret seg;

– at term IDs for taggen fortsatt er riktige;

– at de nåværende taggene samsvarer med tilstanden du skal endre.

Hvis det finnes noen forskjell sammenlignet med dry run, stopp.

Hvis alt stemmer, oppgi:

– totalt antall innlegg;

– nødvendige endringer;

– innlegg som allerede er riktige.

Ikke kjør noen endringer ennå før jeg gir tillatelse.

Slik reduserer vi risikoen betydelig.

Trinn 9. Kjør endringen

Hvis alt ovenfor er OK, kan vi nå godkjenne skrivingen.

På dette tidspunktet er det lurt å være svært presis om hva som kan og ikke kan endres.

Prompt

Jeg godkjenner at endringene kjøres.

Endre utelukkende innleggene som er med i den validerte listen.

For hvert innlegg:

1. Les de nåværende taggene.

2. Identifiser språket til innlegget.

3. Bruk utelukkende oversettelsen av den nye taggen hvis språk nøyaktig samsvarer med språket til dette innlegget.

4. Hent term ID for den taggen.

5. Kontroller om dette term ID allerede finnes.

6. Hvis den ikke finnes, legg den til i den nåværende arrayen med tagger.

7. Behold alle andre eksisterende term IDs.

8. Lagre hele den resulterende arrayen.

Forholdet skal alltid være:

innlegg på språk X → tagg på språk X → term ID for den taggen.

Tildel aldri term ID for den spanske taggen til et innlegg på et annet språk, og bruk aldri en tagg hvis språk ikke nøyaktig samsvarer med språket til innlegget.

Hvis du for et innlegg ikke entydig kan identifisere taggen på samme språk, hvis en oversettelse av taggen mangler eller hvis språket til innlegget og taggen ikke samsvarer, ikke endre det innlegget og logg feilen.

IKKE endre:

– tittel;

– innhold;

– excerpt;

– slug;

– kategorier;

– forfatter;

– dato;

– status;

– fremhevet bilde;

– ACF-felt;

– SEO;

– ingen andre opplysninger om innlegget.

Ikke endre innlegg utenfor den godkjente listen.

Logg for hver operasjon:

– post ID;

– språket til innlegget;

– navnet på den tildelte taggen;

– språket til taggen;

– lagt til term ID;

– tagger før;

– tagger etter;

– WordPress-responskode;

– resultat.

Hvis en operasjon mislykkes, logg feilen og ikke prøv å rette den ved å endre andre felt.

Nå vil Codex gjøre de nødvendige forespørslene mot WordPress.

Men vi har fortsatt én kontroll igjen.

Trinn 10. Les alle innleggene på nytt

Et korrekt API-svar betyr at WordPress har godtatt forespørselen.

Men hvis vi jobber med titalls eller hundrevis av artikler, er det verdt å kontrollere sluttilstanden, i stedet for bare å anta at alt gikk bra.

Derfor gjør vi en ny runde med lesespørringer.

Prompt

Når endringene er ferdige, gjør en uavhengig kontroll med nye GET-forespørsler.

For hvert innlegg i listen, kontroller:

1. At det inneholder term ID for den nye taggen som tilsvarer språket.

2. At det beholder alle term IDs det hadde fra før.

3. At ingen uventet tagg er lagt til.

4. At ingen innlegg utenfor listen er endret.

Returner en sluttoppsummering med:

– gjennomgåtte innlegg;

– utførte endringer;

– innlegg som allerede var korrekt tagget;

– REST-feil;

– tidligere tagger som gikk tapt;

– uventet endrede innlegg;

– endelige avvik.

Anse oppgaven som fullført bare hvis det finnes 0 avvik.

Med dette avslutter vi prosessen.

Vi har ikke bare utført endringene, vi har også kontrollert hva som faktisk ble lagret korrekt i WordPress.

Konklusjoner

Den første er at det for noen få innlegg sannsynligvis fortsatt går raskere å gjøre det manuelt. Men skalaen endrer seg raskt, særlig med flere språk:

• 10 artikler × 10 språk = 100 innlegg
• 30 artikler × 10 språk = 300 innlegg
• 50 artikler × 10 språk = 500 innlegg

På det tidspunktet handler det ikke lenger bare om å spare klikk, men først og fremst om å redusere feil.

Det jeg vil at du skal sitte igjen med, fordi jeg synes dette systemet er genuint nyttig, er at Codex ikke fritt bestemmer og endrer WordPress-en din:

• Først bygger den systemet.
• Deretter simulerer den.
• Så validerer den på nytt.
• Først da skriver den.
• Og når den er ferdig, kontrollerer den alt på nytt.

For redaksjonelt vedlikehold i stor skala synes jeg dette er en langt mer fornuftig måte å bruke agenter som Codex på.

Jeg har faktisk allerede helt klart for meg en annen endring som påvirker mer enn 500 innlegg, og som jeg hadde tenkt å gjøre manuelt med SQL. 

Etter å ha prøvd denne metoden er det tydelig for meg at den er mye bedre, og at sannsynligheten for feil reduseres betydelig.

Dette ble en enveisreise.