Fix WordPress Demo Import Timeout and Memory Errors on Envato Themes

You hit “Import Demo Data” on your new Envato theme, watch the progress bar freeze solid at 28%, and get smacked with a 504 Gateway Time-out or Fatal error: Allowed memory size exhausted. I’ve lost count of how many ThemeForest setups break right here. Here’s how to dial in your PHP resource limits, configure web server timeouts, and pull in heavy demo packages without crashing or bloating your database with duplicates.

Most multipurpose Envato themes pack dozens of full-page layouts, Slider Revolution archives, hundreds of high-res media files, and full WooCommerce product tables into a single installer. Shared hosting defaults are built for quick, lightweight page views—not chewing through 300MB of remote assets inside one continuous PHP thread. When the runtime runs out of RAM or hits its execution ceiling, the import dies mid-flight.

Why Envato Theme Demo Importers Fail on Default Hosting

When you fire off a one-click demo import in themes like Avada, Betheme, WoodMart, or Salient, the theme runs an AJAX worker or a bulk background script that executes several heavy jobs back-to-back:

• Pulls hundreds of remote media assets from the developer’s Amazon S3 or CDN buckets.
• Regenerates 5 to 10 image thumbnails per file for responsive image sizes.
• Parses massive WXR (WordPress eXtended RSS) XML files packed with thousands of posts, terms, and custom post types.
• Deserializes and writes custom widget options, Elementor/WPBakery page builder data, and theme options directly into the wp_options table.

Standard shared hosting is usually throttled to memory_limit = 128M and max_execution_time = 30. A full demo import generally demands at least 512MB of RAM and 300 to 600 seconds of runtime. If you’re hitting upload limits earlier during theme installation itself, check out our guide on how to fix ‘The Link You Followed Has Expired’ in WordPress before tweaking memory ceilings.

Step 1: Increase PHP Memory Limit in wp-config.php

WordPress enforces its own internal PHP memory limit, which often sits lower than your server’s master PHP allocation. By default, WordPress caps admin operations at 256MB and frontend requests at 40MB.

Connect to your site’s root directory via SFTP, SSH, or your host’s file manager. Open wp-config.php and add these directives right above the line that reads /* That's all, stop editing! Happy publishing. */:

// Define WordPress runtime memory limits
define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '768M' );

WP_MEMORY_LIMIT handles regular frontend and background tasks, while WP_MAX_MEMORY_LIMIT covers admin operations like batch imports and database migrations. For more background on these constants, check the WordPress wp-config.php documentation.

Step 2: Adjust Execution Time and Input Variables in .user.ini or php.ini

Raising memory limits in wp-config.php won’t save you if PHP kills the script after 30 seconds. You need to adjust your execution times and input variables directly in your PHP config.

If your host runs PHP via FastCGI or PHP-FPM (standard on modern cPanel, Plesk, and hPanel setups), create or edit a .user.ini file in your public_html root directory:

upload_max_filesize = 128M
post_max_size = 128M
memory_limit = 512M
max_execution_time = 600
max_input_time = 600
max_input_vars = 5000

If your server uses Apache with mod_php, add these lines to the top of your .htaccess file instead:

 php_value memory_limit 512M php_value max_execution_time 600 php_value max_input_time 600 php_value max_input_vars 5000 php_value post_max_size 128M php_value upload_max_filesize 128M
  php_value memory_limit 512M php_value max_execution_time 600 php_value max_input_time 600 php_value max_input_vars 5000 php_value post_max_size 128M php_value upload_max_filesize 128M

The max_input_vars directive is critical here. Envato themes import massive navigation menus and nested options tables. If max_input_vars stays at the default 1000, PHP quietly drops menu items during the import loop without throwing an obvious error. You can verify available settings in the PHP core runtime configuration manual.

Step 3: Fix Nginx and FastCGI 504 Gateway Timeouts

If you manage your own VPS or your host runs an Nginx reverse proxy in front of Apache or PHP-FPM, you can still run into a 504 Gateway Time-out even with PHP set to 600 seconds. Nginx cuts the connection if the upstream FastCGI process doesn’t send back data within 60 seconds.

Open your Nginx server block config (usually in /etc/nginx/sites-available/your-domain.com or /etc/nginx/conf.d/default.conf):

sudo nano /etc/nginx/sites-available/your-domain.com

Add these timeout buffers inside your location ~ .php$ block or your primary server block:

location ~ .php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php8.2-fpm.sock; # Increase upstream timeouts for long demo imports fastcgi_connect_timeout 300s; fastcgi_send_timeout 300s; fastcgi_read_timeout 600s; proxy_connect_timeout 300s; proxy_send_timeout 300s; proxy_read_timeout 600s;
}

Check your configuration syntax and reload Nginx:

