Search & Replace SQL

Baguhin ang URL ng iyong site nang hindi sinisira ang serialized na data

Tumatakbo sa iyong browser. Walang ina-upload.

Ang pagbabago

Lumang URL Bagong URL Table prefixTingnan ang wp-config.php. Hindi ito palaging wp_ — at sa isang multisite, siguradong hindi.

Basahin ito bago ka magpatakbo ng kahit ano

Iniimbak ng WordPress ang maraming opsyon bilang PHP-serialized na mga string, at ang isang serialized na string ay nagre-record ng sarili nitong haba sa byte — s:19:"http://old-site.com". Ang payak na SQL replace ay binabago ang teksto ngunit hindi ang haba, kaya hindi na maaaring i-unserialize ng PHP ang row. Hindi ito nag-e-error. Basta na lang tahimik na nagiging walang laman ang halaga.

Ang mawawala sa iyo: konpigurasyon ng widget, mga theme mod, at karamihan sa mga setting ng plugin. Kadalasan, hindi mo ito napapansin hanggang makalipas ang ilang araw, at sa puntong iyon wala na rin ang backup na sana ay ibinalik mo.

Ito ang dahilan kung bakit ang mga query sa ibaba ay sadyang hindi hinahawakan ang wp_options.

Ano ang inililipat mo?

Nilalaman at mga excerpt ng postAng post_content at post_excerpt ay plain text. Ligtas. I-rewrite din ang GUID columnHUWAG lagyan ng tsek ito maliban kung alam mo kung bakit mo kailangan. Ang GUID ay permanenteng natatanging identifier, hindi URL — ang pagbabago nito ay nagpapaituring sa bawat feed reader na bagong-bago ang bawat lumang post. Post meta (maaaring serialized — mapanganib)Madalas na naglalaman ang postmeta ng serialized na data. Ang paglalagay ng tsek dito ay nagpapakita sa iyo ng query na may nakakabit na malakas na babala.

search-replace.sql

Kumuha muna ng backup ng database. Hindi 'pag-isipang kumuha' — kumuha talaga. Walang undo para sa isang UPDATE.

Tungkol sa Search & Replace SQL

Ang isang basta-bastang SQL find-and-replace sa isang WordPress database ay sinisira ang bawat serialized na option na madampian nito, dahil hindi na tumutugma ang nakaimbak na haba ng string. Bumubuo ito ng mga query na ligtas, at ipinapaliwanag nang eksakto kung alin ang hindi.

Kaugnay

Iba pang tools na baka kailanganin mo

wp-config.php Generator

Bumuo ng tamang wp-config.php nang hindi kinokopya mula sa isang blog post noong 2014

FAQ

Mga Tanong

Puwede ko bang baguhin ang aking WordPress site URL gamit ang isang SQL find and replace?

Hindi nang ligtas, at ito ang pinaka-ibinabahaging masamang payo sa WordPress. Maraming option ang naka-store bilang PHP-serialized na strings na nagre-record ng sariling byte length. Ang isang plain SQL replace ay binabago ang text ngunit hindi ang length, kaya tahimik na nabibigo ang PHP na i-unserialize ang row at basta na lang nawawala ang value — dala ang widget settings, theme mods at plugin config.

Ano ang dapat kong gamitin sa halip?

WP-CLI: 'wp search-replace old new --all-tables --dry-run' muna, tapos nang walang --dry-run. Nauunawaan nito ang serialization at muling isinusulat ang length prefixes nang tama. Kung wala kang CLI access, ang Better Search Replace plugin ay gumagawa ng parehong bagay mula sa admin.

Dapat ko bang i-update ang GUID column?

Hindi. Ang GUID ay isang permanenteng unique identifier para sa isang post, hindi isang link, at umaasa dito ang feed readers. Ang pag-rewrite nito ay ginagawang makita ng bawat subscriber ang bawat lumang post bilang bagong-bago. Malinaw na sinasabi ng dokumentasyon ng WordPress na huwag itong baguhin.