چطور وردپرس را بدون از دست رفتن داده منتقل کنیم؟

انتقال وردپرس فقط کپی پوشه‌ها نیست. در فاصله تهیه بکاپ تا تغییر DNS ممکن است سفارش، نظر، فرم یا فایل تازه‌ای در مبدا ثبت شود. اگر این داده‌ها در برنامه انتقال دیده نشوند، نسخه مقصد از سایت واقعی عقب می‌ماند. برای فروشگاه فعال، مهم‌ترین بخش مهاجرت معمولا هماهنگی همین فاصله زمانی است.

هیچ برنامه‌ای بدون شناخت سایت، تضمین وقفه صفر نمی‌دهد. اما با ثبت وابستگی‌ها، آزمون مقصد و یک مرحله نهایی کنترل‌شده می‌توان خطر را کاهش داد. این راهنما برای ساخت همان برنامه است. برای سرویس حساس، زمان اجرا و مسئول هر بخش را پیش از شروع مشخص کنید.

پیش از کپی، فهرست وابستگی‌ها را بنویسید

دامنه اصلی و زیردامنه‌ها، نسخه PHP، افزونه‌ها، قالب، حجم فایل‌ها و اندازه دیتابیس را ثبت کنید. Cron، صف سفارش، جست‌وجوی بیرونی، فضای ذخیره رسانه و APIهای متصل را هم فراموش نکنید. اگر فایل‌ها روی CDN هستند، باید بدانید مقصد فقط وردپرس است یا رسانه‌ها هم جابه‌جا می‌شوند.

از همه رکوردهای DNS خروجی بگیرید. A و AAAA به وب مربوط می‌شوند، اما MX، SPF، DKIM و سایر TXTها ممکن است سرویس ایمیل یا احراز مالکیت را کنترل کنند. انتقال وب به معنی انتقال ایمیل نیست. تغییر Nameserver بدون آماده‌سازی این رکوردها می‌تواند خدماتی را قطع کند که ارتباطی به هاست تازه ندارند.

به راهنمای رسمی جابه‌جایی وردپرس مراجعه کنید. اگر آدرس دامنه تغییر می‌کند، جایگزینی داده باید با روش سازگار با داده سریال‌شده انجام شود. جست‌وجو و جایگزینی خام در فایل SQL می‌تواند تنظیمات قالب یا افزونه را خراب کند. ابزار مناسب را ابتدا روی نسخه آزمایشی امتحان کنید.

بکاپ مستقل و مسیر بازگشت بسازید

از فایل‌ها و دیتابیس در یک بازه زمانی سازگار بکاپ بگیرید و یک نسخه خارج از مبدا داشته باشید. فقط وجود فایل ZIP کافی نیست. بررسی کنید فایل باز می‌شود، پوشه uploads کامل است و خروجی دیتابیس خطا ندارد. برای سایت بزرگ، روش ساخت بکاپ باید با محدودیت زمان و فضای سرور سازگار باشد.

پیش از اجرا بنویسید چه شرایطی به معنی توقف انتقال است. برای مثال، ورود ناموفق، مشکل ثبت سفارش یا ناهماهنگی موجودی باید بررسی شوند. بازگشت هم فقط تغییر DNS به عقب نیست. اگر روی مقصد سفارش تازه ثبت شده، برگرداندن ترافیک به مبدا قدیمی می‌تواند دو مجموعه داده متفاوت ایجاد کند.

اعتبار دسترسی‌ها را محدود کنید و در پایان لغو کنید. رمزها را در تیکت عمومی یا فایل قابل دسترس وب قرار ندهید. نام مسئول اجرا، زمان بکاپ و محل امن نگهداری آن باید مشخص باشد. راهنمای آزمون بازیابی برای ارزیابی نسخه پشتیبان مفید است.

مقصد را با رفتار واقعی دامنه آزمایش کنید

نسخه اولیه را به مقصد ببرید و تنظیمات اتصال دیتابیس را اصلاح کنید. پیش از تغییر عمومی DNS، با روش مناسب مانند تنظیم محلی hosts مقصد را با نام دامنه اصلی آزمایش کنید. این روش به بررسی لینک‌ها و رفتار ورود کمک می‌کند. صدور و اعتبار گواهی HTTPS هم باید متناسب با روش اعتبارسنجی مدیریت شود.

