نسخه PHP وردپرس: چرا یک تیک در ووکامرس فارسی، PHP 7.4 را «پیشنهادی» نشان می‌دهد؟

وردپرس 7.1.4 فارسی را فقط با ووکامرس و ووکامرس فارسی (10.0.7) روی PHP 7.4.33 اجرا کردیم. صفحه «سلامت سایت» نوشت: «سایت شما در حال اجرای پیشنهادی PHP (7.4.33) است». پشتیبانی امنیتی PHP 7.4 از ۷ آذر ۱۴۰۱ تمام شده است.

علتش یک تیک در ووکامرس فارسی است. همان تیک را برداشتیم و همان سایت روی همان PHP نوشت که نسخه‌اش منسوخ است و به‌روزرسانی امنیتی نمی‌گیرد. پس برای انتخاب نسخه PHP به سلامت سایت تکیه نکنید.

برای نسخه PHP وردپرس، کوتاه‌ترین جواب 8.3 است. وردپرس همین نسخه یا بالاتر را توصیه می‌کند و PHP 8.3 تا ۱۰ دی ۱۴۰۶ به‌روزرسانی امنیتی می‌گیرد. PHP 8.4 و 8.5 هم سایت آزمایشی ۳۲ افزونه‌ای ما را بالا آوردند، اما لاگ را پر از هشدار کردند.

با تنظیم پیش‌فرض ووکامرس فارسی، سلامت سایت هر هفت نسخه PHP را «پیشنهادی» می‌خواند

سلامت سایت نسخه PHP را خودش نمی‌سنجد. از سرویس Serve Happy در WordPress.org می‌پرسد برای این نسخه کدام نسخه پیشنهاد می‌شود و جواب را با نسخه فعلی مقایسه می‌کند. ووکامرس فارسی در زبانه «سوپر ادمین» گزینه «افزایش سرعت پیشخوان» را دارد و پیش‌فرضش تیک‌خورده است:

تا این تیک هست، افزونه به درخواست Serve Happy خودش جواب «[]» می‌دهد و درخواست به WordPress.org نمی‌رسد. جواب خالی نسخه پیشنهادی ندارد و هسته وردپرس نسخه فعلی را «پیشنهادی» حساب می‌کند. این همان ردیف روی PHP 7.4.33 است:

بعد از برداشتن تیک، همان ردیف روی همان نسخه این شد:

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

نسخه PHP	سلامت سایت، تنظیم پیش‌فرض	بعد از برداشتن تیک
7.4.33	پیشنهادی	بحرانی: منسوخ، بدون به‌روزرسانی امنیتی
8.0.30	پیشنهادی	بحرانی: منسوخ، بدون به‌روزرسانی امنیتی
8.1.34	پیشنهادی	قدیمی، باید به‌روز شود
8.2.35	پیشنهادی	قدیمی، باید به‌روز شود
8.3.36	پیشنهادی	پیشنهادی
8.4.27	پیشنهادی	پیشنهادی
8.5.12	پیشنهادی	پیشنهادی

این جدول را از آزمون PHP خود سلامت سایت خواندیم که داخل هر نسخه اجرا شد؛ تصویرها فقط روی 7.4.33 گرفته شده‌اند. پاسخ Serve Happy هنوز 8.1 و 8.2 را از نظر به‌روزرسانی امنیتی «امن» می‌داند (is_secure)، با اینکه php.net به‌روزرسانی امنیتی 8.1 را از ۱۰ دی ۱۴۰۴ تمام‌شده نوشته؛ پس حتی بدون آن تیک، سلامت سایت 8.1 را بحرانی نمی‌کند و فقط «قدیمی» می‌نویسد، با اینکه پشتیبانی امنیتی‌اش تمام شده.

