WP Configurator Pro works on ordinary WordPress hosting, but a few PHP settings decide whether large configurators save cleanly, whether big layer images can be uploaded, and how much room an import has to work in.
This page covers the settings themselves. For anything specific to moving configurators between sites.
See Import & Export Configurators
System requirements
| WordPress | 5.6 or higher |
| PHP | 7.4 or higher |
| WooCommerce (optional) | 9.6 or higher |
Checking your current configuration
Go to Configurator → Status. The page reports your site’s live values and flags anything that is too low:
- PHP version
- WordPress memory limit
- PHP post max size
- PHP time limit
- PHP max input vars
- Max upload size
- Background processing (3.9.0 and later) — Action Scheduler, WP-Cron, and the import queue.
Start here before changing anything. There is no point raising a limit your host has already set generously.
The settings that matter
memory limit
Recommended: 256M. The plugin warns below 64M.
Memory is consumed by the largest single image being processed, not by the total. A 6000 × 4000 pixel photo needs well over 100 MB to open and resize, even though the JPEG on disk is only 3 MB.
Symptoms of a limit that is too low: a white screen when activating the plugin, a failure when saving a configurator with many layers, or an import that dies part way through.
max_input_vars
Recommended: 20000. PHP’s default is 1000.
Every element of a configurator — each group, sub-group, layer and option — travels as its own field when you save. Once the count passes max_input_vars, PHP silently discards the rest. There is no error. The save appears to succeed and layers or options are simply missing afterwards. If elements disappear after saving a large configurator, this is almost always the cause.
upload_max_filesize and post_max_size
Recommended: 64M for both.
These two work together, and the effective limit is whichever is smaller:
upload_max_filesizecaps a single uploaded file.post_max_sizethe entire request, so it must always be equal to or
larger than upload_max_filesize.
They apply both to layer images and to .json/.zip files uploaded on the import screen.
max_execution_time
Recommended: 300.
How long PHP will let a single request run. It matters most during imports.
- On 3.8.6 and earlier, the entire import happens in one request, so this value has to cover the whole job. See Option 1 in the import guide.
- On 3.9.0 and later, imports run in the background in short tasks, and this value largely stops mattering. See Option 2.
Note that PHP is not the only clock. Under PHP-FPM, the web server has its own timeout (fastcgi_read_timeout in nginx, max_execution_time.
Recommended php.ini settings
ini
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
max_input_vars = 20000Where to change them
Pick whichever of these you have access to. The first that works, wins.
Hosting control panel — the usual route on shared hosting:
- cPanel: MultiPHP INI Editor
- Plesk: PHP Settings
- Most managed hosts have an equivalent panel
php.ini — if you can edit it directly, use the block above.
.htaccess (Apache with mod_php only; ignored under PHP-FPM):
apache
php_value memory_limit 256M
php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value max_input_vars 20000wp-config.php — raises WordPress’s own memory limit only. It cannot raise upload sizes, execution time or input vars:
php
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );Ask your host. If none of the above is available, hosting support can apply these values for you. They are routine requests and well within normal shared hosting allowances.
After making a change, reload Configurator → Status and confirm the new values are actually in effect. Some hosts cap what a site can set for itself.
Background processing (3.9.0 and later)
From 3.9.0 the plugin runs imports on a queue instead of in a single request, so a low max_execution_time no longer decides whether an import finishes. That moves the requirement elsewhere: the queue has to be able to run.
Configurator → Status → Background processing reports:
- Whether Action Scheduler is loaded, its version, and which plugin provides it
- Whether WP-Cron can drive the queue
- How many import tasks are pending or failed
- A link to the Scheduled Actions screen
If WP-Cron is disabled and no system cron is calling wp-cron.php, background imports only advance while the import progress panel is open in a browser. The Status page says so when this applies.
The queue and its behaviour are covered in full in Import & Export Configurators
See also
- Import & Export Configurators
- Configurator → Status — your current values
- Configurator → Logs — enable debug logging when diagnosing a failure