Cara Memindahkan Satu Situs Klien dari Jaringan WordPress Multisite

Jika Anda mengelola agensi atau layanan hosting di WordPress Multisite, momen ini tidak bisa dihindari: ada satu klien yang sudah terlalu besar untuk berada di jaringan tersebut, atau ingin memindahkan situs mereka ke hosting mereka sendiri, atau Anda hanya perlu mengisolasinya untuk urusan penagihan dan dukungan (support). Di atas kertas, mengekstrak satu subsite terdengar seperti proses ekspor lima menit saja. Kenyataannya, ini adalah salah satu pekerjaan paling merepotkan di WordPress. Panduan ini menjelaskan alur kerja yang tepat untuk menarik satu subsite dengan rapi dan membangunnya kembali sebagai situs mandiri yang sepenuhnya dimiliki oleh klien.

1. Mengapa mengekstrak satu subsite sangat merepotkan

Sebuah subsite Multisite bukanlah situs yang berdiri sendiri. Ia hanyalah sekumpulan tabel dengan awalan (seperti wp_5_posts, wp_5_options, dan seterusnya) yang berbagi tabel global untuk pengguna, usermeta, dan pengaturan jaringan. Layar Tools > Export bawaan hanya memberikan Anda file XML berisi pos, halaman, dan media. Fitur ini meninggalkan:

• Pengguna dan perannya, yang berada di tabel global bersama
• Pengaturan plugin dan theme yang disimpan dalam tabel options subsite
• Tabel kustom yang dibuat oleh plugin form, e-commerce, atau membership
• Data serial yang di dalamnya terdapat URL atau path subsite lama

Jika Anda membangun ulang situs hanya dari XML tersebut, Anda akan menghabiskan waktu berhari-hari untuk membuat ulang akun, mengonfigurasi ulang plugin, dan mencari tautan yang rusak (broken links). Sebaliknya, tujuannya adalah mendapatkan salinan data subsite tersebut secara lengkap dan sama persis (byte-for-byte), lalu melakukan proses restore yang bersih ke dalam instalasi yang belum pernah menjadi Multisite.

2. Pilih arsitektur target

Putuskan di mana situs yang diekstrak akan ditempatkan sebelum Anda mengekspornya. Ada dua hasil yang baik:

• Instalasi standalone single-site. Instalasi WordPress biasa di hosting milik klien sendiri atau milik Anda. Ini adalah opsi yang sepenuhnya independen dan yang biasanya diinginkan klien saat mereka pindah.
• Tenant GrabWP yang terisolasi. Jika Anda ingin mempertahankan keuntungan operasional dari satu basis kode (codebase) tetapi dengan pemisahan nyata, pindahkan situs sebagai tenant menggunakan plugin gratis GrabWP Tenancy. Setiap tenant mendapatkan folder uploads yang terisolasi, awalan tabelnya sendiri, dan perutean (routing) berbasis domain atau path, misalnya yoursite.com/site/client-a tanpa perubahan DNS.

Apapun pilihannya, targetnya adalah konteks single-site, bukan Multisite lain. Hal ini penting untuk langkah restore di bawah.

3. Ekspor data subsite

Cara yang rapi untuk menangkap semuanya adalah dengan melakukan backup per-tenant dari GrabWP Tenancy Pro. Fitur backup-nya menghasilkan arsip ekspor yang dibaca oleh alat restore: paket lengkap dari database situs dan direktori wp-content miliknya, bukan sekadar dump XML.

1. Di lingkungan sumber, jalankan backup per-tenant untuk subsite yang Anda pindahkan.
2. Proses backup 7 langkah ini berjalan dengan progres AJAX sehingga Anda bisa melihatnya sampai selesai.
3. Unduh file ZIP ekspor yang dihasilkan. Arsip ini adalah satu-satunya artefak yang Anda bawa ke tempat baru.

Ini penting karena GrabWP Restore hanya menerima file ZIP yang dihasilkan oleh fitur backup GrabWP Tenancy Pro. Ini bukanlah pengimpor generik untuk sembarang backup, dan batasan inilah yang membuat proses restore dapat diprediksi.

4. Bangun ulang dengan bersih menggunakan GrabWP Restore

Siapkan instalasi WordPress single-site yang baru di tujuan, lalu instal plugin gratis GrabWP Restore.

1. Buka menu Tools > GrabWP Restore (hanya administrator).
2. Unggah file ZIP ekspor dari langkah 3.
3. Konfirmasi peringatan backup eksplisit yang diminta plugin sebelum melanjutkan.
4. Jalankan 8 langkah restore dan perhatikan progres AJAX-nya.

