آموزش ساخت Staging وردپرس؛ کلون سایت، تست تغییرات و انتقال امن به سایت اصلی

ارسال توسط Dev Source

24 مهر 1405

منتشرشده در 6 مرداد 1405

🗓 آخرین به‌روزرسانی: 24 مهر 1405

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

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

مشکل اصلی زمانی ایجاد می‌شود که مدیر سایت Staging را فقط یک «کپی ساده» بداند. نسخه آزمایشی اگر درست ایمن نشود، می‌تواند ایمیل واقعی ارسال کند، پرداخت واقعی بسازد، Webhook را دوباره اجرا کند، اطلاعات مشتری را در معرض دید قرار دهد، وارد نتایج گوگل شود یا هنگام انتقال به Production سفارش‌های جدید را بازنویسی کند.

در این آموزش، تفاوت Development، Staging و Production، روش‌های ساخت نسخه آزمایشی با هاست، cPanel، افزونه یا WP-CLI، کلون فایل و دیتابیس، Search‑Replace امن، جلوگیری از ایندکس، غیرفعال‌سازی ایمیل و پرداخت، تست WooCommerce، روش انتشار تغییرات و Rollback را مرحله‌به‌مرحله بررسی می‌کنیم.

وضعیت سایت فعلی: dev-source.ir روی WordPress 7.0.2، WooCommerce 10.9.4، WoodMart، LiteSpeed Cache و چند افزونه سفارشی اجرا می‌شود. افزونه اختصاصی Staging در فهرست افزونه‌های فعال مشاهده نشد و وجود قابلیت One‑Click Staging در پنل هاست از داخل وردپرس قابل تأیید نیست. این مقاله فقط راهنماست و هیچ محیط Staging واقعی، دیتابیس جدید یا کپی از اطلاعات مشتریان در این مرحله ساخته نمی‌شود.

Staging چیست؟

Staging نسخه‌ای از سایت اصلی است که از نظر نسخه WordPress، PHP، دیتابیس، قالب، افزونه‌ها و تنظیمات سرور تا حد امکان شبیه Production نگه داشته می‌شود؛ اما برای مشتری و موتور جست‌وجو عمومی نیست.

نمونه آدرس‌ها:

staging.example.com
example.com/staging/
یک دامنه آزمایشی متعلق به شرکت هاست
یک محیط خصوصی روی سرور جدا

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

تفاوت Development، Staging و Production

Development

محیط توسعه برای نوشتن کد، Debug و آزمایش اولیه است. ممکن است روی لپ‌تاپ، Docker، Local یا سرور توسعه اجرا شود. داده آن معمولاً نمونه و غیرواقعی است.

Staging

محیطی نزدیک به Production برای تست نهایی است. نسخه PHP، وب‌سرور، قالب، افزونه و ساختار دیتابیس باید تا حد امکان مشابه سایت اصلی باشد.

Production

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

Staging چه زمانی ضروری است؟

به‌روزرسانی WordPress، WooCommerce یا WoodMart
نصب یا تعویض افزونه مهم
تغییر PHP یا تنظیمات سرور
فعال‌سازی HPOS، Cache یا قابلیت آزمایشی
تغییر Checkout، درگاه یا Callback
Import انبوه محصول
پاک‌سازی یا بهینه‌سازی دیتابیس
تغییر Header، Footer یا طراحی صفحات اصلی
ویرایش افزونه سفارشی
مهاجرت هاست یا دامنه
رفع خطای پیچیده و بازتولید Incident

برای اصلاح یک غلط تایپی یا تغییر قیمت ساده معمولاً ساخت نسخه جدید Staging لازم نیست؛ اما هر تغییری که بتواند فروش، سفارش یا دسترسی مدیریت را مختل کند باید ابتدا آزمایش شود.

Staging جایگزین Backup نیست

نسخه آزمایشی ممکن است اشتباه، ناقص یا آلوده باشد. Backup برای بازیابی داده طراحی شده و Staging برای آزمایش تغییرات.

قبل از ساخت یا Refresh محیط آزمایشی:

از فایل و دیتابیس Production بکاپ بگیرید.
قابلیت Restore را بررسی کنید.
نسخه فعلی Staging را در صورت وجود آرشیو نمایید.
راه بازگشت DNS، فایل و دیتابیس مشخص باشد.

جزئیات در مقاله آموزش بکاپ‌گیری و بازیابی وردپرس قرار دارد.

