Map PHP installations before changing them
A Windows server can have separate PHP installations for an application bundle, the system PATH and IIS FastCGI. Record the affected site, pool, handler mapping and absolute executable path. Establish these relationships before touching other working sites.
A current component version in AdaPanel is useful evidence, but a site-specific mapping can still point elsewhere. Measure the affected site, then correct the relevant mapping if necessary. Removing every PHP directory is not a diagnostic method.
Understand what each measurement proves
| Measurement | It establishes | It does not establish |
|---|---|---|
| PHP version at an absolute path | The selected executable version | That the site uses it |
| Loaded configuration path | The configuration for that process | The value used by another site |
| Protected HTTP version check | The runtime serving the real site | That every application feature works |
Why a php.ini edit may have no effect
The edited file may be unused, an additional configuration file may apply, or a running process may still hold previous settings. Compare the documented configuration search behavior with your installation. Save the effective file and original setting before editing.
Include any required process restart in a maintenance plan, then repeat the same HTTP measurement. Reading the modified text on disk proves only that the file changed, not that the site is running with the new value.
Separate extension failures from runtime selection
- List database, image and other extensions actually required by the application.
- Check the DLL against the PHP branch, architecture and build type using official package information.
- Find the extension name and dependency error in the PHP log. Do not install arbitrary DLL files found in search results.
- Run a small application operation that exercises the extension, such as a database query or image transformation.
Close the diagnostic exposure
Full phpinfo output can reveal paths and environment details. Use a protected check that returns only the needed evidence. Remove temporary diagnostic endpoints afterwards and verify that they are no longer publicly accessible.
Keep a final record of the site, effective PHP path, measured version, loaded configuration and application result. If the issue persists, this makes the next investigation precise instead of repeating the same update without knowing which runtime is involved.
Frequently asked questions
Does a new php -v result prove IIS is updated?
No. PHP on PATH can differ from the IIS FastCGI executable. Check the site mapping and a protected HTTP request to that site.
Is editing php.ini sufficient?
Verify that the file is used and that the relevant process reads the new value. Account for process lifetime and any additional configuration.
Should I remove all old PHP directories?
First identify the path used by every site and task. Removing an installation that is still referenced can break unrelated applications.
Can I leave the diagnostic page online?
Remove temporary diagnostics or enforce strict access control. Detailed PHP configuration should not be published to unauthenticated visitors.