تغییر نسخه PHP، افزایش محدودیت‌ها و فعال‌سازی اکستنشن‌ها در cPanel

فایلی را در وردپرس آپلود می‌کنید و پیام The uploaded file exceeds the upload_max_filesize می‌گیرید؛ وسط نصب یک افزونه صفحه با خطای Allowed memory size exhausted سفید می‌شود؛ یا قالب پولی که خریده‌اید هنگام فعال‌سازی می‌گوید ionCube Loader فعال نیست. هر سه یک ریشه دارند: تنظیمات PHP هاست با چیزی که سایت لازم دارد جور نیست. این ماجرا هم مخصوص وردپرس نیست؛ جوملا و هر سیستم مدیریت محتوای دیگری دقیقاً به همین دیوار می‌خورد. خوشبختانه همه این موارد — نسخه PHP، سقف حافظه و حجم آپلود، و اکستنشن‌های فعال — از داخل سی‌پنل و بدون نیاز به SSH قابل تغییر است.

تغییر نسخه PHP در سی‌پنل

نسخه PHP هم روی عملکرد سایت اثر دارد و هم روی امنیت آن. نسخه‌های ۵.x و ۷.x و همچنین ۸.۰ و ۸.۱ به پایان عمر (End of Life) رسیده‌اند و دیگر وصله امنیتی رسمی دریافت نمی‌کنند؛ بنابراین قاعده کلی این است: بالاترین نسخه‌ای را انتخاب کنید که سیستم مدیریت محتوا، قالب و افزونه‌های شما رسماً پشتیبانی می‌کنند. فهرست به‌روزِ نسخه‌هایی که هنوز پشتیبانی می‌شوند همیشه در صفحه Supported Versions سایت php.net در دسترس است؛ پیش از انتخاب، یک نگاه به آن بیندازید.

روش امروزی: ابزار Select PHP Version

• در سی‌پنل، در بخش Software روی گزینه Select PHP Version کلیک کنید.
• فهرست نسخه‌های نصب‌شده روی سرور را می‌بینید. نسخه مورد نظر (مثلاً ۸٫۳) را انتخاب کنید.
• تغییر بلافاصله اعمال می‌شود و نیازی به ری‌استارت سرویس یا تماس با پشتیبانی نیست.

اگر سایت پس از تغییر نسخه با خطا بالا نیامد، از همین صفحه به نسخه قبلی برگردید؛ برگشت هم لحظه‌ای است. برای اطمینان از این‌که واقعاً نسخه جدید روی دامنه اجرا می‌شود، یک فایل موقت مثل info.php با محتوای <?php phpinfo(); در public_html بسازید، خروجی را ببینید و بلافاصله آن فایل را پاک کنید (باقی گذاشتنش یک نشت اطلاعاتی است). توجه کنید که فرمان php -v در SSH نسخه پیش‌فرض خط فرمان را نشان می‌دهد، نه لزوماً نسخه‌ای که وب‌سایت با آن اجرا می‌شود.

اگر روی سرور چند دامنه یا ساب‌دامنه دارید و می‌خواهید هرکدام نسخه جداگانه‌ای داشته باشند، مدیر سرور می‌تواند این کار را از WHM و ابزار MultiPHP Manager انجام دهد؛ در سطح کاربر هم اگر MultiPHP Manager در حساب شما فعال باشد، همان قابلیت را برای دامنه‌های خودتان دارید.

اگر سرور شما هنوز ntPHPSelector دارد

روی سرورهای قدیمی‌تر هاست لینوکس سی‌پنل، به‌جای Select PHP Version ابزاری به نام ntPHPSelector در بخش Software قرار داشت. این ابزار نسخه PHP را نه روی کل حساب، بلکه روی یک پوشه اعمال می‌کرد:

• وارد پنل مدیریتی هاست شوید و در بخش Software روی ntPHPSelector کلیک کنید؛ فهرست پوشه‌های هاست نمایش داده می‌شود.
• روی پوشه‌ای که می‌خواهید تغییر روی آن اعمال شود کلیک کنید. پوشه اصلی سایت public_html است.
• نسخه مورد نظر را انتخاب و روی Submit کلیک کنید.
• در انتهای صفحه، در بخش The list of current custom PHP versions set، نسخه ست‌شده به همراه پوشه مربوطه نمایش داده می‌شود؛ از همین‌جا نتیجه کار را تأیید کنید.

این ابزار یک افزونه جانبی بود و امروز منسوخ است؛ روی سی‌پنل‌های به‌روز دیده نمی‌شود و جای آن را ابزارهای امروزی گرفته‌اند: Select PHP Version بر پایه EasyApache 4، یا PHP Selector کلودلینوکس. اگر هنوز ntPHPSelector را در پنل خود می‌بینید، یعنی سرور شما نسخه بسیار قدیمی سی‌پنل را اجرا می‌کند و بهتر است ارتقای آن را از مدیر سرور بخواهید.

افزایش محدودیت‌های PHP در MultiPHP INI Editor

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

• وارد MultiPHP INI Editor شوید.
• در بخش Configure PHP INI basic settings دامنه مورد نظر را انتخاب کنید.
• مقادیر را تغییر دهید و در پایان روی دکمه آبی‌رنگ Apply کلیک کنید تا ذخیره شوند.

معنی گزینه‌های این بخش

• allow_url_fopen — امکان فراخوانی فایل‌ها از طریق آدرس‌های URL را فعال می‌کند. در صورت فعال بودن، اسکریپت‌ها می‌توانند فایل‌هایی را از منابع خارجی مانند APIها یا سایت‌های دیگر بخوانند و برخی افزونه‌های وردپرس به آن نیاز دارند. دقت کنید که این گزینه با allow_url_include فرق دارد؛ آن یکی که اجرای کد از روی URL را ممکن می‌کرد در PHP 7.4 منسوخ و در PHP 8.0 به‌طور کامل حذف شد و دیگر قابل فعال‌سازی نیست.
• display_errors — مشخص می‌کند خطاهای PHP مستقیماً در مرورگر نمایش داده شوند یا نه. در محیط توسعه می‌تواند روشن باشد، اما در سایت عملیاتی باید خاموش بماند؛ پیام‌های خطا مسیر فایل‌ها و گاهی اطلاعات دیتابیس را لو می‌دهند. به‌جای آن log_errors را روشن و خطاها را در فایل لاگ بررسی کنید.
• enable_dl — قابلیت بارگذاری داینامیک اکستنشن حین اجرای اسکریپت با تابع dl(). در PHP امروزی این تابع در SAPIهای وب در دسترس نیست و روی هاست اشتراکی عملاً بی‌اثر است؛ به دلایل امنیتی خاموش بگذاریدش.
• file_uploads — تعیین می‌کند آپلود فایل از طریق فرم‌ها ممکن باشد یا نه. برای هر سایتی که قابلیت آپلود دارد (مانند وردپرس) باید فعال باشد.
• max_execution_time — حداکثر زمان اجرای یک اسکریپت PHP برحسب ثانیه. مقدار پیش‌فرض معمولاً ۳۰ ثانیه است. برای عملیات سنگین مانند import اطلاعات، بکاپ‌گیری یا نصب افزونه می‌توان آن را افزایش داد؛ مثلاً به ۳۰۰٫
• max_input_time — حداکثر زمانی که PHP برای دریافت و پردازش ورودی‌ها (POST، GET، فایل‌ها) در اختیار دارد. افزایش آن برای فرم‌های سنگین و آپلود فایل‌های بزرگ توصیه می‌شود.
• max_input_vars — تعداد متغیرهای ورودی که PHP در هر درخواست می‌پذیرد؛ پیش‌فرض ۱۰۰۰ است. در قالب‌های پیچیده یا پنل‌های تنظیمات با فیلدهای زیاد، اگر بخشی از تنظیمات بی‌سروصدا ذخیره نشود معمولاً مقصر همین است و باید مقدار را بالا ببرید، مثلاً ۱۰۰۰۰٫
• memory_limit — میزان حافظه‌ای که هر اسکریپت PHP مجاز به مصرف آن است. اگر کم باشد با خطای Allowed memory size exhausted روبه‌رو می‌شوید. مقدار ۵۱۲M برای وردپرس پیشنهاد خوبی است.
• post_max_size — حداکثر حجم داده‌ای که با متد POST ارسال می‌شود. باید حداقل برابر upload_max_filesize و ترجیحاً بیشتر از آن باشد؛ مثلاً اگر فایل‌هایی تا ۱۲۸M آپلود می‌کنید، این مقدار را روی ۲۵۶M بگذارید.
• session.gc_maxlifetime — مدت نگهداری اطلاعات نشست (session) برحسب ثانیه. مقدار ۸۶۴۰۰ یعنی ۲۴ ساعت. در سایت‌های فروشگاهی یا هر سایتی که کاربران در آن لاگین می‌مانند اهمیت دارد.
• session.save_path — مسیر ذخیره فایل‌های session. اگر تغییری نداده‌اید، مسیر پیش‌فرض /var/cpanel/php/sessions/ea-phpXX مناسب است.
• upload_max_filesize — حداکثر حجم هر فایل آپلودی؛ پیش‌فرض PHP فقط ۲ مگابایت است و خطای معروف The uploaded file exceeds the upload_max_filesize دقیقاً از همین‌جا می‌آید. اگر کاربران شما فایل‌های حجیم مانند PDF، ZIP یا تصاویر بزرگ آپلود می‌کنند، مثلاً روی ۱۲۸M تنظیمش کنید.
• zlib.output_compression — فشرده‌سازی خروجی PHP پیش از ارسال به مرورگر. اگر وب‌سرور شما (Apache با mod_deflate یا LiteSpeed) خودش فشرده‌سازی را انجام می‌دهد، نیازی به روشن‌کردن این گزینه نیست و فعال‌کردن هم‌زمان هر دو سودی ندارد.

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

