Import & Export Configurators - documentation.wpconfigurator.com

Export lets you move a configurator out of one site as a file. Import loads that
file into another site — a staging copy, a client’s site, or a fresh install —
and rebuilds the configurator there, images included.

Short on time? Skip to Two ways to handle a large import. That is the section that matters once a configurator carries more than a hundred or so
images.

What is actually inside an export file

This one fact explains almost everything else on this page:

An export contains your configurator’s settings and the web addresses of its images. It does not contain the image files themselves.

A .json export of a 400-image configurator is often under 1 MB. The images stay
where they are, on the source site. When you import that file, the receiving site
downloads all 400 images over HTTP, one at a time, and adds each one to its own
media library.

Three consequences follow:

Import time depends on the number of images and the speed of the source server, not on the size of the file you uploaded. A 300 KB file can take ten
minutes to import.
The source site has to stay online and publicly reachable for the whole
import. If it is behind a password, a firewall, a “coming soon” plugin, or a
local-only address such as mysite.local, the receiving site cannot fetch the
images.
A long import is a long series of downloads. That is what runs into PHP’s
execution time limit, and it is the problem the two options below solve.

Exporting

One configurator

Go to Configurator → All configurators.
Hover the row you want and click Export Template.
A .json file downloads.

Several at once

Go to Configurator → All configurators.
Tick the configurators you want.
Choose Export from the Bulk actions dropdown and click Apply.
A .zip file downloads, holding one .json per configurator.

The .zip is just a container. Importing the ZIP is the same as importing each
JSON in turn.

What is not carried over

An export describes the configurator. It does not carry the rest of your site
with it, so after importing you will still need to:

Re-link the configurator to a WooCommerce product on the new site, if you use
the WooCommerce integration.
Recreate any page or shortcode that displayed it.
Check plugin settings that live outside the configurator (e-mail templates,
currency, tax) — those are site-wide, not per-configurator.

Importing

Go to Configurator → All configurators.
Click Import Configurators at the top of the list.
Choose a .json file or a .zip archive.
Click Import Now.

Accepted files

File types	`.json` and `.zip` only
Default size limit	64 MB (also capped by your server’s `upload_max_filesize` and `post_max_size`)
ZIP contents	Any number of `.json` exports, including ones inside subfolders

If a ZIP holds ten configurators, you get ten configurators. Each one is imported
on its own, so a problem with one does not discard the other nine.

What happens next

The file is validated and stored.
For each configurator in it: a post is created, then every image referenced in
its layers, options and views is downloaded from the source site and added to
your media library.
The saved settings are rewritten to point at the new local attachment IDs.
The configurator becomes editable.

Step 2 is where all the time goes.

Two ways to handle a large import

Which one applies to you depends on your plugin version.

	Option 1 — Raise the server limits	Option 2 — Import in the background
Plugin version	Any version. The only choice on 3.8.6 and earlier.	3.9.0 and later
How it works	The whole import runs in one long page request, so the request is given enough time and memory to finish.	The import is split into many short tasks that run on a queue. No single request has to finish it.
Needs hosting changes	Yes — `max_execution_time`, `memory_limit` and friends	No
Browser must stay open	Yes. Closing the tab kills the import.	No. It continues without you.
Progress visible	No — a spinner until it finishes or dies	Yes — a live progress panel
If one image fails	The whole import stops	That image is reported; the rest continues
Can be retried	Re-upload and start again	Try again button; already-imported work is kept

If you are on 3.9.0 or later, Option 2 is already switched on and you do not
need to do anything. Option 1 remains useful there for a different reason: a
comfortable memory_limit still helps when the source images are very large.

Option 1 — Give the import more server resources

Use this on WP Configurator Pro 3.8.6 and earlier.

In those versions the entire import — unzipping, decoding, downloading every
image, generating every thumbnail size, writing every meta value — happens inside
the single page request that starts when you click Import Now.

PHP stops any request that runs past max_execution_time. Shared hosting commonly
sets that to 30 or 60 seconds. At roughly one second per image (download plus
thumbnail generation for every registered image size), an import of 200 images
needs several minutes and will be killed long before it finishes. The symptom is
a spinner that never resolves, a blank page, or a 504 from the web server — and a
half-imported configurator left behind.

