There are two reasons behind getting the error “The link you followed has expired. Please try again.” (native WordPress error) or ending up with data that is not saved after form submission. We’ll go through each one below.
Possible reason #1: The value set for max_input_vars in php.ini is low (default is 1000)
Whenever you submit a form through Asset CleanUp Pro, the most common one being the CSS/JS manager one, the POST data containing the information is sent for processing. The default value is 1000 which is set for max_input_vars within php.ini. Often, this value is too small and you need to increase it to a higher number (e.g. at least 4000) to make sure that all the fields are sent correctly for processing.
The most likely scenario for this problem to happen would be in the edit post/page area (e.g. its URI would be something like /wp-admin/post.php?post=[POST_ID_HERE]&action=edit) where there is one form that contains fields added by Asset CleanUp Pro, other plugins, as well as the native WordPress ones. These include “Title”, “Categories” side box, “Tags”, “Yoast SEO” (if you’re using the well-known plugin or a similar one), etc.
If the default value of max_input_vars is 1000, and you’re submitting a form that has 1200 fields (note that a form has hidden fields as well containing various information, and these fields are included as well), then the last 200 of those fields will not be processed by PHP and plenty of changes will not be taken into consideration. One of those fields could be the security nonce that is added as a hidden field. If that field is not recognized, the error “The link you followed has expired.” will show up and the changes you submitted via the CSS/JS manager will not take any effect.
To increase the value of max_input_vars, you can edit either php.ini or .htaccess if you have access to either of them. Here’s how to do it using either of these methods:
Method #1: Editing php.ini
This method is ideal if you have access to php.ini or you’re on a local host. Some hosting companies do not allow direct access to this file.
- Locate the php.ini file. If you find difficulties finding it, you can ask your hosting company about the location OR try to create the php.ini in the WordPress root directory as you might have it there (some hosting accounts allow that)
- Open the file, then locate the following line followed by the actual value set there: max_input_vars = …. (e.g. it could be max_input_vars = 1000)
- Update the number set there with a higher one (e.g. max_input_vars = 3000)
- Save the file and reboot the server (this is needed in many situations, it might work without reboot) or your local host server (e.g. MAMP, WAMP)
Method #2: Editing .htaccess
If you fail to update using the previous method, you can try to update the values within .htaccess. This is an easier method as it’s more likely to have access to this file which is located in the WordPress root directory. Note that you have to be careful when editing this file and it’s recommended to make a backup before editing it.
- Locate the .htaccess file in the WordPress root directory (if you can’t find it, it might be hidden. Consider reading the following post on how to access it: https://hostpapasupport.com/locate-htaccess-files/
- Open the .htaccess file with a text editor (e.g. Notepad, TextEdit, Sublime Text, etc.) and add the following line to the current code:
php_value max_input_vars 3000
(you can add a higher value as well, not necessarily 3000). Note that if you have the Suhosin security patch, you need to add the following lines:
suhosin.get.max_vars = 3000 suhosin.post.max_vars = 3000 suhosin.request.max_vars = 3000
- Save the changes and try to re-submit the same form that was not processing correctly before.
No access to php.ini or .htaccess?
In some situations (e.g. the hosting account is a shared one), you might not have access to the php.ini or the .htaccess files. Consider contacting the hosting company to do these changes for you.
How to verify if the changes made by myself or the staff from the hosting company were applied?
You can create a PHP file in the WordPress root directory of your website. Because it would print sensitive information, it’s better to add a unique name that is hard to guess (e.g. info-4ac711b28df9e1dc8c0.php). Add the following code to the file:
<?php phpinfo();
Once the PHP information shows up, locate “max_input_vars” and check its value. If everything looks good, you can safely delete this info file that you just created.
I made the changes, but they don’t take any effect.
If that’s the case, then it’s most likely your web hosting provider does not allow changing max_input_vars (e.g. they are limiting it to a value they set, and even if you add your own value in .htaccess, it won’t take any effect) and you need to contact them to do this change themselves. This happens often in shared hosting accounts. You might want to consider upgrading to a better hosting package if you want more flexibility or even change the hosting company.
Possible reason #2: The page you loaded containing the CSS/JS manager hasn’t been accessed in a very long time and the security nonce has expired
Another situation when you’re not able to save the changes you made is when you submit a form with a nonce that already expired. For instance, you open the CSS/JS manager and start making some changes. You then pause the process, put your laptop on sleep mode, return to the same page (which is still open in your browser), and resume your changes. If more than 24 hours have passed since the page was loaded (e.g. before you put your laptop on sleep mode), you will likely get the well-known error that the link you followed has expired. So, it’s a good practice to reload the form if you know you left the browser session open for over 24 hours. This is in a way similar to a banking app (the security nonces in WordPress). You start a process (e.g sending money to someone), but you forget about it and come back to the app after a few hours. You will likely be already logged out and you have to login in again to the app. Many plugins with forms use this approach in the WordPress environment.