memory_limit >= post_max_size >= upload_max_filesize

وقتی گزینه مورد نظر در حالت Basic نیست

حالت Basic Mode فقط چند دستور پرکاربرد را نشان می‌دهد. برای بقیه دستورها، در همان MultiPHP INI Editor به تب Editor Mode بروید؛ آنجا فایل تنظیمات اختصاصی همان دامنه را به‌صورت متنی ویرایش می‌کنید.

در آموزش‌های قدیمی توصیه می‌شد یک فایل php.ini را در پوشه‌ای که برنامه در آن نصب شده آپلود کنید تا محدودیت‌ها (از جمله همان سقف ۲ مگابایتی آپلود) تغییر کند. این روش فقط زمانی جواب می‌دهد که PHP به‌صورت CGI/suPHP اجرا شود. روی سرورهای امروزی که PHP با PHP-FPM اجرا می‌شود، فایل php.ini رهاشده در پوشه سایت هیچ اثری ندارد و باید به‌جای آن از فایل .user.ini استفاده کنید:

upload_max_filesize = 128M
post_max_size = 256M
memory_limit = 512M
max_execution_time = 300
max_input_vars = 10000

این فایل را در ریشه سایت (معمولاً public_html) بسازید. دو نکته: اول این‌که .user.ini فقط دستورهایی را می‌پذیرد که در سطح دایرکتوری قابل تنظیم‌اند (PHP_INI_PERDIR و PHP_INI_USER)؛ چیزی مثل disable_functions از این راه تغییر نمی‌کند. دوم این‌که PHP محتوای این فایل را کش می‌کند و اعمال تغییر ممکن است تا حدود پنج دقیقه طول بکشد.

