“The link you followed has expired” in WordPress: the upload limit behind it

What does “The link you followed has expired” mean in WordPress?

It usually means your upload was too big for PHP. The message comes from WordPress’s security check on admin forms, which is only the messenger.

When a request is larger than PHP’s post_max_size, PHP empties the form data before WordPress reads it. The PHP manual says so directly: the $_POST and $_FILES superglobals are empty. The security token goes with them, the check fails, and WordPress prints the expired-link page from wp_nonce_ays().

Upload faults like this are one of the fixes on our WordPress care and fixes page, where we work on a copy of the site first.

How did we test it?

On 13 Oct 2026 we ran WordPress 6.9.4 on PHP 8.2 and Apache in Docker, with a MariaDB 11 database. The server had PHP’s stock limits: upload_max_filesize 2M and post_max_size 8M.

A script logged in as an admin and uploaded three plugin zips through Plugins > Add New > Upload: a 214-byte plugin, a 3 MB one and a 9 MB one. It sent the two large zips through the plain form on Media > Add New too, and recorded the status and page text each time.

What did each upload size show?

The 9 MB page gives no hint about size. The Apache error log does: “PHP Warning: POST Content-Length of 9438127 bytes exceeds the limit of 8388608 bytes”. If your host gives you error logs, that line names the cause.

Which fixes raised the maximum upload size?

We set each fix to 16M for uploads and 20M for posts, then ran the same uploads again.

Why did wp-config.php and .user.ini not work?

PHP will not let ini_set change these two settings at all. The PHP manual marks upload_max_filesize and post_max_size as PHP_INI_PERDIR, which means php.ini, .htaccess, httpd.conf or .user.ini only. The upload is also read before WordPress loads, so wp-config.php would be too late even if PHP allowed it. On our server the limit stayed at 2 MB with the lines in place.

.user.ini is a different story. The PHP manual on .user.ini files says PHP reads them only under the CGI/FastCGI SAPI. Our server ran PHP as an Apache module, so it ignored the file. On a host that runs PHP-FPM it may well work. We did not test that.

The .htaccess lines work the other way round. They need PHP running as an Apache module, which is what we had. We did not try them on any other setup, so test them on a copy of the site first.

Why is raising upload_max_filesize alone not enough?

Because the expired-link error comes from post_max_size. We raised upload_max_filesize to 16M and left post_max_size at 8M. The 3 MB zip installed; the 9 MB zip still said “The link you followed has expired.”

WordPress showed 8 MB as the maximum upload size in that state. wp_max_upload_size() takes the smaller of the two values, so the number on Media > Add New is the one to trust.

How do you fix “The link you followed has expired”?

1. Check the size of the file you are uploading.
2. Open Media > Add New and read “Maximum upload file size”.
3. If the file is bigger, raise post_max_size and upload_max_filesize together, with post_max_size the larger of the two. If your host has a PHP settings screen, change them there; otherwise they go in php.ini.
4. Restart PHP or ask the host to, then read the Media > Add New line again before you retry the upload.

Step 4 saved us from a false result. The first time we raised the limits, the page still said 2 MB: our new settings file had not reached the server at all. We only trusted a fix once the number on that page moved.

If you cannot change PHP settings, you can also upload the plugin or theme folder over SFTP into wp-content and activate it from the admin. That skips the upload form entirely.

If the file is small and WordPress still refuses it, the cause is the file’s type, not its size: see why WordPress says you are not allowed to upload this file type.

This is a fix we do as a one-off job. We find which limit your host enforces, raise it in the place your server actually reads, and test an upload before we hand it back.

PHP limits cause other failures too. Our post on the WordPress memory exhausted error covers memory_limit, the next setting people hit after the upload limit.

What did we not test?

• Hosts that run PHP-FPM, LiteSpeed or nginx, where .user.ini and the host’s control panel take the place of .htaccess.
• The drag-and-drop media uploader in a real browser. We used the plain upload form.
• Theme uploads and the block editor’s upload button.
• Uploads through the REST API.

Is an upload failing on your site right now?

Tell us the file size and the message you see, and we will tell you which limit is in the way.