صفحه اصلی، مقاله، تصاویر، جست‌وجو، فرم و ورود را بررسی کنید. در فروشگاه، محصول متغیر، کد تخفیف، هزینه ارسال و پرداخت آزمایشی را هم ببینید. ارسال ایمیل از مقصد را جداگانه آزمایش کنید. باز شدن وب‌سایت ثابت نمی‌کند که ایمیل سفارش هم ارسال می‌شود.

محیط آزمایشی نباید برای مشتری‌ها پیام واقعی بفرستد یا یک کار زمان‌بندی‌شده را هم‌زمان با مبدا اجرا کند. درگاه، وب‌هوک و اتصال‌های بیرونی را با دقت کنترل کنید. برای جلوگیری از ایندکس‌شدن نسخه آزمایشی، دسترسی و تنظیمات مناسب داشته باشید. صرف وجود یک دامنه موقت، آن را از دسترس موتور جست‌وجو خارج نمی‌کند.

سفارش‌های فاصله انتقال را چه کنیم؟

برای فروشگاه فعال، مرحله نهایی باید زمان کوتاه و مشخصی داشته باشد. با مسئول سایت توافق کنید چه زمانی نوشتن داده در مبدا متوقف می‌شود، آخرین همگام‌سازی چگونه انجام می‌گیرد و چه زمانی مقصد پذیرای سفارش خواهد شد. بسته به روش انتقال، توقف موقت خرید یا راهکار تخصصی همگام‌سازی لازم است.

کپی دوباره کل دیتابیس بعد از شروع فروش در مقصد خطرناک است. این کار ممکن است سفارش‌های تازه مقصد را بازنویسی کند. انتقال گزینشی سفارش هم بدون شناخت روابط داده، کاربران، انبار و افزونه‌های مالی کار ساده‌ای نیست. اگر دوطرف هم‌زمان داده دریافت کرده‌اند، پیش از هر بازنویسی، توقف و تطبیق را در اولویت بگذارید.

تغییر DNS پایان انتقال نیست

TTL را پیش از زمان انتقال و متناسب با برنامه تغییر دهید. کاهش آن در لحظه اجرا، کش قبلی تمام resolverها را پاک نمی‌کند. بعد از تغییر، A و AAAA را بررسی کنید. باقی ماندن IPv6 قدیمی ممکن است بخشی از کاربران را همچنان به مبدا ببرد.

کش صفحه، کش شیء و CDN را با ترتیب مناسب تازه کنید. گواهی دامنه اصلی و www، ریدایرکت نسخه منتخب و آدرس‌های canonical را بررسی کنید. اگر ساختار URL عوض شده است، نگاشت ریدایرکت باید پیش از انتشار آماده باشد. انتقال سرور به‌تنهایی نباید به تغییر ناخواسته آدرس صفحه‌ها تبدیل شود.

مبدا را بلافاصله حذف نکنید. لاگ‌ها، ثبت سفارش، ایمیل و خطاهای سمت کاربر را در بازه توافق‌شده دنبال کنید. هم‌زمان مطمئن شوید مبدا دیگر سفارش یا کار زمان‌بندی‌شده تکراری اجرا نمی‌کند. نگهداری نسخه قبلی باید کنترل‌شده باشد، نه داشتن دو فروشگاه فعال با داده جدا.

یک تحویل فنی کوتاه اما روشن داشته باشید

پس از تایید، نسخه PHP، محل بکاپ، زمان آخرین همگام‌سازی، تغییرات DNS و دسترسی‌های لغوشده را ثبت کنید. آزمون دوره‌ای بازیابی و بررسی مصرف منابع را برای بعد از انتقال در نظر بگیرید. راهنمای کش ووکامرس برای آزمون فروشگاه روی مقصد و بررسی عملکرد صفحه برای مقایسه قبل و بعد کاربرد دارد.

اگر مقصد روناتا است، ابتدا مسیر انتقال سایت و محدوده خدمات را بخوانید. انتقال قابل اعتماد زمانی تمام می‌شود که داده، خرید و خدمات جانبی تایید شده باشند، نه وقتی نوار کپی فایل به انتها برسد.