PHP Version و سازگاری وردپرس

در طول سال‌هایی که با پروژه‌های وردپرسی مختلف کار کرده‌ام، یکی از پرتکرارترین تماس‌های اضطراری پس از بروزرسانی PHP یا وردپرس، مربوط به خطاهایی بوده که ریشه آن‌ها در ناسازگاری نسخه PHP نهفته بود. تجربه نشان داده که بسیاری از مدیران سایت تصور می‌کنند نسخه PHP موضوعی صرفاً فنی است و تا زمانی که سایت کار می‌کند، نیازی به تغییر آن نیست. اما همین غفلت، در بلندمدت به کاهش عملکرد، افت امنیت و شکست در برابر آسیب‌پذیری‌های جدید منجر می‌شود. آنچه در ادامه می‌آید، چارچوبی عملی برای مدیریت دقیق نسخه PHP در وردپرس است که در ده‌ها پروژه واقعی آزموده شده است.

چرا نسخه PHP برای وردپرس حیاتی است؟

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

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

PHP یک زبان با تاریخ طولانی است که از سال ۱۹۹۵ میلادی تا کنون تکامل یافته است. این تکامل، نه فقط افزودن قابلیت‌های جدید، بلکه حذف رفتارهای قدیمی و ناسازگار را نیز شامل می‌شود. نتیجه این فرآیند، نسخه‌هایی است که اگرچه سریع‌تر و امن‌تر هستند، اما ممکن است کدهای قدیمی را ناسازگار کنند.

در سال‌های اخیر، تیم وردپرس استراتژی فعالی برای ترغیب کاربران به استفاده از نسخه‌های جدید PHP اتخاذ کرده است. برای مثال، از وردپرس 5.2 به بعد، اگر سایت روی نسخه PHP ناسازگار اجرا شود، پیشخوان وردپرس هشدار می‌دهد. از نسخه 5.9، برخی محدودیت‌ها اعمال می‌شود و در نسخه‌های جدیدتر، امکان نصب بعضی افزونه‌ها تنها در صورت سازگاری با نسخه PHP فعلی فراهم است.

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

نسخه PHP مانند موتور خودروست. با موتور قدیمی، خودرو همچنان راه می‌رود، اما سرعت، ایمنی و مصرف سوخت آن در سطح مطلوب نیست.

تاریخچه نسخه‌های PHP و پشتیبانی وردپرس

برای درک وضعیت فعلی، باید نگاهی به تاریخچه تکامل PHP و نحوه تعامل وردپرس با این تکامل داشت.

مهاجرت از PHP 5 به 7

PHP 5 در سال ۲۰۰۴ منتشر شد و سال‌ها نسخه غالب این زبان بود. PHP 5.6 آخرین نسخه از این شاخه بود که در سال ۲۰۱۴ منتشر شد. در دسامبر ۲۰۱۸، پشتیبانی امنیتی PHP 5.6 پایان یافت.

PHP 7 در دسامبر ۲۰۱۵ منتشر شد و یک جهش بنیادین در عملکرد و سازگاری بود. بهبودهای کلیدی PHP 7:

• بهبود عملکرد تا ۲ برابر نسبت به PHP 5.6 در بارهای کاری واقعی.
• کاهش چشمگیر مصرف حافظه.
• معرفی Scalar Type Hints و Return Type Declarations.
• معرفی Null Coalescing Operator (??).
• بهبود مکانیزم مدیریت خطا با Throwable.

وردپرس از نسخه 5.2 (مه ۲۰۱۹) به بعد، به‌طور رسمی PHP 7 را توصیه کرد. از نسخه 5.9 (ژانویه ۲۰۲۲)، حداقل نسخه پشتیبانی‌شده PHP به 5.6.20 ارتقا یافت. اما در آوریل ۲۰۲۳ با انتشار وردپرس 6.2، این حداقل به 5.6.20 کاهش یافت و سپس در نسخه‌های بعدی، تمرکز بر PHP 7.4 و بالاتر منتقل شد.

مهاجرت از PHP 7 به 8

PHP 8 در نوامبر ۲۰۲۰ منتشر شد و تغییرات اساسی در زبان ایجاد کرد. مهم‌ترین تغییرات PHP 8:

