بروزرسانی وردپرس روی کپی: انتقال کپی به سایت اصلی یک سفارش را پاک کرد

روز ۱۶ آبان ۱۴۰۵ روی یک فروشگاه آزمایشی کوچک فارسی که خودمان ساخته بودیم، با وردپرس 7.1.3، ووکامرس 11.1.2 و قالب Storefront، پنج چیز را به‌روز کردیم: خود وردپرس، سه افزونه و قالب. اول روی یک کپی، بعد روی سایت اصلی. در فهرستی از ۱۳ بررسی ساده (صفحه اصلی، سبد خرید، ثبت سفارش، فرم تماس، ورود) سایت اصلی هر ۱۳ بررسی را گذراند و کپی ۱۰ بررسی را؛ سه موردی که کپی نگذراند همه به ایمیل مربوط بود. انتقال کپی به سایت اصلی سفارشی را که بعد از ساخت کپی ثبت شده بود پاک کرد.

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

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

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

وقتی ابزار به‌روزرسانی خودکار وردپرس را اجرا کردیم، هسته از 7.1.3 به 7.1.4 رفت و سه افزونه و قالب سر جایشان ماندند، چون به‌روزرسانی خودکارشان خاموش بود (برای هر افزونه و قالب جدا روشن می‌شود). سایتی که فقط نگارش‌های تعمیر و امنیتی را می‌گیرد، این جمله را در همان صفحه می‌بیند: «این سایت فقط با نگارش‌های تعمیر و امنیتی به صورت خودکار به‌روز می‌شود.» اگر این حالت را می‌خواهید، این خط را به wp-config.php اضافه کنید:

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

کپی را در ۳۷ ثانیه ساختیم و خود افزونه می‌گوید چه چیزی را خاموش کرده است

برای ساختن کپی (Staging) از WP Staging Pro نگارش 6.19.0 استفاده کردیم، همان نگارشی که فروشگاه می‌فروشد. در پنجره «Create Staging Site» فقط نام را عوض کردیم. ساخت ۳۷ ثانیه طول کشید. نتیجه پوشه‌ای حدود ۲۴۲ مگابایت است که وردپرس خودش را هم دارد. پنجره پیش از ساخت می‌نویسد ایمیل، کرون (Cron jobs) و WooCommerce actions در کپی خاموش است. پیشخوان کپی هم نوار نارنجی «STAGING» دارد و یادداشتی که می‌گوید کش، پیوندهای دائمی نام نوشته و ایمیل‌های خروجی خاموش شده است.

کپی برای بازدیدکننده و ربات‌ها چه می‌شود (صفحه ورود، noindex، پیوندهای ساده) را در نوشته تغییر قالب روی کپی آزموده‌ایم. کپی وردپرس خودش را دارد: هسته را آنجا به 7.1.4 بردیم و سایت اصلی روی 7.1.3 ماند.

کپی همه بررسی‌ها را گذراند، جز سه بررسی ایمیل

همان فهرست را قبل و بعد از به‌روزرسانی‌ها اجرا کردیم. ۱۳ بررسی جواب درست یا نادرست دارند: باز شدن صفحه اصلی، فروشگاه، یک صفحه محصول، سبد و صفحه تسویه حساب (۵)، ثبت یک سفارش با پرداخت در محل و ذخیره شدن آن (۲)، رسیدن ایمیل سفارش (۱)، فرم تماس و رسیدن ایمیلش (۲)، ورود و باز شدن پیشخوان (۲) و نبودن خطای مرگبار در لاگ (۱). یک خط چهاردهم هم فقط چاپ می‌کند کدام یک از دو جمله آزمایشی ما، یکی در قالب مادر و یکی در قالب فرزند، پایین صفحه هست.

	سایت اصلی	کپی
قبل از به‌روزرسانی	۱۳ از ۱۳	۱۰ از ۱۳
بعد از همان پنج به‌روزرسانی	۱۳ از ۱۳	۱۰ از ۱۳
خط‌های عوض‌شده در متن پنج صفحه	۱۲۷	۱۲۷

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

متن پنج صفحه (صفحه اصلی، فروشگاه، سبد، تسویه حساب و تماس) را هم قبل و بعد ذخیره و مقایسه کردیم. روی کپی و روی سایت اصلی دقیقاً همان ۱۲۷ خط عوض شد. بیشتر آنها برچسب‌های انگلیسی قالب بود («Menu»، «My Account»، «Cart»، «Built with WooCommerce») که فارسی شد، چون با این به‌روزرسانی‌ها ۹ فایل ترجمه برای افزونه‌ها و قالب‌ها آمد؛ این سایت تازه ساخته شده بود و تا آن لحظه هیچ‌کدام را نگرفته بود. فهرست مرتب‌سازی فروشگاه هم متن دیگری گرفت: «مرتب سازی بر اساس میانگین رتبه» شد «مرتب‌سازی بر اساس امتیاز».