سلامت سایت جواب Serve Happy را یک هفته نگه می‌دارد، پس بعد از برداشتن تیک ممکن است تا یک هفته همان جواب قبلی را ببینید. نسخه واقعی را از «ابزارها > سلامت سایت > اطلاعات > سرور» بخوانید: ردیف «نگارش php» را خود PHP می‌نویسد و روی همین سایت 7.4.33 را درست نشان داد. اگر هاست شما به WordPress.org دسترسی دارد و می‌خواهید سلامت سایت نسخه را با پیشنهاد WordPress.org مقایسه کند، تیک را بردارید؛ ما فقط با دسترسی آزاد به WordPress.org آزمودیم و هاستی را که به آن دسترسی ندارد آزمایش نکردیم. ما سرعت پیشخوان را با تیک و بدون تیک نسنجیدیم و توضیح خود افزونه می‌گوید این تیک تحلیل‌های پیشخوان را سریع‌تر می‌کند.

وردپرس PHP 8.3 یا بالاتر را توصیه می‌کند و php.net پایان هر نسخه را می‌نویسد

صفحه نیازمندی‌های وردپرس هاستی با PHP 8.3 یا بالاتر را توصیه می‌کند. جدول سازگاری PHP در راهنمای هسته وردپرس برای وردپرس 7.1 هر نسخه از 7.4 تا 8.5 را سازگار می‌نویسد، پس انتخاب بین نسخه‌هاست و پایان پشتیبانی تصمیم می‌گیرد. تاریخ‌ها را php.net نوشته و ما شمسی کرده‌ایم:

نسخه PHP	پایان پشتیبانی امنیتی
7.4	۷ آذر ۱۴۰۱ (تمام شده)
8.0	۵ آذر ۱۴۰۲ (تمام شده)
8.1	۱۰ دی ۱۴۰۴ (تمام شده)
8.2	۱۰ دی ۱۴۰۵
8.3	۱۰ دی ۱۴۰۶
8.4	۱۱ دی ۱۴۰۷
8.5	۱۱ دی ۱۴۰۸

پس سه نسخه اول رفته‌اند و 8.2 در دی همین سال می‌رود. از نسخه‌هایی که با توصیه وردپرس جور است (8.3 به بعد)، روی سایت آزمایشی ۳۲ افزونه‌ای ما فقط روی 8.3 هیچ افزونه‌ای در لاگ خط هشدار منسوخ‌شدگی از PHP ننوشت. انتخاب ما: امروز 8.3؛ 8.4 وقتی که روی یک کپی هیچ افزونه‌ای در لاگ سایت خودتان هشدار منسوخ‌شدگی از PHP ننویسد.

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

سایتی فروشگاهی با قالب Astra و ۳۲ افزونه فعال ساختیم: ووکامرس، ووکامرس فارسی و افزونه‌هایی که فروشگاه ما بیشترین دانلود را برایشان دارد، از جمله Elementor Pro، Yoast SEO Premium، Gravity Forms، Dokan Pro و Slider Revolution. فایل‌ها و دیتابیس یکی بود و فقط PHP عوض می‌شد. روی هر نسخه ۲۶۵ درخواست فرستادیم: صفحه‌های سایت، افزودن به سبد، سبد و تسویه حساب، ثبت یک فرم، API و صفحه‌های منوی پیشخوان. هر نسخه، یکی‌یکی، از یک وضعیت ذخیره‌شده یکسان شروع شد.

روی هر هفت نسخه ۲۶۴ درخواست جواب ۲۰۰ داد و صفحه ۴۰۴ عمدی ۴۰۴ ماند. هیچ صفحه‌ای «یک خطای مهم در این وب سایت رخ داده است» نشان نداد. لاگ‌ها فرق داشتند. این جدول خط‌های هشداری را می‌شمارد که خود PHP درباره کد قدیمی نوشت:

نسخه PHP	خط هشدار منسوخ‌شدگی در لاگ	از کجا
7.4 و 8.0	۰
8.1 تا 8.3	۲	هسته وردپرس، به خاطر همان جواب خالی Serve Happy
8.4	۸۸۷	هسته وردپرس و ۶ افزونه
8.5	۳٬۱۳۱	هسته وردپرس و ۹ افزونه

