مشکل WP Rocket با WordPress 7.1؛ علت خطای بحرانی و راهحل
اگر بعد از بهروزرسانی وردپرس به نسخه 7.1 با خطای بحرانی، صفحه سفید، خطای 500 یا از دسترس خارج شدن پنل مدیریت مواجه شدهاید و افزونه WP Rocket روی سایت شما فعال است، احتمال دارد با یکی از مهمترین ناسازگاریهای اخیر WP Rocket روبهرو شده باشید.
با انتشار WordPress 7.1 در 19 اوت 2026 مشخص شد برخی نسخههای WP Rocket در بعضی پیکربندیها میتوانند باعث بروز یک Fatal Type Error شوند؛ خطایی که در شرایطی حتی دسترسی به بخش مدیریت وردپرس را هم غیرممکن میکرد.
WP Rocket این مشکل را تأیید کرد و یک روز بعد، در 20 اوت 2026، نسخه 3.23.2.2 را بهعنوان Hotfix منتشر کرد.
خبر خوب این است که مشکل شناختهشده اکنون برطرف شده؛ اما ماجرا از نظر فنی و از نظر شیوه مدیریت بهروزرسانی سایتهای وردپرسی نکات مهمی دارد.
مشکل WP Rocket و WordPress 7.1 دقیقاً چیست؟
پس از ارتقای برخی سایتها از WordPress 7.0.x به WordPress 7.1، سایت با خطایی مشابه نمونه زیر مواجه میشد:
PHP Fatal error:
Uncaught TypeError:
substr(): Argument #1 ($string) must be of type string, int given
/wp-content/plugins/wp-rocket/inc/ThirdParty/Plugins/CDN/Cloudflare.php:562
در چنین شرایطی ممکن بود نهتنها Front-end سایت، بلکه /wp-admin نیز از دسترس خارج شود.
نکته مهم اینجاست که خطا در فایل مربوط به سازگاری Cloudflare در WP Rocket اتفاق میافتاد، اما برای بروز مشکل الزاماً نیازی نبود افزونه رسمی Cloudflare روی وردپرس نصب شده باشد.
بنابراین دیدن عبارت Cloudflare.php در Error Log لزوماً به این معنی نیست که مشکل از تنظیمات Cloudflare سایت شماست.
علت فنی خطا چه بود؟
ریشه مشکل به نحوه پردازش Callbackهای سیستم Hook وردپرس برمیگردد.
WP Rocket در بخشی از کد خود کلید Callback را مستقیماً به تابع PHP یعنی substr() ارسال میکرد:
substr( $key, … )
کد افزونه فرض کرده بود که مقدار $key همیشه از نوع String است.
اما در شرایطی که با WordPress 7.1 ایجاد میشد، این کلید میتوانست بهصورت Integer در آرایه قرار بگیرد. در PHP 8 و بهخصوص در کدی که بررسی نوع داده در آن سختگیرانه است، ارسال Integer به substr() باعث TypeError میشود.
به بیان ساده، WP Rocket انتظار داشت چیزی شبیه این دریافت کند:
“20788”
اما در برخی شرایط مقدار به شکل عددی دریافت میشد:
20788
همین تفاوت کوچک در نوع داده میتوانست اجرای PHP را متوقف کرده و سایت را به Critical Error برساند.
آیا همه سایتهای دارای WP Rocket از کار افتادند؟
خیر.
وجود WP Rocket و WordPress 7.1 بهتنهایی به این معنی نیست که سایت حتماً Crash خواهد کرد.
بروز خطا به مجموعه Hookها و Callbackهایی که افزونهها و قالب سایت ثبت کردهاند بستگی داشت. به همین دلیل بعضی سایتها پس از آپدیت بدون مشکل کار میکردند و بعضی سایتها بلافاصله با Fatal Error مواجه میشدند.
با این حال شدت اثر خطا بالا بود؛ زیرا در سایتی که شرایط لازم برای ایجاد آن وجود داشت، ممکن بود تقریباً تمام Requestهای وردپرس تحت تأثیر قرار بگیرند.
نکته مهمتر؛ این باگ قبل از انتشار WordPress 7.1 گزارش شده بود
یکی از نکات قابل توجه این اتفاق این است که گزارش اصلی مربوط به این باگ در Repository عمومی WP Rocket در GitHub در 6 ژوئیه 2026 ثبت شده بود.
در گزارش حتی به سناریوی بروز خطا، خط مشکلدار و امکان تبدیل $key به String اشاره شده بود.
این Issue بعدها با Severity و Priority بحرانی مشخص شد.
بنابراین مشکل زمانی شناخته شد که WordPress 7.1 هنوز در چرخه توسعه قرار داشت و انتشار عمومی نسخه نهایی آن چند هفته بعد انجام شد.
از دید مدیریت نرمافزار، این بخش ماجرا شاید مهمتر از خود باگ باشد. وجود خطا در یک نرمافزار پیچیده غیرعادی نیست؛ اما این اتفاق بار دیگر اهمیت تست افزونههای مهم در نسخههای Beta و Release Candidate وردپرس را نشان داد.
Rocket مشکل را چگونه برطرف کرد؟
پس از انتشار WordPress 7.1 و گزارش کاربران، تیم WP Rocket ناسازگاری را رسماً تأیید کرد.
در 20 اوت 2026 نسخه:
WP Rocket 3.23.2.2
منتشر شد.
در Changelog رسمی این نسخه، تغییر اصلی بهصورت رفع Fatal Type Error پس از ارتقا به WordPress Core 7.1 در برخی پیکربندیها اعلام شده است.
بنابراین اگر از WordPress 7.1 استفاده میکنید، توصیه میشود WP Rocket را حداقل به نسخه 3.23.2.2 یا نسخه جدیدتر ارتقا دهید.
اگر سایت بعد از آپدیت WordPress 7.1 از دسترس خارج شده چه کنیم؟
اگر هنوز به پنل مدیریت دسترسی دارید، ابتدا نسخه WP Rocket را بررسی و آن را به آخرین نسخه موجود ارتقا دهید.
اما اگر Critical Error باعث شده /wp-admin هم باز نشود، یکی از سریعترین روشهای بازیابی سایت غیرفعال کردن موقت WP Rocket از طریق File Manager هاست یا SFTP است.
به مسیر زیر بروید:
/wp-content/plugins/
و نام پوشه:
wp-rocket
را موقتاً به چیزی مانند زیر تغییر دهید:
wp-rocket-off
وردپرس دیگر قادر به بارگذاری افزونه نخواهد بود و در بسیاری از سایتهای درگیر، دسترسی به سایت و پنل مدیریت دوباره برقرار میشود.
پس از ورود به مدیریت میتوانید نسخه جدید WP Rocket را نصب یا افزونه را به نسخه اصلاحشده ارتقا دهید.
این روش در مستندات رسمی WP Rocket نیز بهعنوان یکی از روشهای بازیابی سایتهای تحت تأثیر مطرح شده است.
آیا باید WordPress 7.1 را Rollback کنیم؟
اگر WP Rocket را به نسخه اصلاحشده ارتقا دادهاید و سایت بدون مشکل کار میکند، معمولاً نیازی به Rollback وردپرس به 7.0.x وجود ندارد.
Rollback بیشتر یک راهکار موقت برای شرایطی بود که Hotfix هنوز منتشر نشده بود یا به هر دلیل امکان ارتقای WP Rocket وجود نداشت.
در حال حاضر مسیر منطقیتر این است:
- از سایت Backup کامل تهیه کنید.
- WP Rocket را به آخرین نسخه پایدار ارتقا دهید.
- Cacheهای سایت و CDN را پاک کنید.
- Front-end، پنل مدیریت و عملیات اصلی سایت را تست کنید.
- Error Log سرور را برای خطاهای PHP بررسی کنید.
برای سایتهای فروشگاهی یا وبسایتهای تجاری مهم بهتر است همین مراحل ابتدا در Staging Environment انجام شوند.
آیا مشکل از Cloudflare بود؟
خیر؛ حداقل نه به معنایی که ممکن است از نام فایل خطا برداشت شود.
خطا در کلاس سازگاری Cloudflare داخل WP Rocket اتفاق میافتاد، اما گزارشهای فنی نشان دادند سایت میتوانست بدون نصب افزونه رسمی Cloudflare نیز با این Fatal Error مواجه شود.
بنابراین غیرفعال کردن DNS Proxy کلادفلر یا تغییر تنظیمات CDN الزاماً راهحل این مشکل نیست.
راهحل اصلی، ارتقای WP Rocket به نسخه اصلاحشده است.
آیا حالا استفاده از WP Rocket امن است؟
این اتفاق بهتنهایی دلیلی برای کنار گذاشتن WP Rocket نیست. WP Rocket همچنان یکی از افزونههای شناختهشده بهینهسازی عملکرد وردپرس است و تیم توسعه نیز Hotfix را سریع منتشر کرد.
اما این Incident یک یادآوری مهم برای مدیران سایت است:
هیچ افزونهای، حتی یکی از محبوبترین افزونههای تجاری وردپرس، نباید جای Backup، Staging و فرآیند کنترلشده بهروزرسانی را بگیرد.
بهخصوص در سایتهایی که WooCommerce، Elementor، افزونههای اختصاصی، سیستم عضویت یا Integrationهای متعدد دارند، بهروزرسانی همزمان WordPress Core و چند افزونه مهم بدون تست میتواند ریسک قابل توجهی ایجاد کند.
پیشنهاد مایرایانه برای بهروزرسانی سایتهای وردپرسی
برای سایتهای مهم بهتر است Core وردپرس، قالب و افزونههای حیاتی مستقیماً و بدون بررسی روی سایت Production بهروزرسانی نشوند.
یک فرآیند حرفهای شامل Backup، بررسی Changelog، تست در Staging، کنترل Error Log و سپس انتشار تغییرات روی سایت اصلی است.
این موضوع مخصوص WP Rocket نیست؛ افزونههایی مانند WooCommerce، Elementor، افزونههای امنیتی، افزونههای Cache و پلاگینهای متصل به سرویسهای خارجی هم میتوانند در نسخههای جدید WordPress دچار ناسازگاری شوند.
جمعبندی
ناسازگاری WP Rocket با WordPress 7.1 باعث شد برخی سایتها پس از ارتقای وردپرس با Fatal Type Error و Critical Error مواجه شوند.
منشأ خطا در بخشی از Integration مربوط به Cloudflare در WP Rocket بود که نوع داده Callback Key را String فرض میکرد.
WP Rocket این مشکل را تأیید و در نسخه 3.23.2.2 منتشرشده در 20 اوت 2026 اصلاح کرد.
اگر WordPress 7.1 دارید و هنوز از نسخه قدیمی WP Rocket استفاده میکنید، قبل از هر اقدام دیگری افزونه را به آخرین نسخه پایدار ارتقا دهید.
و مهمتر از همه، این اتفاق نشان میدهد برای سایتهای تجاری و مهم، «Update» نباید فقط فشردن یک دکمه باشد؛ بلکه باید بخشی از یک فرآیند مدیریتشده نگهداری و تست وبسایت باشد.