چهار روش ساخت Staging وردپرس

روش اول: One‑Click Staging شرکت هاست

بسیاری از هاست‌های مدیریت‌شده ابزار Clone یا Staging دارند. مزایا:

ساخت سریع نسخه فایل و دیتابیس
تولید URL آزمایشی
Search‑Replace خودکار
امکان Push یا Pull
مدیریت SSL و Permission

پیش از استفاده بررسی کنید:

Push کل دیتابیس است یا انتخابی؟
آیا سفارش‌های Production بازنویسی می‌شوند؟
ایمیل و Cron در Clone غیرفعال می‌شوند؟
محیط با رمز محافظت می‌شود؟
Backup قبل از Deploy خودکار ساخته می‌شود؟

روش دوم: ساخت دستی با cPanel

این روش کنترل بیشتری دارد و شامل ساخت Subdomain، Database جدا، کپی فایل، Import دیتابیس و تغییر URL است. مسئولیت امنیت و هماهنگی کامل بر عهده شماست.

روش سوم: افزونه Staging یا Migration

افزونه می‌تواند Clone را ساده کند، اما روی سایت بزرگ ممکن است با محدودیت PHP، Timeout، فضای دیسک و فایل‌های حجیم مواجه شود.

معیار انتخاب:

سازگاری با WooCommerce و HPOS
پشتیبانی از فایل‌های بزرگ و Multisite
Search‑Replace Serialized Data
محافظت از Login
توانایی Exclude جدول و پوشه
Push انتخابی

روش چهارم: Local یا محیط توسعه جدا

برای کدنویسی و طراحی مفید است، اما تفاوت PHP، وب‌سرور، ایمیل، SSL و منابع ممکن است خطایی را که در Production رخ می‌دهد بازتولید نکند. تست نهایی بهتر است روی Staging مشابه سرور اصلی انجام شود.

انتخاب محل مناسب Staging

همان سرور Production

مزیت آن شباهت محیط و سادگی است، اما CPU، RAM و Disk مشترک ممکن است سایت زنده را کند کند. Import، Image Optimization و Backup سنگین در Staging می‌تواند منابع Production را مصرف کند.

سرور جدا

ریسک اثر روی سایت اصلی کمتر است، اما باید نسخه PHP، وب‌سرور، Extensionها، Cache و محدودیت‌ها هماهنگ شوند.

بهترین انتخاب

محیط Resource‑isolated که از نظر Software Stack شبیه Production باشد و دسترسی عمومی نداشته باشد.

مرحله اول: برنامه Clone را بنویسید

قبل از کپی مشخص کنید:

هدف آزمایش چیست؟
چه نسخه‌ای از Production کپی می‌شود؟
چه داده‌هایی نباید منتقل شوند؟
ایمیل، درگاه، Webhook و API چگونه غیرفعال می‌شوند؟
چه کسی دسترسی دارد؟
تغییر چگونه به Production منتقل می‌شود؟
معیار موفقیت و Rollback چیست؟

بدون برنامه، Staging به نسخه قدیمی و نامطمئن تبدیل می‌شود که نتیجه تست آن قابل اتکا نیست.

مرحله دوم: آدرس و SSL محیط آزمایشی

یک Subdomain مانند staging.example.com بسازید و SSL معتبر فعال کنید. بسیاری از قابلیت‌های WordPress، REST API، Cookie و Payment در HTTP رفتار متفاوت دارند.

اگر سایت اصلی HTTPS و Staging HTTP باشد، Mixed Content، Cookie و Redirect ممکن است نتیجه تست را بی‌اعتبار کند.

مرحله سوم: دیتابیس جدا بسازید

Staging نباید به دیتابیس Production متصل باشد. در cPanel:

یک Database جدید بسازید.
User جدا با رمز تصادفی ایجاد کنید.
User را فقط به Database آزمایشی متصل نمایید.
مجوز لازم را اختصاص دهید.
مشخصات را در Password Manager نگه دارید.

اشتباه در wp-config.php ممکن است محیط آزمایشی را مستقیماً به دیتابیس زنده متصل کند؛ پیش از هر Update این مورد را دوباره بررسی کنید.

مرحله چهارم: فایل‌های سایت را کپی کنید

روش‌های متداول:

File Manager و Compress/Extract
SFTP
SSH و rsync
ابزار Clone هاست

بخش‌های مهم:

wp-content/uploads
قالب و Child Theme
افزونه‌های سفارشی
فایل‌های دانلودی محصول
wp-config.php با تنظیمات جدید
Ruleهای وب‌سرور

پوشه Cache، Backupهای قدیمی و Logهای حجیم را می‌توان در صورت عدم نیاز Exclude کرد.

مرحله پنجم: خروجی دیتابیس Production

با WP‑CLI:

wp db export production-before-staging.sql --add-drop-table

این دستور از Credentialهای داخل wp-config.php استفاده می‌کند. فایل SQL شامل اطلاعات حساس است و نباید داخل Web Root باقی بماند.

با phpMyAdmin نیز می‌توانید Export کامل با فرمت SQL و Compression بسازید.

مرحله ششم: Import به دیتابیس Staging

پس از تنظیم wp-config.php برای دیتابیس آزمایشی:

wp db import production-before-staging.sql

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

مرحله هفتم: تغییر URL با Search‑Replace امن

جایگزینی ساده متن در فایل SQL می‌تواند Serialized Data را خراب کند. از WP‑CLI یا ابزار سازگار استفاده کنید.

ابتدا Dry Run:

wp search-replace 'https://example.com' 'https://staging.example.com' --all-tables-with-prefix --skip-columns=guid --dry-run

بعد از بررسی گزارش:

wp search-replace 'https://example.com' 'https://staging.example.com' --all-tables-with-prefix --skip-columns=guid

WP‑CLI داده‌های PHP Serialized را می‌شناسد و Primary Keyها را تغییر نمی‌دهد. گزینه --all-tables-with-prefix جدول‌های افزونه‌ای با Prefix همان سایت را نیز بررسی می‌کند.

چرا GUID را تغییر ندهیم؟

GUID شناسه پایدار Feed و محتواست و نباید مانند URL نمایش عمومی تغییر کند. به همین دلیل در Search‑Replace معمولاً ستون guid Exclude می‌شود.

مرحله هشتم: تنظیم home و siteurl

اگر بعد از Import وارد مدیریت نمی‌شوید، می‌توانید URL را با WP‑CLI کنترل کنید:

wp option get home
wp option get siteurl

در صورت نیاز:

wp option update home 'https://staging.example.com'
wp option update siteurl 'https://staging.example.com'

در Multisite یا ساختار غیرعادی، فقط این دو Option کافی نیست و باید جدول‌های شبکه و Mapping بررسی شوند.

مرحله نهم: Permalink و Cache

پس از Clone:

Settings → Permalinks را بدون تغییر Save کنید.
یا از wp rewrite flush استفاده نمایید.
LiteSpeed Cache را Purge کنید.
Object Cache و CDN آزمایشی را پاک کنید.
OPcache در صورت نیاز Refresh شود.

تا زمانی که URL قدیمی داخل Cache باشد، Redirect یا تصویر Production نمایش داده می‌شود.

مرحله دهم: Staging را از دسترس عمومی خارج کنید

گزینه «Discourage search engines from indexing» کافی نیست؛ این گزینه فقط درخواست Noindex است و کنترل دسترسی محسوب نمی‌شود.

لایه‌های پیشنهادی

HTTP Basic Authentication
Cloudflare Access یا SSO
محدودیت IP برای تیم ثابت
Login اختصاصی Staging
Robots Noindex و Disallow به‌عنوان لایه تکمیلی

اگر داده مشتری در Clone وجود دارد، دسترسی باید محدود و Log شود.

تنظیم Search Engine Visibility

در Settings → Reading گزینه جلوگیری از ایندکس را فعال کنید. همچنین Meta Robots باید Noindex باشد. اما هرگز فقط به robots.txt تکیه نکنید؛ URL ممکن است بدون Crawl نیز در نتایج دیده شود.

داده مشتری را روی Staging چگونه مدیریت کنیم؟

Clone فروشگاه شامل نام، ایمیل، تلفن، آدرس و سفارش‌هاست. اصول ایمن:

فقط داده لازم را منتقل کنید.
در صورت امکان داده شخصی را Anonymize نمایید.
دسترسی تیم محدود باشد.
Backup Staging رمزگذاری شود.
پس از پایان پروژه محیط حذف یا Refresh شود.
Log و فایل Export در مسیر عمومی باقی نماند.

برای تست طراحی معمولاً نیازی به کل تاریخ سفارش واقعی وجود ندارد.

ایمیل‌های Staging را متوقف کنید