درباره .htaccess هم دقت کنید: دستورهای php_value و php_flag فقط وقتی کار می‌کنند که PHP به‌صورت ماژول Apache (mod_php) یا با LiteSpeed اجرا شود. اگر سرور از Apache به‌همراه PHP-FPM استفاده کند، همین خطوط باعث خطای 500 Internal Server Error در کل سایت می‌شوند. پس پیش از دست‌زدن به .htaccess یک کپی از آن نگه دارید؛ اگر بعد از افزودن یک خط سایت ۵۰۰ داد، همان خط را پاک کنید و سراغ .user.ini یا MultiPHP INI Editor بروید.

فعال‌سازی اکستنشن‌های PHP

برای فعال‌سازی اکستنشن‌ها از طریق همان بخش Select PHP Version، تب Extensions را باز کنید و اکستنشن مورد نظر را تیک بزنید. مهم‌ترین‌ها:

• ionCube Loader — برای اجرای کدهای رمزنگاری‌شده؛ بسیاری از قالب‌ها و افزونه‌های پولی به آن نیاز دارند. اگر در فهرست اکستنشن‌ها نبود، یعنی روی سرور نصب نشده و باید از مدیر سرور بخواهید نصبش کند.
• gd — کتابخانه پردازش تصویر؛ برای ساخت بندانگشتی (thumbnail)، تصاویر امنیتی captcha و تغییر اندازه عکس‌ها لازم است.
• imagick — پردازش تصویر پیشرفته‌تر و باکیفیت‌تر از gd. وردپرس اگر هر دو موجود باشند imagick را ترجیح می‌دهد.
• intl — پشتیبانی از تاریخ و زمان و زبان‌های مختلف.
• zip — کار با فایل‌های zip؛ وردپرس هنگام نصب افزونه و قالب و همچنین ساخت فایل خروجی از آن استفاده می‌کند.
• curl — ارسال درخواست‌های HTTP؛ لازمه اتصال به درگاه پرداخت، APIها و به‌روزرسانی‌ها.
• mbstring — کار درست با رشته‌های چندبایتی؛ برای محتوای فارسی عملاً ضروری است.
• mysqli یا pdo_mysql — اتصال به دیتابیس MySQL/MariaDB.

پس از فعال‌سازی هر اکستنشن، تغییرات به‌صورت لحظه‌ای اعمال می‌شود و نیازی به ری‌استارت نیست.

فعال کردن GD در سطح سرور

اگر کاربر هاست هستید، همان تیک gd در تب Extensions کافی است و بقیه این بخش به شما مربوط نمی‌شود. اگر مدیر سرور هستید و اصلاً بسته gd برای آن نسخه PHP نصب نیست، در سی‌پنل امروزی (EasyApache 4) از WHM وارد EasyApache 4 شوید، در مرحله PHP Extensions بسته ea-phpXX-php-gd را انتخاب و پروفایل را Provision کنید. معادل خط فرمانش روی AlmaLinux یا Rocky Linux این است (83 را با نسخه خودتان عوض کنید):

dnf install ea-php83-php-gd
systemctl restart ea-php83-php-fpm

ری‌استارت PHP-FPM چند ثانیه قطعی برای سایت‌های همان نسخه دارد؛ آن را در ساعت کم‌ترافیک انجام دهید. روی سرورهای قدیمی‌تر با CentOS 7 به‌جای dnf از yum استفاده کنید. روش قدیمی که در آموزش‌های چند سال پیش می‌خواندید — یعنی رفتن به WHM » EasyApache، تیک‌زدن GD و Rebuild کردن کل PHP — مربوط به EasyApache 3 است؛ این ابزار سال‌هاست بازنشسته شده و روی سرورهای امروزی وجود ندارد. در EasyApache 4 دیگر چیزی کامپایل نمی‌شود و اکستنشن‌ها فقط بسته‌های آماده RPM هستند که نصب و حذف می‌شوند.

