วิธีปรับปรุงการโยกย้ายหลายไซต์ของ WordPress ด้วย MU-Migration

การย้ายไซต์ WordPress แบบสแตนด์อโลนไปยังเครือข่ายไซต์ (หรือ "หลายไซต์") เป็นความพยายามที่น่าเบื่อและยุ่งยาก ตรงกันข้ามก็เป็นความจริงเช่นกัน ตัวนำเข้า WordPress ทำงานได้ดีพอสมควรสำหรับไซต์ขนาดเล็กและเรียบง่าย แต่ยังเหลือพื้นที่สำหรับการปรับปรุง โดยจะส่งออกเนื้อหา แต่ไม่ใช่ข้อมูลการกำหนดค่าไซต์ เช่น การกำหนดค่าวิดเจ็ตและเครื่องมือปรับแต่ง ปลั๊กอิน และการตั้งค่าไซต์ ผู้นำเข้ายังประสบปัญหาในการจัดการเนื้อหาจำนวนมาก ในบทความนี้ คุณจะได้เรียนรู้วิธีปรับปรุงการย้ายประเภทนี้โดยใช้ MU-Migration ซึ่งเป็นปลั๊กอิน WP-CLI

การทำความเข้าใจ Multisite

ไซต์หลายไซต์ของ WordPress ช่วยให้คุณสามารถเรียกใช้หลายเว็บไซต์ภายในการติดตั้ง WordPress เดียวกันได้ มักเรียกกันว่า "เครือข่ายหลายไซต์" WordPress.com อาจเป็นตัวอย่างที่ใหญ่ที่สุดของเครือข่ายหลายไซต์ โดยใช้งานไซต์หลายพันไซต์ภายในอินสแตนซ์ WordPress เดียวกัน

ไซต์หลายไซต์ของ WordPress อาจเหมาะสมอย่างยิ่งกับกรณีการใช้งานหลายกรณี บางส่วนรวมถึง:

• ลูกค้าของคุณอาจมีพร็อพเพอร์ตี้หลายรายการ และการรวมเว็บไซต์ทั้งหมดเข้าไว้ในการติดตั้ง WordPress ที่ไม่ซ้ำใคร เป็นการแชร์โดเมนเดียวแต่ไม่จำกัดเพียงโดเมนเดียว

• เมื่อคุณตั้งค่าแล้ว จะเป็นกระบวนการที่ง่ายและตรงไปตรงมาในการสร้างไซต์ใหม่และใช้ประโยชน์จากธีมและปลั๊กอินที่มีอยู่แล้วในเครือข่าย

ความเข้าใจอย่างลึกซึ้งเกี่ยวกับวิธีการทำงานแบบหลายไซต์นั้นอยู่นอกเหนือขอบเขตของบทความนี้ แต่คุณสามารถตรวจสอบลิงก์ต่อไปนี้ได้:

• “สร้างเครือข่าย” Codex, WordPress.org

• “WordPress Multisite: ฟังก์ชั่นและวิธีการที่ใช้งานได้จริง” Kevin Leary, Smashing Magazine

ทำความเข้าใจกับความท้าทาย

ความแตกต่างระหว่างโครงสร้างของไซต์เดียวและหลายไซต์ของ WordPress นั้นค่อนข้างสมเหตุสมผล ด้วย multisite แต่ละไซต์ย่อยจะได้รับชุดตารางฐานข้อมูลของตนเอง ยกเว้นตารางของผู้ใช้ ( wp_user ) ที่แชร์กันระหว่างไซต์ทั้งหมด วิธีการทำงานบน WordPress คือชุดไซต์ย่อยแต่ละชุดมี ID ของไซต์ที่เพิ่มในแต่ละชื่อตาราง ( wp_X_posts , wp_X_postmeta , wp_X_options )

