Hoe je oude posts in meerdere talen opnieuw tagt in WordPress met Codex-AI

Onlangs liep ik tegen een nieuwe uitdaging aan: hoe je een nieuwe tag toevoegt — in mijn geval ‘sciencefiction’ — aan alle artikelen, zowel in het Spaans als in de andere talen. 

Met andere woorden: bijna 3.000 artikelen die moesten worden:

• Geanalyseerd om te zien bij welke de tag echt paste.
• Voorzien van de tag in de juiste taal zonder de overige tags te verwijderen.
• Gecontroleerd om te zien of alles goed was gegaan.

De tag in elke taal aanmaken was met mijn eigen maatwerk geen probleem. De echte uitdaging was alleen de oude artikelen taggen die hem daadwerkelijk moesten krijgen.

Je zou het natuurlijk handmatig kunnen doen, maar na het nalopen van de content hield ik een lijst over van 12 artikelen in het Spaans. Dat betekent dat ik, omdat de site in tien talen is vertaald, in totaal 120 posts.

moest taggen. Elke post in zijn eigen taal zoeken, openen en 120 keer achter elkaar die tag toevoegen zag ik eerlijk gezegd niet zitten.

Dus bedacht ik dat dit een behoorlijk geschikte taak was voor Codex.

Bovendien wilde ik deze vrij eenvoudige case gebruiken als basis voor iets veel algemeners: automatisch wijzigingen toepassen op veel artikelen, zonder de agent vrij spel te geven en op eigen houtje van alles te laten veranderen.

Dat is precies wat ik in deze tutorial uitleg.

Doel

Eenvoudig: een specifieke tag toevoegen aan een gesloten lijst met WordPress-posts.

Inclusief de juiste vertaling van die tag voor elke taalversie van het artikel, met Polylang, de meertalige plugin die ik gebruik.

En we gaan dit niet op goed geluk doen, maar met een paar voorzorgsmaatregelen:

• We werken met een gesloten lijst met artikelen.
• We controleren eerst wat Codex gaat wijzigen.
• We maken niet automatisch nieuwe tags aan.
• We behouden alle tags die elke post al heeft.
• We voeren eerst een simulatie uit voordat we iets schrijven.
• Daarna controleren we WordPress opnieuw om het resultaat te verifiëren.

Jouw situatie hoeft niet precies hetzelfde te zijn als de mijne. Het is genoeg als je iets wilt wijzigen in een specifieke reeks WordPress-posts waar je handmatig flink wat tijd aan kwijt zou zijn.

Zelf gebruik ik Codex, maar je kunt hetzelfde proces volgen als je liever Claude Code of Antigravity gebruikt. De tool verandert, de stappen niet.

Stap 1. Maak de tag aan voordat je begint

Het eerste wat je nodig hebt, is dat de tag die je wilt toepassen al in WordPress is aangemaakt.

Dit kun je het beste handmatig doen, want ik wil niet dat Codex beslist hoe de taxonomie van de site moet worden ingericht. We willen dat het zich beperkt tot iets vinden dat al bestaat en dat aan bepaalde posts toewijzen.

In WordPress kun je dat, zoals je weet, doen via:

Berichten > Tags

Als je site maar één taal heeft, ben je met deze stap praktisch klaar.

Als je Polylang gebruikt (de Pro-versie of eigen maatwerk erbovenop, zoals bij mij), maak dan ook de vertalingen van de tag aan en controleer of ze correct aan elkaar gekoppeld zijn.

Bij mij zag dat er bijvoorbeeld zo uit:

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

Enzovoort.

WordPress slaat ze intern op als verschillende termen (tags), en elke term heeft zijn eigen ID. Dat wordt later belangrijk.

Een opmerking: ik heb een zelfontwikkelde plugin die ze automatisch in alle talen aanmaakt, maar jij zult ze waarschijnlijk handmatig per taal moeten aanmaken.

Prompt om de tags te controleren

Zodra je ze hebt aangemaakt, kun je Codex vragen ze op te zoeken:

Ik wil een bestaande tag toevoegen aan meerdere WordPress-posts.

De hoofdtag is:

[NAAM VAN DE TAG]

Wijzig voorlopig geen gegevens.

Zoek de tag in WordPress en, als de site Polylang gebruikt, alle vertalingen ervan.

Geef voor elke taal terug:

– taal;

– naam van de tag;

– slug;

– term ID.

Maak geen nieuwe tags aan.

Als een vertaling ontbreekt, er duplicaten zijn of er enige onduidelijkheid bestaat, stop dan en waarschuw me.

De term ID is simpelweg het nummer waarmee WordPress die tag intern identificeert. Belangrijk is dat Codex weet welke ID bij elke taal hoort.

Stap 2. Maak een gesloten lijst met artikelen

Nu moeten we bepalen welke posts we willen wijzigen.

Hier raad ik aan de agent niet te veel vrijheid te geven.

We zouden kunnen vragen:

Zoek alle artikelen over sciencefiction en tag ze.

Maar dan mengen we twee heel verschillende taken:

1. Redactioneel beslissen welke content de tag moet krijgen.
2. Dezelfde wijziging 20, 100 of 500 keer uitvoeren in WordPress.

Ik houd die twee liever gescheiden, zodat ik elke stap kan controleren.

Je kunt de lijst handmatig maken als het aantal artikelen niet erg groot is.

Je kunt ook ChatGPT of Codex gebruiken om mogelijke kandidaten te vinden.

In mijn geval was het volume groot, dus gaf ik de drie artikel-sitemaps door en vroeg ik ChatGPT om op basis van de URL kandidaten voor te stellen.

Hoe je het ook doet, je zou een concrete lijst met artikelen moeten hebben voordat je iets wijzigt.

Bijvoorbeeld:

• Blade Runner: recensie en analyse.
• De beste sciencefictionstrips.
• Akira: manga en film.
• El Eternauta: recensie van de serie.
• …

Zoals gezegd kwam ik uit op 12 artikelen per taal, nadat ik enkele kandidaten had geschrapt die ChatGPT passend vond maar ik niet.

Prompt om de werkset voor te bereiden

Zodra je de lijst hebt, geef je Codex dit:

Ik ga je een gesloten lijst met WordPress-artikelen geven.

Werk uitsluitend met deze artikelen.

Voeg geen andere content toe, ook niet als je denkt dat die ook bij de tag zou passen.

Lijst:

[PLAK HIER DE TITELS OF URL’S]

Voer voorlopig geen wijzigingen uit.

Zoek elke post op en geef terug:

– titel;

– URL;

– post ID;

– status;

– taal.

Als een post niet eenduidig kan worden geïdentificeerd, stop dan en markeer hem.

Hiermee hebben we beide kanten van de operatie vastgelegd:

1. Welke posts we willen taggen
2. Welke tag we willen toevoegen.

Stap 3. Configureer Codex-toegang tot WordPress

Om bepaalde WordPress-eigenschappen te lezen en vooral om posts te wijzigen, moet Codex zich authenticeren.

Er zijn verschillende manieren, de ene veiliger dan de andere. Een behoorlijk handige manier is via een WordPress Application Password.

Dat is niet je normale wachtwoord voor het dashboard. Het is een extra wachtwoord dat speciaal wordt aangemaakt zodat een applicatie via de REST API. 

Net zoals je het kunt aanmaken, kun je het op elk moment intrekken zonder je gewone wachtwoord te hoeven wijzigen.

Je maakt het aan via:

Gebruikers > Profiel > Applicatiewachtwoorden

Geef het een naam waaraan je het later herkent, bijvoorbeeld “Codex”.

WordPress genereert dan een wachtwoord.

Hoe je het wachtwoord aan Codex doorgeeft

Zet het wachtwoord niet rechtstreeks in de prompt

Het zou kunnen werken, maar je wachtwoorden naar de cloud sturen is geen goede gewoonte.

Het beste is om het lokaal op te slaan als omgevingsvariabele of in een .env bestand dat niet naar de repository wordt geüpload, als je met Git werkt.

Je kunt bijvoorbeeld een .env-bestand opslaan met alleen deze drie regels:

WP_URL=https://tudominio.com

WP_USERNAME=tu_usuario

WP_APP_PASSWORD=tu_application_password

Sla het op in C:UsersTU_USUARIO_WINDOWS.codex.env

En voeg .env toe aan .gitignore zodat het niet wordt geüpload.

Het idee is dat Codex de inloggegevens kan gebruiken zonder ze steeds te hoeven tonen of kopiëren.

Nadat je het bestand hebt aangemaakt, moet je Codex sluiten en opnieuw openen zodat het bestand wordt ingelezen.

Twee belangrijke dingen: 

1. De WordPress-gebruikersnaam hoeft niet overeen te komen met de openbare naam die als auteur wordt weergegeven. Zet de echte gebruikersnaam in het bestand.
2. De sleutel die WordPress genereert bevat spaties. Verwijder die wanneer je hem in .env opslaat. Anders werkt het niet.

Prompt voor dit deel

Geef Codex na de vorige stap deze prompt:

Gebruik de WordPress-inloggegevens die beschikbaar zijn in de lokale omgevingsvariabelen.

Toon, print of kopieer geen wachtwoorden, tokens of andere geheimen in de uitvoer.

Wijzig nog geen content.

Controleer alleen of de benodigde variabelen beschikbaar zijn.

Zo weet je of Codex ze correct heeft opgepikt, een onmisbare stap voordat je verdergaat.

Stap 4. Controleer of Codex verbinding kan maken

De volgende stap is controleren of de verbinding werkt.

De REST API is in feite de interface waarmee Codex WordPress dingen kan vragen zoals Welke tags heeft deze post? of Voeg deze tag toe en sla het artikel op.

Op dit moment willen we alleen het eerste doen. Vraag Codex daarom om een alleen-lezen query uit te voeren:

Controleer de authenticatie tegen de WordPress REST API.

Voer uitsluitend GET-verzoeken uit.

Bevestig:

– dat de verbinding werkt;

– welke WordPress-gebruiker is geauthenticeerd;

– dat deze gebruiker rechten heeft om de posts te bewerken waarmee we gaan werken.

Als er een authenticatie- of permissiefout is, stop dan.

Voer geen schrijfverzoeken uit.

Als alles goed is, hebben we toegang. Krijg je een 401-fout, dan moet je meestal de inloggegevens controleren.

Stap 5. Zoek de vertalingen van elke post

Deze stap is alleen nodig als je website meertalig.

Als je Polylang gebruikt, willen we niet dat Codex vertalingen zoekt door titels te vergelijken, omdat een titel enorm kan verschillen per taal.

We willen dat het de vertaalrelaties gebruikt die WordPress/Polylang al heeft.

We beginnen bij elk origineel artikel en zoeken de taalversies op.

De prompt

Zoek uitsluitend vanuit de posts in de goedgekeurde lijst hun vertalingen via de Polylang-relaties.

Zoek vertalingen niet op basis van gelijkenis van de titel.

Geef voor elk artikel terug:

– originele post;

– taal;

– titel van de vertaling;

– post ID;

– URL.

De website gebruikt deze talen:

[LIJST MET TALEN]

Elk artikel zou moeten hebben:

[AANTAL VERSIES]

versies in totaal.

Als een vertaling ontbreekt of je een inconsistente relatie vindt, stop dan en wijzig niets.

Hier hebben we een heel eenvoudige controle die de moeite waard is.

Als je 25 artikelen × 5 talen = 125 posts Codex zou exact dit moeten vinden: 125.

Als het 124 vindt, moet het niet doorgaan.

Stap 6. Voer een volledige dry run uit

Nu hebben we genoeg informatie om de echte operatie op te zetten, maar we gaan hem nog niet uitvoeren.

Eerst doen we een dry run, wat niets anders is dan een simulatie van wat er zou gebeuren als we de wijzigingen toestaan.

We willen dat Codex een tabel opbouwt die koppelt: post > taal > bijbehorende tag > huidige status.

Prompt

Voer nu een volledige dry run van de operatie uit.

Voer geen POST-, PUT-, PATCH- of DELETE-verzoeken uit.

Voor elke post in de gevalideerde lijst:

1. Vraag de huidige tags op.

2. Bepaal de taal van de post.

3. Zoek de vertaling van de nieuwe tag die exact overeenkomt met diezelfde taal.

4. Haal de term ID van die tag op.

5. Controleer of die term ID al aan de post is toegewezen.

6. Bereken hoe de uiteindelijke tags-array eruit zou zien nadat je hem toevoegt, met behoud van alle bestaande term IDs.

De relatie moet altijd zijn:

post in taal X → tag in taal X → term ID van die tag.

Wijs nooit de term ID van de Spaanse tag toe aan een post in een andere taal en gebruik nooit een tag waarvan de taal niet exact overeenkomt met de taal van de post.

Geef een tabel terug met:

– post ID;

– taal van de post;

– titel;

– huidige tags;

– naam van de tag die bij die taal hoort;

– taal van de tag;

– term ID die toegevoegd zou moeten worden;

– of die al aanwezig is;

– verwachte uiteindelijke tags.

Controleer uitdrukkelijk dat de taal van de post en de taal van de tag in alle gevallen overeenkomen.

Als je een post vindt waarvoor je de tag in dezelfde taal niet eenduidig kunt identificeren, als een vertaling van de tag ontbreekt of als de taal van de post en de tag niet overeenkomen, stop dan en wijzig niets.

Geef aan het einde aan:

– totaal aantal posts;

– posts die moeten worden gewijzigd;

– posts die de tag al bevatten;

– fouten of inconsistenties.

Schrijf nog niets.

Deze stap heeft twee voordelen.

Het eerste ligt voor de hand: we kunnen precies zien wat Codex van plan is.

Het tweede is dat we posts ontdekken die de tag al hebben.

Die artikelen hoeven niet opnieuw te worden gewijzigd.

In mijn geval waren er 120 posts, maar 2 waren al correct getagd (dat had ik handmatig gedaan).

Stap 7. Controleer dat er geen tags worden verwijderd

Dit is het punt waar ik het meeste aandacht aan zou besteden.

Stel dat een artikel al deze tags heeft:

• Bitcoin.
• Investering.
• Tutorial.

En we willen “Fiscaliteit” toevoegen.

Het gewenste resultaat is natuurlijk dat het artikel alle vier bevat, niet alleen Fiscaliteit.

Het lijkt vanzelfsprekend, maar wanneer je via de REST API werkt, moet je onthouden dat het veld tags staat voor de volledige set tags die de post moet hebben.

Daarom moet Codex eerst de bestaande IDs lezen, de nieuwe toevoegen en daarna de volledige set versturen.

We willen niet vervangen, we willen toevoegen.

Je kunt dit nog versterken met een specifieke prompt:

Controleer deze regel voordat je de wijzigingen uitvoert:

Vervang NOOIT de huidige tags van de post door alleen de nieuwe tag.

Voor elke post:

1. Lees de huidige array met term IDs.

2. Behoud alle bestaande IDs.

3. Controleer of de nieuwe term ID al bestaat.

4. Als die niet bestaat, voeg hem dan toe aan de array.

5. Verwijder of wijzig geen enkele andere term ID.

Laat me elk geval zien waarin je deze operatie niet kunt garanderen.

Schrijf nog niet.

Als je een operatie als deze gaat automatiseren, zou ik deze controle niet overslaan.

Stap 8. Valideer alles opnieuw vlak voordat je WordPress wijzigt

We hebben de dry run al goedgekeurd. We zouden direct kunnen uitvoeren, maar het kost vrijwel niets om WordPress vlak voor het schrijven nog een keer uit te lezen.

De reden is eenvoudig: de status van een post kan tussen twee queries zijn veranderd. Misschien heb je hem zelf op verschillende dagen aangepast of heeft iemand anders dat gedaan. We willen zeker weten dat Codex met de actuele versie werkt.

Prompt

Voer direct vóór het uitvoeren van de wijzigingen een hervalidatie uit.

Vraag WordPress opnieuw op en bevestig:

– dat alle verwachte posts nog bestaan;

– dat de vertaalrelaties niet zijn veranderd;

– dat de term IDs van de tag nog correct zijn;

– dat de huidige tags overeenkomen met de status die je gaat wijzigen.

Als er enig verschil is ten opzichte van de dry run, stop dan.

Als alles overeenkomt, vertel me:

– totaal aantal posts;

– benodigde wijzigingen;

– posts die al correct zijn.

Voer nog geen wijzigingen uit totdat ik toestemming geef.

Zo verkleinen we het risico aanzienlijk.

Stap 9. Voer de wijziging uit

Als alles hierboven OK is, kunnen we nu het schrijven toestaan.

Op dit punt is het verstandig heel precies te zijn over wat wel en niet mag worden gewijzigd.

Prompt

Ik geef toestemming om de wijzigingen uit te voeren.

Wijzig uitsluitend de posts in de gevalideerde lijst.

Voor elke post:

1. Lees de huidige tags.

2. Bepaal de taal van de post.