در دایرکت‌ادمین ابتدا بررسی کنید که gd واقعاً غایب است:

php -m | grep -i gd

توجه کنید که php در خط فرمان، نسخه پیش‌فرض سرور را اجرا می‌کند؛ اگر چند نسخه PHP نصب دارید، همان باینری نسخه‌ای را صدا بزنید که سایت با آن اجرا می‌شود، یا نتیجه را از خروجی phpinfo() روی خود دامنه بگیرید.

در بیشتر نصب‌های امروزی دایرکت‌ادمین، gd از پیش در PHP کامپایل شده است. اگر واقعاً نبود، از طریق CustomBuild اقدام کنید — اما پیش از اجرا حواستان باشد که این فرمان PHP را از نو می‌سازد: بسته به سرور ده‌ها دقیقه طول می‌کشد، در پایان سرویس PHP ری‌استارت می‌شود و اگر بیلد شکست بخورد سایت‌ها بالا نمی‌آیند. اول از سرور بکاپ کامل بگیرید و کار را در ساعت کم‌ترافیک و در یک نشست پایدار (مثلاً داخل screen یا tmux) انجام دهید:

cd /usr/local/directadmin/custombuild
./build update
./build php n

دستور yum install GD که در آموزش‌های قدیمی تکرار می‌شد دو ایراد دارد: نام بسته در مخازن لینوکس با حروف کوچک (gd) است، و مهم‌تر این‌که خودِ کتابخانه سیستمی gd به‌تنهایی اکستنشن PHP را نمی‌سازد؛ PHP باید با پشتیبانی از آن ساخته یا بسته اکستنشن مربوطه نصب شود. اگر CustomBuild نسخه شما فرمان بالا را نشناخت، ./build را بدون آرگومان اجرا کنید تا فهرست فرمان‌های همان نسخه را ببینید.

تکلیف register_globals و دستورهای حذف‌شده

یکی از پرتکرارترین درخواست‌ها هنگام انتقال اسکریپت‌های قدیمی این است: «register_globals را روشن کنید تا سایتم بالا بیاید.» پاسخ صریح این است که چنین کاری ممکن نیست. مقدار پیش‌فرض این دستور در PHP 4.2.0 از On به Off تغییر کرد، در PHP 5.3 منسوخ اعلام شد و در PHP 5.4 به‌طور کامل از زبان حذف شد. امروز هیچ راهی برای فعال‌کردنش وجود ندارد؛ نه با آپلود یک فایل php.ini در پوشه برنامه، نه در .user.ini، نه در .htaccess و نه با هیچ ترفند دیگری. اگر آن را در فایل تنظیمات بنویسید، در بهترین حالت نادیده گرفته می‌شود.

راه‌حل درست، اصلاح خودِ کد است. اسکریپتی که به register_globals تکیه دارد، متغیر ورودی را مستقیم به شکل $username می‌خواند. باید آن را صریحاً از آرایه ورودی بگیرد:

// کد قدیمی که به register_globals تکیه دارد:
echo $username;

// جایگزین درست:
$username = $_POST['username'] ?? '';
echo htmlspecialchars($username, ENT_QUOTES, 'UTF-8');

مراقب «راه‌حل‌های» اینترنتی مانند extract($_REQUEST) در ابتدای فایل باشید؛ این کار دقیقاً همان حفره امنیتی register_globals را برمی‌گرداند و به هر بازدیدکننده اجازه می‌دهد متغیرهای داخلی برنامه شما را بازنویسی کند. اگر اسکریپتی آن‌قدر قدیمی است که بدون register_globals کار نمی‌کند، تقریباً به‌طور قطع آسیب‌پذیری‌های شناخته‌شده دیگری هم دارد و امن‌ترین کار، بازنویسی یا جایگزینی آن است.

