Most WordPress sites should treat php.ini as the server’s PHP control room and wp-config.php as the WordPress-only settings file. A site owner changes php.ini to adjust limits such as memory, upload size, execution time, and error logging. The same owner changes wp-config.php to set database credentials, debug mode, salts, cache flags, and WordPress constants. WordPress lists PHP as a core server requirement, so these settings matter before a plugin ever loads [source: WordPress.org].

TLDR: php.ini controls how PHP behaves on the server, while wp-config.php controls how WordPress behaves inside that PHP setup. For example, a WooCommerce store with 1,200 products may raise memory_limit from 128M to 256M in php.ini, then enable WP_DEBUG in wp-config.php during testing. In one common support case, a 64 MB upload failed until upload_max_filesize and post_max_size were both raised to 128M. The rule is simple: server limits go in PHP configuration; WordPress behavior goes in WordPress configuration.

What php.ini Does for WordPress

php.ini is the main configuration file for PHP itself. It is read by the PHP engine before WordPress starts running. That means it affects WordPress, plugins, themes, cron jobs, image processing, imports, backups, and admin requests.

Common php.ini settings include:

• memory_limit: Sets the maximum memory a PHP process can use.
• upload_max_filesize: Sets the largest single uploaded file size.
• post_max_size: Sets the largest total POST request size.
• max_execution_time: Sets how long a script can run.
• max_input_vars: Limits how many input fields PHP accepts.
• display_errors: Controls whether PHP errors appear on screen.
• error_log: Sets where PHP writes error logs.

These settings can decide whether a backup finishes, whether Elementor saves a page, or whether a large XML import crashes halfway through. Honestly, it feels like WordPress gets blamed for problems that are just PHP limits wearing a fake mustache.

What wp-config.php Does

wp-config.php sits in the WordPress root folder. It loads early, but after PHP itself is already running. Its job is to tell WordPress how to connect, how to behave, and which internal features to enable.

Common wp-config.php settings include:

• Database details: DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST.
• Security keys: Authentication salts for cookies and sessions.
• Debugging: WP_DEBUG, WP_DEBUG_LOG, and WP_DEBUG_DISPLAY.
• Memory requests: WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT.
• Cache flags: WP_CACHE.
• File editing: DISALLOW_FILE_EDIT.
• Automatic updates: WP_AUTO_UPDATE_CORE.

A typical debug setup may look like this:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

This setup logs problems without showing raw errors to visitors. That is safer for live sites. Public error messages can reveal paths, plugin names, and other details attackers love.

The Key Difference: Scope

The main difference is scope. php.ini affects PHP at the server or account level. wp-config.php affects one WordPress installation.

If a hosting account runs three WordPress sites under the same PHP setup, one php.ini change may affect all three. A change in one site’s wp-config.php affects only that site.

Need	Best Place	Example
Raise upload size	php.ini	upload_max_filesize = 128M
Enable WordPress debug logs	wp-config.php	define('WP_DEBUG_LOG', true);
Increase script runtime	php.ini	max_execution_time = 300
Turn off theme and plugin file editor	wp-config.php	define('DISALLOW_FILE_EDIT', true);

Memory Limits Can Be Confusing

Memory is where the two files often overlap. PHP has memory_limit. WordPress has WP_MEMORY_LIMIT. These are not equal in power.

php.ini sets the hard PHP ceiling. WordPress can request memory with WP_MEMORY_LIMIT, but it cannot go above the server limit. If PHP is capped at 128M, setting WordPress to 512M will not magically unlock 512 MB.

A practical setup might be:

; php.ini
memory_limit = 256M

// wp-config.php
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

The admin area can use the higher value when allowed by the server. Still, the host must permit it. Shared hosting often blocks changes, which is annoying because the error message rarely says that plainly.

Where to Edit php.ini

Access depends on the hosting setup. On a VPS or dedicated server, an administrator may edit the real php.ini file. On shared hosting, the user may need a control panel, a local php.ini, a .user.ini file, or a support ticket.

Common places include:

• cPanel MultiPHP INI Editor
• Plesk PHP Settings
• A local .user.ini file
• Server files such as /etc/php/8.2/apache2/php.ini
• Hosting support panel settings

After a change, PHP may need a restart. With PHP-FPM, the pool may need reloading. With shared hosting, changes may take a few minutes. Expect to waste time on caching here. A setting can be correct, yet WordPress still shows the old value for a short while.

Where to Edit wp-config.php

wp-config.php is usually found in the main WordPress folder, next to wp-admin, wp-content, and wp-includes. It can also sit one level above the public root on some setups.

Safe editing rules matter:

• Download a backup before editing.
• Use a plain text editor, not a word processor.
• Place custom constants above the line that says “That’s all, stop editing!”
• Check for missing semicolons.
• Do not expose database passwords in screenshots or support chats.

Which File Should Be Changed First?

The best choice depends on the problem.

• Uploads failing? Check php.ini values for upload_max_filesize and post_max_size.
• White screen or fatal error? Enable logging in wp-config.php, then check the PHP error log.
• Import timing out? Raise max_execution_time in php.ini.
• Plugin editor should be blocked? Set DISALLOW_FILE_EDIT in wp-config.php.
• Object cache plugin installed? Confirm WP_CACHE in wp-config.php.

Security Best Practices

Security settings should be split wisely. PHP should hide errors from visitors:

display_errors = Off
log_errors = On

WordPress should log debug data only when needed:

define('WP_DEBUG', false);

For live sites, file editing should usually be disabled:

define('DISALLOW_FILE_EDIT', true);

This blocks the built-in theme and plugin editor in the dashboard. It does not block FTP, SSH, Git, or hosting file managers, but it reduces damage if an admin account is stolen.

FAQ

Can wp-config.php replace php.ini?

No. wp-config.php can request some settings, but it cannot replace server-level PHP configuration. Hard PHP limits still win.

Why did a changed upload limit not work?

upload_max_filesize may have been raised without raising post_max_size. The POST limit should usually be larger than the upload limit.

Is it safe to edit wp-config.php?

Yes, if a backup exists and the editor preserves plain text. One missing quote or semicolon can break the site.

Should errors be displayed on a live WordPress site?

No. Errors should be logged, not shown to visitors. Public errors can expose sensitive paths and plugin details.

Which file controls database access?

wp-config.php controls database name, username, password, host, and table prefix.

Which file should be checked for performance tuning?

Both may matter. PHP limits belong in php.ini. WordPress cache flags, debug settings, and memory requests belong in wp-config.php.