Zoeken & vervangen SQL

Wijzig je site-URL zonder geserialiseerde data te beschadigen

Draait in je browser. Er wordt niets geüpload.

De wijziging

Oude URL Nieuwe URL TabelprefixControleer wp-config.php. Het is niet altijd wp_ — en op een multisite zeker niet.

Lees dit voordat je iets uitvoert

WordPress slaat veel opties op als PHP-serialized strings, en een geserialiseerde string legt zijn eigen bytelengte vast — s:19:"http://old-site.com". Een gewone SQL-replace verandert de tekst maar niet de lengte, waardoor PHP de rij niet meer kan deserialiseren. Er komt geen foutmelding. De waarde wordt gewoon stilletjes leeg.

Wat je kwijtraakt: widgetconfiguratie, thema-aanpassingen en de meeste plugininstellingen. Meestal merk je het pas dagen later, en tegen die tijd is de back-up die je had willen terugzetten ook verdwenen.

Daarom raken de onderstaande queries bewust wp_options niet aan.

Wat verplaats je?

Berichtinhoud en samenvattingenpost_content en post_excerpt zijn platte tekst. Veilig. Ook de GUID-kolom herschrijvenVink dit NIET aan tenzij je weet waarom je het nodig hebt. De GUID is een permanente unieke identificatie, geen URL — hem wijzigen laat elke feedlezer elk oud bericht als gloednieuw behandelen. Post-meta (kan geserialiseerd zijn — riskant)postmeta bevat vaak geserialiseerde data. Dit aanvinken toont je de query met een nadrukkelijke waarschuwing erbij.

search-replace.sql

Maak eerst een databaseback-up. Niet 'overweeg er een te maken' — maak er een. Er is geen ongedaan maken voor een UPDATE.

Over de Zoeken & vervangen SQL

Een naïeve SQL-zoek-en-vervang op een WordPress-database breekt elke geserialiseerde optie die hij raakt, omdat de opgeslagen tekenreekslengte niet meer klopt. Deze tool genereert de query's die veilig zijn, en legt precies uit welke dat niet zijn.

Gerelateerd

Andere tools die je misschien nodig hebt

wp-config.php-generator

Bouw een correcte wp-config.php zonder te kopiëren uit een blogpost uit 2014

FAQ

Vragen

Kan ik mijn WordPress-site-URL wijzigen met een SQL find-and-replace?

Niet veilig, en dit is het meest gedeelde slechte advies in WordPress. Veel opties worden opgeslagen als PHP-geserialiseerde strings die hun eigen bytelengte vastleggen. Een gewone SQL-replace verandert de tekst maar niet de lengte, dus PHP faalt stilletjes bij het deserialiseren van de rij en de waarde verdwijnt simpelweg — samen met widgetinstellingen, thememods en pluginconfig.

Wat moet ik in plaats daarvan gebruiken?

WP-CLI: 'wp search-replace old new --all-tables --dry-run' eerst, dan zonder --dry-run. Het begrijpt serialisatie en herschrijft de lengteprefixen correct. Als je geen CLI-toegang hebt, doet de plugin Better Search Replace hetzelfde vanuit het beheer.

Moet ik de GUID-kolom bijwerken?

Nee. De GUID is een permanente unieke identifier voor een bericht, geen link, en feedreaders gebruiken hem als sleutel. Hem herschrijven zorgt ervoor dat elke abonnee elk oud bericht als gloednieuw ziet. De WordPress-documentatie zegt expliciet hem niet te wijzigen.