استیجینگ وردپرس: راه‌اندازی، همگام‌سازی و بازگردانی امن

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

استیجینگ وردپرس را کجا بسازید: ساب‌دامین یا سرور جدا

سه گزینه واقعی دارید و هرکدام هزینه‌ای دارد که فقط بعد از چند هفته معلوم می‌شود.

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

برای راه‌اندازی، اول یک ساب‌دامین بسازید و رکورد DNS آن را تنظیم کنید. اگر این کار را تازه انجام می‌دهید، راهنمای کامل تنظیم DNS برای سایت تازه‌کار ترتیب رکوردها و زمان انتظار propagation را توضیح می‌دهد.

کپی گرفتن از سایت زنده بدون خراب کردن آن

هرگز با cp -r از پوشه سایت زنده کپی نگیرید؛ فایل‌های cache و uploads نیمه‌کاره را هم می‌آورید. ترتیب درست این است:

wp db export /tmp/live.sql --add-drop-table
rsync -avz --exclude='wp-content/cache' --exclude='wp-content/uploads/*' \
  /var/www/live/ stage@host:/var/www/stage/

پوشه uploads را جدا و فقط در صورت نیاز منتقل کنید. اگر سایت شما بیش از ۲ گیگابایت uploads دارد، انتقال کامل هر بار حدود ۱۰ تا ۲۰ دقیقه طول می‌کشد و این زمان با هر همگام‌سازی تکرار می‌شود. برای سایت‌های بزرگ، فقط فایل‌های جدید را با rsync --ignore-existing بفرستید.

بعد از انتقال، در فایل wp-config.php استیجینگ این خطوط را عوض کنید:

define('DB_NAME', 'stage_db');
define('DB_USER', 'stage_user');
define('DB_HOST', 'localhost');
define('WP_HOME', 'https://stage.example.com');
define('WP_SITEURL', 'https://stage.example.com');

اگر WP_HOME و WP_SITEURL را ست نکنید، وردپرس از مقدار داخل دیتابیس استفاده می‌کند و شما را به سایت زنده redirect می‌کند. این شایع‌ترین دلیل «استیجینگم کار نمی‌کند» است.

همگام‌سازی دیتابیس: جایی که همه خراب می‌کنند

اینجا اشتباه می‌کنند. کسی دیتابیس استیجینگ را روی سایت زنده push می‌کند تا «تغییرات را منتقل کند» و بعد می‌بیند سفارش‌های دو هفته گذشته، کاربران جدید و کامنت‌های تاییدشده همه پاک شده‌اند. علامتش هم واضح است: تعداد کاربران در پیشخوان یک‌شبه کم می‌شود و مشتری‌ها ایمیل می‌زنند که «حسابم را نمی‌شناسد».

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

وقتی دیتابیس زنده را روی استیجینگ می‌ریزید، دو کار را حتماً انجام دهید:

1. URLها را با wp search-replace 'https://example.com' 'https://stage.example.com' --all-tables --precise عوض کنید. بدون --precise، سریالایز شده‌ها خراب می‌شوند و ویجت‌ها و تنظیمات صفحه‌ساز از کار می‌افتند.
2. ارسال ایمیل را قطع کنید. با wp config set WP_ENVIRONMENT_TYPE staging و یک افزونه مثل WP Mail SMTP که خروجی را می‌گیرد، جلوی ارسال ایمیل تستی به مشتری‌های واقعی را بگیرید.

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

بازگردانی به سایت زنده: چک‌لیست قبل از push

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

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

اگر تغییرات شما شامل کد قالب یا افزونه سفارشی است، بهتر است از ابتدا با گیت کار کنید. آموزش گیت برای استقرار سایت نشان می‌دهد چطور بدون انتقال دستی فایل، نسخه‌ها را مدیریت کنید.

چیزهایی که روی استیجینگ فرق می‌کنند و تست را بی‌اعتبار می‌کنند

استیجینگ هیچ‌وقت دقیقاً مثل زنده نیست. این تفاوت‌ها را بشناسید تا نتیجه تست را اشتباه تفسیر نکنید:

• حجم داده: دیتابیس استیجینگ معمولاً کوچک‌تر است. کوئری‌ای که روی ۵۰۰ محصول سریع است، روی ۵۰٬۰۰۰ محصول کند می‌شود.
• ترافیک: بدون بازدیدکننده واقعی، مشکل کش و همزمانی را نمی‌بینید.
• CDN و DNS: اگر استیجینگ پشت CDN نیست، زمان بارگذاری واقعی را اندازه نمی‌گیرید.
• افزونه‌های امنیتی: بعضی افزونه‌ها روی دامنه استیجینگ رفتار متفاوتی دارند یا کپچا را رد می‌کنند.

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

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

پرسش‌های پرتکرار

آیا می‌توانم استیجینگ را روی همان دیتابیس سایت زنده اجرا کنم؟

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

چطور بفهمم استیجینگ به‌درستی از سایت زنده جدا شده؟

سه چیز را چک کنید: مقدار WP_HOME در wp-config.php، نام دیتابیس، و اینکه موتور جستجو ایندکس نکند. برای مورد آخر در تنظیمات خواندن، گزینه « discouraging search engines » را فعال کنید یا هدر X-Robots-Tag: noindex را اضافه کنید. اگر این کار را نکنید، نسخه استیجینگ در نتایج گوگل ظاهر می‌شود و محتوای تکراری می‌سازد.

بعد از همگام‌سازی دیتابیس، چرا تصاویر نمایش داده نمی‌شوند؟

معمولاً به‌خاطر search-replace ناقص است. اگر URL قدیمی در جدول‌های متا یا فایل‌های سریالایز شده باقی مانده باشد، مسیر تصاویر می‌شکند. با wp search-replace و فلگ --precise دوباره اجرا کنید و بعد جدول wp_options را برای کلیدهای حاوی دامنه قدیمی بررسی کنید.

هر چند وقت یک‌بار باید استیجینگ را با سایت زنده همگام کنم؟

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

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