Raising the limits gives the request room to complete.

Recommended values

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
max_input_vars = 20000

Scale max_execution_time and memory_limit up with the number of images:

Images in the configurator	Typical import time	`max_execution_time`	`memory_limit`
Up to 100	Under 1 minute	300	256M
100–500	1–8 minutes	600	256M
500–1500	8–25 minutes	900	512M
1500+	25 minutes and up	900	512M, and import in batches

memory_limit is driven by the largest single image, not the total. A
6000 × 4000 pixel photo needs well over 100 MB to process even when the JPEG on
disk is only 3 MB.

See Server Configuration Setting for what each
directive does and where to change it.

Things that can still stop the import

Your host may ignore the plugin’s own attempt to raise the limits. The
plugin asks PHP for more headroom when an import starts, but many hosts disable
that. Setting the values in php.ini — or through your hosting control panel —
is what actually works.
The web server has its own timeout. Under PHP-FPM, nginx’s
fastcgi_read_timeout or Apache’s ProxyTimeout will cut the connection at
its own limit no matter how high max_execution_time goes. If the import dies
at a suspiciously round number of seconds, this is usually why.
The browser tab must stay open. The import is that request. Closing the
tab, sleeping the laptop, or losing Wi-Fi ends it.

If you cannot change the server at all

Split the work instead of extending it:

On the source site, export configurators individually rather than as one
bulk ZIP.
Import them one at a time.
For a single configurator that is too big on its own, reduce the image count
temporarily — export, import, then add the remaining layers by hand.

Or upgrade to 3.9.0, where this stops being your problem.

Option 2 — Import in the background

Available from WP Configurator Pro 3.9.0. It is on by default; there is no
setting to switch on.

The import no longer runs in your page request. Uploading the file only queues
the work, and the page comes straight back. From there the import is carried out
by a queue — Action Scheduler, the same scheduler WooCommerce uses — which
fetches about five images per task and hands off to the next task before PHP’s
time limit is anywhere near. A server capped at 10 seconds can complete an import
that represents ten minutes of total work.

Because images are streamed to disk rather than held in memory, a low
memory_limit also stops being the deciding factor.

What you see

A progress panel appears at the top of the configurator list:

Overall progress, and each configurator ticked off as it completes.
Any images that could not be fetched, with the reason.
Cancel import — stop here and keep what has been imported so far.
Try again — appears if the import failed or finished with problems.
Reload the list — appears when everything is done.

You can navigate away, close the tab, or shut the laptop. The import carries on.
Leaving the panel open simply makes it finish sooner, because each progress check
also nudges the queue along.

Creating a configurator from a bundled demo works the same way. The editor opens
immediately, shows its own progress, and refreshes itself once the images have
landed. The bundled demos carry over 50 images each, which used to be enough to
time out on a slow host.

Requirements

Requirement	Why	Where to check
Action Scheduler loaded	Runs the queue	Configurator → Status → Background processing
WP-Cron enabled, or a real system cron calling `wp-cron.php`	Drives the queue when no one is watching	Same section

The plugin bundles its own copy of Action Scheduler, so nothing needs installing.
If another plugin on the site ships a newer copy, WordPress uses that one — the
Status page names which plugin is providing it.

If WP-Cron is disabled (DISABLE_WP_CRON set to true, common on hosts that
run a system cron instead) and no system cron is configured, background imports
only advance while the progress panel is open. They will not finish on their own.
The Status page flags this explicitly.

If Action Scheduler is unusable, the plugin falls back to the old
single-request import automatically — which puts you back in Option 1 territory,
so raise the server limits in that case.

Keeping an eye on it

Where	Shows
Configurator → Status → Background processing	Action Scheduler version and which plugin provides it, whether WP-Cron can drive the queue, how many import tasks are pending or failed, and a link to the Scheduled Actions screen
Configurator → Tools → Recent imports	The last 20 imports with their outcome, counts and first recorded problem
Tools → Scheduled Actions	The queue itself — every scheduled, running and failed action

Some plugins hide the Scheduled Actions item from the Tools menu (WPForms
does by default). Use the link on the Status page instead; it says so when this
has happened.

When images fail

A single unreachable image no longer aborts the import. It is reported, the layer
keeps its original reference so the gap is visible in the editor, and the rest of
the import continues.