โครงสร้างฐานข้อมูลนี้เองได้แนะนำความซับซ้อนบางอย่างไปแล้ว ตัวอย่างเช่น คุณจะย้ายไซต์ย่อยจากหลายไซต์ไปเป็นการติดตั้งครั้งเดียวได้อย่างไร เห็นได้ชัดว่าคุณไม่สามารถส่งออกและนำเข้าฐานข้อมูลในการติดตั้งครั้งเดียวได้ ชื่อตารางต่างกัน! คุณจะต้องเปลี่ยนชื่อตารางในไฟล์ .sql ที่ส่งออก หรือใช้แบบสอบถาม ALTER TABLE SQL เพื่อเปลี่ยนชื่อตารางหลังจากนำเข้า เช่นเดียวกับในทางตรงข้าม: หากคุณกำลังนำเข้าไซต์เดียวไปยังไซต์หลายไซต์ คุณจะต้องอัปเดตคำนำหน้าของตารางด้วย ฟังดูเหมือนงานมากเกินไปใช่ไหม

ตารางของผู้ใช้ในหลายไซต์เป็นแบบโกลบอล ซึ่งหมายความว่าคุณไม่สามารถนำเข้าตารางของผู้ใช้จากไซต์เดียวได้ เนื่องจากจะแทนที่ตารางของผู้ใช้ทั่วโลกที่มีหลายไซต์โดยสมบูรณ์ หากคุณกำลังทำตรงกันข้าม แยกไซต์ย่อยออกจาก WordPress และนำเข้าไปยังไซต์เดียว คุณจะต้องแบกรับผู้ใช้เครือข่ายทั้งหมด แม้กระทั่งผู้ใช้ที่ไม่ได้อยู่ในไซต์ย่อยที่กำลังถูกย้าย นอกจากนี้ หากย้ายไซต์ย่อยจากหลายไซต์หนึ่งไปยังอีกไซต์หนึ่ง การส่งออกตารางของผู้ใช้จะออกจากตารางโดยสมบูรณ์

ทางออกที่ดีที่สุดคือการส่งออกผู้ใช้แยกกัน แต่เกิดปัญหาอีกประการหนึ่ง: เมื่อนำเข้าผู้ใช้แล้ว จะได้รับ ID ที่แตกต่างกัน เพื่อแก้ปัญหานี้ จำเป็นต้องติดตาม ID ผู้ใช้ใหม่ สร้างตารางการแมป และใช้ตารางการแมปเพื่ออัปเดตการอ้างอิงทั้งหมดไปยัง ID ผู้ใช้ใน WordPress! อีกครั้ง งานมากเกินไปใช่มั้ย?

นี่เป็นเพียงสองตัวอย่างของความท้าทายที่เราเผชิญได้เมื่อต้องรับมือกับการย้ายถิ่นในลักษณะนี้ มีสิ่งเล็กๆ น้อยๆ อื่นๆ อีกมากที่ต้องดูแล เช่น การย้ายโฟลเดอร์อัปโหลดไปยังตำแหน่งที่เหมาะสม การย้ายระเบียนในฐานข้อมูลที่อ้างอิง ID ของไซต์ เป็นต้น

พบกับ MU-Migration

MU-Migration เป็นปลั๊กอิน WP-CLI ที่ฉันสร้างขึ้นในขณะที่ทำงานกับการโยกย้ายไคลเอนต์หลายตัวและเปิดแหล่งที่มาในภายหลังโดย 10up ได้รับการออกแบบมาเพื่อปรับปรุงกระบวนการย้ายไซต์จากไซต์ WordPress เดียวไปยังอินสแตนซ์หลายไซต์ (หรือกลับกัน) โดยพื้นฐานแล้วจะส่งออกทุกอย่างลงในแพ็คเกจ ZIP ซึ่งสามารถใช้เพื่อนำเข้าไซต์ในการติดตั้ง WordPress ที่ต้องการ

มันทำงานโดยการส่งออกเนื้อหาของเว็บไซต์และตัวเลือกธีม ปลั๊กอิน และโฟลเดอร์อัพโหลดไปยังแพ็คเกจ zip ที่นำเข้าไปยังการติดตั้ง WordPress อื่นได้อย่างง่ายดาย เมื่อใช้ MU-Migration คุณไม่จำเป็นต้องกังวลเกี่ยวกับรายละเอียดทางเทคนิคที่สำคัญของการย้ายข้อมูล มันจะดูแลทั้งหมดนั้นให้คุณ เพื่อให้คุณสามารถมุ่งเน้นไปที่สิ่งที่สำคัญ: ส่งมอบการย้ายที่ประสบความสำเร็จให้กับลูกค้าของคุณ

