Increase the All-in-One WP Migration upload limit for free

For years I migrated sites by hacking the same file. Open all-in-one-wp-migration/constants.php, find AI1WM_MAX_FILE_SIZE, change it to whatever I wanted, save. The 512 MB ceiling would vanish and a 3 GB backup would import without a fuss.

Then version 7.71 landed and the constant was gone. My clients started hitting the limit again. The old blog posts saying “just edit constants.php” stopped working overnight, and the workaround I’d been using for years was dead.

So I went looking for what controlled the limit after that. It was a JavaScript check in the browser, and I built a small free plugin that removes it.

Removing the check is only half the story. All-in-One WP Migration sends the whole backup to your server in one request, in 7.113 and in every free release I checked back to 6.77 from 2019.

When I tested it, a 36 MB backup sent to a server with an 8 MB limit failed to import. The page lets you pick the file, but the server drops it.

What works is putting the file on the server yourself and restoring it from the Backups page, which skips the upload completely.

What the uploader actually does

The import uploader lives in lib/view/assets/javascript/import.min.js. In 7.113 it puts the whole file into one FormData object and sends it to admin-ajax.php as a single POST:

const a=new FormData;a.append("upload_file",t);

The plugin still defines AI1WM_MAX_CHUNK_SIZE as 5 MB in constants.php and registers an ai1wm_max_chunk_size filter. Nothing in the import script reads either of them, in 7.113 or in any older free version I checked (6.77, 7.0, 7.40, 7.70, 7.71, 7.80, 7.97, 7.105, 7.110 and 7.112). The file goes up in one piece.

The size check before the upload is still there. The plugin passes wp_max_upload_size() to the page as ai1wm_uploader.max_file_size. WordPress computes that number as the smaller of upload_max_filesize and post_max_size, then runs it through the upload_size_limit filter (see the wp_max_upload_size() reference). So the limit on the import page is your server’s real limit.

On a stock install with both limits at 8 MB, picking a bigger file stops right away with this message:

Your file exceeds the 8 MB upload limit set by your host.
Our Unlimited Extension bypasses this!
If you prefer a manual fix, follow our step-by-step guide on raising your upload limit.

Versions up to 7.80 said it differently, and you’ll still see this one on sites that haven’t updated:

The file that you are trying to import is over the maximum upload file size limit of 512 MB.

Does removing the 512 MB check still work?

I set up a throwaway WordPress Playground site with upload_max_filesize and post_max_size at 8M, activated Upload Unlocker, and imported a 36 MB backup from another test site. The page said “Maximum upload file size: Unlimited.” and took the file. The progress bar reached 100%, because the browser had finished sending the bytes. Then PHP refused the request body:

PHP Warning: PHP Request Startup: POST Content-Length of 37924062 bytes exceeds the limit of 8388608 bytes in Unknown on line 0

That matches the PHP manual entry for post_max_size: when the post data is bigger than the limit, $_POST and $_FILES are empty. The plugin got a request with no file in it, went on to the next step anyway, and stopped there:

Import failed
Could not open file for reading. File: /wordpress/wp-content/plugins/all-in-one-wp-migration/storage/vx7xqo5vsgiu/oversized-site.wpress

That error sends you looking in the wrong place. Nothing was wrong with the file or the folder permissions. The file never arrived. If you see it right after the bar hits 100%, compare the backup size with post_max_size before anything else.

So on 7.113, removing the check only changes what you see before the upload. When your server limits are big enough, the check passes anyway. When they’re too small, removing it moves the failure from a clear message to a confusing one. I still ship it in Upload Unlocker, but Restore is the reason the plugin is useful now.

Import a backup bigger than your upload limit

The Backups page lists every .wpress file in wp-content/ai1wm-backups. Restore reads the file from that folder on the server. There’s no browser upload, so upload_max_filesize and post_max_size never come into it. On my test site the restore requests were a couple of hundred bytes each.

On the stock free plugin, Restore opens a notice instead. It says the feature is part of the paid Unlimited Extension, and suggests downloading the backup and using “Import from file”, which puts you back at the upload limit.

The Backups page script checks for three restore handlers before it falls back to that notice: Ai1wm.MultisiteExtensionRestore, Ai1wm.UnlimitedExtensionRestore, and Ai1wm.FreeExtensionRestore. The free plugin defines none of them. My plugin, Upload Unlocker for All in All Migration, defines the last one. It starts the plugin’s own import at step 10, right after the upload step (step 5), and sets ai1wm_manual_restore so the plugin reads the archive from the backups folder.

The steps I used on the destination site:

