PHP behavior depends on configuration as well as source code. The same script can run differently when the CLI uses one php.ini and the web server uses another. Settings control loaded extensions, upload limits, error display, memory budgets, and session behavior. This reference explains how to locate active configuration, distinguish startup settings from runtime changes, and choose production values deliberately. You will learn why ini_set() cannot change every directive and why a copied memory limit is not a universal recommendation. The goal is to inspect and manage your environment without leaving sensitive diagnostic pages publicly accessible.
Identify the runtime and active configuration
Run php --ini in the intended CLI environment to see loaded configuration paths. php_ini_loaded_file() and php_ini_scanned_files() can inspect the current process. A web handler may use PHP-FPM, an Apache module, or another interface with different files and service accounts. Verify its configuration through protected diagnostics or operational tooling. Do not assume editing the CLI file changes the web service. Additional scanned .ini files can override earlier values, and a deployment image may generate settings at startup. Record which runtime serves the application and how settings are applied. That turns configuration troubleshooting into a known procedure instead of repeatedly editing similarly named files and hoping one affects the site.
Understand where directives can change
PHP directives have changeability modes. Some can be set with ini_set() at runtime, while others require startup or server-level configuration. A runtime call may return false if the directive cannot be changed or the environment disallows it. Check results where the change is important. Extension loading is generally a startup concern, not something an ordinary request enables dynamically. A .user.ini file applies only under supported interfaces and may have refresh delays. Web-server configuration and PHP-FPM pool settings can add their own policy. Document the supported override mechanism rather than mixing every possible file. If a managed host controls a value, use its documented settings instead of assuming the application can override it.
Choose resource limits for the workload
memory_limit limits PHP memory use under its runtime behavior, while max_execution_time provides an execution-time control whose coverage differs by platform and operations. Neither is a complete substitute for infrastructure deadlines or bounded algorithms. Uploads involve upload_max_filesize and post_max_size, with the whole request including multipart overhead. A proxy or web server can reject a body before PHP receives it. Set limits according to expected files and processing cost, not by copying unlimited values from a troubleshooting answer. Increasing memory can hide an unbounded CSV or XML design. Large batch jobs may deserve a separate worker configuration while web requests retain smaller budgets. Measure normal and worst-case resource use.
Configure errors for the environment
Development benefits from detailed errors and E_ALL so warnings and deprecations are noticed early. Production should normally log errors privately and avoid displaying paths, SQL, or stack traces to visitors. display_errors and log_errors serve different purposes. A parse or startup failure may occur before runtime ini_set() code executes, so production settings must be correct in configuration, not only inside a script. Keep error_log destinations writable and protected, and verify rotation or platform log collection. Do not suppress warnings globally to make a page look clean. Fix the underlying issue or translate an expected failure under a specific policy. Deprecated features should be reviewed before a runtime upgrade rather than silently ignored forever.
Treat sessions and file paths as deployment policy
Session storage paths, upload temporary directories, timezone, and enabled extensions can materially affect an application. A directory that works locally may not exist or persist in a hosted instance. Ensure service-account permissions are appropriate and avoid public storage of session files. Configure session cookie behavior according to the application's HTTPS and authentication requirements. Set a timezone intentionally for date operations while keeping database timestamp semantics explicit. Check that required extensions such as pdo_mysql, fileinfo, mbstring, or DOM are available before deploying features that use them. A dependency declaration can describe extension needs, but the actual runtime still must provide them. Configuration is part of the deployment artifact's compatibility contract.
Apply changes and verify the effective value
Some changes require restarting or reloading the PHP service; others apply when a new request or process starts. Follow the environment's documented rollout process and verify effective values afterward with ini_get() or protected operational inspection. Avoid publishing a full phpinfo() page, which can expose server and environment information. Keep configuration changes in version-controlled deployment files when appropriate, with secrets injected separately. Test the intended effect rather than only checking the file text. For example, upload an allowed development fixture and one above the limit to confirm the response path. Preserve a rollback path for settings that affect availability, and compare web and CLI settings before running scheduled jobs.
Practice task and worked solution
Prepare configuration for a site accepting two-MiB profile pictures and running a separate CSV import worker. The solution gives the upload request enough total-body room, enforces the smaller application file limit, and checks proxy limits. Keep the worker's memory and time budget separate from interactive requests. Enable private production logs while disabling public error display at startup. Verify required Fileinfo and database extensions in the serving runtime. Document the exact configuration files and required reload steps. Test an allowed image, an oversized request, and a worker file large enough to confirm streaming behavior. Do not make all limits unlimited merely to pass the tests.
Continue learning
Review file handling, exceptions, and security.
The PHP configuration manual explains configuration locations and changeability.
PHP Configuration and php.ini Examples
Each example shows the code, the output it produces and what each part does.
Inspect a few non-secret effective settings
This CLI diagnostic prints selected values and the active configuration filename. Use it locally or in protected tooling rather than as a public endpoint.
The interface, configuration path, and values depend on the PHP process. Compare the output from the actual CLI and web environments rather than assuming they match.
<?php
echo 'Interface: ' . PHP_SAPI . PHP_EOL;
echo 'Configuration: ' . (php_ini_loaded_file() ?: 'none') . PHP_EOL;
foreach (['memory_limit', 'max_execution_time', 'upload_max_filesize', 'post_max_size'] as $key) {
echo $key . ': ' . ini_get($key) . PHP_EOL;
}Environment-dependent: PHP_SAPI, active php.ini path, and effective resource-limit values.PHP Configuration and php.ini FAQ
Why does ini_set not work?
The directive may not be runtime-changeable, or host policy may restrict it. Settings such as post_max_size and upload_max_filesize are read before your script starts, so changing them with ini_set() has no effect on the current request. Set them in php.ini, the PHP-FPM pool configuration or your host's control panel.
Why do CLI and web differ?
They can load different configuration and interfaces: the command line and PHP-FPM often read separate php.ini files and may even be different PHP versions. Compare php --ini and php -v in the terminal with phpinfo() served by the web server.
Will a runtime display_errors setting hide startup failures?
It may run too late. ini_set('display_errors', ...) only takes effect when that line executes, so parse errors in the file and problems during PHP's startup are handled with the configured setting. Set error display and logging in the server configuration.
Is phpinfo safe publicly?
No. phpinfo() reveals the PHP version, loaded extensions, file paths and environment variables, which may include secrets, all useful to attackers. Keep detailed diagnostics protected: use it briefly on a development machine or behind authentication, then remove it.
PHP Configuration and php.ini Exercises
Answer each one and check it instantly. If you get stuck, open the hint before the answer.
A huge CSV exceeds memory. What should be reviewed first?
PHP Configuration and php.ini Quiz
2 questions to check what you learned.
What confirms a configuration change actually applies?
- Only editing any php.ini file
- Changing the HTML heading
- Assuming CLI equals web
- Inspecting the effective value in the intended runtime
Why configure production error display outside runtime code?
- Startup or parse failures can occur before that code runs
- Calling ini_set() can always handle a syntax error in the same file
- Setting log_errors automatically disables display_errors
- The CLI configuration always governs web requests