WordPress hosting requirements: PHP, MySQL, and php.ini settings reference

Short answer: WordPress needs PHP 7.4 or newer (8.1+ recommended), MySQL 5.7+ or MariaDB 10.4+, HTTPS, and a web server – Apache or nginx. The PHP settings that actually affect WordPress day-to-day are memory_limit (256M minimum), max_execution_time (60s minimum), upload_max_filesize , and post_max_size . Everything else is noise.

This page is a reference card. Each setting links out to a deeper guide when you need to change one.

What WordPress requires to run#

These are the minimums that will technically work. They are not the numbers you should plan around – see the “recommended” column.

The official WordPress project lists these in the handbook, but what is “required” and what will actually run a real site in production are two different numbers. When you evaluate hosting, look at the recommended column, not the minimum.

“Does my host meet these requirements?”

Do not guess. Check from inside WordPress itself: Tools > Site Health > Info in wp-admin. The Server section shows the exact PHP version, MySQL version, and server software your install is running on. The Database section shows the MySQL/MariaDB version and whether key features are supported.

How to check your PHP version and find php.ini covers four different ways to check the PHP version (Site Health, phpinfo, SSH, WP-CLI) and which to use when your host has blocked some of the easier paths.

PHP settings that actually affect WordPress#

Out of the hundred-plus directives in a typical php.ini , only a handful matter for WordPress in practice. The rest either have sensible defaults you never need to touch, or are for features WordPress does not use.

Five of the six are about “something big is happening and PHP needs to let it finish.” The sixth – max_input_vars – is the sneaky one: when you exceed it, PHP silently truncates the POST data, WordPress saves partial data, and you end up with a menu missing the last 20 items or a product variation matrix with chunks missing.

memory_limit

The single setting people hit most often. WordPress allocates memory for each loaded plugin, theme file, and in-memory query result. A WooCommerce store with 30 active plugins can use 300M+ just to render the admin dashboard.

Full troubleshooting: WordPress PHP memory exhausted error – how to fix it.

max_execution_time

If you see “Maximum execution time of 30 seconds exceeded” in the error log, a PHP script hit this limit. Usually it is a plugin doing a long database operation (the biggest offenders: import/export plugins, backup plugins running through the admin UI, WooCommerce bulk actions).

Full guide: WordPress maximum execution time exceeded – how to fix it.

upload_max_filesize and post_max_size

These two work together. If post_max_size is smaller than upload_max_filesize , PHP discards the POST data silently. If an nginx client_max_body_size in front of PHP is smaller than either, you get a 413 error before the request ever reaches PHP.

The three have to be aligned:

nginx client_max_body_size = upload_max_filesize = post_max_size / 2

If uploads fail in ways that are not the obvious “file too large” message, see the uploaded file could not be moved to wp-content/uploads – a common upload failure that looks like a size problem but often is not.

How to check your current settings#

From WordPress admin (easiest)

Tools > Site Health > Info > Server lists every relevant value. No server access required. This is the right place to look first, every time, for every WordPress PHP question.

From phpinfo()

Create a temporary file info.php in the WordPress root:

<?php phpinfo(); ?>

Load https://yoursite.com/info.php in the browser. Search for the directive name. Delete the file immediately after checking – leaving phpinfo output publicly visible exposes server details that are useful to attackers.

From the command line

If you have SSH:

# Show all PHP settings
php -i

# Show a specific directive
php -i | grep memory_limit

# From the WordPress directory, using WP-CLI
wp eval "echo ini_get('memory_limit');"

The WP-CLI version is the only one that reflects WordPress’s actual runtime value, including any ini_set() calls made by plugins or themes. php -i shows the php.ini default; WordPress might be running with different values after wp-config.php or plugin overrides kick in.

Where to change settings (in priority order)#

PHP reads settings from multiple sources, and the later ones override the earlier ones. When you need to change a value, start with the lowest-impact method that works.

1. Hosting control panel – if your host exposes a PHP Manager or equivalent, use that. The change is scoped to your site, survives updates, and is easy to reverse.
2. wp-config.php – for memory_limit specifically, WordPress respects define('WP_MEMORY_LIMIT', '256M'); . Documented in wp-config.php explained – what every setting does.
3. php.ini – if your host gives you a per-site php.ini or .user.ini , place overrides there. Scope is the directory and below.
4. .htaccess – Apache-only, and only for a few directives ( php_value memory_limit 256M ). Does not work on nginx, does not work with PHP-FPM in many configurations.
5. ini_set() in code – last resort. Changes are scoped to the current request only, and some directives cannot be changed this way ( upload_max_filesize notably cannot).

