مرجع تنظیمات php.ini؛ هر دستور با مقدار پیش‌فرض و اثر عملی

چرا فایل php.ini شما با فایل همسایه‌تان فرق دارد

سایتی که خطای Fatal error: Allowed memory size of 134217728 bytes exhausted می‌دهد با سایتی که همان خطا را با عدد 268435456 می‌بیند، یک مشکل ندارند. اولی به ۱۲۸ مگابایت محدود شده، دومی به ۲۵۶. هر دو دارند به سقف حافظه می‌خورند، اما سقف‌شان را یک نفر دیگر تعیین کرده. روی هاست اشتراکی، تنظیمات php.ini اصلی دست شما نیست؛ چیزی که می‌بینید حاصل سه لایه است: مقدار کامپایل‌شده در خود PHP، مقدار فایل اصلی سرور، و مقدار فایل .user.ini یا php.ini اختصاصی که در ریشه سایت‌تان گذاشته‌اید. این مقاله می‌گوید هر دستور چه می‌کند، مقدار پیش‌فرضش چیست، و اصلاً در محیط اشتراکی اجازه تغییرش را دارید یا نه.

دستورات حافظه و اجرا؛ جایی که ۹۰٪ خطاها از آنجا می‌آید

memory_limit

سقف حافظه‌ای که یک اسکریپت می‌تواند مصرف کند. مقدار پیش‌فرض در PHP 8.x برابر 128M است، اما خیلی از هاست‌های اشتراکی آن را روی 256M می‌گذارند. اگر وردپرس با خطای exhausted مواجه شد، اول مقصر یک افزونه بی‌کیفیت است، نه این تنظیم. افزایش بی‌رویه این عدد روی هاست اشتراکی، راهی برای کرش کردن کل سرور است؛ پس اگر به بیش از ۲۵۶ مگابایت نیاز دارید، مشکل جای دیگری است.

در هاست اشتراکی معمولاً می‌توانید تا سقفی که provider تعیین کرده (مثلاً ۵۱۲ مگابایت) بالا ببرید. بالاتر از آن را نه. این‌جا اشتباه می‌کنند: عدد را تا سقف مجاز بالا می‌برند، خطا برای چند روز ناپدید می‌شود، بعد با خطای 503 Service Unavailable مواجه می‌شوند چون کل سایت از حد مجاز CPU عبور کرده. حافظه بیشتر یعنی پردازش بیشتر، و پردازش بیشتر یعنی سهم بیشتری از CPU. مشکل را با log گرفتن حل کنید، نه با بزرگ‌کردن سقف.

max_execution_time

مدت زمان مجاز اجرای هر اسکریپت، بر حسب ثانیه. پیش‌فرض در PHP روی 30 است؛ در هاست اشتراکی معمولاً 60 یا 120. اگر اسکریپتی برای پردازش تصویر یا ایمیل انبوه به بیش از این زمان نیاز دارد، راه درست استفاده از cron job است، نه بالا بردن این عدد. اسکریپتی که ۳۰۰ ثانیه اجرا می‌شود، در هاست اشتراکی همسایه‌های شما را هم کند می‌کند.

توجه کنید که در PHP 8 این مقدار فقط برای اجرای خود اسکریپت حساب می‌شود، نه زمان انتظار برای ورودی. پس اگر اسکریپت منتظر پاسخ یک API خارجی است، این تایمر متوقف می‌شود. خیلی‌ها این را نمی‌دانند و فکر می‌کنند timeout از I/O نشات گرفته.

max_input_vars

حداکثر تعداد متغیرهای ورودی که یک درخواست می‌تواند داشته باشد (GET، POST و Cookie). پیش‌فرض 1000 است. فرمی با ۱٬۲۰۰ فیلد، ۲۰۰ فیلد آخر را بی‌صدا حذف می‌کند. هیچ خطایی نمی‌بینید؛ فقط داده‌ها گم می‌شوند. این یکی از آن خطاهای خاموش است که debugging آن ساعت‌ها طول می‌کشد.

در هاست اشتراکی معمولاً می‌توانید تا 2000 یا 3000 بالا ببرید. بالاتر از آن نشانه طراحی بد فرم است، نه نیاز واقعی.