การติดตั้ง WP-CLI และ MU-Migration

ในการใช้ MU-Migration คุณต้องติดตั้ง WP-CLI ซึ่งเป็นเครื่องมือบรรทัดคำสั่งอย่างเป็นทางการของ WordPress ก่อน การติดตั้ง WP-CLI ทำได้ง่ายเพียงแค่รันคำสั่งด้านล่างบนเซิร์ฟเวอร์ของคุณ:

 $ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar $ chmod +x wp-cli.phar $ sudo mv wp-cli.phar /usr/local/bin/wp

หลังจากทำตามขั้นตอนเหล่านี้แล้ว คุณจะสามารถรัน WP-CLI ได้โดยพิมพ์ wp จากการติดตั้ง WordPress ใดๆ ก็ตาม ตราบใดที่คุณอยู่ในไดเร็กทอรีรากของ WordPress

ตัวอย่างเช่น ในโฟลเดอร์การติดตั้ง WordPress ให้ลองเรียกใช้คำสั่งต่อไปนี้:

 $ wp theme status

เป็นคำสั่งง่ายๆ และจะแสดงรายการธีมทั้งหมดที่มี โดยเน้นว่าธีมใดที่ใช้งานอยู่ในปัจจุบัน

สุดท้าย ในการติดตั้ง MU-Migration คุณสามารถใช้คำสั่ง package install ได้ ใช้คำสั่งต่อไปนี้เพื่อดาวน์โหลดและติดตั้ง MU-Migration เป็นปลั๊กอิน WP-CLI

 $ wp package install 10up/mu-migration

เรียกใช้การโยกย้ายอย่างง่าย

การใช้ MU-Migration นั้นค่อนข้างง่าย สำหรับสถานการณ์แรกของเรา เราจะย้ายไซต์ WordPress เดียวไปยังการติดตั้งหลายไซต์ของ WordPress

การส่งออกเว็บไซต์เดียว

เราจะเริ่มต้นด้วยการส่งออกไซต์เดียว ในการทำเช่นนั้น เราต้องใช้คำสั่ง export all :

 $ wp mu-migration export all single-site.zip --themes --plugins --uploads

คำสั่งด้านบนจะส่งออกทั้งไซต์เป็นแพ็คเกจ ZIP แฟล็ --themes , --plugins และ --uploads เป็นทางเลือก และจะรวมธีมปัจจุบัน ปลั๊กอินทั้งหมด และโฟลเดอร์อัปโหลดตามลำดับในการส่งออก อาจใช้เวลาสักครู่ในการดำเนินการให้เสร็จสิ้น ทั้งนี้ขึ้นอยู่กับขนาดของไซต์ของคุณ แต่สำหรับไซต์ส่วนใหญ่ กระบวนการส่งออกไม่ควรใช้เวลาเกินสองสามนาที

เมื่อเสร็จแล้ว มันจะสร้างไฟล์ชื่อ single-site.zip ที่มีข้อมูล ธีม และปลั๊กอินทั้งหมดของเว็บไซต์ รวมถึงไดเร็กทอรีอัพโหลด ขั้นตอนต่อไปคือการย้ายไปยังเซิร์ฟเวอร์ที่มีหลายไซต์ของ WordPress คุณสามารถใช้ไคลเอ็นต์ SFTP ที่ต้องการหรือโซลูชันที่มีประสิทธิภาพมากขึ้น เช่น rsync

การนำเข้าไซต์เดียวไปยังหลายไซต์

ด้วยไฟล์ที่ส่งออกในเซิร์ฟเวอร์หลายไซต์ของคุณ สิ่งที่คุณต้องทำคือใช้คำสั่งนำเข้าจากไดเร็กทอรีหลายไซต์ของ WordPress; จำเป็นต้องติดตั้งทั้ง WP-CLI และ MU-Migration บนเซิร์ฟเวอร์ปลายทางด้วย

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site

