When PHP behavior looks inconsistent, the root cause is often simple: you edited the wrong file.
This guide shows how to find the active config file for both CLI and web requests, then verify your changes safely.
Why php.ini matters
controls runtime defaults such as:
- memory limits
- upload size constraints
- error reporting and logging
- mail transport options (
, SMTP-related behavior)
PHP may load different ini files for CLI and FPM/Apache, so always verify both contexts.
Fastest way to identify the active file
CLI context
Look for:
Web context (FPM/Apache)
Create a temporary file with:
Open it in your browser and check:
Delete this file after debugging to avoid exposing server details.
Typical php.ini locations
Linux (package installs)
macOS (Homebrew)
(Apple Silicon)(Intel)
Windows (XAMPP/WAMP/manual)
If unsure, use:
Applying changes safely
- Back up the current file.
- Change one setting at a time.
- Validate syntax and restart the relevant service.
- Re-check with
or.
Example (Linux + PHP-FPM):
Common pitfalls
Edited CLI ini but testing through web server
Result: command-line scripts behave differently from your app.
Overridden by additional ini files
Values in files like can supersede php.ini defaults.
Changed mail settings but didn’t verify delivery path
For app-level email workflows, validate with an end-to-end test inbox, not only local send success.
Practical email debugging workflow
If you are changing PHP mail behavior:
- confirm active ini path in the exact runtime context
- update mail directives
- restart PHP runtime
- send a test message
- assert received output in a test inbox
For deterministic checks, use MailSlurp test inboxes and PHP email receive examples.