یک تفاوت به ترجمه ربط نداشت. در footer.php قالب مادر یک جمله نوشته بودیم و در functions.php قالب فرزند یک جمله دیگر. بعد از به‌روزرسانی قالب، جمله قالب فرزند ماند و جمله قالب مادر نبود. هیچ‌کدام از ۱۳ بررسی رد یا قبول به آن نگاه نمی‌کرد، و خط چهاردهم فقط چاپش می‌کرد. ویرایشی که در خود فایل‌های قالب مادر بنویسید، مثل همان جمله، با به‌روزرسانی قالب می‌رود؛ در قالب فرزند می‌ماند.

در آزمایش ما وردپرس افزونه خراب را فقط وقتی خودش به‌روز کرده بود برگرداند

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

دستی، از صفحه «به‌روزرسانی‌ها»: صفحه نوشت افزونه با موفقیت به‌روز شد. بعد از آن صفحه اصلی، پیشخوان، صفحه ورود و فروشگاه هر چهار کد 500 دادند و نگارش قبلی دیگر نبود. راه بیرون آمدن (حالت بازیابی یا تغییر نام پوشه افزونه) را در نوشته خطای 500 وردپرس آورده‌ایم.

خودکار، با ابزار به‌روزرسانی خود وردپرس: افزونه به 1.1 رفت، وردپرس صفحه اصلی را باز کرد، خطای مرگبار را دید و نگارش 1.0 را برگرداند؛ کل کار حدود ۱۲ ثانیه طول کشید. سایت خودش دوباره باز شد و ایمیلی با عنوان «به‌روزرسانی برخی از افزونه‌ها ناموفق بود» به مدیر آمد: «افزونه‌های زیر در به‌روزرسانی شکست خوردند. اگر در به‌روزرسانی خطای کشنده‌ای وجود داشته باشد، نسخه قبلی نصب شده بازگردانی خواهد شد.»

این برگرداندن شرط دارد. دیدیم که فقط در اجرای زمان‌بندی‌شده (کرون) کار می‌کند (کرون را با تعریف ثابت DOING_CRON در خط فرمان شبیه‌سازی کردیم): بار اول ابزار را بیرون از کرون اجرا کردیم، وردپرس افزونه را پیش از به‌روزرسانی غیرفعال کرد، 1.1 غیرفعال روی دیسک ماند و برگردانده نشد. دو شرط دیگر را از کد وردپرس خواندیم و اجرا نکردیم: افزونه باید فعال باشد، و بررسی فقط صفحه اصلی را باز می‌کند و فقط خطای مرگبار را می‌بیند، پس افزونه‌ای که فقط سبد خرید را اشتباه نشان بدهد برگردانده نمی‌شود. آنچه دیدیم با یک افزونه آزمایشی، PHP 8.3 و وردپرس 7.1.3 بود.

اگر کار وسط به‌روزرسانی قطع شود، سایت تا ۱۰ دقیقه 503 می‌دهد

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

خط اول نام فایل است و خط دوم محتوای آن. به‌روزرسانی را روی هاستی شبیه‌سازی کردیم که کار را بعد از ۳ ثانیه متوقف می‌کند. فایل ماند و افزونه روی 1.0 ماند، چون کار پیش از جابه‌جایی فایل‌ها قطع شد؛ قطع شدن کار در وسط جابه‌جایی فایل‌ها را آزمایش نکردیم. صفحه اصلی، پیشخوان و ورود با سرصفحه Retry-After: 600 کد 503 دادند. متن صفحه روی سایت فارسی ما انگلیسی بود: «Briefly unavailable for scheduled maintenance. Check back in a minute.»

طبق کد وردپرس اگر زمان داخل فایل ۱۰ دقیقه یا بیشتر پیش باشد، وردپرس آن را نادیده می‌گیرد. در آزمایش ما با فایلی که زمان داخلش ۹ دقیقه پیش بود سایت 503 داد و با فایلی که زمانش ۱۱ دقیقه پیش بود 200. فایل در هر دو حال روی دیسک ماند. اگر مطمئنید به‌روزرسانی دیگر در جریان نیست و نمی‌خواهید صبر کنید، همان فایل را پاک کنید.

کپی را به سایت فروشگاهی منتقل نکنید

