Bug: max_input_vars not showing correct value about core HOT 2 CLOSED

Hi @jcarney2024 , I believe typically this would be more so an issue for the forums rather than github issues, hence why it's gone unanswered for a few days, without knowing the specifications of the server itself (not just the browser/device you're accessing it with) often makes it difficult to provide support for questions like this, so in future I'd recommend including these details from the get go.

Nevertheless I think it may actually not be a bug (or if it is, is a bug of your web server) on gibbon's part, as this information is obtained using a standard PHP function, so most likely either something is broken with your PHP and/or webserver (unlikely, but possible), or there may be something that's gone amiss in your configurations. (Quite likely, there's no shame in it being user error, I encounter this issue frequently when first setting up servers).

This response ended up being a lot longer than I anticipated as I went through essentially what the issue may be coming from how you'd check to identify the root issue, and how to hopefully repair it, with a short tl;dr at the top of each section as well as a more detailed explanation that might help if you're not super familiar with webservers in general.

Before you go deep into these big chunks though, the number one solution to 90% of tech issues is to give everything a restart and then try again, and especially in the case of safari you will also want to try using a different browser such as firefox or chrome. (And if you're not on a localhost, try using a different device).

What might be the issue

(tl;dr: You might be checking in the wrong place/misconfigured something in your setup)
If you've set up this server yourself, and are checking configuration files you've set up and configured (e.g you're using a localhost or other server that you have access to), What might be the issue is I've often found myself looking at the wrong php.ini config files (e.g. when using MAMP or my personal homebrewed combination of PHP and Apache I'd sometimes still look at the default mac PHP files within /usr/, which aren't what the webserver is using. I've also had the opposite issue before where sometimes I found myself to believe my Apache was using my homebrewed PHP and changed configuration files there when actually it was using the default mac ones... (On later versions of MacOS I've also recently started encountering the issue of thinking I'm using my homebrew apache and the PHP that it loads in, when the default mac apache somehow continues to run over it). In this case I would follow the information below in the order I provide it in.
If you're using a virtual hosting service or something where you have some sort of admin panel access to check and configure your settings, your server configuration is probably actually set to whatever you're seeing and configuring in this panel properly, but you might have a cheeky .htaccess file or similar changing the settings, I'd suggest either skipping the next section at first, then going back to it if the sections after don't help, and then contacting whoever is providing the service/product you're using for their support, including the information you would've gotten from the sections below.

How to identify that your server configuration is the issue and fix it

(tl;dr Use phpinfo() to confirm your server variables and find the config files you should be changing)
What you can do to quickly check, if you haven't done this already, where your server is getting these values from, and also to make sure your max_input_vars is really not 1000 is to create a php file on your webserver, in the same directory as the gibbon directory (or even within the gibbon directory itself), that contains the following code

<?php phpinfo();

and then when you navigate to that page on your webhost, you should get all your server's PHP information. It will list the location of your php.ini config file(s) (it's near the top but you can command+f for "Loaded Configuration File") as well as tell you further down what all your server variables, including max_input_vars, are. You should find that the value here aligns with what gibbon is reporting, and you can change this either by using a .htaccess configuration in the gibbon directory or by editing the loaded configuration file according to the phpinfo() page. If everything is as it should be and still not working at this point, give everything a restart just to be sure all your settings have been applied, and if it's still not working move onto the next section.

It's not your server configuration... but it is a .htaccess file that you need to find and change

(tl;dr; you've got a .htaccess that your file explorer/finder might not be showing or that you've mislooked, and you need to change it)
It's most likely that you have a .htaccess file somewhere in a directory that gibbon is within that is changing the max_input_vars variable for gibbon, and you'll have to look for a .htaccess file in any of the parent directories of gibbon . If you're not using a localhost or you've not got ftp/smb/ssh/etc access to your webserver, such as if you're using a limited virtual host service, you might have to figure out how the virtual host server is configured, see if you can find anything named .htaccess on the server, and/or talk with your virtual host provider for further support.
However, if it's either a localhost or you're able to connect to it via ftp/smb/etc and you don't want to trouble your virtual host provider, you can either manually search through yourself on finder for it (by default .htaccess files are hidden on mac's finder though so you will need to use the command key combination command+shift+. whilst finder is open to make these files visible) or, more conveniently, especially if your gibbon is located quite deep within several directories of your webserver, you can also use the find command in terminal to search the top directory of your webserver for any file named .htaccess and it will print it back for you. I'm on my windows machine right now but if I remember correctly this command would be find /Path/To/Directory -name .htaccess (if you're unfamiliar with terminal usage or don't know the full path for your directory (or even just if it's quite long and you're lazy like me, you can type find and then drag the top directory folder from your finder into your terminal and it will write the directory name for you, and you can type the rest of the command out from there. If a .htaccess file exists within the directory it'll print out the locations of it, and you can then either navigate to it in finder manually to edit it (making sure you've used the command key combination I mentioned before to show hidden files) or you can use your preferred terminal text editor such as vi or nano to view and edit any files it lists, or if you're not familiar with terminal you could also use the command open -a TextEdit /Path/To/.htacess to open it with TextEdit and edit it there. Look for anything that mentions max_input_vars and either remove it or change it to your desired variable for that directory and all it's subdirectories.
If there are no .htaccess files, or you've changed any and all .htaccess files you can find and it's still not made a difference, restart your server just to play it safe, see if that changes anything, then if you previously skipped the section regarding identifying your configuration, go back and go through that... If you're still getting the issue, give the next section a shot

It's not your config file and there's no .htaccess affecting it, let's work around this

(tl;dr use a .htaccess to set the variable)
If you've followed all the steps before and still haven't gotten it working as expected, colour me impressed... I still don't think this would be a gibbon issue though, it's possibly something may be malformed somewhere, most probably your PHP binaries but potentially also your Apache binaries, and if you're really wanting to and have the technilogical know-how you could try and recompile these or use a different set of binaries (perhaps different versions of them entirely) first, but the easiest fix that will (hopefully) get the job done is probably to edit the .htaccess file in your gibbon directory and add the line php_value max_input_vars 5000 to it (make sure it's not within any of the blocks, just put it either right at the top on the first line, or right at the bottom on the last line), which will hopefully override anything that's somehow changing it elsewhere and the gibbon installer should detect this...

Last ditch attempt

(tl;dr I'm at a loss, try hard coding it into gibbon.php)
I'd be incredibly surprised if it still doesn't work at this point, especially after one last restart of everything just to be safe, doubly so if you went the extra mile and changed your binaries. Try hard coding ini_set('max_input_vars', 5000); at the start of the /gibbon.php file (on the second line after the opening <?php tag, but as a new line before the comment ) and see if that changes anything.
However, I can't with good intent however recommend that you use this in production, as whilst you may be able to get away with it (The majority of files in gibbon include gibbon.php in the same way as the page that shows your system info does, and it is also not very often that you will need more than 1000 input variables, let alone 5000) there is still a non-zero possibility that it would come back to bite you in the ass at some point and that is not a risk I would personally want to take (If you choose to ignore this warning, I take no responsibility for anything that goes wrong or fails to work in the future but would just like to recommend, even more so than I would normally, that you make frequent backups of your server, especially it's database, in particular doing so before doing any major tasks within gibbon so that you can rollback if anything goes wrong), but if you're just using this for testing or development purposes, if it works it works.

Final words

Let me know what the thing that finally worked for you was, or if, god forbid, it still isn't working, I'm going to have to throw my hands up in the air. You can try providing more details here and maybe someone else will have a suggestion (or maybe I'll think of something else) and be able to help.

from core.

Thanks @powertashton for the detailed response! 😃 I'm going to close this issue for now, as I feel there's enough information to solve the issue, and if it does reoccur we'd be happy to continue in the support forms https://ask.gibbonedu.org

from core.