คำสั่งด้านบนจะใช้ไฟล์ single-site.zip ไฟล์และนำเข้าทุกอย่างไปยังหลายไซต์ มันจะสร้างไซต์ย่อยใหม่ในเครือข่ายของคุณ พารามิเตอร์ --new_url เป็นทางเลือก มันจะสั่งให้ MU-Migration ทำการค้นหาและแทนที่เพื่อแทนที่ URL ไซต์ทั้งหมดของไซต์ที่ส่งออกด้วย URL ที่ระบุ พารามิเตอร์นี้มีประโยชน์เมื่อการโยกย้ายรวมถึงการเปลี่ยนแปลงของ URL หรือหากคุณกำลังนำเข้าในเครื่อง หรือแม้แต่ในสภาพแวดล้อมการจัดเตรียม

กระบวนการนำเข้ามักจะใช้เวลานานกว่าและขึ้นอยู่กับขนาดของไซต์ที่คุณกำลังนำเข้า แต่อย่ากลัว MU-Migration จะแจ้งข้อมูลอัปเดตให้คุณทราบเมื่อการโยกย้ายดำเนินการ เมื่อกระบวนการเสร็จสิ้น MU-Migration จะแจ้ง URL สุดท้ายของไซต์ที่คุณนำเข้า ขอแนะนำอย่างยิ่งให้ล้างเลเยอร์แคชทั้งหมด ที่ทำงานบนเซิร์ฟเวอร์ของคุณ โดยเฉพาะ Memcache หรือ Redis

เรียกใช้การย้ายข้อมูลอีกครั้ง

เมื่อทำการโยกย้าย เป็นเรื่องปกติที่จะทำแบบแห้งก่อนโดยมีวัตถุประสงค์เพื่อทดสอบสิ่งต่าง ๆ ก่อนทำการโยกย้ายขั้นสุดท้าย ซึ่งมักจะหมายถึงการส่งออกและนำเข้าอีกครั้งในการติดตั้งแบบหลายไซต์ปลายทาง อย่างไรก็ตาม โปรดทราบว่าในตัวอย่างการย้ายครั้งแรกของเรา MU-Migration ได้สร้างไซต์ย่อยใหม่ภายในเครือข่ายเพื่อนำเข้าไซต์เดียวที่ด้านบน การรันคำสั่งเดิมอีกครั้งจะนำไปสู่การสร้างไซต์ย่อยอื่น ซึ่งไม่ใช่สิ่งที่เราคาดหวังอย่างแน่นอน

โชคดีที่สามารถระบุ blog_id ซึ่งบอกให้ MU-Migration แทนที่ไซต์ย่อยด้วย blog_id ที่ระบุ ตัวอย่างเช่น สมมติว่าคำสั่งนำเข้าก่อนหน้านี้สร้างไซต์ย่อยที่มี 2 เป็น ID และคุณต้องการเรียกใช้การย้ายข้อมูลอีกครั้ง คุณสามารถทำสิ่งต่อไปนี้:

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site --blog_id=2

ถ้าคุณไม่รู้จัก blog_id คุณสามารถรับได้ผ่านการตั้งค่าผู้ดูแลระบบเครือข่าย หรือโดยการเรียกใช้ $ wp site list

การแยกไซต์ย่อยจากการติดตั้งแบบหลายไซต์

MU-Migration ยังสนับสนุนการแยกไซต์ย่อยจากการติดตั้งแบบหลายไซต์และนำเข้าไปยังไซต์อื่นหรือในไซต์เดียว

สำหรับสองสถานการณ์นี้ เราจะเรียกใช้คำสั่ง export จากการติดตั้งแบบหลายไซต์ ไม่ใช่จากไซต์เดียว ซึ่งหมายความว่าเราต้องการวิธีระบุไซต์ย่อยที่เราต้องการส่งออก ในการทำเช่นนั้น เราเพียงแค่ส่งพารามิเตอร์ --blog_id ไปยังคำสั่ง export:

 $ wp mu-migration export all subsite-3.zip --themes --plugins --uploads --blog_id=3

