A curious thing happened to us this morning while trying to update a supposedly small Joomla 2.5.28 website to 3.5.1. No – we didn’t suddenly develop xray vision, it was something even curiouser than that!
Let us begin by explaining what we were doing… We were, as stated before, trying to update a small Joomla website from 2.5.28 to 3.5.1 by following the official guide (we only do that for very small websites – since it expedites the work – otherwise, we perform the migration manually). As you may probably know, the second step of a migration from 2.5.28 to 3.5.1 (the first step is always the backup step), would be to change the Update Server from Long Term Support (recommended) to Short Term Support in the Options of the Joomla Update extension, but, when we tried to do that on the client’s site, we saw something unexpected: we saw the Joomla configuration settings page loaded in the popup after clicking on the Save button! Yes – you heard (or read) that right: the popup loaded the configuration settings page! Huh?
That was very weird, we thought. We thought it was a glitch, and so we did it again, and again, and again. Still, we had the same problem, but we did notice something: we noticed that the popup had a large number of fields inside it, mainly because there was a huge ACL database on that particular website. Could it be, we thought?
We then went to the configuration settings page, and made a small modification (we decreased the session lifetime from 60 to 59), and then tried to save it. Unsurprisingly, our little change wasn’t saved! We knew immediately what was happening: the number of the fields on that page (and the Joomla Update popup) was exceeding the maximum number of inputs allowed by the PHP instance on the development server (we were doing the update on a development server).
To verify our theory, we checked the value of max_input_vars (by creating a small PHP page with phpinfo(); in it), and it was set to the default value of 1000. Checking the HTML code of the Joomla configuration settings page revealed that the page had the following fields:
- 2933 select fields
- 583 input fields
- 4 textareas
The total number of fields was 3520, which was more than triple the PHP limit. Clearly, that was the problem!
So, how did we solve the problem?
We solved the problem by creating a .user.ini file in the main directory of the Joomla website (e.g. at the same level of the index.php file) with the following content:
max_input_vars = 8000
As you can see, we increased the maximum number of input variables to 8,000, which is more than double the current need. We then tried to modify a setting in the configuration settings, and this time it worked!
Will the above solution always work?
The above solution should work flawlessly on most recent servers (especially those using WHM). However, on some older servers (or servers with weird environments), it may not work. If it doesn’t, then try renaming the .user.ini file to php.ini file. If it still doesn’t work, then create a file called defines.php in the main directory of your Joomla website, and then add the following code to it:
<?php ini_set('max_input_vars', '8000'); ?>
If the above still doesn’t work, then you will need to modify the max_input_vars value in the master php.ini (e.g. the server’s php.ini file) and then restart Apache. If you are on a shared hosting, then most likely you don’t have access to that file, which means that you will need to beg ask your hosting company if they can do it for you.
How come the client didn’t notice the problem?
The client didn’t notice the problem because the production website resided on a different server with an already altered max_input_vars. Obviously, whoever was working previously on that Joomla website noticed the problem before and addressed it on the production server.
Are there any side effects for having a large max_input_vars value?
Yes – DoS (Denial of Service) attacks – especially ones using hash collisions (aka HashDOS attacks) – will be more dangerous on servers where the max_input_vars directive is set to a high value. This problem, of course, is more relevant to websites with high exposure and many enemies (as these are the websites that typically get hit with more than the FDA recommended intake of DoS attacks).
But why so many fields in the configuration settings page?
Well, there are 2 entities that must be blamed here: the Joomla administrator (that’s you), and Joomla itself. First, if a Joomla website has more than 100 groups and/or access levels, then there must be something conceptually wrong with the website. In other words, the groups/access levels are being used for the wrong purpose. Second, Joomla must not display all the ACL data on one page – not only this is a problem at the server level (where the max_input_vars can be exceeded), but it is also a problem at the client level (the browser may crash because of all these fields). Additionally, Joomla must have a mechanism to check for the max_input_vars and warn the administrator if a certain page is exceeding the effective limit.
We hope you enjoyed reading this post as much as we have enjoyed writing it. We have tried our best to make it as uncomplicated as we can. We reckon, however, that non-developers may find it a bit over their head. If this is the case for you, then please contact us. We are always happy to serve, our fees are affordable, our work is top notch, and we always strive for the cleanest solution possible.