Problem: settings cannot be saved.
On the form edit page when you click “Update Options”, the browser window appears to refresh and load the form again, but none of the settings you just entered show up on the form (or just some are not showing as changed). This can happen to the WordPress and the PHP version. The problem may also appear when trying to add new forms, or more fields.
This can happen on some servers because the admin form edit page has over 200 fields on it. If you add new forms, or more fields you can get into the 1000’s of fields. Some servers limit the maximum number of post fields to 100, 200, 1000, etc. Once you hit this limit, the problem appears. PHP 5.3.9+ has max_input_vars set to 1000 by default. The solution is to adjust the setting to a higher number, such as 2000, or 3000 as needed:
Configure the PHP max_input_vars setting
These settings are sometimes available in the php.ini directive called max_input_vars
Edit the server php.ini or in some cases you can add a secondary php.ini inside the account (domain) folder.
Configure the php.ini like this:
max_input_vars = 3000
You may need to do this via .htaccess (on a shared host for instance), use:
php_value max_input_vars 3000
Check for and configure Suhosin
Some servers use a PHP Suhosin patch/extension that imposes limitations on POST vars, which can prevent certain forms from working properly. When the Suhosin number of fields limits are exceeded, Suhosin’s default behavior is to log its errors to syslog, not the Apache error log. Suhosin does not even show any errors on the screen to indicate what just happened.
How to check if your server has Suhosin:
Put this PHP code in a test.php file and use and FTP program like FileZilla to upload it to your server.
<?php phpinfo(); ?>
Next, view the page in on your web site URL. This page will show PHP information with details about the PHP server configurations. After the page is loaded use your web browser to find on the page the word: “Suhosin”. If it finds the Suhosin word, your server does have it. Be sure to remove the test.php page when you are done because leaving this information online can be a low level security risk.
What can be done to fix Suhosin causing this?
1. You can try to enable suhosin.simulation for the account (domain) instead of disabling Suhosin server wide. The suhosin.simulation if turned ON, will log the violations as usual but nothing will be blocked or removed from the request. You can perform this task in one of the either ways:
a) Enable suhosin.simulation in a .htaccess file of the domain (suphp enabled server)
php_flag suhosin.simulation On
b) Create a php.ini file under the account (domain) and turn ON the simulation
suhosin.simulation = On
There is no need to restart any service in any of the above case. As not all servers are setup equally, be prepared to test and undo these changes if they do not work.
2. Ask your web host to examine the server logs, maybe they can point out the exact suhosin directive violations that are occurring. Suhosin has a few different installation methods and about 100 different settings. Examining the log files will reveal just what setting (s) need to be adjusted. Here is a sample from a log file found in /var/log/messages:
Jul 20 14:17:23 centos4 suhosin: ALERT – configured POST variable limit exceeded – dropped variable ‘si_contact_text_message_sent’ (attacker ‘192.168.1.10’, file ‘/var/www/html/mosaic/htdocs/blog-test/wp-admin/plugins.php’)
You could adjust the Suhosin max_vars settings usually found in php.ini:
Default is 200, so adjust the following values to a higher number, such as 3000:
suhosin.post.max_vars = 3000 suhosin.request.max_vars = 3000
This setting is normally used to limit an attacker from flooding your server with thousands of post variables in an attempt to overtake it or bring it down. 1000 is still a rather small amount that will not cause any decrease in security. It is common for security programs to periodically need settings/adjustments, that is why the setting is there. These settings are available in the php.ini, the suhosin.ini, or .htaccess. There may be other settings involved, so contact the server administrator if you need help.
3. You could disable Suhosin server wide:
Unless you are the server administrator, disabling this is probably not permitted, so I am not going to try to explain how. If you have not has success with the other options above, perhaps you can ask your web host if they can white list your WordPress wp-admin/plugins.php page.
Mod_security Apache module can also prevent data saving; you may experience error 503′s or “406 Not Acceptable” if this is the case. As with the above issues, you may want to contact your web host support to determine the rule that is causing it. Then they can adjust the rule to resolve this issue. Workarounds include:
- Configuring mod_security to allow the data through(advanced settings)
- (Dreamhost only) Turn the “Extra web security” setting off in the control panel.
If you have any information that could be useful to me, please contact SupportDo you need help?
Send us a Donation: