WordPress stores absolute URLs in dozens of database tables, so a domain change or an SSL move leaves old addresses scattered through posts, options and plugin settings: a search and replace is how…

Een zoeken en vervangen uitvoeren in uw WordPress-database

WordPress slaat absolute URL's op in tientallen databasetabellen, dus een domeinwijziging of een SSL-verplaatsing laat oude adressen verspreid achter in berichten, opties en instellingen van plugins: een zoeken en vervangen is hoe u dit veilig opschoont. Deze handleiding behandelt de twee ondersteunde manieren om dit in KPanel te doen, waarom een veel voorkomende derde methode gegevens beschadigt, en hoe u het resultaat verifieert.

Wanneer u er een nodig hebt

Verplaatsen van http:// naar https:// nadat SSL is ingeschakeld.
Domein wijzigen, bijvoorbeeld old-brand.co.nz naar new-brand.co.nz.
Na het pushen van staging naar productie, wanneer de staging-hostnaam nog steeds in de database is opgeslagen.
Een oude asset-host uitfaseren en alle afbeeldings-URL's tegelijk opnieuw instellen.
Een bulk-typfout over veel berichten corrigeren, zoals een oud telefoonnummer of een discontinu productnaam.

Een zoeken en vervangen herschrijft rijen over alle tabellen tegelijk en er is geen undo per rij. Maak altijd een back-up voordat u begint, elke keer, ook voor een wijziging die triviaal lijkt. KPanel maakt er automatisch een wanneer u de ingebouwde tools gebruikt die hieronder worden beschreven, maar als u de opdracht zelf uitvoert, bent u er zelf verantwoordelijk voor. Zie Een back-up maken.

Waarom u niet gewoon een SQL REPLACE kunt uitvoeren

Dit is de meest schadelijke fout in WordPress-databasewerk, dus het is de moeite waard om dit te begrijpen voordat u een methode kiest.

WordPress slaat plugin-instellingen, thema-opties en widgetgegevens op als PHP-geserialiseerde strings. Een geserialiseerde string registreert de lengte van elke waarde erin, zoals dit:

a:1:{s:3:"url";s:26:"http://old-domain.co.nz/x";}

Die s:26 zegt dat de URL 26 tekens lang is. Vervang http:// door https:// met behulp van een gewone SQL REPLACE() en de tekst wordt 27 tekens terwijl de opgeslagen lengte nog steeds 26 beweert. PHP weigert vervolgens de hele optie te deserialiseren, en de instelling wordt stilzwijgend teruggezet naar leeg. Instellingen in de theme-customizer verdwijnen, sliders verliezen hun dia's, pluginlicenties melden zich zelf af.

De WP-CLI search-replace die KPanel uitvoert deserialiseert elke waarde, vervangt erin, en re-serialiseert met gecorrigeerde lengtes. Daarom is het de enige methode die hier wordt gedocumenteerd.

Voer nooit UPDATE wp_options SET option_value = REPLACE(...) of het equivalent in phpMyAdmin uit tegen een WordPress-database. Het ziet eruit als of het werkte, het rapporteert betreffende rijen, en het vernietigt stilzwijgend elke geserialiseerde instelling die het raakte. Er is geen reparatie zonder het herstellen van een back-up.

Methode 1: De kaart Zoeken en vervangen

Dit is de juiste keuze voor bijna iedereen. Het is beschikbaar op elk WordPress-plan.

Meld u aan bij KPanel en klik op Websites in de linker zijbalk.
Klik op de site.
Open het tabblad WordPress en vervolgens de sectie Quick Actions.
Zoek de kaart Search & Replace en klik op Configure.
Voer de bestaande tekst in bij Find (old value).
Voer de nieuwe tekst in bij Replace with.
Houd Dry run (preview only, no changes) ingeschakeld en klik op Preview.

De dry run rapporteert hoeveel vervangingen zouden worden gemaakt en splitst de telling op per tabel en kolom, zodat u exact kunt zien waar de wijziging zou plaatsvinden voordat u zich eraan verbindt.

Wanneer de preview er goed uitziet:

Schakel Dry run uit.
Klik op Run.
Bevestig het dialoogvenster.

Er wordt automatisch een volledige back-up gemaakt voordat de vervanging begint, en de run dekking alle tabellen, inclusief die gemaakt door plugins.

Zoek naar de meest specifieke string die u kunt. Het vervangen van old-domain.co.nz herschrijft ook mail.old-domain.co.nz en staging.old-domain.co.nz, wat zelden is wat u wilt. Het schema opnemen, zoals in https://old-domain.co.nz, houdt de match strak.

Methode 2: WP-CLI vanaf de console