مهم‌ترین خطر Clone این است که ایمیل New Order، Completed، Reset Password یا خبرنامه برای کاربر واقعی ارسال شود.

روش‌های امن

استفاده از Mail Catcher یا SMTP Sandbox
Redirect همه گیرنده‌ها به ایمیل تست
غیرفعال‌کردن ارسال در سطح Application
مسدودکردن خروجی SMTP در سرور آزمایشی
استفاده از افزونه‌ای که ایمیل را Log و متوقف می‌کند

فقط غیرفعال‌کردن ایمیل‌های WooCommerce کافی نیست؛ WordPress، Contact Form 7، Mailchimp و افزونه‌های سفارشی نیز می‌توانند پیام ارسال کنند.

درگاه پرداخت را غیرفعال یا Sandbox کنید

نسخه Clone ممکن است Credential واقعی درگاه را حفظ کند. پیش از هر تست:

درگاه واقعی را غیرفعال کنید.
در صورت پشتیبانی، Test Mode فعال نمایید.
Merchant Credential واقعی را از محیط آزمایشی حذف کنید.
Callback آزمایشی را جدا تنظیم نمایید.
تراکنش واقعی روی Staging انجام ندهید.

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

Webhookها و اتصال‌های خارجی را کنترل کنید

Clone ممکن است Webhook، API و Feedهای سایت اصلی را دوباره اجرا کند.

Webhookهای WooCommerce را Disable کنید.
API Keyهای Production را حذف یا Rotate نمایید.
ارسال Feed به مارکت‌پلیس را متوقف کنید.
Mailchimp Sync را غیرفعال کنید.
اتصال هوش مصنوعی و MCP را با Credential جدا تست کنید.
سرویس‌های Analytics و Pixel را به محیط آزمایشی نفرستید.

در سایت فعلی، افزونه‌های Torob، Mailchimp و Royal MCP فعال‌اند؛ بنابراین Clone بدون ایزوله‌سازی می‌تواند داده یا درخواست ناخواسته ارسال کند.

WP‑Cron و Scheduled Actions در Staging

بعد از Clone، Jobهای زمان‌بندی‌شده نیز کپی می‌شوند. ممکن است ایمیل، Webhook، Import، پاک‌سازی یا Analytics اجرا شوند.

دو حالت

اگر Cron بخشی از تست نیست، موقتاً اجرای خودکار را متوقف کنید.
اگر Cron باید تست شود، Jobها را با داده و Endpoint آزمایشی اجرا نمایید.

Action Scheduler ووکامرس را بررسی کنید تا Jobهای Pending محیط Production روی Clone اجرا نشوند.

License افزونه و قالب

بعضی Licenseها Staging را تشخیص می‌دهند و بعضی تعداد فعال‌سازی محدود دارند.

دامنه Staging را در حساب فروشنده بررسی کنید.
License Production را بی‌دلیل Deactivate نکنید.
Auto‑Update را تا زمان کنترل محیط مدیریت کنید.
فایل افزونه تجاری را از Source معتبر کپی کنید.

Staging باید چقدر شبیه Production باشد؟

برای تست قابل اعتماد این موارد هماهنگ باشند:

نسخه PHP و Extensionها
نسخه WordPress و WooCommerce
Theme و Child Theme
افزونه‌ها و MU Pluginها
وب‌سرور و Rewrite
Database Engine و Version
Object Cache و Page Cache
SSL و HTTPS
حافظه PHP و Timeout
Cron و Queue

اگر Staging منابع بسیار قوی‌تر از Production داشته باشد، کندی واقعی دیده نمی‌شود؛ اگر Cache کاملاً متفاوت باشد، نتیجه Performance معتبر نیست.

چک‌لیست تست عمومی وردپرس

ورود و خروج مدیر
2FA یا Passkey
ایجاد و ویرایش نوشته
آپلود تصویر و SVG
منو، Header و Footer
جست‌وجو و Pagination
فرم تماس
REST API
Cron و Scheduled Task
Sitemap و Redirect
موبایل، RTL و مرورگرها

چک‌لیست تست WooCommerce

محصول

محصول ساده، مجازی و دانلودی
Variation و Attribute
قیمت و تخفیف
موجودی و Backorder
تصویر و فایل دانلودی

سبد و Checkout

افزودن و حذف محصول
کوپن
خرید مهمان
خرید حساب‌دار
اعتبارسنجی فیلدها
Checkout موبایل