دستورات آپلود؛ جایی که کاربر نهایی خطا می‌بیند

upload_max_filesize و post_max_size

اولی سقف حجم هر فایل آپلودی است، دومی سقف کل بدنه درخواست POST. پیش‌فرض‌ها به ترتیب 2M و 8M هستند. در هاست اشتراکی معمولاً 64M و 128M. قانون طلایی: post_max_size باید همیشه بزرگ‌تر از upload_max_filesize باشد، چون بدنه درخواست شامل فایل به اضافه سایر فیلدهای فرم است.

این‌جا اشتباه می‌کنند: فقط upload_max_filesize را بالا می‌برند، بعد آپلود فایل ۳۰ مگابایتی با خطای 413 Request Entity Too Large یا خطای خالی PHP مواجه می‌شود. سقف واقعی، کوچک‌ترین عدد بین این دو تنظیم و محدودیت وب‌سرور (مثلاً client_max_body_size در Nginx) است. هر سه را باید هماهنگ کنید.

max_file_uploads

حداکثر تعداد فایل در یک درخواست. پیش‌فرض 20. اگر فرمی دارید که کاربر باید ۳۰ تصویر آپلود کند، بقیه بی‌صدا حذف می‌شوند. در هاست اشتراکی تغییر این مقدار معمولاً ممکن است، اما بالا بردن آن به ۵۰ یا ۱۰۰، فشار واقعی روی حافظه و زمان اجرا می‌گذارد.

دستورات امنیتی؛ پیش‌فرض‌ها اینجا قابل اعتماد نیستند

display_errors

در محیط توسعه باید On باشد تا خطاها را ببینید. در محیط production باید Off باشد. مقدار پیش‌فرض در PHP 8 On است، اما هاست‌های اشتراکی معمولاً آن را Off می‌کنند و خطاها را در error_log می‌نویسند. اگر خطای صفحه سفید وردپرس را می‌بینید و هیچ پیامی نمایش داده نمی‌شود، اول این تنظیم را چک کنید.

روی هاست اشتراکی، تغییر این مقدار از طریق .user.ini معمولاً ممکن است، اما اگر provider آن را در سطح سرور Off کرده باشد، نمی‌توانید override کنید. در آن صورت باید لاگ خطا را بخوانید. راهنمای رفع صفحه سفید در وردپرس و PHP دقیقاً همین مسیر را نشان می‌دهد.

disable_functions

لیست توابعی که به کل غیرفعال شده‌اند. در هاست اشتراکی، توابع خطرناکی مثل exec، shell_exec، system و passthru معمولاً غیرفعال هستند. این یک محدودیت امنیتی است، نه یک نقص. اگر افزونه‌ای به این توابع نیاز دارد، یعنی آن افزونه برای هاست اشتراکی طراحی نشده.

نکته ظریف: بعضی توابع مثل mail() ممکن است غیرفعال نباشند اما به شدت محدود شده باشند. اگر ایمیل‌های سایت‌تان به اسپم می‌رود یا اصلاً ارسال نمی‌شود، اول این را چک کنید، نه تنظیمات SMTP را.

دستورات اجرایی؛ تفاوت بین هاست اشتراکی و سرور اختصاصی

opcache.enable

کش کدهای میانی PHP. وقتی On باشد، اسکریپت‌ها بعد از اولین اجرا کامپایل نمی‌شوند و مستقیم از حافظه اجرا می‌شوند. تفاوت واقعی را اینجا می‌بینید: سایتی با opcache غیرفعال، ۳ تا ۵ برابر کندتر از همان سایت با opcache فعال است. روی هاست اشتراکی معمولاً On است و نمی‌توانید خاموشش کنید. اگر خاموش است، یعنی provider آن را عمداً غیرفعال کرده، چون opcache روی هاست اشتراکی حافظه سرور را می‌خورد.

اگر روی سرور اختصاصی هستید، مقدار opcache.memory_consumption را روی ۱۲۸ یا ۲۵۶ مگابایت بگذارید و opcache.revalidate_freq را روی 2 تا 5 ثانیه تنظیم کنید. صفر نگذارید؛ یعنی هر بار چک می‌کند فایل تغییر کرده یا نه و عملاً کش را بی‌اثر می‌کند.