ในตัวอย่างนี้ เรากำลังส่งออกไซต์ย่อยที่มี ID เท่ากับ 3 นี้จะสร้างไฟล์ ZIP ที่พร้อมที่จะนำเข้าไปยังหลายไซต์อื่นหรือในไซต์เดียว คำสั่งสำหรับการนำเข้าไปยังไซต์เดียวและหลายไซต์จะเหมือนกันทุกประการ MU-Migration จะตรวจพบว่ากำลังทำงานบนหลายไซต์หรือไม่ และจะปรับตัวเองให้เป็นอัตโนมัติ ในหมายเหตุด้านข้าง เมื่อนำเข้าไปยังอินสแตนซ์หลายไซต์อื่น คุณยังสามารถระบุพารามิเตอร์ --blog_id เพื่อแทนที่ไซต์ย่อยที่มีอยู่

 $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ]

เคล็ดลับสำหรับการโยกย้ายถิ่นฐานขนาดใหญ่

แม้ว่าตัวอย่างก่อนหน้านี้จะทำงานได้ดีมากสำหรับการย้ายข้อมูลขนาดเล็กถึงขนาดกลาง การย้ายไซต์ขนาดใหญ่ไปยังหรือจากหลายไซต์อาจใช้เวลาพอสมควร ในส่วนนี้ ฉันจะแบ่งปันบทเรียนบางส่วนที่ได้เรียนรู้ในขณะที่ทำการโยกย้ายแบบหลายองค์กร

สร้างแผนการย้ายถิ่น

การย้ายข้อมูลมักมีความจำเป็น แต่ก็เป็นส่วนที่ถูกละเลยในหลายโครงการ การย้ายถิ่นอาจเป็นเรื่องยุ่งยากและซับซ้อน แต่เมื่อวางแผนอย่างเหมาะสมแล้ว ก็จะไม่เจ็บปวด การสร้างแผนการย้ายถิ่นควรเป็นขั้นตอนแรกของโครงการการย้ายถิ่น

แผนการย้ายถิ่นโดยทั่วไปประกอบด้วยสิ่งต่างๆ เช่น:

• ผลกระทบของการย้ายข้อมูลต่อกระบวนการบรรณาธิการด้านการผลิตใดๆ (เช่น การหยุดเนื้อหา ข้อกำหนดการย้ายข้อมูลส่วนต่าง)

• คาดว่าการย้ายข้อมูลจะทำงานนานเท่าใด

• การสำรองข้อมูลจะถูกกู้คืนได้อย่างไร? การโยกย้ายที่ล้มเหลวจะได้รับการจัดการอย่างไร?

• กระบวนการส่งออกจะส่งผลต่อประสิทธิภาพของเว็บไซต์อย่างไร ไซต์จำนวนมากไม่สามารถส่งออกฐานข้อมูลในช่วงเวลาเร่งด่วนได้

ตามหลักการทั่วไป การโยกย้ายควรเป็นไปอย่างราบรื่นที่สุดเท่าที่จะเป็นไปได้ และตามหลักแล้ว ณ วันเปิดตัว การยกของหนักทั้งหมดจะเสร็จสมบูรณ์แล้ว และควรทำเฉพาะขั้นตอนที่จำเป็นอย่างยิ่งเท่านั้น ซึ่งหมายความว่าคุณควรย้ายข้อมูลทุกอย่างที่ทำได้ก่อนวันเปิดตัวจริง เนื่องจากจะทำให้คุณมีพื้นที่สำหรับแก้ไขข้อผิดพลาดและ QAing หากเป็นการสร้างไซต์ใหม่และคุณกำลังย้ายข้อมูล คุณมักจะได้รับประโยชน์จากหน้าต่างการหยุดเนื้อหาและทำให้เนื้อหาของคุณถูกย้ายล่วงหน้า คุณยังสามารถใช้กลยุทธ์เพื่อย้ายเนื้อหาของคุณไปเรื่อย ๆ ถ้าเป็นไปได้ ลองดูตัวอย่างเทคนิคนี้ในหัวข้อถัดไป

แม้ว่าจะละเลยหลายครั้ง แต่แผนการย้ายถิ่นที่เหมาะสมสามารถหลีกเลี่ยงปัญหาต่างๆ เกี่ยวกับการย้ายถิ่นได้ อย่าปล่อยให้สถานการณ์ที่ไม่คาดคิดทำให้การโยกย้ายของคุณล้มเหลว วางแผนล่วงหน้า! สำหรับการอภิปรายเชิงลึกเกี่ยวกับการวางแผนการย้ายถิ่น เราขอแนะนำให้คุณดูส่วนการย้ายถิ่นของแนวทางปฏิบัติที่ดีที่สุดของ 10up

