SQL ค้นหาและแทนที่

เปลี่ยน URL ของเว็บไซต์โดยไม่ทำให้ข้อมูลแบบ serialized เสียหาย

ทำงานในเบราว์เซอร์ของคุณ ไม่มีการอัพโหลดอะไร

การเปลี่ยนแปลง

URL เดิม URL ใหม่ prefix ของตารางตรวจสอบใน wp-config.php ค่านี้ไม่ได้เป็น wp_ เสมอไป — และบน multisite ยิ่งไม่ใช่แน่นอน

อ่านตรงนี้ก่อนจะรันอะไร

WordPress จัดเก็บตัวเลือกจำนวนมากในรูปแบบสตริงที่เป็น PHP-serialized และสตริงที่ผ่านการ serialize จะบันทึกความยาวเป็นไบต์ของตัวมันเองเอาไว้ด้วย — s:19:"http://old-site.com" การแทนที่ด้วย SQL ธรรมดาจะเปลี่ยนข้อความแต่ไม่เปลี่ยนความยาว ทำให้ PHP ไม่สามารถ unserialize แถวข้อมูลนั้นได้อีกต่อไป โดยจะไม่มีการแจ้งข้อผิดพลาดใด ๆ ค่าดังกล่าวจะกลายเป็นค่าว่างไปเงียบ ๆ

สิ่งที่คุณจะเสียไป: การตั้งค่าวิดเจ็ต, theme mod และการตั้งค่าปลั๊กอินส่วนใหญ่ โดยทั่วไปคุณจะ ไม่ทันสังเกตจนผ่านไปหลายวัน และถึงตอนนั้นตัวสำรองที่คุณจะเอามากู้คืนก็หายไปแล้วเช่นกัน

นี่คือเหตุผลที่คำสั่งคิวรีด้านล่างจงใจไม่แตะต้อง wp_options

คุณกำลังย้ายอะไร?

เนื้อหาโพสต์และบทคัดย่อ (excerpt)post_content และ post_excerpt เป็นข้อความธรรมดา ปลอดภัย เขียนทับคอลัมน์ GUID ด้วยอย่าติ๊กช่องนี้เว้นแต่คุณรู้ว่าทำไมถึงต้องใช้ GUID คือตัวระบุเฉพาะแบบถาวร ไม่ใช่ URL — การเปลี่ยนมันทำให้โปรแกรมอ่าน feed มองว่าโพสต์เก่าทุกโพสต์เป็นของใหม่ทั้งหมด Post meta (อาจเป็นข้อมูลแบบ serialized — เสี่ยง)postmeta มักมีข้อมูลแบบ serialized การติ๊กช่องนี้จะแสดง query พร้อมคำเตือนชัดเจนแนบมาด้วย

search-replace.sql

สำรองข้อมูลฐานข้อมูลก่อนเป็นอันดับแรก ไม่ใช่แค่ 'ลองคิดจะสำรองดู' — แต่ให้สำรองจริงๆ เพราะ UPDATE ไม่มีการย้อนกลับ (undo)

เกี่ยวกับ SQL ค้นหาและแทนที่

การค้นหาและแทนที่ด้วย SQL แบบง่าย ๆ บนฐานข้อมูล WordPress จะทำให้ตัวเลือกแบบ serialized ทุกตัวที่ถูกแตะเสียหาย เพราะความยาวของสตริงที่เก็บไว้จะไม่ตรงกันอีกต่อไป เครื่องมือนี้จะสร้างคำสั่ง query ที่ปลอดภัย และอธิบายให้ชัดเจนว่าคำสั่งไหนที่ไม่ปลอดภัย

ที่เกี่ยวข้อง

เครื่องมืออื่นที่คุณอาจต้องใช้

ตัวสร้าง wp-config.php

สร้าง wp-config.php ที่ถูกต้อง โดยไม่ต้องคัดลอกมาจากบล็อกโพสต์เมื่อปี 2014

คำถามที่พบบ่อย

คำถาม

เปลี่ยน URL เว็บ WordPress ด้วยการ find and replace แบบ SQL ได้ไหม?

ไม่ปลอดภัย และนี่คือคำแนะนำแย่ๆ ที่ถูกแชร์มากที่สุดในวงการ WordPress หลาย option ถูกเก็บเป็นสตริงแบบ PHP-serialized ที่บันทึกความยาวไบต์ของตัวเองไว้ การ replace แบบ SQL ธรรมดาเปลี่ยนข้อความแต่ไม่เปลี่ยนความยาว PHP จึง unserialize แถวนั้นล้มเหลวเงียบๆ และค่านั้นก็หายไปเฉยๆ — พาการตั้งค่า widget, theme mod และ config ของปลั๊กอินหายไปด้วย

แล้วควรใช้อะไรแทน?

WP-CLI: 'wp search-replace old new --all-tables --dry-run' ก่อน แล้วค่อยรันแบบไม่มี --dry-run มันเข้าใจ serialization และเขียน length prefix ใหม่ได้ถูกต้อง ถ้าคุณไม่มีสิทธิ์เข้า CLI ปลั๊กอิน wordpress ชื่อ Better Search Replace ทำสิ่งเดียวกันได้จากหน้า admin

ควรอัปเดตคอลัมน์ GUID ไหม?

ไม่ GUID เป็นตัวระบุเฉพาะถาวรของโพสต์ ไม่ใช่ลิงก์ และตัวอ่าน feed ใช้มันเป็นกุญแจ การเขียนมันใหม่ทำให้ผู้ติดตามทุกคนเห็นโพสต์เก่าทุกโพสต์เป็นของใหม่เอี่ยม เอกสารของ WordPress ระบุชัดว่าอย่าเปลี่ยนมัน