• معرفی JIT (Just-In-Time) Compiler که در برخی بارهای کاری، بهبود عملکرد ۲ تا ۳ برابری ارائه می‌دهد.
• معرفی Union Types (int|string).
• معرفی Named Arguments.
• معرفی Match Expression.
• معرفی Nullsafe Operator (?->).
• تبدیل بسیاری از خطاهای Deprecated به خطاهای واقعی، مانند strlen(null).

PHP 8 در ابتدا مشکلات سازگاری متعددی با اکوسیستم وردپرس ایجاد کرد. بسیاری از افزونه‌ها و قالب‌هایی که کد آن‌ها در دوره PHP 5 نوشته شده بود، در PHP 8 خطاهای Fatal می‌دادند. اما با گذشت زمان، این اکوسیستم خود را هماهنگ کرد و امروز اکثر افزونه‌های فعال با PHP 8 سازگارند.

وردپرس از نسخه 5.6 (دسامبر ۲۰۲۰) به بعد، PHP 8 را به‌طور رسمی پشتیبانی کرد. با این حال، توصیه می‌شد که مهاجرت با احتیاط انجام شود.

نسخه‌های 8.1، 8.2 و 8.3

پس از PHP 8.0، نسخه‌های بعدی به‌صورت دوره‌ای منتشر شده‌اند:

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

نگاه به PHP 9 و آینده

در زمان نگارش این مطلب، PHP 9 هنوز منتشر نشده است. اما انتظار می‌رود که این نسخه، حذف‌های بیشتری از رفتارهای قدیمی داشته باشد و کدهای قدیمی را ناسازگار کند. برای پروژه‌های حرفه‌ای، آماده‌سازی زودهنگام برای این تغییرات، یک رویکرد عقلانی است.

ماتریس سازگاری وردپرس و PHP

وردپرس برای هر نسخه، حداقل و حداکثر نسخه PHP مورد پشتیبانی را اعلام می‌کند. درک این ماتریس، برای تصمیم‌گیری درست ضروری است.

نیازمندی‌های رسمی وردپرس

طبق مستندات رسمی وردپرس، برای نسخه‌های اخیر:

• حداقل نسخه PHP: 7.2.24 (در نسخه‌های اخیر وردپرس 6.x).
• نسخه پیشنهادی: 8.1 یا بالاتر.
• نسخه MySQL: 5.7 یا بالاتر، یا MariaDB 10.4 یا بالاتر.

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

حداقل، پیشنهادی و بهینه

در مدیریت نسخه PHP، سه سطح را باید از هم تفکیک کرد:

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

پایان چرخه پشتیبانی PHP

هر نسخه PHP یک چرخه عمر مشخص دارد:

• Active Support: دو سال پس از انتشار. رفع باگ و افزودن قابلیت.
• Security Support: یک سال اضافه. فقط رفع آسیب‌پذیری‌های امنیتی.
• End of Life (EOL): پایان پشتیبانی کامل. هیچ وصله‌ای ارائه نمی‌شود.

در زمان نگارش این مطلب، PHP 7.4 و 8.0 به EOL رسیده‌اند و استفاده از آن‌ها در محیط تولید یک ریسک امنیتی جدی است. برای مطالعه بیشتر درباره امنیت، مقاله امنیت در PHP و CVE جدید وردپرس منتشر شده؛ چطور بدون بروزرسانی فوری از آن جلوگیری کنیم؟ را ببینید.

تفاوت‌های کلیدی نسخه‌های PHP و تأثیر بر وردپرس

درک تفاوت‌های عملی بین نسخه‌های PHP، به تصمیم‌گیری دقیق‌تر کمک می‌کند.

بهبود عملکرد در نسخه‌های جدید

هر نسخه جدید PHP، بهبودهایی در عملکرد دارد. این بهبودها در سایت‌های وردپرسی به‌طور مستقیم قابل مشاهده هستند:

• PHP 7.0: تا ۲ برابر سریع‌تر از PHP 5.6.
• PHP 7.4: حدود ۱۵٪ سریع‌تر از PHP 7.0.
• PHP 8.0: با JIT، تا ۳۰٪ سریع‌تر از PHP 7.4 در برخی بارها.
• PHP 8.1 و بعد: بهبودهای تدریجی در حوزه‌های خاص.

در آزمون‌های عملی روی سایت‌های وردپرسی، مهاجرت از PHP 7.4 به 8.1 می‌تواند زمان پاسخ سرور (TTFB) را تا ۲۰٪ کاهش دهد. برای مطالعه بیشتر، مقاله بهینه‌سازی سرعت سایت چیست و چرا مهم است؟ را ببینید.

توابع منسوخ و حذف‌شده

هر نسخه PHP، تعدادی از توابع را منسوخ (Deprecated) یا حذف (Removed) می‌کند. نمونه‌های مهم:

اگر افزونه‌ای از این توابع استفاده کند، در نسخه‌های جدید PHP خطای Fatal می‌دهد. برای مطالعه بیشتر، مقاله تفاوت PHP 7 و PHP 8 را ببینید.

سیستم نوع و سخت‌گیری نسخه 8

PHP 8 سخت‌گیری بیشتری در بررسی انواع دارد. مثال‌ها:

// در PHP 7.4: Notice، بازگشت 0
$length = strlen(null);

// در PHP 8.0: TypeError
$length = strlen(null); // TypeError: strlen(): Argument #1 ($string) must be of type string, null given

// در PHP 8.1: Deprecated، بازگشت 0
$length = strlen(null); // Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated

این تغییرات باعث می‌شوند که کد قدیمی که در PHP 7.4 کار می‌کرد، در PHP 8 به خطا منجر شود. برای مطالعه بیشتر، مقاله مدیریت خطا در PHP را ببینید.

JIT Compiler در PHP 8

JIT (Just-In-Time) Compiler یکی از مهم‌ترین ویژگی‌های PHP 8 است. JIT کد PHP را در زمان اجرا به کد ماشین تبدیل می‌کند و در برخی بارهای کاری، بهبود عملکرد چشمگیری ارائه می‌دهد.

با این حال، تأثیر JIT بر وردپرس کمتر از حد انتظار است، زیرا وردپرس بار کاری I/O-bound دارد (وابسته به دیتابیس و فایل‌سیستم) نه CPU-bound. مطالعات نشان می‌دهد که JIT در سایت‌های وردپرسی بهبود ۵ تا ۱۵ درصدی ایجاد می‌کند، در حالی که در بارهای محاسباتی سنگین، بهبود ۲ تا ۳ برابری دارد.

برای فعال‌سازی JIT، باید در php.ini تنظیمات زیر اعمال شود:

opcache.enable=1
opcache.jit_buffer_size=100M
opcache.jit=tracing

حالت tracing بهترین عملکرد را در اکثر بارها ارائه می‌دهد، اما در برخی موارد، حالت function پایدارتر است.

روش‌های تشخیص نسخه PHP

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

استفاده از WP-CLI

wp --info
wp eval 'echo PHP_VERSION;'
wp eval 'echo PHP_INT_SIZE;'

خروجی این دستورات، نسخه دقیق PHP و اطلاعات مرتبط را نمایش می‌دهد. برای مطالعه بیشتر، مقاله WP-CLI و مدیریت وردپرس از خط فرمان را ببینید.

ابزار Site Health وردپرس

در وردپرس 5.2 به بعد، ابزار Site Health (ابزارها > سلامت سایت > اطلاعات) نسخه PHP و اطلاعات مرتبط را نمایش می‌دهد. همچنین هشدارهایی درباره نسخه‌های قدیمی نمایش داده می‌شود.

phpinfo و توابع PHP

برای دیدن اطلاعات کامل PHP، می‌توان یک فایل موقت ایجاد کرد:

<?php
phpinfo();

این فایل را با نام phpinfo.php در ریشه سایت قرار دهید و از طریق مرورگر باز کنید. پس از استفاده، حتماً فایل را حذف کنید، زیرا اطلاعات حساس سرور را افشا می‌کند.

روش امن‌تر، استفاده از توابع PHP در یک MU-Plugin است:

add_action('admin_notices', function() {
    if (!current_user_can('manage_options')) {
        return;
    }
    printf(
        '<div class="notice notice-info"><p>نسخه PHP: <strong>%s</strong> | معماری: %s بیت</p></div>',
        esc_html(PHP_VERSION),
        esc_html(PHP_INT_SIZE * 8)
    );
});

ابزارهای سرور

در سطح سرور، می‌توان از ابزارهای خط فرمان استفاده کرد:

php -v
php -i | grep -E "Loaded Configuration|PHP Version"
ls /etc/php/

بررسی سازگاری افزونه‌ها و قالب‌ها

پس از تشخیص نسخه PHP، باید سازگاری اجزای سایت با نسخه هدف بررسی شود.

هدر Requires PHP و Tested up to

افزونه‌ها و قالب‌ها معمولاً اطلاعاتی درباره نسخه PHP مورد نیاز خود در README یا فایل اصلی اعلام می‌کنند:

/*
Plugin Name: My Plugin
Requires at least: 5.8
Tested up to: 6.4
Requires PHP: 7.4
*/

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

تحلیل لاگ Deprecation

پیش از مهاجرت، باید لاگ‌های Deprecation را تحلیل کرد. این لاگ‌ها نشان می‌دهند که کدام بخش از کد، در نسخه جدید PHP منسوخ شده است:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEPRECATED_HOOKS', true);

پس از فعال‌سازی، فایل wp-content/debug.log را بررسی کنید:

grep -i "deprecated" wp-content/debug.log

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

تحلیل استاتیک کد

ابزارهای تحلیل استاتیک می‌توانند پیش از اجرا، ناسازگاری‌ها را شناسایی کنند:

composer require --dev phpcompatibility/php-compatibility
vendor/bin/phpcs --standard=PHPCompatibility --runtime-set testVersion 8.2 wp-content/plugins/

این دستور، تمام کد افزونه‌ها را بررسی می‌کند و ناسازگاری‌ها با PHP 8.2 را گزارش می‌دهد.

PHP Compatibility Checker

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

استراتژی مهاجرت به نسخه جدید PHP

مهاجرت به نسخه جدید PHP، نیازمند یک استراتژی دقیق است. رویکرد عجولانه، خطرات جدی دارد.

محیط استیجینگ

هرگز مهاجرت را در محیط تولید انجام ندهید. ابتدا یک محیط استیجینگ (Staging) از سایت ایجاد کنید. این محیط باید:

• کپی دقیقی از سایت تولید باشد.
• روی نسخه PHP هدف اجرا شود.
• داده‌های واقعی (نه آزمایشی) داشته باشد.
• قابل حذف پس از تست باشد.

برای راه‌اندازی استیجینگ، می‌توان از افزونه‌هایی مانند WP Staging یا محیط‌های Docker استفاده کرد. برای مطالعه بیشتر، مقاله تجربه کار با Docker در توسعه پروژه‌ها را ببینید.

پشتیبان‌گیری اجباری

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

wp db export backup-$(date +%Y%m%d).sql
tar -czf files-backup-$(date +%Y%m%d).tar.gz wp-content/

پشتیبان باید در مکانی جدا از سرور نگهداری شود. برای مطالعه بیشتر، مقاله چرا بکاپ وردپرس بدون استراتژی بی‌فایده است؟ را ببینید.

مهاجرت تدریجی

به‌جای پرش از PHP 7.4 به 8.3، بهتر است تدریجی عمل کنید:

1. ابتدا به PHP 8.0 مهاجرت کنید.
2. سایت را برای چند روز پایش کنید.
3. سپس به PHP 8.1 و 8.2.
4. در نهایت به 8.3.

این رویکرد، امکان شناسایی دقیق مشکلات در هر مرحله را فراهم می‌کند. هر مرحله، تغییرات کمتری دارد و ریشه‌یابی ساده‌تر است.

برنامه بازگشت

پیش از مهاجرت، برنامه بازگشت (Rollback Plan) داشته باشید:

• پشتیبان کامل از دیتابیس و فایل‌ها.
• اطلاعات کامل نسخه‌های فعلی (PHP، وردپرس، افزونه‌ها).
• دسترسی به پنل هاست برای تغییر سریع نسخه PHP.
• مستندات تغییرات انجام‌شده.

چک‌لیست تست پس از مهاجرت

پس از مهاجرت، این موارد را تست کنید:

• [ ] بارگذاری صفحه اصلی
• [ ] ورود به پیشخوان
• [ ] ایجاد و ویرایش نوشته
• [ ] آپلود تصویر
• [ ] ثبت سفارش (در فروشگاه)
• [ ] ارسال ایمیل (با تست ایمیل تراکنشی)
• [ ] کارکرد فرم‌ها
• [ ] کارکرد جستجو
• [ ] نمایش درست صفحات فارسی
• [ ] بررسی خطاهای دیتابیس
• [ ] بررسی لاگ خطاها
• [ ] بررسی عملکرد (سرعت)
• [ ] بررسی دسترسی ادمین
• [ ] بررسی سازگاری افزونه‌های کلیدی
• [ ] بررسی APIها و یکپارچگی‌ها

مشکلات رایج پس از تغییر نسخه PHP

حتی با آماده‌سازی دقیق، برخی مشکلات ممکن است رخ دهد. شناخت این مشکلات، رفع سریع‌تر را ممکن می‌کند.

صفحه سفید مرگ

رایج‌ترین مشکل پس از مهاجرت، صفحه سفید مرگ (WSOD) است که به‌دلیل خطای Fatal در PHP رخ می‌دهد. برای مطالعه جامع درباره این مشکل، مقاله چرا سایت وردپرسی شما ناگهان با صفحه سفید مواجه می‌شود و چطور ریشه مشکل را پیدا کنید؟ را ببینید.

هشدارهای Deprecation

حتی اگر سایت کار کند، ممکن است هشدارهای Deprecation در لاگ ظاهر شود. این هشدارها نشانه‌ای از ناسازگاری‌های آینده هستند و باید پیگیری شوند.

Deprecated: Function create_function() is deprecated in /path/to/plugin.php on line 123

در PHP 8.0، این خطا به خطای Fatal تبدیل می‌شود. بنابراین، بروزرسانی افزونه یا اصلاح کد ضروری است.

از کار افتادن افزونه‌ها

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

از کار افتادن قالب

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

تغییر رفتار APIهای هسته

برخی APIهای وردپرس ممکن است رفتار متفاوتی در نسخه‌های جدید PHP داشته باشند. برای مثال، توابعی که به‌طور پیش‌فرض مقدار null را به‌عنوان ورودی می‌پذیرفتند، در PHP 8 خطا می‌دهند.

تأثیر نسخه PHP بر عملکرد سایت

نسخه PHP تأثیر مستقیمی بر عملکرد سایت دارد. در آزمون‌های عملی روی سایت‌های وردپرسی، نتایج زیر مشاهده شده است:

علاوه بر این، با فعال‌سازی OPcache و JIT، بهبود بیشتری حاصل می‌شود:

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=10000
opcache.revalidate_freq=2
opcache.jit_buffer_size=100M
opcache.jit=tracing

برای مطالعه بیشتر، مقاله بهینه سازی کدهای php را ببینید.

ملاحظات امنیتی

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

• PHP 5.6: EOL در دسامبر ۲۰۱۸. آسیب‌پذیری‌های متعدد تأیید شده.
• PHP 7.0: EOL در ژانویه ۲۰۱۹.
• PHP 7.1: EOL در دسامبر ۲۰۱۹.
• PHP 7.2: EOL در نوامبر ۲۰۲۰.
• PHP 7.3: EOL در دسامبر ۲۰۲۱.
• PHP 7.4: EOL در نوامبر ۲۰۲۲.
• PHP 8.0: EOL در نوامبر ۲۰۲۳.

استفاده از نسخه‌های EOL در محیط تولید، به معنای پذیرش ریسک امنیتی است. برای مطالعه بیشتر، مقاله امنیت در PHP و چگونه سایت وردپرسی را در برابر هک محافظت کنیم؟ را ببینید.

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

انتخاب هاست و نسخه PHP

هاست‌های مختلف، پشتیبانی متفاوتی از نسخه‌های PHP دارند:

• هاست‌های اشتراکی ارزان: معمولاً نسخه‌های قدیمی یا محدود. ممکن است امکان انتخاب نسخه نباشد.
• هاست‌های اشتراکی حرفه‌ای: امکان انتخاب نسخه از پنل.
• VPS و سرور اختصاصی: کنترل کامل بر نسخه PHP و افزونه‌های آن.
• هاست‌های مدیریت‌شده وردپرس: معمولاً نسخه‌های جدید PHP را به‌طور خودکار اعمال می‌کنند.

هنگام انتخاب هاست، این پرسش‌ها را بپرسید:

• آیا امکان انتخاب نسخه PHP از پنل وجود دارد؟
• آیا نسخه‌های جدید PHP (8.1 و بالاتر) پشتیبانی می‌شوند؟
• آیا امکان تغییر سریع نسخه PHP در صورت نیاز وجود دارد؟
• آیا OPcache و افزونه‌های مهم PHP فعال هستند؟

برای مطالعه بیشتر، مقاله چگونه هاست مناسب برای وردپرس انتخاب کنیم؟ را ببینید.

اشتباهات رایج در مدیریت نسخه PHP

در پروژه‌های متعدد، اشتباهات تکراری در مدیریت نسخه PHP دیده می‌شود:

1. ماندن روی نسخه EOL: عدم مهاجرت به‌دلیل ترس از شکستن سایت.
2. مهاجرت بدون تست: پرش مستقیم از PHP 7.4 به 8.3 بدون استیجینگ.
3. عدم پشتیبان‌گیری: مهاجرت بدون نسخه پشتیبان قابل بازیابی.
4. نادیده گرفتن هشدارهای Deprecation: عدم توجه به لاگ‌ها تا بروز مشکل.
5. عدم بررسی سازگاری افزونه‌ها: فرض اینکه همه افزونه‌ها با نسخه جدید سازگارند.
6. فعال نکردن OPcache: از دست دادن بهبود عملکرد رایگان.
7. عدم فعال‌سازی JIT در نسخه 8: از دست دادن بخشی از بهبود عملکرد.
8. نادیده گرفتن حافظه: عدم افزایش memory_limit پس از مهاجرت.
9. عدم مستندسازی: از دست دادن اطلاعات نسخه‌های قبلی.
10. عدم بررسی عملکرد پس از مهاجرت: فرض بهبود خودکار بدون اندازه‌گیری.
11. عدم آموزش تیم: تیم نمی‌داند چگونه با نسخه جدید کار کند.
12. نادیده گرفتن نسخه‌های افزونه‌های PHP: مانند OPcache، APCu، Imagick و ... .
13. عدم بررسی MySQL: نسخه MySQL نیز باید با نسخه جدید PHP سازگار باشد.
14. عدم پایش پس از مهاجرت: مشکل ممکن است چند روز بعد ظاهر شود.
15. مقاومت در برابر تغییر: ماندن روی نسخه قدیمی به‌دلیل راحتی.

پرسش‌های پرتکرار درباره نسخه PHP و وردپرس

در این بخش، به پرسش‌های متداول پاسخ داده می‌شود. این ساختار برای بهینه‌سازی محتوا برای موتورهای پاسخگو (Answer Engines) نیز مفید است.

کدام نسخه PHP برای وردپرس بهتر است؟

برای نسخه‌های اخیر وردپرس (6.x)، نسخه PHP 8.1 یا 8.2 تعادل بهینه بین سازگاری و عملکرد است. اگر تمام افزونه‌ها و قالب‌ها سازگار باشند، PHP 8.3 نیز انتخاب خوبی است.

آیا نسخه PHP بر سرعت وردپرس اثر می‌گذارد؟

بله، به‌طور مستقیم. مهاجرت از PHP 7.4 به 8.2 می‌تواند زمان پاسخ سرور را تا ۲۰٪ کاهش دهد و مصرف حافظه را کاهش دهد.

حداقل نسخه PHP برای وردپرس چقدر است؟

در نسخه‌های اخیر وردپرس 6.x، حداقل نسخه PHP 7.2.24 است. اما این حداقل ممکن است در نسخه‌های آینده افزایش یابد.

آیا PHP 7.4 برای وردپرس کافی است؟

PHP 7.4 در نوامبر ۲۰۲۲ به EOL رسید و از آن پس هیچ وصله امنیتی دریافت نمی‌کند. استفاده از آن در محیط تولید توصیه نمی‌شود.

چگونه نسخه PHP خود را تغییر دهم؟

بسته به هاست، می‌توان از پنل cPanel/DirectAdmin یا از فایل .htaccess یا از طریق پشتیبانی هاست. در VPS، با مدیریت بسته‌ها (مانند apt یا yum).

آیا تغییر نسخه PHP می‌تواند سایت را از کار بیندازد؟

بله، به‌ویژه اگر افزونه‌ها یا قالب‌های قدیمی ناسازگار باشند. به همین دلیل، مهاجرت باید در محیط استیجینگ و با پشتیبان‌گیری انجام شود.

چگونه سازگاری افزونه‌ها را با نسخه PHP جدید بررسی کنم؟

با استفاده از افزونه PHP Compatibility Checker یا ابزار تحلیل استاتیک PHPCompatibility. همچنین بررسی هدر Requires PHP در فایل‌های افزونه.

آیا افزونه‌های رایگان وردپرس با PHP 8 سازگارند؟

اکثر افزونه‌های فعال و بروزرسانی‌شده با PHP 8 سازگارند. اما افزونه‌های قدیمی که مدتی بروزرسانی نشده‌اند، ممکن است ناسازگار باشند.

آیا استفاده از PHP 8 باعث کاهش رتبه سئو می‌شود؟

خیر، برعکس. PHP 8 سریع‌تر است و سرعت سایت یکی از عوامل رتبه‌بندی گوگل است. بنابراین، مهاجرت به PHP 8 می‌تواند به بهبود سئو کمک کند.

تفاوت JIT و OPcache چیست؟

OPcache کد PHP را در حافظه ذخیره می‌کند تا در هر درخواست دوباره کامپایل نشود. JIT کد PHP را در زمان اجرا به کد ماشین تبدیل می‌کند و در بارهای CPU-bound بهبود می‌دهد.

آیا پس از مهاجرت به PHP 8 باید نگران امنیت باشم؟

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

چه افزونه‌های PHP برای وردپرس ضروری هستند؟

معمولاً mysqli یا pdo_mysql، json، mbstring، curl، gd یا imagick، zip، xml. برخی هاست‌ها این افزونه‌ها را به‌طور پیش‌فرض نصب می‌کنند.

آیا می‌توان از PHP 8.3 در محیط تولید استفاده کرد؟

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

چگونه از بروز مشکل پس از مهاجرت جلوگیری کنم؟

با محیط استیجینگ، پشتیبان‌گیری، تست جامع، پایش لاگ‌ها و مهاجرت تدریجی. برای مطالعه بیشتر، مقاله چگونه مشکل سرعت سایت را عیب‌یابی کنیم؟ را ببینید.

نکات پیشرفته برای مهندسان ارشد

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

PHP-FPM Pools و مدیریت نسخه‌ها

در سرورهایی که چند سایت وردپرسی با نسخه‌های PHP متفاوت اجرا می‌کنند، می‌توان از PHP-FPM Pools استفاده کرد:

# /etc/php/8.2/fpm/pool.d/site1.conf
[site1]
user = site1
group = site1
listen = /run/php/site1.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 10

# /etc/php/8.3/fpm/pool.d/site2.conf
[site2]
user = site2
group = site2
listen = /run/php/site2.sock

سپس در پیکربندی Nginx، برای هر سایت، سوکت مربوطه تعیین می‌شود:

location ~ \.php$ {
    fastcgi_pass unix:/run/php/site1.sock;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

OPcache Tuning پیشرفته

برای سایت‌های پربازدید، تنظیم دقیق OPcache حیاتی است:

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=512
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.max_wasted_percentage=10
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.save_comments=1
opcache.fast_shutdown=1
opcache.jit_buffer_size=256M
opcache.jit=tracing
opcache.jit_hot_func=127
opcache.jit_hot_loop=64
opcache.jit_hot_return=16

نکته: opcache.validate_timestamps=0 باعث می‌شود که OPcache تغییرات فایل‌ها را بررسی نکند و به‌طور دستی باید opcache_reset() فراخوانی شود. این تنظیم در محیط تولید توصیه می‌شود.

PHP-FPM Performance Tuning

pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500
pm.process_idle_timeout = 10s
request_terminate_timeout = 60s
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slow.log

تنظیم pm.max_children باید بر اساس حافظه سرور محاسبه شود: تعداد فرزندان = (حافظه کل - حافظه سیستم) / متوسط مصرف هر فرزند.

پایش عملکرد با New Relic یا Tideways

در محیط‌های تولیدی، پایش عملکرد PHP ضروری است. ابزارهایی مانند New Relic و Tideways می‌توانند:

• زمان اجرای هر توابع PHP را اندازه‌گیری کنند.
• کوئری‌های کند را شناسایی کنند.
• درخواست‌های HTTP خارجی را ردیابی کنند.
• مصرف حافظه را نمایش دهند.
• خطاها را با stack trace کامل ثبت کنند.

برای مطالعه بیشتر درباره پایش، مقاله Sentry Performance برای وردپرس چطور کار می‌کند؟ را ببینید.

Kubernetes و مدیریت نسخه PHP

در معماری‌های Kubernetes، هر سرویس می‌تواند از یک image PHP متفاوت استفاده کند:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress-82
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: php
        image: php:8.2-fpm-alpine
        resources:
          requests:
            memory: "512Mi"
            cpu: "500m"
          limits:
            memory: "1Gi"
            cpu: "1000m"

این رویکرد، امکان مدیریت دقیق نسخه PHP در محیط‌های توزیع‌شده را فراهم می‌کند.

الگوهای Regression Testing

برای اطمینان از سازگاری پس از مهاجرت، باید تست خودکار وجود داشته باشد:

class PHP_Compatibility_Test extends WP_UnitTestCase {
    public function test_no_deprecated_functions() {
        $plugins = glob(WP_PLUGIN_DIR . '/*');
        
        foreach ($plugins as $plugin) {
            if (!is_dir($plugin)) {
                continue;
            }
            
            $files = new RecursiveIteratorIterator(
                new RecursiveDirectoryIterator($plugin)
            );
            
            foreach ($files as $file) {
                if ($file->getExtension() !== 'php') {
                    continue;
                }
                
                $content = file_get_contents($file->getPathname());
                
                $deprecated = array(
                    'create_function(',
                    'each(',
                    'money_format(',
                    'mysql_connect(',
                );
                
                foreach ($deprecated as $func) {
                    $this->assertStringNotContainsString(
                        $func,
                        $content,
                        sprintf('Deprecated function %s found in %s', $func, $file->getPathname())
                    );
                }
            }
        }
    }
}

این تست‌ها را می‌توان در pipeline CI/CD اجرا کرد. برای مطالعه بیشتر، مقاله تست و دیباگ پروژه‌های توسعه وردپرس را ببینید.

Composer Platform Config

در پروژه‌هایی که از Composer استفاده می‌کنند، می‌توان نسخه PHP مورد نیاز را تعریف کرد:

{
    "config": {
        "platform": {
            "php": "8.2.0"
        }
    },
    "require": {
        "php": ">=8.1"
    }
}

این تنظیم تضمین می‌کند که Composer وابستگی‌های سازگار با نسخه مشخص را نصب می‌کند. برای مطالعه بیشتر، مقاله Composer برای مدیریت وابستگی وردپرس را ببینید.

نکات کلیدی برای پایداری بلندمدت

در پایان، چند نکته کلیدی که باید در خاطر بماند:

• پایش مداوم نسخه PHP: از ابزار Site Health و WP-CLI استفاده کنید.
• محیط استیجینگ: هر مهاجرت ابتدا در استیجینگ تست شود.
• پشتیبان‌گیری اجباری: پیش از هر تغییر.
• مهاجرت تدریجی: نسخه‌به‌نسخه، نه پرش مستقیم.
• OPcache و JIT: فعال و تنظیم شوند.
• پایش لاگ Deprecation: پیگیری هشدارها پیش از تبدیل به خطا.
• تست خودکار: در pipeline CI/CD.
• Composer Platform: برای تضمین سازگاری وابستگی‌ها.
• مستندسازی: نسخه‌ها و تغییرات ثبت شوند.
• آموزش تیم: همه اعضا با نسخه جدید و تفاوت‌ها آشنا باشند.
• پایش پس از مهاجرت: ۲۴ تا ۴۸ ساعت پس از مهاجرت.
• برنامه بازگشت: برای شرایط اضطراری.

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