Zoeken & vervangen SQL

Wijzig je site-URL zonder geserialiseerde data te beschadigen

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

The change

Old URL New URL Table prefixCheck wp-config.php. It is not always wp_ — and on a multisite it definitely is not.

Read this before you run anything

WordPress stores many options as PHP-serialized strings, and a serialized string records its own byte length — s:19:"http://old-site.com". A plain SQL replace changes the text but not the length, so PHP can no longer unserialize the row. It does not error. The value just silently becomes empty.

What you lose: widget configuration, theme mods, and most plugin settings. Usually you do not notice until days later, and by then the backup you would have restored is gone too.

This is why the queries below deliberately do not touch wp_options.

What are you moving?

Post content and excerptspost_content and post_excerpt are plain text. Safe. Also rewrite the GUID columnDo NOT tick this unless you know why you need to. The GUID is a permanent unique identifier, not a URL — changing it makes every feed reader treat every old post as brand new. Post meta (may be serialized — risky)postmeta often contains serialized data. Ticking this shows you the query with a loud warning attached.

search-replace.sql

Take a database backup first. Not 'consider taking one' — take one. There is no undo for an 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.