Di balik layar, Restore melakukan pekerjaan berat yang sering kali salah saat migrasi manual: impor SQL streaming yang mampu menangani database besar tanpa menguras memori, penulisan ulang awalan tabel otomatis agar tabel yang masuk cocok dengan tujuan, serta kompatibilitas collation MySQL 5.7 dan 8.0 sehingga proses impor tidak gagal karena ketidakcocokan charset.

Satu aturan tegas: Restore sengaja dinonaktifkan di Multisite. Operasi destruktif berskala jaringan membutuhkan alur kerja yang mengenali jaringan (network-aware), jadi Anda harus melakukan restore ke instalasi single-site yang baru, dan jangan pernah ke jaringan yang sedang aktif. Jika Anda mencoba mengambil jalan pintas dengan melakukan restore ke Multisite lain, alat ini akan menghentikan Anda.

5. Verifikasi URL dan data serial

Di sinilah letak kegagalan pada proses migrasi yang naif. URL atau path subsite lama tertulis di ratusan baris data, termasuk array serial yang akan rusak jika Anda menggunakan fungsi cari-dan-ganti (find-and-replace) biasa. GrabWP Restore menangani hal ini untuk Anda:

• Pembaruan otomatis URL situs mengatur URL home dan situs (site URL) ke tujuan baru.
• Pencarian-dan-penggantian URL di seluruh database menulis ulang alamat lama di semua tempat, termasuk data serial dan data yang di-encode oleh theme, sehingga tata letak (layout) page builder, opsi widget, dan pengaturan plugin tetap berfungsi.

Setelah proses restore selesai, periksa hasilnya:

1. Login dan pastikan akun admin serta peran (roles) Anda terbawa.
2. Buka halaman yang dibuat menggunakan page builder Anda dan pastikan gambar serta modul ditampilkan dengan benar.
3. Cari di front end (tampilan depan) jika ada sisa-sisa referensi ke path /subsite yang lama.
4. Pastikan file upload berhasil diakses, karena Restore melakukan pengembalian file yang aman dengan mengubah nama direktori plugins, themes, dan uploads yang ada menjadi akhiran .old sebelum menulis direktori yang baru, sehingga tidak ada file yang ditimpa secara diam-diam.

6. Serah terima atau pindahkan sebagai tenant terisolasi

Pada titik ini Anda memiliki dua jalur yang bersih:

• Serahkan situs. Instalasi standalone tersebut kini sepenuhnya milik klien. Transfer kredensial hosting dan tugas Anda selesai. Tidak ada tabel bersama, tidak ada ketergantungan jaringan.
• Pindahkan sebagai tenant terisolasi. Pertahankan situs di infrastruktur yang Anda jalankan, tetapi sebagai tenant yang sesungguhnya. Dengan GrabWP Tenancy Pro, setiap tenant dapat menggunakan awalan MySQL bersama, database MySQL khusus, atau SQLite, dan mendapatkan folder wp-content terisolasi sendiri. Ini adalah pemisahan nyata untuk dukungan pelanggan dan penagihan, tanpa adanya pengikatan tabel bersama yang membuat ekstraksi terasa merepotkan sejak awal.

7. Hindari kerumitan ini di masa depan

Alasan mengapa pekerjaan ini sulit ada pada sisi arsitektur: Multisite mengikat setiap subsite pada tabel global bersama. Jika Anda memperkirakan bahwa klien akan datang dan pergi, mulailah layanan untuk mereka dengan arsitektur isolasi data di mana setiap situs sudah independen sejak awal. Menjalankan situs klien sebagai tenant GrabWP berarti masing-masing situs sudah memiliki folder uploads yang terisolasi, awalannya sendiri, dan perutean yang mandiri. Dengan demikian, tugas “memindahkan klien” hanya menjadi “jalankan satu backup dan satu restore” alih-alih pekerjaan mengurai kekacauan yang bisa memakan waktu berhari-hari.

Mulai sekarang

Alur kerja ekstraksi di atas berjalan dengan berbagai alat gratis plus satu alat berbayar: GrabWP Restore dan GrabWP Tenancy tersedia secara gratis, sementara fitur backup per-tenant yang menghasilkan arsip ekspor untuk di-restore merupakan bagian dari GrabWP Pro seharga $9.99/month. Jika Anda masih menimbang-nimbang apakah Multisite cocok untuk agensi Anda, baca artikel selanjutnya tentang kapan tidak boleh menggunakan WordPress Multisite.