1. Install and activate All-in-One WP Migration.
2. Download the Upload Unlocker zip, then go to Plugins, Add New, Upload Plugin, and activate it.
3. Go to All-in-One WP Migration, Backups, click Upload backup, and pick your .wpress file. It goes up in pieces of up to 5 MB, each under your server’s upload limit, and the backup shows up in the list when it’s done.
4. Click the three dots next to your file and choose Restore.
5. Click Proceed on the confirmation and wait for the success message.

If your server’s upload limit is under 1 MB, the button shows a note instead. In that case, or if you use the snippet below, copy the .wpress file into wp-content/ai1wm-backups with SFTP or your host’s file manager, then restore it. That copy doesn’t go through PHP, so PHP’s upload limits don’t apply.

On the 8 MB test site, Upload Unlocker sent the 36 MB backup in 8 pieces, and the file on the server matched the original byte for byte. The restore finished in under 30 seconds.

Afterwards the destination had the source site’s marker post, a custom option I’d added, and the 20 MB file from its uploads folder. I also ran the restore with the snippet and a backup copied over SFTP, and got the same result.

After a restore, the plugin list matches the source site, so if Upload Unlocker wasn’t active there, it won’t be active here either. Activate it again before the next restore. And the .wpress file stays in the backups folder, so delete it from the Backups page once you’ve checked the site, since it’s a full copy of your site.

If All-in-One WP Migration isn’t active, Upload Unlocker shows a warning notice and does nothing, so you can leave it installed. It changes no plugin files. Everything goes through WordPress hooks.

The snippet version if you’d rather not add another plugin

The snippet turns on Restore and lifts the import page check, like the plugin, but it doesn’t add the Upload backup button. With the snippet, copy the backup to the server over SFTP first. Drop it in a child theme’s functions.php, use a code snippets plugin like SnipDrop or WPCode, or save it as wp-content/mu-plugins/ai1wm-unlock.php so it survives theme switches. I tested it as a must-use plugin.

<?php
// Practical ceiling for the JS gate. JavaScript's Number.MAX_SAFE_INTEGER,
// so the value stays exact when it crosses the PHP-to-JS boundary.
const AI1WM_UNLOCK_LIMIT = 9007199254740991;

add_filter( 'upload_size_limit', function ( $limit ) {
    if ( ! ai1wm_unlock_is_migration_screen() ) {
        return $limit;
    }
    return max( (int) $limit, AI1WM_UNLOCK_LIMIT );
} );

add_filter( 'ai1wm_pro', function () {
    return '<p class="max-upload-size">Maximum upload file size: Unlimited.</p>';
}, 20 );

add_action( 'admin_enqueue_scripts', function () {
    if ( ! ai1wm_unlock_is_migration_screen() ) {
        return;
    }
    if ( wp_script_is( 'ai1wm_import', 'enqueued' ) || wp_script_is( 'ai1wm_import', 'registered' ) ) {
        wp_add_inline_script(
            'ai1wm_import',
            'if(typeof ai1wm_uploader!=="undefined"){ai1wm_uploader.max_file_size=Math.max(ai1wm_uploader.max_file_size,' . AI1WM_UNLOCK_LIMIT . ');}',
            'after'
        );
    }
    if ( wp_script_is( 'ai1wm_backups', 'enqueued' ) || wp_script_is( 'ai1wm_backups', 'registered' ) ) {
        $js = '(function(){if(typeof Ai1wm==="undefined"||typeof Ai1wm.Import==="undefined")return;'
            . 'Ai1wm.FreeExtensionRestore=function(a){var m=new Ai1wm.Import();'
            . 'm.setParams([{name:"storage",value:Date.now().toString()},{name:"archive",value:a},{name:"ai1wm_manual_restore",value:"1"}]);'
            . 'm.start([{name:"priority",value:10}]);};})();';
        wp_add_inline_script( 'ai1wm_backups', $js, 'after' );
    }
}, 99 );

add_action( 'current_screen', function () {
    if ( ai1wm_unlock_is_migration_screen() ) {
        wp_raise_memory_limit( 'admin' );
    }
} );

function ai1wm_unlock_is_migration_screen() {
    if ( ! function_exists( 'get_current_screen' ) ) {
        return false;
    }
    $screen = get_current_screen();
    return $screen && false !== strpos( $screen->id, 'ai1wm' );
}

The part that matters for Restore is the ai1wm_backups block. It defines Ai1wm.FreeExtensionRestore and starts the import at step 10. The upload_size_limit filter, the ai1wm_pro filter and the ai1wm_import line only change what the import page shows. As the test above showed, they don’t get a big file past the server.

The number 9007199254740991 is Number.MAX_SAFE_INTEGER in JavaScript, the biggest whole number that stays exact when it goes from PHP to the page. It only needs to be big enough that the check never trips.