If none of those work, your host is either preventing the change at the platform level (common on shared hosting) or you are editing a file PHP is not actually reading. Use Tools > Site Health > Info to confirm which php.ini file is loaded and verify your change appears there after a PHP-FPM or web server reload.

Things you do not need to worry about#

Most PHP settings have no practical effect on WordPress. You will see tutorials online telling you to tweak these – ignore them unless you have a specific reason:

• register_globals – removed in PHP 5.4. If your tutorial mentions it, the tutorial is 15 years old.
• magic_quotes_gpc – removed in PHP 5.4. Same.
• allow_url_include – should always be Off . Enabling it is a security hole.
• short_open_tag – WordPress core does not use short tags; plugins should not either.
• expose_php – nice-to-have (hides PHP version in HTTP headers), but not a real security measure because version info leaks elsewhere.
• output_buffering – WordPress has its own output handling. Leave at PHP default.
• session.* – WordPress does not use PHP sessions by default. Plugins that need them configure their own.

If a tutorial tells you to tweak more than the six settings in the reference table above, the tutorial is either outdated or solving a problem you probably do not have.

Common mistakes#

• Setting upload_max_filesize higher than post_max_size . Uploads fail silently because PHP discards the POST body before parsing. Always keep post_max_size at least 2x upload_max_filesize .
• Raising memory_limit to fix a bug that is really a plugin leak. A plugin in an infinite loop will fill 256M as quickly as it fills 64M. If raising the limit “works” at 512M but fails again at 2G, the problem is not memory – it is a plugin that needs to be found and replaced.
• Editing the wrong php.ini. PHP loads multiple files in order (main php.ini , scan directories, per-user overrides). A change in one file can be overridden by a later one. Verify your change actually took effect via Site Health or php -i .
• Enabling display_errors in production to debug an issue and forgetting to disable it. Error output in the page HTML exposes file paths, variable values, and sometimes database credentials to every visitor. Log errors to a file instead.
• Running PHP 7.4 in 2026 because “it still works.” It works until the first public PHP 7.4 exploit and a bot scans your server. End-of-life PHP is a security problem, not a cost savings.
• Not checking max_input_vars before importing 5,000 WooCommerce products. The import appears to succeed but drops a third of the products with no error. Set max_input_vars to 5000 or higher before bulk WooCommerce or large menu operations.

How Hostney handles this#

Hostney ships current PHP versions (5.6 through 8.5, selectable per site through the control panel) with easy switching that takes effect immediately. You can run different PHP versions on different subdomains of the same account, which is the right way to test a major PHP upgrade before committing the whole site to it.

Under Hosting > PHP Manager > Variables, the directives you can change per site are the ones that matter: max_execution_time , upload_max_filesize , post_max_size , max_input_vars , max_input_time , and related upload/execution settings. Changes apply immediately to the site’s PHP container – no restart, no support ticket.

One explicit design choice worth calling out: memory_limit is not user-configurable on the PHP Manager. It is managed at the platform level per container, sized to the plan. This is deliberate – raising memory_limit manually is usually the wrong fix (see the “common mistakes” section), and the platform-managed ceiling prevents a single misbehaving plugin from starving other processes on the server. If you hit memory issues, the right path is to find the plugin causing the leak, or to move to a plan with a larger memory allocation.

MySQL, nginx, and the HTTPS/TLS layer are all managed too – current MySQL versions, nginx with HTTP/3, automatic Let’s Encrypt SSL. You do not configure these; they come configured correctly. The container isolation means your PHP process and limits do not compete with other customers’ processes on the same server.

For the “does my install meet WordPress requirements” question: the dashboard surfaces your current PHP and MySQL versions alongside every WordPress install, and Tools > Site Health inside WordPress works the same way it does anywhere else.

Summary#

WordPress needs PHP 7.4+ (aim for 8.2+), MySQL 5.7+ or MariaDB 10.4+, HTTPS, and a web server. The PHP settings that matter in practice are memory_limit , max_execution_time , upload_max_filesize , post_max_size , max_input_vars , and max_input_time – six directives out of a hundred. Check current values from Tools > Site Health > Info. When a value needs to change, start at the hosting control panel and work down through wp-config.php, per-site php.ini, and .htaccess in that order. Most PHP directives are noise for WordPress and tutorials that tell you to tweak them extensively are usually outdated. If raising memory_limit “fixes” a problem until the problem comes back, the bug is not memory – find the plugin that is leaking.