هم‌خانواده‌های register_globals هم همین سرنوشت را داشتند. اگر بعد از ارتقای نسخه PHP سایت شما خطای Fatal error می‌دهد، احتمالاً یکی از این‌ها مقصر است:

• magic_quotes_gpc و safe_mode — همراه register_globals در PHP 5.4 حذف شدند.
• توابع mysql_* (مانند mysql_connect) — در PHP 7.0 حذف شدند؛ جایگزین آن‌ها mysqli یا PDO است.
• توابع ereg_* — در PHP 7.0 حذف شدند؛ جایگزین‌شان خانواده preg_* است.
• each() و create_function() — در PHP 8.0 حذف شدند.
• allow_url_include — در PHP 8.0 حذف شد.

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

php.ini سطح سرور و بازگرداندن آن به حالت پیش‌فرض

این بخش مخصوص مدیران سرور با دسترسی root است. اگر کاربر هاست اشتراکی هستید، ابزار درست برای شما همان MultiPHP INI Editor است و لازم نیست هیچ‌کدام از فرمان‌های زیر را اجرا کنید.

در آموزش‌های قدیمی برای پیش‌فرض کردن تنظیمات PHP این دو خط توصیه می‌شد:

mv /usr/local/lib/php.ini /usr/local/lib/php.ini.bakold
/scripts/phpini

هر دو مربوط به دوره EasyApache 3 و PHP کامپایل‌شده هستند. روی سی‌پنل امروزی، نه فایل /usr/local/lib/php.ini نقشی دارد و نه اسکریپت /scripts/phpini وجود دارد؛ اجرای آن فقط خطای command not found می‌دهد. ضمناً استفاده از mv به‌جای cp خطرناک است: تا لحظه‌ای که فایل جدید ساخته شود، PHP بدون فایل تنظیمات اجرا می‌شود.

در EasyApache 4 هر نسخه PHP فایل تنظیمات مستقل خودش را دارد، در مسیری مانند /opt/cpanel/ea-php83/root/etc/php.ini. برای اطمینان از این‌که کدام فایل واقعاً بارگذاری شده:

/opt/cpanel/ea-php83/root/usr/bin/php --ini

برای بکاپ‌گیری و بازگرداندن فایل به حالت اولیه، ابتدا یک کپی امن بگیرید، سپس ببینید فایل متعلق به کدام بسته است و همان بسته را دوباره نصب کنید:

cp /opt/cpanel/ea-php83/root/etc/php.ini /opt/cpanel/ea-php83/root/etc/php.ini.bak
rpm -qf /opt/cpanel/ea-php83/root/etc/php.ini
dnf reinstall PACKAGE_NAME

به‌جای PACKAGE_NAME نام بسته‌ای را بگذارید که فرمان rpm -qf نشان داده است. حالا یک نکته که اغلب از قلم می‌افتد: فایل php.ini در این بسته‌ها به‌صورت config(noreplace) بسته‌بندی شده؛ یعنی اگر آن را دستی ویرایش کرده باشید، نصب مجدد بسته فایل شما را بازنویسی نمی‌کند و نسخه اصلی را کنارش با پسوند .rpmnew می‌گذارد. پس بعد از reinstall حتماً بررسی کنید و در صورت وجود، خودتان جایگزینش کنید:

ls -l /opt/cpanel/ea-php83/root/etc/php.ini.rpmnew
cp /opt/cpanel/ea-php83/root/etc/php.ini.rpmnew /opt/cpanel/ea-php83/root/etc/php.ini
systemctl restart ea-php83-php-fpm

اگر rpm -qf بگوید فایل متعلق به هیچ بسته‌ای نیست، یعنی فایل دستی ساخته شده و باید محتوای آن را خودتان اصلاح کنید. ساده‌تر و کم‌ریسک‌تر از همه این است که به‌جای SSH، در WHM از مسیر Software » MultiPHP INI Editor همان فایل را برای هر نسخه PHP ویرایش کنید.