realpath_cache_size

کش مسیرهای واقعی فایل‌ها. پیش‌فرض 4096K در PHP 8. سایتی با هزاران فایل شامل، اگر این کش کوچک باشد، هر بار مسیرها را از دیسک می‌خواند. در هاست اشتراکی به این مقدار دسترسی ندارید؛ در سرور اختصاصی می‌توانید به 8192K برسانید. تفاوت محسوس است، اما نه به اندازه opcache.

کدام دستورات را در هاست اشتراکی اصلاً نمی‌توانید تغییر دهید

لیست زیر دستوراتی است که در ۹۹٪ هاست‌های اشتراکی در سطح سرور قفل شده‌اند و هر چقدر در .user.ini بنویسید، بی‌اثر است:

• allow_url_fopen — معمولاً On است و نمی‌توانید خاموشش کنید
• open_basedir — محدودیت دسترسی به دایرکتوری‌ها، توسط provider تنظیم می‌شود
• session.save_path — مسیر ذخیره سشن‌ها
• error_log — مسیر فایل لاگ خطا
• extension — بارگذاری افزونه‌های PHP

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

روش درست تغییر تنظیمات در هاست اشتراکی

در هاست‌های cPanel، فایل .user.ini در ریشه public_html معتبر است و تنظیمات آن به همه زیرشاخه‌ها هم سرایت می‌کند. اگر فقط یک زیرشاخه خاص را می‌خواهید تغییر دهید، همان‌جا فایل بگذارید. سینتکس ساده است:

memory_limit = 256M
max_execution_time = 120
upload_max_filesize = 64M
post_max_size = 128M
max_input_vars = 3000
display_errors = Off

بعد از تغییر، با یک فایل تست حاوی <?php phpinfo(); ?> بررسی کنید که مقدار جدید اعمال شده یا نه. اگر اعمال نشده، یعنی provider آن را قفل کرده. این روش را با ابزارهای رایگان وب‌مستر هم می‌توانید چک کنید.

مقایسه سریع: دستوراتی که باید بشناسید

پرسش‌های پرتکرار

فایل php.ini من کجاست؟

روی هاست اشتراکی cPanel معمولاً باید فایل .user.ini را در ریشه public_html بسازید. برای پیدا کردن مسیر دقیق، یک فایل تست با <?php phpinfo(); ?> بسازید و دنبال مقدار Loaded Configuration File بگردید.

چرا تغییرات php.ini من اعمال نمی‌شود؟

دو دلیل رایج دارد: یا دستوری که تغییر داده‌اید در سطح سرور قفل شده (مثل disable_functions)، یا بعد از تغییر، PHP را ریست نکرده‌اید. در هاست اشتراکی معمولاً تغییرات .user.ini بلافاصله اعمال می‌شود، اما اگر نه، چند دقیقه صبر کنید یا از پنل گزینه «Restart PHP» را بزنید.

کدام تنظیمات php.ini برای وردپرس حیاتی است؟

memory_limit حداقل ۱۲۸ مگابایت، max_execution_time حداقل ۶۰ ثانیه و upload_max_filesize حداقل ۳۲ مگابایت. اگر سایت‌تان با این سه عدد کار می‌کند و باز خطا می‌دهد، مشکل از PHP نیست؛ از یک افزونه یا قالب بد است. راهنمای بهینه‌سازی وردپرس روی هاست اشتراکی مسیر دقیق‌تری را نشان می‌دهد.

فرق php.ini با .htaccess چیست؟

.htaccess تنظیمات وب‌سرور آپاچی را کنترل می‌کند (مثل ریدایرکت و rewrite)، در حالی که php.ini تنظیمات خود زبان PHP را. بعضی تنظیمات مثل upload_max_filesize را در هر دو می‌توان دید، اما اگر هاست شما Nginx است، .htaccess اصلاً کار نمی‌کند و فقط .user.ini معتبر است.

یک نکته آخر: قبل از هر تغییری، مقدار فعلی را با phpinfo ثبت کنید. اگر بعداً سایت خراب شد، اولین کاری که می‌کنید برگرداندن همان مقادیر است. بدون نقطه مرجع، هر تغییر بعدی یک قمار است.