ใช้ Rsync เพื่อคัดลอกการอัปโหลดอย่างต่อเนื่อง

โฟลเดอร์อัปโหลดของไซต์ขนาดใหญ่อาจมีขนาดใหญ่มาก และการบีบอัดเป็นไฟล์ ZIP เพื่อแยกไฟล์ในภายหลังอาจไม่ใช่วิธีแก้ปัญหาที่ดีที่สุดและรวดเร็วเสมอไป มีหลายวิธีในการคัดลอกโฟลเดอร์อัปโหลดไปยังเซิร์ฟเวอร์ปลายทาง เครื่องมือที่ใช้กันทั่วไปสำหรับการย้ายข้อมูลแบบองค์กรคือ rsync ซึ่งสามารถถ่ายโอนไฟล์ระหว่างเซิร์ฟเวอร์ได้เร็วกว่าการใช้โซลูชัน SFTP มาตรฐาน และยังสามารถหยุดชั่วคราวและกู้คืนการถ่ายโอนได้อีกด้วย มันติดตามว่ามีอะไรถูกโอนไปแล้ว หมายความว่าเราสามารถซิงค์ไฟล์ของเราได้เรื่อยๆ ตัวอย่างเช่น คุณสามารถเริ่มซิงค์ไฟล์ได้สองสามวันก่อนการโยกย้ายจริงเพื่อซื้อเวลาให้คุณ จากนั้นในวันที่ย้ายข้อมูล สิ่งที่คุณต้องทำคือซิงค์ไฟล์เพื่อให้แน่ใจว่าทุกอย่างที่เพิ่มเข้ามาตั้งแต่การซิงค์ครั้งล่าสุดจะถูกโอนไปยังเซิร์ฟเวอร์ปลายทาง

ข้อแม้เพียงอย่างเดียวของแนวทางนี้คือ คุณจะต้องย้ายไดเรกทอรีย่อยของการอัปโหลดไปยังตำแหน่งที่ถูกต้องด้วยตนเอง เนื่องจากหลายไซต์มีโครงสร้างที่แตกต่างกันเล็กน้อยสำหรับโฟลเดอร์อัปโหลด: แต่ละไซต์จะมีโฟลเดอร์ย่อยของตัวเองซึ่งมีชื่อเป็น ID ของไซต์ .

เป็นตัวอย่างสุดท้าย มาดูกันว่าเราจะย้ายไซต์เดียวขนาดใหญ่เป็นอินสแตนซ์หลายไซต์ได้อย่างไร เราจะเริ่มด้วยการส่งออกไซต์เดียวไปยังแพ็คเกจ ZIP และเรียกใช้การทดสอบแบบแห้งบนเซิร์ฟเวอร์ปลายทาง เมื่อถึงจุดนั้น ทุกคนจะไม่สามารถเข้าถึงไซต์ได้ เนื่องจากโดเมนยังคงชี้ไปที่เซิร์ฟเวอร์เก่า ซึ่งหมายความว่าคุณสามารถชี้ไฟล์ของโฮสต์ไปยังเซิร์ฟเวอร์ใหม่ได้อย่างปลอดภัยเพื่อทดสอบการย้ายข้อมูล คุณยังสามารถเปิดใช้งานปลั๊กอิน เช่น จำกัดการเข้าถึงไซต์บนไซต์ปลายทาง เพื่อให้แน่ใจว่าจะไม่สามารถเข้าถึงได้แบบสาธารณะไม่ว่าด้วยวิธีใด

สำหรับการทดสอบแบบทดสอบรัน เราจะส่งออกไซต์ก่อนวันย้ายที่วางแผนไว้สองสามวันหรือหลายสัปดาห์เพื่อทดสอบและทำความเข้าใจว่ากระบวนการนี้จะใช้เวลานานแค่ไหน โปรดทราบว่า ไม่ รวมโฟลเดอร์อัปโหลด

ทำแห้งก่อน