De console biedt u dezelfde engine met meer controle over flags. Het is een van de secties die op managed plans verschijnen; op andere plans toont de tabbalk in plaats daarvan een link +8 on Managed.

Open de site, dan WordPress, dan Console. De prompt begint al met wp, dus typ alleen de rest van de opdracht.

Voorbeeld eerst:

search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables --dry-run

Voer het dan werkelijk uit:

search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables

De console maakt geen back-up voor u. De automatische pre-run back-up gebeurt alleen wanneer u de kaart Search & Replace in Methode 1 gebruikt. Als u de opdracht hier uitvoert, maak eerst zelf een back-up uit het tabblad Backups van de site.

Nuttige flags:

Flag	Wat het doet
`--all-tables`	Bevat aangepaste tabellen gemaakt door plugins, niet alleen de kern WordPress-tabellen
`--dry-run`	Rapporteert wat zou veranderen en schrijft niets
`--precise`	Gebruikt PHP in plaats van SQL voor de vervanging. Langzamer, maar verwerkt moeilijke geserialiseerde structuren
`--skip-columns=guid`	Laat post-GUID's alleen (zie hieronder)
`--report-changed-only`	Beperkt de uitvoer tot tabellen die werkelijk zijn veranderd

Een opmerking over GUID's

Elke WordPress-post heeft een guid kolom. Ondanks dat het eruit ziet als een URL, is het een identifier, geen link, en feed-readers gebruiken het om te bepalen of ze een item al hebben gezien. Het herschrijven kan ervoor zorgen dat elk bericht in uw feed opnieuw als nieuw verschijnt.

Herschrijf GUID's wanneer u het domein permanent wijzigt en opnieuw begint. Sla ze over met --skip-columns=guid wanneer u alleen van HTTP naar HTTPS gaat op hetzelfde domein.

Domein wijzigen: Gebruik in plaats daarvan de kaart Site-URL wijzigen

Als het geheel het doel is om de site naar een nieuw domein te verplaatsen, begin dan niet met zoeken en vervangen. De kaart Change Site URL, in dezelfde sectie Quick Actions, werkt de opties siteurl en home bij en voert de vervanging over alle tabellen in één bewerking uit, in de juiste volgorde. Het andersom doen kan WordPress onmogelijk maken om zijn eigen admin in te laden.

Na de vervanging

Werk deze lijst door voordat u klaar bent.

Flush de cache. In de sectie Quick Actions voert u Flush Cache uit. Als de site de volledige pagina-cache gebruikt, verwijdert u deze uit WordPress, vervolgens Caching.
Flush de rewrite-regels. Voer Flush Rewrites uit op dezelfde sectie, of open Settings, vervolgens Permalinks in wp-admin en klik op Save Changes zonder iets te wijzigen.
Verwijder de CDN als de site erop staat, vanuit Performance, vervolgens Kapsule CDN. Zie De CDN-cache verwijderen.
Laad de site in een privévenster zodat uw browsercache u niet kan misleiden.
Controleer het hangslot. Een ontbrekend of waarschuwingshangslot na een SSL-verplaatsing betekent dat URL's zijn achtergelaten: Waarschuwingen over gemengde inhoud herstellen.
Klik door de moeilijke pagina's. Startpagina-sliders, het header-logo, elke pagina gebouwd met een page builder, en de checkout op een winkel. Deze bevatten de URL's die in geserialiseerde opties leven.
Wis een caching-plugin uit het eigen instellingenscherm.

Probleemoplossing

De dry run rapporteert nul vervangingen. De string staat niet in exact die vorm in de database. Controleer op een slash aan het einde, een www. voorvoegsel, of het schema. Probeer eerst naar alleen de bare hostnaam te zoeken om te bevestigen dat het daar überhaupt is.

Afbeeldingen zijn verbroken na een domeinwijziging. Media-URL's bevinden zich in wp_posts en wp_postmeta en worden opgehaald door --all-tables, maar een CDN of afbeeldingsoptimalisatie-plugin kan zijn eigen herschreven kopieën in cache opslaan. Verwijder de CDN en de cache van de plugin, laad vervolgens opnieuw.

Instellingen verdwenen na de vervanging. Dat is het serialisatieprobleem, en het betekent dat de wijziging met raw SQL is aangebracht in plaats van via de tools hier. Herstel de back-up die voor de run is gemaakt: Herstellen van een back-up.

Staging-URL's blijven terugkomen. Iets vult ze opnieuw in, meestal een geplande push of een cached optie. Controleer de workflow in Staging gebruiken: pushen en pullen en zorg ervoor dat Rewrite URLs is ingeschakeld wanneer u pusht.

Een zoeken en vervangen uitvoeren in uw WordPress database