سفارش

ثبت Order آزمایشی
تغییر Status
Order Note
Refund آزمایشی
کاهش و بازگردانی موجودی
دانلود فایل

فنی

HPOS
Action Scheduler
WooCommerce Logs
Template Overrideهای WoodMart
ایمیل داخل Sandbox
Callback درگاه تستی

تست افزونه‌های سفارشی سایت فعلی

برای dev-source.ir باید این موارد جدا بررسی شوند:

Import مرحله‌ای محصولات
تولید Thumbnail از PDF
فایل WebP و Media Metadata
Checkout مجازی
اسکنر محتوای محصول
مشخصات هوشمند محصول
Feed و اتصال Torob
Royal MCP و دسترسی API

هر افزونه سفارشی باید Log مستقل و Rollback مشخص داشته باشد.

تست عملکرد در Staging

Staging برای مقایسه قبل و بعد مناسب است، اما عدد آن لزوماً معادل Production نیست.

اندازه‌گیری‌ها:

TTFB
Query Time
PHP Memory
تعداد Requestها
Core Web Vitals آزمایشگاهی
زمان Checkout بدون Cache
زمان Import یا Action Scheduler

نتیجه را با Baseline همان محیط مقایسه کنید، نه فقط با عدد مطلق.

انتقال تغییر از Staging به Production

مهم‌ترین اصل: دیتابیس کامل Staging را روی فروشگاه زنده بازنویسی نکنید. از زمان ساخت Clone، Production سفارش، کاربر، پیام، موجودی و Session جدید تولید می‌کند.

تغییرات فایل و کد

قالب، Child Theme و افزونه سفارشی را با Git، Release ZIP یا Deploy کنترل‌شده منتقل کنید.

نسخه Release مشخص باشد.
فایل تغییرکرده مستند شود.
Build Assetها قابل بازتولید باشد.
Backup قبل از Deploy ساخته شود.

تغییرات تنظیمات

تنظیمات کوچک را دستی و مستند در Production اعمال کنید. برای تنظیم پیچیده، Migration Script یا ابزار رسمی افزونه استفاده شود.

تغییرات محتوا

برای نوشته یا برگه خاص می‌توان از Export انتخابی، Block Copy، Template Export یا API استفاده کرد. Import کل دیتابیس برای انتقال یک صفحه مناسب نیست.

تغییر Schema دیتابیس

Migration باید Versioned و قابل تکرار باشد. افزونه سفارشی می‌تواند با Version Option و Hook فعال‌سازی تغییر جدول را مدیریت کند.

چه زمانی Push کامل دیتابیس قابل قبول است؟

فقط وقتی Production در زمان پروژه داده جدید تولید نمی‌کند؛ مثلاً سایت هنوز راه‌اندازی نشده و در Coming Soon است. حتی در این حالت باید Backup و تأیید نهایی انجام شود.

برای فروشگاه فعال، Push کامل معمولاً سفارش و مشتری جدید را حذف می‌کند.

انتشار به Production با کمترین ریسک

تغییرها را Freeze کنید.
Backup تازه بگیرید.
Maintenance Window کوتاه اعلام کنید.
در صورت تغییر دیتابیس، Checkout را موقتاً محدود کنید.
کد و Migration را Deploy نمایید.
Cacheها را هدفمند Purge کنید.
Smoke Test اجرا کنید.
Checkout را باز کنید.
Log و سفارش‌ها را مانیتور نمایید.

Smoke Test بعد از Deploy

صفحه اصلی و محصول باز می‌شوند.
ورود مدیر کار می‌کند.
افزودن به Cart انجام می‌شود.
Checkout بارگذاری می‌شود.
درگاه نمایش داده می‌شود.
یک سفارش آزمایشی کنترل‌شده ثبت می‌شود.
ایمیل تراکنشی ارسال می‌شود.
Download کار می‌کند.
PHP و WooCommerce Log خطای جدید ندارند.

Rollback چیست؟

Rollback باید پیش از Deploy طراحی شود، نه بعد از خرابی.

کد

بازگشت به Release قبلی
Revert Commit
تعویض Symlink نسخه

دیتابیس

Migration معکوس در صورت امکان
Restore Backup فقط با درنظرگرفتن سفارش‌های جدید
اصلاح انتخابی جدول یا Option

Restore کامل دیتابیس بعد از چند سفارش جدید می‌تواند آسیب بیشتری ایجاد کند؛ بنابراین Migration باید تا حد امکان Backward‑compatible باشد.