The ai1wm_unlock_is_migration_screen() check keeps all of this on All-in-One WP Migration admin pages. Your Media Library and every other upload screen keep the normal limit.

The memory line runs when an All-in-One WP Migration admin page loads. The import steps themselves run through admin-ajax.php, which doesn’t load an admin screen, so don’t count on it for a big import. I don’t raise max_execution_time either, because the plugin’s ai1wm_setup_environment() already calls set_time_limit( 0 ) at the start of every import request.

Raise upload_max_filesize and post_max_size

If you’d rather use “Import from file” in the browser, the server has to accept the whole backup in one request. That means both upload_max_filesize and post_max_size have to be bigger than the backup. The PHP manual says post_max_size must be larger than upload_max_filesize, and the request carries a little form data on top of the file (642 extra bytes in my test), so set it a bit higher.

On the same test site I raised both to 64M and imported the 36 MB backup in the browser. It worked with Upload Unlocker off and again with it on. You can check your current values under Tools, Site Health, Info, Server, where WordPress lists “Upload max filesize” and “PHP post max size”.

If your host lets you change them, the usual place is .htaccess at the WordPress root. Turn on “show hidden files” in your host’s file manager to see it.

Then edit .htaccess and add the values at the bottom.

Pick numbers above your backup size. For a backup under 1 GB, for example:

php_value upload_max_filesize 1024M
php_value post_max_size 1100M

These php_value lines only work when PHP runs as an Apache module (PHP manual). If your host runs PHP-FPM or another CGI or FastCGI setup, use a .user.ini file in the WordPress root instead:

upload_max_filesize = 1024M
post_max_size = 1100M

PHP re-reads .user.ini every 300 seconds by default (PHP manual), so give it five minutes before you try again. Many managed hosts ignore both files and set these limits in their own panel, so check there or ask their support if Site Health still shows the old values.

Nginx and Cloudflare can refuse a big request too:

• Nginx rejects any request body bigger than client_max_body_size with a 413 error, and its default is 1 MB. The 7.113 uploader turns a 413 into the “Your file exceeds the upload limit set by your host web server” message.
• If the site sits behind Cloudflare, its maximum upload size is 100 MB on the Free and Pro plans and 200 MB on Business. A bigger request gets a 413, whatever PHP allows.

Restore itself doesn’t hit either of these, because it reads the backup from the server. The Upload backup button does send the file over HTTP, in pieces of up to 5 MB sized to PHP’s limits.

If the web server turns a piece down with a 413, like nginx does at its 1 MB default, the button halves the piece and sends it again, down to 256 KB, then keeps that size for the rest of the upload. I tested it behind nginx at 1 MB: it dropped from 5 MB to 640 KB pieces, and the 36 MB backup restored fully.

If even 256 KB is turned down, it stops and tells you to ask your host to raise the limit or to copy the file over SFTP.

Why the old constants.php hack stopped working

The old fix edited a constant called AI1WM_MAX_FILE_SIZE in the plugin’s constants.php. Before version 7.71, that constant fed the displayed limit and the JS check. Bump the constant, both went up.

After 7.71 the constant was gone. In 7.113 the limit on the import page comes straight from wp_max_upload_size(), and the plugin prints it through its ai1wm_pro filter with an upsell for the paid extension:

Your host restricts uploads to 8 MB. Our Unlimited Extension bypasses this!
If you prefer a manual fix, follow our step-by-step guide on raising your upload limit.

If you’re reading an old tutorial that tells you to edit constants.php, you’ll open the file, find nothing to edit, and wonder if the plugin was updated under you. It was.

If the restore or import still fails

The upload limit is only the first wall. If the restore or the browser import gets past 100% and then hangs on a step, that’s a memory, folder permission or timeout problem on the destination server. I traced those in the post on All-in-One WP Migration imports stuck at 100%, with the error log lines and the fix for each.

If the Import page still shows the old limit after you install Upload Unlocker, hard-refresh the page or open it in a private window. The inline script runs on every page load, so a fresh load is enough.

If the import finishes but images are broken on the new site, that’s usually the upload path error.

If Restore goes back to showing the paid-extension notice after a plugin update, ServMask has probably renamed Ai1wm.FreeExtensionRestore or changed how the Backups page picks a restore handler. Nothing on your site breaks, and no plugin files were ever changed. Restore just stays locked until I update Upload Unlocker and the snippet.

A smaller backup is often the quickest win either way. I wrote a companion post on excluding files and folders from All-in-One WP Migration exports that walks through the four exclude hooks the plugin exposes.

For years I told clients the 512 MB message wasn’t a real wall. On 7.113 it is, because the file goes up in one request. So I’ve stopped fighting the upload. If I can’t raise the server limit, I upload the backup from the Backups page in pieces and restore it there.