Salinan jarang yang merusak pemindahan WordPress. Yang merusaknya adalah yang tidak ditulis siapa pun: sebuah cron, sebuah webhook, plugin yang menanam hostname lama ke dalam satu baris, kotak surat yang masih keluar dari server lama. Saya memperlakukan inventaris sebagai migrasinya. Transfer berkas adalah sore yang mudah sesudahnya.
Tuliskan sistemnya sebelum menyentuhnya
Sebelum berkas bergerak, saya menulis satu halaman yang bisa dipakai orang asing. Versi PHP. Ukuran basis data. Baris cron dan tindakan terjadwal di dalam WordPress, itu bukan daftar yang sama. Surel: siapa mengirim, lewat apa, dan apakah SPF sudah menyebut host itu. Setiap integrasi yang memanggil situs atau yang dipanggil situs. Webhook pembayaran dan sinkron CRM adalah kejutan yang biasa, karena hidup di pengaturan plugin yang tidak diekspor siapa pun.
Saya juga menulis apa arti “bekerja” untuk toko ini. Checkout satu produk fisik. Checkout satu produk virtual. Masuk. Reset kata sandi. Formulir kontak, termasuk surel yang harus sampai. Pencarian, jika katalog bergantung padanya. Jika saya tidak bisa menamai jalurnya, saya belum siap mengubah DNS.
| Baris | Mengapa ada di sini |
|---|---|
| PHP, ukuran basis data, cache objek | Host baru bisa «naik» dan tetap runtime yang salah. |
| Cron dan tindakan terjadwal | Job malam yang terlewat tampak baik sampai laporan pagi kosong. |
| Jalur surat | Situs bisa termuat sementara setiap surel pesanan mati di mesin baru. |
| Webhook dan API keluar | Biasanya tidak tertulis, dan mereka memperhatikan nama host lebih dulu. |
| Lima jalur yang menghasilkan uang | Pemeriksaan beranda tidak menjalankannya. |
Turunkan TTL sehari sebelumnya
Atur TTL DNS ke 300 detik sehari sebelum pindah. Jika Anda melewatinya dan host baru salah, sebagian pengunjung menyimpan rekaman lama berjam-jam. Anda tidak bisa mempercepat cache yang tidak Anda pendekkan. Saya lebih suka menunggu sehari dengan sengaja daripada menemukan penantian itu saat gangguan.
URL staging bukan nama host yang asli
Saya naikkan server baru dan mengarahkan hanya mesin saya sendiri ke sana, dengan pengecualian di berkas hosts, sementara DNS publik masih melayani host lama. Lalu saya menelusuri jalur pada nama sungguhan. URL staging menyembunyikan plugin yang menyimpan domain produksi di basis data. Mereka berlaku baik sampai nama sungguhan ada di permintaan, dan itulah saat Anda tidak ingin kejutan lagi.
Jika jalur kritis belum dijalani pada nama host yang asli, migrasi belum diuji.
Biarkan host lama tetap hangat
Saya tidak membatalkan hosting lama pada minggu pemindahan. Hosting itu tetap hidup, hanya-baca, paling tidak dua minggu. Biayanya kecil. Itu satu-satunya jalan kembali yang tidak bergantung pada cadangan yang belum pernah harus saya pakai. Jika host baru bermasalah di hari ketiga, rekaman lama masih berarti sesuatu.
Surat adalah pemeriksaan yang dilupakan
Situs bisa tampak selesai sementara setiap surel pesanan mati di mesin baru. Saya menulis alamat From, relay, dan apakah port 25 bahkan terbuka. Di lebih dari satu host tidak terbuka, dan satu-satunya jalur yang jalan adalah relay terautentikasi di 587. SPF sudah punya satu rekaman. Saya tidak menambah yang kedua. Dua rekaman SPF tidak bergabung. Keduanya menjadi tidak sah, dan surel yang dulu sampai mulai hilang pada minggu setelah pemindahan yang selain itu berjalan baik.
Saya kirim satu surel pesanan sungguhan dan satu reset kata sandi dari host baru, ke kotak yang saya kendalikan, sebelum menyebut pemindahan selesai. Baris log yang bilang “sent” bukan pesan di kotak masuk. Yang kedua itulah ujiannya.
HTTPS di apex dan di www. Sertifikat memperbarui dirinya sendiri. Surel masih keluar. Lima jalur masih selesai. Lalu saya menonton log kesalahan sehari, bukan beranda. Beranda adalah yang sudah dipuji monitor kepada Anda. Log adalah tempat webhook mulai mengembalikan 404 ke penyedia pembayaran.
Pemindahan yang dilakukan seperti ini membosankan. Itu memang tujuannya. Cerita menarik tentang migrasi hampir selalu cerita tentang satu baris yang hilang dari inventaris.