Blue‑Green Deployment چیست؟

در این مدل دو محیط Production آماده وجود دارد. نسخه جدید روی محیط غیرفعال Deploy و تست می‌شود، سپس Traffic به آن منتقل می‌گردد. Rollback با بازگرداندن Traffic سریع‌تر است.

برای WordPress فروشگاهی، Database مشترک یا همگام‌سازی پیچیده است و طراحی تخصصی نیاز دارد. این روش با یک Staging ساده یکسان نیست.

Refresh کردن Staging

محیط آزمایشی باید دوره‌ای از Production تازه شود. قبل از Refresh:

کدهای توسعه‌نیافته Commit شوند.
تغییرهای لازم Export شوند.
داده تست مهم ثبت شود.
Backup Staging گرفته شود.

بعد از Refresh دوباره ایمیل، درگاه، Webhook، Noindex و Basic Auth را بررسی کنید؛ Clone جدید ممکن است تنظیمات Production را برگرداند.

Staging دائمی یا موقت؟

دائمی

برای تیم توسعه فعال مناسب است، اما باید به‌روز، Patch و مانیتور شود.

موقت

برای پروژه یا Update ساخته و پس از پایان حذف می‌شود. ریسک داده قدیمی و سطح حمله کمتر است.

هر محیط فراموش‌شده با WordPress قدیمی می‌تواند نقطه نفوذ به هاست باشد.

خطا: Staging به سایت اصلی Redirect می‌شود

home یا siteurl هنوز Production است.
Search‑Replace ناقص انجام شده است.
Cache قدیمی است.
Rule در .htaccess یا Nginx وجود دارد.
WoodMart یا افزونه Redirect URL ذخیره کرده است.

ابتدا wp option get home و siteurl را بررسی کنید.

خطا: تصاویر از Production بارگذاری می‌شوند

URL قدیمی در Content، Post Meta، CSS، CDN یا Serialized Option باقی مانده است. Dry Run با WP‑CLI اجرا و جدول‌های سفارشی را بررسی کنید.

خطا: Mixed Content

بعضی URLها هنوز HTTP هستند یا SSL Staging ناقص است. Search‑Replace، Console مرورگر و تنظیم CDN را بررسی کنید.

خطا: ورود مدیریت Loop می‌شود

Cookie Domain اشتباه است.
HTTPS در Proxy درست تشخیص داده نمی‌شود.
Cache صفحه Login فعال است.
Salt یا Session ناسازگار است.
Security Plugin دامنه جدید را نمی‌شناسد.

خطا: Staging ایمیل واقعی ارسال کرد

فقط ایمیل WooCommerce غیرفعال شده و SMTP یا افزونه دیگری همچنان فعال است. خروجی Mail را در سطح مرکزی Sandbox یا Block کنید.

خطا: سفارش آزمایشی در درگاه واقعی ثبت شد

Credential Production در Clone باقی مانده است. درگاه را فوراً غیرفعال، Log را بررسی و Credential را در صورت احتمال نشت Rotate کنید.

خطا: مشتریان جدید بعد از Push حذف شدند

دیتابیس Staging روی Production بازنویسی شده است. آخرین Backup و Delta Orderها باید توسط متخصص بررسی شوند. Import ساده ممکن است HPOS، موجودی و Transaction ID را ناسازگار کند.

خطا: افزونه روی Staging License ندارد

دامنه Clone در License Policy پشتیبانی نمی‌شود یا تعداد فعال‌سازی پر شده است. از قابلیت Development Domain فروشنده استفاده کنید و License اصلی را بی‌دلیل حذف نکنید.

خطا: Staging بسیار کند است

منابع محدودتر از Production است.
Cache غیرفعال است.
Debug روشن است.
Basic Auth و Proxy سربار دارند.
Jobهای Clone هم‌زمان اجرا می‌شوند.

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

خطا: تغییرات Staging روی Production ظاهر شد

دو محیط ممکن است Database، Uploads، Object Cache یا CDN مشترک داشته باشند. Prefix، Bucket، Cache Namespace و Credentialها باید جدا باشند.

چک‌لیست امنیت Staging