sudo nginx -t && sudo systemctl reload nginx

For more details on buffering and upstream connection parameters, see the official Nginx FastCGI module documentation.

Step 4: Increase MySQL Packet Size to Prevent Database Drops

Complex demo packages frequently dump base64-encoded slider assets and large serialized JSON objects into wp_options and wp_posts. If a single SQL query exceeds MySQL’s packet size limit, the connection drops with a MySQL server has gone away error.

If you have root access to MySQL or MariaDB, open your configuration file (typically /etc/mysql/my.cnf or /etc/mysql/mariadb.conf.d/50-server.cnf):

[mysqld]
max_allowed_packet = 128M
wait_timeout = 600
interactive_timeout = 600

Restart the MySQL service to apply the change:

sudo systemctl restart mysql

If you run into file permission issues or storage limits during heavy imports, see our troubleshooting guide on how to fix ‘Upload: Failed to Write File to Disk’ in WordPress.

Step 5: Clean Up Half-Imported Content Before Retrying

Never re-run an importer on top of a failed attempt. If the process died at 40%, running it again will duplicate your menus, clutter the media library, and orphan rows in the database.

If you’re working on a fresh staging build, use WP-CLI to wipe the database back to clean in seconds:

# Reset the database completely
wp db reset --yes # Re-run standard WordPress core installation
wp core install  --url="https://example.com"  --title="Staging Site"  --admin_user="devadmin"  --admin_password="SuperSecretPass123!"  --admin_email="dev@example.com"

If you don’t have SSH access, grab the free WP Reset plugin from the repository, wipe the database tables, reactivate your theme, and run the import cleanly. If you have an existing database dump to restore, check out our guide on how to import a large WordPress database via SSH.

Step 6: Import via WP-CLI When Web Importers Keep Crashing

Browser-based importers are always vulnerable to HTTP timeouts and dropped AJAX connections. If you’re on a locked-down host that blocks custom PHP settings or drops long-running requests, the command line avoids the web server entirely.

Most Envato themes store their demo files inside the theme directory under wp-content/themes/theme-name/inc/demos/ or include a standalone demo-content.xml file inside the main ZIP package.

To import the XML file directly with WP-CLI and bypass browser limits entirely, run:

# Ensure the wordpress-importer plugin is installed
wp plugin install wordpress-importer --activate # Run the import with attachment downloads enabled
wp import /path/to/demo-content.xml --authors=create

For themes powered by the One Click Demo

Import (OCDI) framework, you can run the full demo import using their CLI hook:

wp ocdi import --demo=0

If you need a complete walkthrough on setting up parent and child themes before pulling demo assets, take a look at our guide on how to install an Envato WordPress theme and import demo content.

Verifying Your Active Server Values

Before launching the demo import again, confirm that WordPress actually sees your updated limits:

1. Log into your WordPress admin dashboard.
2. Go to Tools > Site Health.
3. Open the Info tab and expand the Server panel.
4. Check the values for PHP memory limit (512M), PHP time limit (600), and PHP max input variables (5000).
5. Expand the WordPress Constants panel and verify that WP_MAX_MEMORY_LIMIT shows 768M.

If Site Health reports lower numbers than what you configured in .user.ini or wp-config.php, your host is likely enforcing a hard override via CloudLinux or cPanel’s MultiPHP INI manager.

Frequently Asked Questions

Why does my demo import always stall at the exact same percentage?

Stalling at an exact percentage (like 30% or 70%) points to a hard server boundary. If it freezes after roughly 30 to 60 seconds, you hit an Apache or Nginx timeout. If it stalls while generating thumbnails, the server ran out of RAM or choked downloading a remote asset blocked by a firewall.

Does increasing PHP memory slow down my server for visitors?

No. The memory_limit setting in PHP is an upper ceiling, not reserved memory. A normal visitor viewing a blog post will still only consume 20MB to 40MB of RAM. The 512MB ceiling only gets utilized when heavy jobs—like image resampling or batch XML parsing—actually need it.

Why are images missing after the demo import shows a success message?

Many Envato theme authors can’t legally redistribute copyrighted stock photos inside the demo files. Instead, the importer generates blank gray placeholder images matching the exact layout dimensions. Check the theme’s documentation to see if stock photos are excluded from the demo package.

Can I lower the PHP limits back down after the demo finishes?

Yes. Once your demo content, widgets, menus, and sliders are in place, you can safely drop max_execution_time back to 60 and memory_limit to 256M to prevent misbehaving plugins from consuming excessive resources down the road.

Next Steps

Once your demo content is imported and working, make sure your caching layer is dialed in so pages load instantly. Read our guide on how to configure CDN edge cache rules for WordPress cookies and dynamic URLs to keep TTFB low across all your new pages.