در این مقاله
آپدیت امنیتی وردپرس را باید سریع اما با مسیر بازیابی روشن انجام داد. در ۲۸ اکتبر ۲۰۲۶، WordPress 7.1.4 به‌عنوان انتشار امنیتی معرفی شد و تیم وردپرس بهروزرسانی سایت‌ها را توصیه کرد. این راهنما در ۳۱ اکتبر تهیه شده و روی اجرای امن تغییر تمرکز دارد: تشخیص نسخه، تهیه بکاپ قابل استفاده، آزمون مسیرهای مهم و بررسی نتیجه پس از انتشار.
اگر فروشگاه ووکامرس دارید، بازشدن صفحه اصلی نشانه کافی نیست. ورود مدیر، سبد خرید، درگاه، Callback و ثبت سفارش هر کدام مسیر جداگانه‌اند. همچنین بازیابی دیتابیس قدیمی میتواند سفارش‌های پس از زمان بکاپ را حذف کند. پس برنامه تغییر باید هم خطر عقب‌انداختن اصلاح امنیتی را در نظر بگیرد و هم خطر از بین رفتن داده جدید را.
اول خبر رسمی و نسخه نصبشده را تطبیق دهید
اطلاعیه رسمی WordPress 7.1.4 مرجع وضعیت انتشار و اصلاحات است. نسخه‌ای که در یک خبر یا فایل دانلود نوشته شده لزوماً همان نسخه فعال سایت شما نیست. در پیشخوان، بخش بهروزرسانی و اطلاعات سلامت سایت را بررسی کنید. اگر چند محیط یا چند نصب دارید، دامنه و محیط را کنار نسخه ثبت کنید تا اصلاح روی نمونه اشتباه انجام نشود.
فعالبودن آپدیت خودکار با موفقشدن آخرین اجرا یکسان نیست. ممکن است اجرای پس‌زمینه به علت دسترسی فایل، ارتباط شبکه یا خطای افزونه متوقف شده باشد. نسخه نهایی و زمان انجام را بخوانید و پیام خطا را بدون اطلاعات حساس نگه دارید. برای شاخه‌های قدیمی نیز فقط به شماره نسخه این مقاله تکیه نکنید؛ وضعیت پشتیبانی و اصلاح مناسب همان شاخه را از مرجع رسمی بررسی کنید.
آیا باید همه افزونه‌ها را هم‌زمان تغییر دهیم؟
تغییر هم‌زمان هسته، نسخه PHP، قالب و چند افزونه تشخیص علت مشکل را سخت میکند. ترتیب را با ریسک و توصیه سازنده تعیین کنید، اما بدون ضرورت چند محور مستقل را در یک گام جابه‌جا نکنید. برای هر جزء، نسخه فعلی، نسخه مقصد و دلیل تغییر را بنویسید. اگر افزونه‌ای برای نسخه جدید اصلاح سازگاری داده، یادداشت انتشار آن را هم ثبت کنید.
پیش از غیرفعال‌کردن افزونه، کاربردش را بررسی کنید. ممکن است افزونه ظاهراً کوچک، تولید فاکتور، اتصال ارسال یا جلوگیری از ثبت سفارش تکراری را انجام دهد. حذف بی‌برنامه آن میتواند فروشگاه را از نظر ظاهری سالم و از نظر عملیات ناقص کند. راهنمای ارتقای PHP وردپرس و ووکامرس برای جداسازی تغییر Runtime از تغییر هسته مکمل این مرحله است.
بکاپ را با زمان مرجع و مسیر بازیابی تعریف کنید
حداقل باید بدانید نسخه پشتیبان شامل چه دیتابیسی، چه فایل‌هایی و چه تنظیماتی است. قالب سفارشی، فایل بارگذاری‌شده و داده سفارشها ممکن است در جاهای متفاوت باشند. ثبت یک فایل فشرده در پنل به‌تنهایی ثابت نمی‌کند همه اجزا سازگارند. زمان مرجع و روش ایجاد بکاپ را بنویسید و دسترسی به آن را برای افراد لازم محدود نگه دارید.
روی نمونه جدا یک بازیابی انجام دهید. صفحه مدیریت، چند محتوای نمونه، فایل رسانه و سفارش ساختگی باید قابل استفاده باشند. اگر فقط دیتابیس برگردد ولی افزونه یا فایل مورد نیاز نباشد، بازیابی ناقص است. فایل بکاپ را در مسیر عمومی سایت نگه ندارید؛ نسخه پشتیبان ممکن است داده‌ای داشته باشد که در حالت عادی پشت احراز هویت قرار دارد.
محیط آزمایشی را از تراکنش واقعی جدا کنید
کپی فروشگاه نباید با کلید درگاه اصلی پرداخت بگیرد یا پیامک واقعی بفرستد. ایمیل، Webhook، Cron، اتصال حسابداری و حمل‌ونقل را بررسی کنید. دامنه آزمایشی را هم با کنترل دسترسی مناسب محافظت کنید؛ صرف نوشتن noindex جلوی دسترسی به داده مشتری را نمی‌گیرد. برای تست اولیه از داده ساختگی استفاده کنید و ورود اطلاعات واقعی را به حداقل لازم برسانید.
درگاه آزمایشی رسمی را در صورت وجود به کار ببرید. وضعیت سفارش موفق، ناموفق، رهاشده و Callback تکراری را جدا تست کنید. هیچ تراکنش واقعی در این راهنما انجام نشده و سازگاری یک درگاه مشخص ادعا نمی‌شود. نسخه دقیق افزونه درگاه و نوع Checkout باید در گزارش ثبت شود، چون نتیجه یک محیط را نمی‌توان به همه فروشگاه‌ها تعمیم داد.
نظرات کاربران (۰)
هنوز نظری ثبت نشده است. اولین نفر باشید.