Database و User جدا هستند.
HTTP Authentication یا Access Policy فعال است.
Noindex تنظیم شده است.
SMTP به Sandbox می‌رود.
درگاه واقعی غیرفعال است.
Webhook و API Production غیرفعال‌اند.
Cron کنترل شده است.
داده مشتری حداقل یا Anonymized است.
Backup داخل Web Root نیست.
نسخه‌ها به‌روز هستند.
محیط فراموش‌شده حذف می‌شود.

چک‌لیست قبل از انتقال به Production

تست عمومی WordPress کامل شده است.
Cart، Checkout، Order و Download تست شده‌اند.
PHP و WooCommerce Log خطای بحرانی ندارند.
Diff فایل‌ها مشخص است.
Migration دیتابیس مستند است.
Backup و Rollback آماده‌اند.
دیتابیس کامل Staging Push نمی‌شود.
Maintenance Window مشخص است.
Smoke Test نوشته شده است.
مسئول مانیتورینگ پس از Deploy تعیین شده است.

برنامه پیشنهادی برای dev-source.ir

بررسی شود هاست قابلیت One‑Click Staging و Push انتخابی دارد یا خیر.
در صورت نبود، Subdomain و دیتابیس جدا ساخته شود.
Clone با HTTP Auth و Noindex محافظت گردد.
تمام ایمیل‌ها به SMTP Sandbox هدایت شوند.
درگاه واقعی، Torob Feed، Mailchimp و Webhookها غیرفعال شوند.
Royal MCP با Credential جدا یا کاملاً غیرفعال تست شود.
نسخه PHP، WoodMart، WooCommerce و LiteSpeed با Production یکسان باشد.
افزونه‌های سفارشی Import، PDF و Checkout با داده نمونه آزمایش شوند.
انتقال تغییرات فقط فایل‌محور یا Migration‑محور باشد.
پس از Deploy، سفارش، ایمیل، Download و Action Scheduler مانیتور شوند.

📌 همچنین بخوانید: ارتقای نسخه PHP وردپرس، نگهداری دوره‌ای وردپرس و انتقال وردپرس به هاست جدید

پرسش‌های متداول

آیا Staging باید روی همان هاست باشد؟

ضروری نیست. شباهت محیط مهم‌تر است. سرور جدا با Stack مشابه و منابع ایزوله می‌تواند امن‌تر باشد.

آیا فعال‌کردن Noindex کافی است؟

خیر. برای حفاظت از داده باید Basic Auth، SSO یا محدودیت دسترسی نیز وجود داشته باشد.

آیا می‌توان دیتابیس Staging را روی فروشگاه زنده Push کرد؟

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

آیا Staging ایمیل واقعی می‌فرستد؟

اگر خروجی Mail مسدود نشود، بله. Clone همان تنظیمات SMTP و گیرنده‌های Production را دارد.

برای تست درگاه چه کنیم؟

از Sandbox یا Test Mode استفاده کنید و Credential واقعی را در محیط آزمایشی نگه ندارید.

چرا Search‑Replace ساده خطرناک است؟

بعضی داده‌ها Serialized هستند و تغییر طول رشته ساختار را خراب می‌کند. WP‑CLI این ساختار را مدیریت می‌کند.

آیا Staging باید همیشه روشن باشد؟

خیر. محیط موقت پس از پروژه باید حذف شود. محیط دائمی نیز باید به‌روز و مانیتور شود.

جمع‌بندی

ساخت Staging وردپرس فقط کلون فایل و دیتابیس نیست. محیط آزمایشی باید خصوصی، ایزوله و مشابه Production باشد؛ ایمیل، درگاه، Webhook، Cron و APIهای واقعی آن کنترل شوند و داده مشتری فقط به‌اندازه نیاز منتقل شود.

در فروشگاه WooCommerce مهم‌ترین خطر، Push کامل دیتابیس Staging به Production است. از زمان Clone، سایت زنده سفارش و مشتری جدید تولید می‌کند و بازنویسی دیتابیس می‌تواند این داده‌ها را از بین ببرد. کد، فایل و Migration را کنترل‌شده Deploy کنید.

Staging زمانی ارزش دارد که فرایند آن تکرارپذیر باشد: Clone تازه، تست مستند، Backup، Deploy محدود، Smoke Test و Rollback. با این ساختار می‌توان Update و توسعه را بدون تبدیل مشتریان واقعی به آزمایش‌کننده انجام داد.

منابع رسمی

آموزش‌های تازه، کد آماده و رفع خطاهر هفته در کانال Dev Source؛ رایگان.

✈️ کانال تلگرام 🟣 کانال روبیکا