در این شمارش خط‌هایی نیست که در هر هفت نسخه هست، حدود ۲۷۵ خط: بیشترش هشدار «Undefined array key» (روی 7.4 «Undefined index») از Kadence Security Pro و چند هشدار هسته وردپرس به خاطر همان جواب خالی Serve Happy. صفر روی 7.4 و 8.0 هم به معنی بهتر بودن آن‌ها نیست: این نسخه‌ها از چیزی که بعداً منسوخ شد خبر ندارند و پشتیبانی‌شان تمام شده.

در 8.4 تقریباً همه ۸۸۷ خط یک پیام است: پارامتری که مقدار پیش‌فرضش null است و نوعش صریحاً nullable نوشته نشده. Kadence Security Pro ۵۵۳ خط از آن را نوشت، Digits ۲۸۲، wpDataTables ۱۸، Dokan Pro ۱۶، ووکامرس فارسی ۱۵ و Elementor یک خط. در 8.5 همان‌ها هست و این‌ها هم اضافه می‌شود: متد SplObjectStorage::attach در Kadence Security Pro (۸۶۷ خط)، متد ReflectionProperty::setAccessible در Duplicator Pro (۸۵۲)، تبدیل نوع با نام boolean به جای bool در Modern Events Calendar (۲۸۹)، null به جای کلید آرایه در Yoast SEO (۲۳۴) و دو خط دیگر. این‌ها هشدارند، نه خرابی: کدی را نشان می‌دهند که امروز کار می‌کند و در نسخه‌ای بعد ممکن است نکند.

سرعت را هم سنجیدیم. شش صفحه را (صفحه اصلی، فروشگاه، یک محصول متغیر، API محصولات، فهرست محصولات پیشخوان و پیکربندی ووکامرس) هشت دور، با ترتیب تصادفی نسخه‌ها، روی هر هفت نسخه باز کردیم و زمان پردازنده هر درخواست را از خود PHP خواندیم. جمع زمان پردازنده شش صفحه در یک دور، میانه هشت دور، از ۳٬۶۸۲ میلی‌ثانیه (8.0) تا ۳٬۹۵۷ (8.5) بود؛ 7.4 با ۳٬۷۲۸ و 8.3 با ۳٬۸۶۷ میلی‌ثانیه. بالاترین دور 8.0 از پایین‌ترین دور هر یک از 8.1 تا 8.5 کمتر بود؛ دامنه‌های 7.4 و 8.1 تا 8.5 هم‌پوشانی داشتند. روی این سایت و این رایانه تفاوت نسخه‌ها از ۸ درصد کمتر بود و نسخه جدیدتر خودبه‌خود سریع‌تر نبود.

بدون اجرا هم دیده می‌شود که 8.4 مرز است

لاگ فقط کدی را نشان می‌دهد که اجرا شده. برای دیدن بقیه، هر فایل PHP را فقط خواندیم، با php -l: ۷۲٬۹۸۶ فایل از ۵۸ افزونه، از ۶۰ افزونه‌ای که در فروشگاه ما بیشترین دانلود را دارند (دو تای دیگر برنامه PHP هستند، نه افزونه وردپرس). این دستور فقط خطای کامپایل و هشدارهایی را می‌بیند که PHP موقع خواندن فایل می‌دهد، آن هم اگر نمایش خطا روشن و E_DEPRECATED فعال باشد؛ ما هر دو را روشن کردیم:

نسخه PHP	فایل با هشدار منسوخ‌شدگی	افزونه‌ای که دست‌کم یک فایل دارد (از ۵۸)
8.0	۲۵	۷
8.1	۴۱	۱۱
8.2	۴۵	۱۳
8.3	۴۶	۱۳
8.4	۱٬۵۵۲	۲۹
8.5	۱٬۵۸۴	۲۹

