However, in some environments, as soon as you try to make ANY changes to the Weaver II setting:
- The sub-theme reverts back to the default one.
- All Weaver II settings are reset with default settings.
Backing up and restoring the Weaver II settings works ok however this is probably the only other feature which does work correctly in the theme settings. Since I've successfully installed Weaver II on many sites to date, the only thing that is different is the hosting environment.
If this is happening to you, the problem may be a result of your hosting companies having tightened PHP security a little too much.
In a hurry? Skip to the solution…
In the process of trying to solve the problem, I went through the following troubleshooting steps. They are being included here, not so that you can feel my pain of having gone though it all, but because it might help you solve other problems in the future.
Be sure to re-test after each step so that you know which step fixed the problem. This will be a clue as to where the problem is and how to fix it.
- Search and read through the Weaver II support forums.
- Read the Weaver II FAQ.
- Try more than one version of WordPress. The most recent version may have temporarily introduced an incompatibility with the theme, although the Weaver II developers are usually on top of such things.
- Try the previous version of Weaver II. If a bug was introduced in the latest release, you may find relief in the previous version until the problem is fixed. Note that it can be difficult to locate a downloadable copy of the previous release.
- If WordPress was installed using Fantastico or some other automated installer provided by your web hosting provider, try doing a manual installation.
- Ensure that you are not using a clone or copy of your website. Verify that the website path is correct in the WordPress General Settings and is not greyed out.
- Work with the most plain vanilla configuration of WordPress that you can. Don't install any plugins or apply any customization of the WordPress settings.
- If you are working with an existing site, disable the plugins one at a time until the problem disappears. Then re-enable each of the plugins one at a time except for the one that was causing the problem just to make sure that there isn't more than one plugin causing the problem.
- Ensure that WordPress is installed either at the root of a domain or sub-domain, not in a sub-folder. Normally this isn't a problem but it is a troubleshooting step.
- Make sure that there are no spaces in any of the folder names, both from the root of your site and from the root of your file system.
- Poke around and see what other WordPress feature might not be working. Sometimes if you can find other related symptoms, it can be easier to find a solution because something less obvious is causing the problem.
- If the problem is with a theme, try substituting for a different theme. This will help you determine if it is a global problem or if the problem is theme specific.
- Use the original theme, not a sub-theme you might have created. This will help you determine whether the problem is with the original theme or the sub-theme you created.
- Use the Memory Load Consumption and db size Usage plugin to determine how much memory your site is using. Then use the WordPress phpinfo() plugin to verify how much memory the PHP environment has available. These numbers shouldn't even be close. If they are, some operations or features of your site might be causing PHP to run out of memory.
- If you have the option, test your configuration on a different provider's web hosting server. If you don't have access to another hosting provider's server, try it on a local installation of XAMPP.
- Ensure that your web hosting provider's server environment meets the minimum requirements specified for WordPress, your theme and any plugins you might want to use.
- Ensure that there is no caching WordPress plugin, server software installed. If there is, disable it.
- Temporarily disable your web browsers cache and any proxy settings.
How do you know this is the right solution to your problem? You don't. However one clue can be uncovered by removing the // at the beginning of following line found in /wp-content/weaver-ii/includes/lib-admin.php:
// weaverii_save_msg('Current version:' . $version . ' DB version:' . $existing_vers);
Once that is done, browsing admin settings in Weaver II will display the following line at the top of the screen:
Current version:1.2.7 DB version:1.2.7
If the problem is with the hosting environments security settings, you will see the following 3 messages after you try to save any Weaver II setting:
Current version:1.2.7 DB version:
The options settings have been initialized or updated for the current version of Weaver II. (1.2.7)
Notice that the "DB version:" is blank.
This is because the name of the Weaver II sub-theme is not being saved. When this happens, Weaver II will try to fix the problem by resetting the sub-theme back to the default "Antique Ivory" sub-theme including all of the Weaver II settings. This can make it look like your settings are not being saved.
A second clue can be uncovered by inserting the following line around line 26 in /wp-admin/options.php:
echo '<h1> CONTENT_LENGTH: '. (int) $_SERVER['CONTENT_LENGTH'].'</h1>'; exit('<pre>'.var_dump($_POST).'</pre>');
After trying to save your Weaver II settings, search for a string called "Array". There should be two of them as of Weaver II 1.2.7. One of them will have a size of 6 and the other will be at 395. The problem is, as of Weaver II 1.2.7, this last number should actually be 443. This indicates that not all of the Weaver II settings are being received by PHP when you clicked the Save Settings button. The reason the DB version is blank is because this particular setting is within one of the last 10 values which is missing because we are about 50 settings short.
If you are noticing similar symptoms, your web hosting company may have tightened their PHP security.
First check phpinfo to make sure that the following three settings have a minimum value of at least 600 (higher is OK and they don't all need to be the same) in both the Local Values and Master Values column:
max_input_vars = 600
suhosin.post.max_vars = 600
suhosin.request.max_vars = 600
If any of these are set lower than 600, you will need to change these settings in your php.ini file. If you don't have access to php.ini, contact your web hosting company and ask them to do this for you.
Update: Good news! As of Weaver II version 1.2.8, a check will be added which will notify you if this is a problem for your environment.