Temporary failures — a timeout, a refused connection — are retried up to three
times. Problems that cannot resolve themselves, such as an untrusted certificate
or a hostname that does not exist, are reported straight away rather than retried.

If the first ten images all fail for the same reason, the import stops and says
so, rather than working through hundreds of images to reach the same conclusion.
Repeated identical problems are grouped in the report with a count and a few
example URLs.

“cURL error 60” — untrusted certificate

The most common import failure. It means the receiving site does not trust the
HTTPS certificate on the source site. Typical causes:

A self-signed certificate, standard on staging and local sites.
A missing intermediate certificate in the chain.
http:// image URLs where the source server redirects to https:// — the
redirect lands on the same untrusted certificate.

How to resolve it, in order of preference:

Fix the certificate on the source site and retry. Best outcome, and it fixes
the source site for everyone else too.
Click Try again, trusting the source site in the progress panel. This
trusts that one host, for that one import only. It is never enabled ahead of
time and does not persist.
Export from a site with a valid certificate instead.

Retry within 24 hours. The uploaded file and its working files are cleaned up
a day after the import starts, after which you would need to upload again.

Report	Meaning	Fix
404 / not found	The image was deleted from the source site, or the export is stale	Re-export from the source, or replace the image in the editor after importing
Connection refused / timed out	Source site down, firewalled, or behind a “coming soon” page	Make the source publicly reachable and retry
Invalid file type	WordPress does not accept that file type for upload	Convert the image, or allow the type via an upload-filetypes filter
Hostname does not exist	The export came from a local address such as `mysite.local`	Export from a publicly reachable copy of the site

Troubleshooting

The import spinner never finishes (3.8.6 and earlier).
The request was killed. Raise max_execution_time and memory_limit per
Option 1, or upgrade to 3.9.0.

“The import file is larger than the 64 MB limit.”
Export in smaller groups. The limit can also be raised with the
wpc_import_max_upload_size filter, but a 64 MB export is unusual — check that
you exported configurators and not a full site backup.

“Only .json and .zip configurator files can be imported.”
The file is not a WP Configurator export. A .wpress, .xml or .sql file will
not work.

The import panel sits at 0% and never moves (3.9.0+).
The queue is not running. Check Configurator → Status → Background processing for a WP-Cron warning, and confirm Action Scheduler is loaded.

Layers or options disappear after saving a large configurator.
Not an import problem — this is max_input_vars. See
Server Configuration Setting.

The configurator imported but the preview is broken.
Run Configurator → Tools → Reset Preview Image → Rebuild Image Data against it.

Imports fail only on staging.
Almost always the certificate. See
cURL error 60.

Developer reference

Filters and actions added in 3.9.0. Put these in a site-specific plugin or your
theme’s functions.php.

Filter	Default	Purpose
`wpc_import_use_background`	`true`	Set to `false` to force the old single-request import
`wpc_import_image_batch_size`	`5`	Images fetched per queued task
`wpc_import_batch_time_budget`	60% of `max_execution_time`, clamped to 5–20 seconds	Wall-clock budget for one task
`wpc_import_image_timeout`	`15`	Seconds to wait for a single image
`wpc_import_image_max_attempts`	`3`	Retries for a transient image failure
`wpc_import_systematic_failure_threshold`	`10`	Consecutive identical failures before giving up
`wpc_import_max_upload_size`	64 MB	Largest accepted import file, in bytes
`wpc_import_memory_limit`	—	Memory limit requested for the import
`wpc_import_ssl_verify`	`true` unless the host was explicitly trusted for this job	Certificate verification per image URL

Action	Fires
`wpc_import_job_completed`	When a background import finishes
`wpc_after_import_configurator`	After each configurator is imported

Example — a slower source server needs more patience per image:

add_filter( 'wpc_import_image_timeout', function () {
    return 30;
} );

Example — trust a specific staging host during an import:

add_filter( 'wpc_import_ssl_verify', function ( $verify, $url ) {
    if ( false !== strpos( $url, 'staging.example.com' ) ) {
        return false;
    }

    return $verify;
}, 10, 2 );

Prefer the Try again, trusting the source site button where you can — it is
scoped to one import instead of every import forever.

WP Configurator Pro