وردپرس
آپدیت وردپرس و افزونه بدون خراب شدن سایت؛ برنامه تست، انتشار و بازگشت
نوشته وب ریزان شاپانتشار: بهروزرسانی: ۹ دقیقه مطالعه
پاسخ کوتاه
برای کاهش ریسک آپدیت وردپرس و افزونه، نسخه‌های فعلی و تغییرات را ثبت کنید، از فایل‌ها و پایگاه داده بکاپ قابل بازیابی بگیرید و بهروزرسانی را ابتدا روی محیط آزمایشی بررسی کنید. پس از تست صفحه‌های مهم و مسیر سفارش، تغییر را در زمان مناسب منتشر کنید و سلامت سایت را دوباره بسنجید. هیچ روش عمومی نمی‌تواند خراب نشدن همه سایت‌ها را تضمین کند.
در این مطلب
- نسخه پشتیبان باید قابلیت بازگشت واقعی داشته باشد.
- تست صفحه اصلی کافی نیست؛ ورود، فرم و خرید هم مهماند.
- هر تغییر را ثبت کنید تا علت خطا قابل بررسی باشد.
- بازگرداندن دیتابیس قدیمی در فروشگاه فعال ممکن است سفارش‌های تازه را از بین ببرد.
چرا آپدیت لازم است و چرا باید برنامه داشته باشد؟
بهروزرسانی می‌تواند اصلاح خطا، امنیت، سازگاری یا قابلیت تازه بیاورد. باقی ماندن همیشگی روی نسخه قدیمی راه نگهداری مطمئنی نیست، اما اجرای همه تغییرها بدون بررسی هم ریسک دارد. سایت از ترکیب وردپرس، قالب، افزونه، PHP و تنظیمات میزبان ساخته شده است؛ تغییر یکی ممکن است به دیگری وابسته باشد. هدف برنامه، فهم تغییر و کاهش ریسک در محیط واقعی شماست، نه عقب انداختن نامحدود نگهداری.
مستند بهروزرسانی خودکار وردپرس بر نگهداری نسخه‌های جاری و امکان بازگشت با بکاپ تأکید می‌کند. درباره زمان و ترتیب اقدام، باید اهمیت تغییر، وضعیت سایت و وابستگی ابزارها را بررسی کنید. اصلاح امنیتی فوری و ارتقای عمده قابلیت، لزوماً برنامه یکسانی ندارند. اگر اطلاعیه مشخصی درباره آسیب‌پذیری دارید، از مرجع رسمی همان ابزار پیگیری کنید و تصمیم عملیاتی را به مسئول فنی بسپارید.
فهرست نسخه و تغییرها را قبل از شروع ثبت کنید
نسخه وردپرس، قالب فعال، افزونه‌های مهم، PHP و تنظیمات مرتبط را در سابقه داخلی نگه دارید. برای ابزار دارای لایسنس، اعتبار دریافت نسخه و مسیر رسمی را بررسی کنید. یادداشت تغییرات را بخوانید و موارد مرتبط با فروش، فرم، داده یا API را مشخص کنید. صرف عبارت «رفع باگ» همه تفاوت‌ها را توضیح نمی‌دهد؛ اگر تغییر اثرگذار روشن نیست، از مستند یا پشتیبانی سؤال کنید.
در فروشگاه، مسیر تسویه، پرداخت، موجودی و اعلان را جدا علامت بزنید. در سایت خدماتی، فرم درخواست، رزرو و تماس مهماند. تغییرهایی مثل ارتقای PHP یا جابه‌جایی قالب را بی‌دلیل با آپدیت چند افزونه در یک مرحله ترکیب نکنید. اگر وابستگی مستند نیاز به ارتقای هماهنگ دارد، همان ترتیب را ثبت کنید. فهرست تغییر باید به شما اجازه دهد در صورت خطا بگویید دقیقاً چه چیز و چه زمانی تغییر کرده است.
| ثبت داخلی | چرا لازم است؟ |
|---|---|
| نسخه فعلی و پیشنهادی | تشخیص تفاوت و بازگشت |
| دلیل بهروزرسانی | تعیین اولویت |
| پیش‌نیاز و وابستگی | انتخاب ترتیب |
| مسیرهای تحت اثر | طراحی آزمون |
| مسئول و زمان | پاسخ‌گویی هنگام خطا |
بکاپ فایل و دیتابیس را قابل بازیابی کنید
برای وردپرس، فایل‌ها و پایگاه داده هر دو بخشی از بازیابی‌اند. پایگاه داده می‌تواند محتوا، تنظیمات و سفارش را نگه دارد؛ فایل‌ها نیز قالب، افزونه و رسانه را شامل می‌شوند. نسخه باید زمان، محدوده و محل مشخص داشته باشد. گزارش «بکاپ موفق» را با وجود فایل و آزمون بازیابی در محیط جدا تکمیل کنید. برنامه کامل‌تر در راهنمای بکاپ و بازیابی آمده است.
برای فروشگاه زنده، بازگشت ساده دیتابیس به زمان قبل از آپدیت ممکن است سفارش‌های بعدی را حذف کند. پیش از انتشار، درباره مدیریت تغییرهای جدید تصمیم بگیرید: چه زمانی فروش متوقف می‌شود، کدام داده باید حفظ شود و چه کسی تطبیق را انجام میدهد؟ این کار را در لحظه بحران با حدس انجام ندهید. نسخه قبل از تغییر را کنار نسخه‌ها و راه بازگشت ثبت کنید، اما رمز و داده مشتری را در گزارش عمومی قرار ندهید.
محیط آزمایشی را با هدف و محدودیت روشن بسازید
محیط آزمایشی یا staging نسخه‌ای جدا برای بررسی تغییر است. تا حد لازم باید به نسخه‌ها و تنظیمات اصلی نزدیک باشد، ولی نباید برای مشتری یا جستجو با سایت اصلی اشتباه شود. اعلان، پرداخت و وظایف زمان‌بندی‌شده را بررسی کنید تا پیام یا تراکنش واقعی ناخواسته انجام نشود. داده مشتری را به هر ابزار یا سرور دیگری کپی نکنید؛ دسترسی و مبنای مجاز پردازش داده باید مشخص باشد.
ابتدا نسخه فعلی را روی محیط آزمایشی تست کنید تا بدانید خطا از قبل وجود داشته یا پس از تغییر ایجاد شده است. سپس مطابق ترتیب مورد نیاز، یک تغییر یا مجموعه وابسته مستند را اعمال کنید. نتیجه هر مرحله را بنویسید. اگر همان محیط قبل از آپدیت خراب بوده، موفق یا ناموفق بودن آزمون بعدی قابل تفسیر نیست. نزدیک بودن محیط، احتمال کشف مشکل را بیشتر می‌کند ولی همه تفاوت‌های میزبان و ترافیک واقعی را حذف نمی‌کند.
آزمون پذیرش چه مسیرهایی را پوشش دهد؟
یک فهرست کوتاه اما واقعی تهیه کنید. صفحه اصلی و یک صفحه داخلی را در موبایل باز کنید؛ ورود و خروج، فرم معتبر و نامعتبر، جستجو و دکمه تماس را بررسی کنید. اگر فروشگاه دارید، محصول ساده و متغیر، کالای ناموجود، کوپن در صورت استفاده، ارسال و پرداخت آزمایشی را تست کنید. نتیجه فقط «خوب بود» نباشد؛ انتظار و شاهد را بنویسید تا فرد دیگری نیز بتواند آزمون را تکرار کند.
وظایف پشت‌صحنه هم مهماند. دریافت اعلان، خروجی گزارش، پردازش کار زمان‌بندی‌شده و نقش کاربر مرتبط را بررسی کنید. یک مدیر ممکن است صفحه را ببیند اما کاربر عادی دسترسی یا خطای دیگری داشته باشد. برای سنجش سرعت، صفحه و شرایط ثابت نگه دارید و نتیجه مشاهده‌شده را ثبت کنید. از یک امتیاز تنها نتیجه نگیرید که سایت برای همه کاربران سریع‌تر شده است. خطاهای جدید را با زمان و مسیر مشخص جمع کنید.
- قبل از تغییر، سناریوی اصلی را ثبت کنید.
- پس از تغییر، همان سناریو را تکرار کنید.
- ورودی نامعتبر و وضعیت ناموجود را بررسی کنید.
- اعلان و داده ذخیره‌شده را کنترل کنید.
- در موبایل و نقش کاربر واقعی تست کنید.
- برای خطای جدید، انتشار را متوقف و علت را بررسی کنید.
انتشار را در زمان و دامنه کنترل‌شده انجام دهید
زمانی را انتخاب کنید که مسئول فنی و مسئول کسب‌وکار بتوانند نتیجه را پیگیری کنند. زمان کم‌ترافیک می‌تواند ریسک اثر بر مشتری را کمتر کند، اما نبود پشتیبان در همان زمان مزیت را از بین می‌برد. قبل از تغییر، تأیید کنید بکاپ تازه و محیط اصلی همان نسخه بررسی‌شده را دارد. اگر فرد دیگری هم در حال انتشار است، کارها را هماهنگ کنید. دو تغییر هم‌زمان، تشخیص علت و بازگشت را دشوار می‌کنند.
بعد از انتشار، برای آماده شدن سرویس صبر و وضعیت سلامت را بررسی کنید؛ تست زودهنگام هنگام شروع سرویس می‌تواند نتیجه گمراه‌کننده بدهد. پس از آماده شدن، همان مسیرهای حساس را روی نسخه زنده با تست مجاز انجام دهید. کش و فایل‌های قدیمی را طبق راهنمای ابزار بررسی کنید. اگر آزمون اصلی شکست خورد، راه بازگشت از پیش آماده‌شده را اجرا کنید؛ نگه داشتن نسخه خراب فقط چون ساخت یا آپدیت موفق گزارش شده، نتیجه درستی نیست.
اگر پس از آپدیت سایت مشکل داشت چه کنیم؟
ابتدا اثر و نقطه خطا را مشخص کنید: صفحه سفید، فرم خراب، پرداخت یا ظاهر. وضعیت جاری را حفظ و خطا را ثبت کنید؛ حذف فایل و داده به شکل تصادفی، مسیر بررسی را سخت‌تر می‌کند. راه بازگشت باید با نوع تغییر هماهنگ باشد. گاهی فایل نسخه قبل کافی نیست چون ساختار پایگاه داده تغییر کرده؛ گاهی بازگرداندن دیتابیس هم لازم یا پرخطر است. تصمیم را با مستند تغییر و مسئول فنی انجام دهید.
برای فروشگاه، سفارش‌های تازه و وضعیت پرداخت را قبل از بازیابی دیتابیس بررسی کنید. تغییر وضعیت‌ها را بدون تطبیق مالی انجام ندهید. پس از بازگشت، سلامت و مسیرهای اصلی را دوباره تست کنید و نتیجه را ثبت کنید. سپس علت را در محیط آزمایشی پیگیری کنید. مسیر WordPress SOS برای درخواست درباره خرابی موجود است؛ درخواست اولیه شامل شرح و زمان باشد، نه رمز و کلید دسترسی در متن عمومی.
آپدیت خودکار و برنامه نگهداری را چطور انتخاب کنیم؟
فعال بودن بهروزرسانی خودکار را ابزار بی‌نیاز از نظارت ندانید. برای هر جزء، اهمیت امنیت، حساسیت فرایند، کیفیت بکاپ و قابلیت پایش را بررسی کنید. اعلان موفقیت یا شکست باید به فرد مسئول برسد. در سامانه میزبانی‌شده، بعضی تغییرها توسط ارائه‌دهنده انجام می‌شوند؛ قبل از تغییر دستی، محدوده دسترسی و مسئولیت را بپرسید. دسترسی محدود به پیشخوان با مالکیت سرور یکسان نیست.
برای نگهداری، یک بازه بازبینی متناسب با سایت تعیین کنید و اطلاعیه‌های مهم را جدا پیگیری کنید. سابقه تغییر شامل نسخه، دلیل، آزمون، انتشار و بازگشت باشد. اگر آپدیت باعث خطا شد، علت و تصمیم بعدی را هم بنویسید تا همان مشکل تکرار نشود. برنامه خوب باید هم اجازه پیشرفت بدهد و هم مسیر توقف روشن داشته باشد. هیچ چک لیستی جای شناخت محیط، مسئولیت و آزمون واقعی را نمی‌گیرد.
سؤالات پرتکرار
آیا می‌توان آپدیت را همیشه عقب انداخت؟
تعویق نامحدود راه نگهداری مناسبی نیست. اهمیت اصلاح، امنیت و سازگاری را بررسی کنید و برنامه آزمون و انتشار داشته باشید؛ تغییرهای فوری را از مرجع رسمی پیگیری کنید.
آپدیت خودکار برای همه افزونهها مناسب است؟
تصمیم به حساسیت سایت، بکاپ، پایش و وابستگیها بستگی دارد. اعلان و آزمون پس از تغییر مهماند؛ فعال کردن خودکار به معنی نبود مسئول نگهداری نیست.
چرا پس از بازگشت فایل افزونه مشکل حل نشد؟
ممکن است تنظیم یا ساختار داده نیز تغییر کرده باشد یا علت در جزء دیگری باشد. مستند و گزارش تغییر را بررسی کنید؛ دیتابیس زنده را بدون برنامه حفظ داده بازنویسی نکنید.
بعد از آپدیت موفق باید چه بررسی کنم؟
صفحهها، نقش کاربر، فرم و مسیر سفارش و اعلان را طبق فهرست آزمون بررسی کنید. پیام موفقیت نصب فقط انجام عملیات بهروزرسانی را نشان میدهد، نه صحت همه فرایندها.
سؤال دیگری دارید؟ تماس بگیرید
برای بررسی محصول یا مشکل سایت، موضوع درخواست را مشخص کنید.
نام محصول یا نشانی سایت و شرح نیاز را آماده کنید؛ اطلاعات دسترسی را در پیام اولیه نفرستید.
تماس با وب ریزان شاپ