یک نکته درباره ری‌استارت سرویس‌ها: دستورهای قدیمی مانند service httpd restart یا /etc/init.d/httpd restart روی توزیع‌های امروزی جای خود را به systemd داده‌اند:

systemctl restart httpd
systemctl restart ea-php83-php-fpm

روی سی‌پنل، روش پیشنهادی خود cPanel برای ری‌استارت آپاچی اسکریپت زیر است تا سرویس‌مانیتور سی‌پنل هم در جریان قرار بگیرد:

/usr/local/cpanel/scripts/restartsrv_httpd

هر ری‌استارت آپاچی چند ثانیه قطعی برای همه سایت‌های سرور دارد؛ آن را در ساعت کم‌ترافیک انجام دهید و اگر تنظیمات آپاچی را دست‌کاری کرده‌اید، اول با httpd -t صحت فایل‌های پیکربندی را بسنجید تا سرویس بعد از ری‌استارت بالا بیاید.

تغییرات اعمال نشد؛ از کجا شروع کنیم

• اول تأیید کنید، بعد عیب‌یابی. با خروجی phpinfo() روی همان دامنه ببینید مقدار جدید واقعاً بارگذاری شده یا نه. ستون Local Value و مسیر Loaded Configuration File دو چیزی هستند که باید نگاه کنید.
• تداخل تنظیمات. یک php_value در .htaccess یا یک .user.ini در پوشه سایت می‌تواند مقداری را که در پنل تنظیم کرده‌اید بازنویسی کند. آن دو فایل را هم بررسی کنید.
• کش .user.ini. اعمال تغییرات این فایل تا حدود پنج دقیقه طول می‌کشد؛ کمی صبر کنید.
• OPcache. اگر تغییرات کد اعمال نمی‌شود، سرویس PHP-FPM نسخه مربوطه را ری‌استارت کنید. این کار دسترسی root می‌خواهد؛ روی هاست اشتراکی باید از پشتیبانی بخواهید.
• محدودیت در لایه بالاتر. اگر با وجود تنظیمات درست باز هم آپلود فایل بزرگ رد می‌شود، ممکن است محدودیت در سطح وب‌سرور یا فایروال برنامه (ModSecurity) باشد که فقط مدیر سرور می‌تواند بررسی کند.
• سقف سیستم مدیریت محتوا. در وردپرس می‌توانید با افزودن خطوط زیر به wp-config.php سقف حافظه را بالا ببرید. این خطوط باید بالاتر از خط require_once ABSPATH . 'wp-settings.php'; نوشته شوند، و مقدارشان نمی‌تواند از memory_limit خود PHP بیشتر عمل کند؛ برای صفحات پیشخوان هم وردپرس ثابت جداگانه WP_MAX_MEMORY_LIMIT را می‌خواند:

  define('WP_MEMORY_LIMIT', '512M');
  define('WP_MAX_MEMORY_LIMIT', '512M');

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

جمع‌بندی

تقریباً همه چیزی که برای هماهنگ‌کردن محیط PHP با نیاز سایتتان لازم دارید، در دو ابزار سی‌پنل جمع شده است: Select PHP Version برای انتخاب نسخه و اکستنشن‌ها، و MultiPHP INI Editor برای محدودیت‌ها. نسخه‌ای را انتخاب کنید که هنوز وصله امنیتی می‌گیرد، سه مقدار memory_limit و post_max_size و upload_max_filesize را هماهنگ با هم بالا ببرید، و اکستنشن‌های لازم سایتتان را تیک بزنید. در مقابل، دستورهایی مانند register_globals دیگر بخشی از PHP نیستند و به‌جای دنبال‌کردن راه‌های خطرناک برای احیای آن‌ها، باید کد قدیمی را به‌روز کرد.