3. Gebruik uitsluitend de vertaling van de nieuwe tag waarvan de taal exact overeenkomt met de taal van die post.

4. Haal de term ID van die tag op.

5. Controleer of die term ID al aanwezig is.

6. Als die niet aanwezig is, voeg hem toe aan de huidige tags-array.

7. Behoud alle andere bestaande term IDs.

8. Sla de volledige resulterende array op.

De relatie moet altijd zijn:

post in taal X → tag in taal X → term ID van die tag.

Wijs nooit de term ID van de Spaanse tag toe aan een post in een andere taal en gebruik nooit een tag waarvan de taal niet exact overeenkomt met de taal van de post.

Als je voor een post de tag in dezelfde taal niet eenduidig kunt identificeren, als een vertaling van de tag ontbreekt of als de taal van de post en de tag niet overeenkomen, wijzig die post dan niet en log de fout.

Wijzig NIET:

– titel;

– content;

– excerpt;

– slug;

– categorieën;

– auteur;

– datum;

– status;

– uitgelichte afbeelding;

– ACF-velden;

– SEO;

– geen andere gegevens van de post.

Wijzig geen posts buiten de goedgekeurde lijst.

Log voor elke operatie:

– post ID;

– taal van de post;

– naam van de toegewezen tag;

– taal van de tag;

– toegevoegde term ID;

– tags ervoor;

– tags erna;

– WordPress-responscode;

– resultaat.

Als een operatie mislukt, log dan de fout en probeer die niet te herstellen door andere velden te wijzigen.

Nu zal Codex de benodigde verzoeken aan WordPress uitvoeren.

Maar er resteert nog één controle.

Stap 10. Lees alle posts opnieuw

Een succesvolle API-respons betekent dat WordPress het verzoek heeft geaccepteerd.

Maar als we met tientallen of honderden artikelen werken, is het de moeite waard om de uiteindelijke status, in plaats van er simpelweg van uit te gaan dat alles goed is gegaan.

Dus voeren we nog een ronde leesqueries uit.

Prompt

Voer na afloop van de wijzigingen een onafhankelijke verificatie uit met nieuwe GET-verzoeken.

Controleer voor elke post in de lijst:

1. Dat de post de term ID bevat van de nieuwe tag die bij zijn taal hoort.

2. Dat alle term IDs die de post daarvoor had behouden zijn gebleven.

3. Dat er geen onverwachte tag is toegevoegd.

4. Dat er geen post buiten de lijst is gewijzigd.

Geef een definitieve samenvatting met:

– gecontroleerde posts;

– uitgevoerde wijzigingen;

– posts die al correct getagd waren;

– REST-fouten;

– verloren eerdere tags;

– onverwacht gewijzigde posts;

– uiteindelijke afwijkingen.

Beschouw de taak alleen als voltooid als er 0 afwijkingen zijn.

Daarmee sluiten we het proces af.

We hebben niet alleen de wijzigingen uitgevoerd, maar ook gecontroleerd wat er daadwerkelijk correct in WordPress is opgeslagen.

Conclusies

Ten eerste is het bij een paar posts waarschijnlijk nog steeds sneller om het handmatig te doen. Maar de schaal verandert snel, zeker bij meertalige sites:

• 10 artikelen × 10 talen = 100 posts
• 30 artikelen × 10 talen = 300 posts
• 50 artikelen × 10 talen = 500 posts

Vanaf dat punt gaat het niet alleen meer om klikken besparen, maar vooral om fouten verminderen.

Het idee dat ik wil dat je onthoudt, omdat ik het echt nuttig vind aan dit systeem, is dat Codex niet vrij beslist en je WordPress naar eigen inzicht wijzigt:

• Eerst bouwt het systeem op.
• Daarna simuleert het.
• Vervolgens valideert het opnieuw.
• Pas dan schrijft het.
• En als het klaar is, controleert het alles opnieuw.

Voor grootschalig redactioneel onderhoud lijkt dit mij een veel verstandigere manier om agents zoals Codex te gebruiken.

Sterker nog, ik heb alweer een andere wijziging heel duidelijk voor ogen die meer dan 500 posts raakt en die ik handmatig met SQL wilde uitvoeren. 

Na deze aanpak te hebben getest, is het mij duidelijk dat dit veel beter is en dat de kans op fouten aanzienlijk kleiner wordt.

Dit was een enkele reis.