ทำแห้งก่อนเสมอ ตามหลักการแล้ว dry-run ควรเกิดขึ้นบนเซิร์ฟเวอร์จริงหรือในสภาพแวดล้อมการจัดเตรียมที่มีเซิร์ฟเวอร์สแต็กที่คล้ายคลึงกัน

พิจารณาใช้ --mysql-single-transaction

คำสั่งนำเข้ายังสนับสนุน --mysql-single-transaction ที่จะห่อการส่งออก SQL ให้เป็นธุรกรรมเดียวเพื่อยอมรับการเปลี่ยนแปลงทั้งหมดจากการนำเข้าในครั้งเดียว ป้องกันไม่ให้เขียนจากเซิร์ฟเวอร์ฐานข้อมูล โดยเฉพาะอย่างยิ่งในสภาพแวดล้อม MySQL แบบคลัสเตอร์

 $ cd /path/to/wordpress $ wp mu-migration export all site.zip --themes --plugins

ด้วย rsync เราสามารถถ่ายโอนไฟล์ที่ส่งออกที่สร้างขึ้นได้อย่างง่ายดาย:

 $ rsync -aP site.zip [email protected]:/var/www/multisite/

จากนั้นเราเรียกใช้คำสั่งนำเข้าบนเซิร์ฟเวอร์ปลายทาง:

 $ ssh [email protected] $ cd /var/www/multisite $ wp mu-migration import all site.zip

ตอนนี้เราจำเป็นต้องรู้ว่า blog_id ของไซต์ย่อยที่สร้างขึ้นใหม่คืออะไร เราสามารถรับข้อมูลนั้นได้โดยเรียกใช้:

จากผลลัพธ์ของคำสั่งข้างต้น เรารู้ว่าไซต์ของเราถูกนำเข้าด้วย ID 2 เราจำเป็นต้องใช้เพื่อย้ายโฟลเดอร์อัพโหลดอย่างถูกต้องโดยใช้ rsync จากเซิร์ฟเวอร์ไซต์เดียว เราจะเรียกใช้สิ่งต่อไปนี้:

 $ rsync -azP wp-content/uploads/ [email protected]:/var/www/multisite/wp-content/uploads/sites/2/

คำสั่งดังกล่าวจะคัดลอกโฟลเดอร์อัปโหลดทั้งหมดไปยังตำแหน่งที่ถูกต้องในการติดตั้งหลายไซต์ ซึ่งอยู่ภายใต้โฟลเดอร์ไซต์และภายในโฟลเดอร์ที่ชื่อเป็นเพียง ID ของไซต์ (ในกรณีนี้คือ 2) ณ จุดนี้ เราสามารถแก้ไขไฟล์ของโฮสต์เพื่อชี้โดเมนไซต์เดียวไปยังเซิร์ฟเวอร์หลายไซต์ จากนั้นเราสามารถทำการทดสอบเพื่อให้แน่ใจว่าการย้ายข้อมูลทำงานตามที่คาดไว้

สำหรับการโยกย้ายครั้งสุดท้าย ทุกอย่างจะเหมือนเดิม ยกเว้นว่าเราจะส่ง --blog_id=2 ไปยังคำสั่งนำเข้า:

 $ wp mu-migration import all site.zip --blog_id=2

และข้อดีก็คือ การซิงค์การอัปโหลดจะเกิดขึ้นเร็วกว่ามาก เนื่องจาก rsync จะโอนเฉพาะไฟล์ที่มีการเปลี่ยนแปลงหรือเพิ่มตั้งแต่การซิงค์ครั้งล่าสุดเท่านั้น

บทสรุป

การโยกย้ายไปยังหรือจากหลายไซต์นั้นทำได้ยาก และเครื่องมือที่แนะนำในบทความนี้ช่วยลดความยุ่งยากของกระบวนการย้ายข้อมูลทั้งหมดโดยลดความพยายามที่จะใช้คำสั่ง CLI สองสามคำสั่ง MU-Migration ถูกใช้อย่างแข็งขันในการผลิตมานานกว่าหนึ่งปีและเป็นโครงการโอเพนซอร์ซที่สมบูรณ์ ปลั๊กอินได้รับการพัฒนาบน Github และยินดีต้อนรับคำขอดึง!