Published 16 October 2026

If a website still reports the wrong upload limit, memory setting or PHP option after you changed it in cPanel, check what the site’s web request actually receives before editing more files. cPanel’s MultiPHP INI Editor can apply settings to a selected domain or to the account’s home directory, while PHP may also read per-directory configuration depending on its handler. The saved value and the effective value are not automatically the same thing.

This distinction matters for WordPress media uploads, ecommerce imports, contact-form attachments and application deployments. A web request and a command-line task may also use different PHP configurations. The practical fix is to identify the domain and request context, inspect only the relevant settings, then verify again after making one controlled change.

Why can the displayed PHP value differ?

PHP configuration can come from different places. The PHP manual explains that configuration files may be scanned in the current directory and its parent directories for CGI or FastCGI requests when per-user INI files are enabled. Which directives can be set in a particular file depends on the directive’s changeability mode. In cPanel, the MultiPHP INI Editor lets an account select a specific domain or the home directory, and it may write to supported configuration files such as php.ini, .user.ini or .htaccess.

That creates several common sources of confusion: the wrong domain was selected; the application is in a subdirectory with its own configuration; a setting is not permitted at that configuration level; or the test was run from the command line rather than through the website. cPanel’s MultiPHP Manager separately identifies the PHP version assigned to each domain, where the feature is available.

Do not assume that every upload problem is caused by PHP. A web application may impose its own limit, and web-server or account-level restrictions may also affect a request. A value in the editor is one clue, not proof that the entire upload path accepts a file of that size.

Check the live web request, not just the editor

  1. Confirm the exact domain and application path. In cPanel, open MultiPHP Manager and check the PHP version shown for the domain, if the interface is available. Then open MultiPHP INI Editor and confirm that you selected that domain rather than only the account-wide home-directory option. Check whether the site runs from the domain’s document root or a subdirectory.
  2. Inspect the relevant effective value. For a narrow check, create a temporary PHP file in the application directory that prints only the settings you need, for example echo ini_get('upload_max_filesize'); and echo ini_get('post_max_size');. Load it through the same HTTPS hostname used by the application. PHP documents ini_get() as returning a configuration option’s current value.
  3. Compare related limits. For uploads, compare upload_max_filesize with post_max_size; the request body must be able to carry the file and its form data. Also check the application’s own documented limit and any relevant web-server or plan restrictions. Avoid raising unrelated values simply because they appear in the same editor.
  4. Change one setting and retest. Use the cPanel editor where available, save the change, then load the temporary check again through the browser. If PHP processes a local .user.ini file, the manual notes that its cache interval can delay when changes take effect; allow for that before repeatedly editing configuration.
  5. Test the real action. Try a representative upload or application task, not only the diagnostic page. Confirm the failure is resolved and that the change has not caused a new error. Remove the temporary diagnostic file immediately after checking.

Keep diagnostics narrow and temporary

A full phpinfo() page can show extensive information, including PHP version, loaded extensions, paths, environment data and configuration values. That can be useful when an administrator is diagnosing a server, but a publicly accessible diagnostic page reveals more than a single setting check requires. Prefer a temporary script that prints only the needed values, restrict access while testing if possible, and delete it promptly.

Practical note: Do not paste server paths, environment variables or full diagnostic output into public support forums. Share only the specific setting and error message needed for troubleshooting.

When to ask your hosting provider

If the browser check still differs from cPanel after you have confirmed the domain, path and selected PHP version, send your provider the domain, the setting name, the value shown in cPanel, the value observed in the web request, and when you made the change. Do not send passwords or publish a full diagnostic page. Ask whether the directive is supported at account level and whether a server-side limit also applies.

For a WordPress store, this approach can prevent a risky sequence of edits while a product import or customer upload is waiting. HostCupid Web Solutions Private Limited, a Chennai-based provider of shared and WordPress hosting, website development and migration support, may be relevant when an owner needs help checking the hosting-side context during a migration or configuration issue. The same evidence-first checklist is useful with any provider: identify the request, verify its live settings and change only what the application actually needs.

Once troubleshooting is complete, remove test scripts and keep a note of the setting changed and the test performed. That gives the next developer or site owner a clear starting point if the same symptom returns.


Sources

Portrait of Kavya Anand, HostCupid editorial persona
Published by
Kavya Anand

HostCupid Editorial Team

Covers WordPress, cPanel, performance, DNS, website security and practical digital guidance for Indian businesses.

Editorial persona representing the HostCupid content team.

← More HostCupid Insights