از 8.3 به 8.4 فایل‌ها از ۴۶ به ۱٬۵۵۲ می‌رسند و ۲٬۸۶۳ پیام «nullable ضمنی» می‌آید. از 8.0 به بعد فقط سه فایل را PHP اصلاً نمی‌تواند بخواند (خطای کامپایل). روی 7.4 این تعداد ۲۷ است، اما ۱۲ تا از آن‌ها فایل‌هایی است که کتابخانه‌شان فقط روی PHP 8 به بعد وارد می‌کند.

صفحه افزونه‌ها هم جلوی 8.4 را نمی‌گیرد. زیر افزونه‌ای که حداقل PHP بالاتری اعلام کرده باشد می‌نویسد «این افزونه با نگارش PHP شما کار نمی‌کند.» و فعالش را غیرفعال نمی‌کند؛ روی 7.4 زیر Perfmatters 2.6.9 همین را دیدیم. اما از ۵۸ سرآیند افزونه‌ای که خواندیم، ۲۸ تا حداقلی اعلام نکرده‌اند و هیچ‌کدام بالاتر از 8.1 اعلام نکرده، پس این صفحه درباره 8.4 چیزی نمی‌داند.

اول لاگ، بعد تغییر نسخه، و راه برگشت

لاگ را قبل از عوض کردن نسخه روشن کنید. فایل wp-config.php را با مدیر فایل هاست یا FTP باز کنید، خطی را که WP_DEBUG را false می‌گذارد پیدا کنید و به جایش این سه خط را بگذارید. مستندات وردپرس می‌گوید این خط‌ها باید پیش از خطی بیایند که می‌گوید «That’s all, stop editing»؛ خطاها در wp-content/debug.log ذخیره می‌شوند:

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

1. بکاپ بگیرید (بکاپ با UpdraftPlus) و افزونه‌ها و قالب را به‌روز کنید. برای امتحان روی کپی، نوشته تغییر قالب روی کپی روش ما را نشان می‌دهد.
2. نسخه را در پنل هاست عوض کنید (اگر 8.3 در فهرست نیست، از پشتیبانی هاست بخواهید؛ پنل هاست را ما آزمایش نکردیم) و فهرستی شبیه فهرست آزمایش ما را باز کنید: صفحه اصلی، یک محصول، سبد، تسویه حساب، حساب کاربری، یک فرم، فهرست سفارش‌ها و صفحه افزونه‌ها.
3. debug.log را بخوانید. خط «Deprecated» هشدار است و خط «Fatal error» خرابی. روی هشدار می‌شود صبر کرد و به فروشنده افزونه گزارش داد.
4. اگر صفحه‌ای نوشت «یک خطای مهم در این وب سایت رخ داده است»، نسخه را به قبلی برگردانید. ما روی PHP 8.5.12 یک سفارش، یک دیدگاه و یک ورودی فرم ثبت کردیم، به 7.4.33 برگشتیم و هر سه روی همان دیتابیس خوانده شد. در این فاصله هیچ افزونه‌ای را به‌روز نکردیم و حالتی را که افزونه به‌روز شود آزمایش نکردیم.
5. بعد از کار، آن سه خط را بردارید، WP_DEBUG را دوباره false کنید و debug.log را پاک کنید.

اگر صفحه سفید شده یا خطای ۵۰۰ می‌دهد، علت‌های خطای ۵۰۰ و رفع خطاهای PHP را بخوانید. اگر نمی‌خواهید خودتان لاگ بخوانید، رفع خطا را از ما بخواهید یا صفحه پشتیبانی را ببینید.

عددهای آزمایش‌ها را در ۱۱ آبان ۱۴۰۵ گرفتیم: وردپرس، ووکامرس و ووکامرس فارسی از WordPress.org و افزونه‌های پولی از فایل‌هایی که فروشگاه همان روز می‌داد. با نسخه بعدی یک افزونه ممکن است لاگ همان نسخه PHP فرق کند.

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