WP Staging Pro 6.19.0 راهی دارد که کپی را به سایت اصلی می‌برد: در منوی Actions گزینه Push Changes پنجره‌ای با عنوان Push to Current Site باز می‌کند. برای این آزمایش سایت اصلی را به نقطه‌ای برگردانده بودیم که پیش از هر به‌روزرسانی روی سایت اصلی ذخیره کرده بودیم (هسته 7.1.3). پنجره نوشت با روش پیش‌فرض (Classic) انتقال ممکن نیست، چون نگارش وردپرس کپی (7.1.4) با سایت اصلی (7.1.3) فرق دارد. با روش دیگر (Next-Gen) اجازه داد، با کادری نارنجی هشدار داد: «Shop data such as WooCommerce orders can be affected» (ممکن است داده‌های فروشگاه، مثل سفارش‌ها، عوض شوند)، و پیش از اجرا تیک «I understand this will overwrite selected target data and I have verified my backup» (بازنویسی را می‌پذیرم و بکاپ را بررسی کرده‌ام) را خواست.

بقیه تنظیم‌های پنجره را همان‌طور که بود نگه داشتیم: ۵۵ جدول از ۵۵ (به‌روزرسانی‌ها سه جدول به کپی اضافه کرده بود)، ۷ پوشه از ۸، بکاپ کامل روشن. قبل از انتقال یک سفارش روی سایت اصلی ثبت کرده بودیم. انتقال تمام شد. سایت اصلی حالا افزونه‌ها و قالب کپی را داشت، اما وردپرسش هنوز 7.1.3 بود، و فقط یک سفارش داشت: سفارش آزمایشی کپی. سفارشی که روی سایت اصلی ثبت کرده بودیم نبود.

راهنمای WP Staging همین رفتار را می‌نویسد: «Any selected table will completely overwrite its counterpart on the production site.» (هر جدولی که انتخاب شود جدول هم‌نام خودش را در سایت اصلی کاملاً بازنویسی می‌کند.) فایل بکاپی با ۱۱۲٬۸۷۰٬۲۱۹ بایت پیش از انتقال ساخته شده بود؛ آن را برنگرداندیم. سفارش آزمایشی‌ای هم که برای فهرست روی کپی ثبت می‌کنید با همین انتقال به سایت اصلی می‌رود.

این را روی 6.19.0 دیدیم، نگارشی که فروشگاه می‌فروشد. صفحه خود افزونه نگارش 6.20.0 (۱۴ آبان) را تازه نشان می‌داد و آن را آزمایش نکردیم. در یادداشت‌های تغییرات سازنده برای نگارش رایگان 4.20.0 همان روز، با برچسب Pro، آمده است: «Record when a staging site last copied the live shop orders, the baseline for pushing a shop without losing them. (Pro)» (ثبت آخرین باری که کپی سفارش‌های فروشگاه را گرفته، پایه‌ای برای انتقال فروشگاه بدون از دست رفتن سفارش).

راه دوم در راهنمای WP Staging برای به‌روزرسانی افزونه یا قالب فقط انتقال فایل‌هاست. دوباره از همان نقطه شروع کردیم، با یک سفارش تازه روی سایت اصلی، و انتقال را با ۰ جدول از ۵۵ اجرا کردیم. سفارش ماند و افزونه‌ها و قالب تازه شدند، اما هسته 7.1.3 ماند و نگارش دیتابیس ووکامرس 11.1.2 ماند، در حالی که فایل‌هایش 11.2.2 بود، و بررسی خود ووکامرس می‌گفت دیتابیس به‌روزرسانی لازم دارد. یعنی آخرین قدم باز هم روی سایت اصلی است. نوشته به‌روزرسانی دستی افزونه نشان داده بود برگرداندن فایل‌های ووکامرس دیتابیس را برنمی‌گرداند.

ترتیب کار برای سایتی که سفارش می‌گیرد

مستندات ووکامرس هم همین ترتیب را می‌نویسد: اول روی کپی، بعد همان مجموعه به‌روزرسانی روی سایت اصلی. روی سایت ما همان پنج به‌روزرسانی روی سایت اصلی ۱۳ از ۱۳ شد، با همان ۱۲۷ خط.

1. از فایل‌ها و دیتابیس سایت اصلی بکاپ کامل بگیرید. صفحه «به‌روزرسانی‌ها» همین را پیش از هر کاری می‌خواهد.
2. کپی بسازید و هر پنج به‌روزرسانی را همان‌جا اجرا کنید.
3. فهرست را روی کپی اجرا کنید و متن صفحه‌ها را قبل و بعد کنار هم بگذارید.
4. سایت اصلی را در حالت Coming soon بگذارید تا وسط به‌روزرسانی سفارشی ثبت نشود؛ ووکامرس این را می‌نویسد و ما اجرایش نکردیم.
5. همان به‌روزرسانی‌ها را روی سایت اصلی اجرا کنید و با همان فهرست بسنجید؛ فرم و ایمیل را اینجا امتحان کنید.
6. اگر صفحه 503 ماند و به‌روزرسانی دیگر در جریان نیست، ۱۰ دقیقه صبر کنید یا فایلی را که بالا نشان دادیم پاک کنید.

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

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