From time to time, the support forum will receive a question something like “After I make changes, my Weaver theme doesn’t save the settings. None of my options are changed.” If you are having trouble getting your designs in any Weaver Theme theme to save, then this FAQ is for you. This FAQ applies to all Weaver Themes: Weaver II, Weaver II Pro, Aspen, Weaver Xtreme, and Weaver Xtreme with Xtreme Plus.
It is important to note that the way Weaver saves settings is a mature, well tested mechanism. If it seems that Weaver are not saving your settings, then it is almost certainly not caused by a problem with Weaver, but rather some non-standard host configuration, or an invalid setting value. The known possible causes for “not saving settings” are described below, but will always be one of these 3 general issues:
- Non-Standard Host configuration issues
- Invalid option values that cause improper CSS rules to be generated
First, perhaps the most common reason for this is caching – one of: a WordPress server side caching plugin; caching done by your browser; or the caching done by a global caching service like CloudFlare. This is covered in a separate FAQ – click here. If that is not your problem, then this FAQ will have some more suggestions.
Weaver are now a mature, well-tested themes used successfully by thousands of users on many different hosts. Changing and saving settings for the free versions as well as premium versions work. There are no known bugs or problems saving settings as long as your WordPress site is properly configured. So if you can’t save options, then there is something wrong with your host configuration or values entered into the settings. There are no known exceptions to this statement.
The most common issues are discussed in the next two sections. There also is a list of quite rare known host configuration errors or illegal settings values described at the end of this page.
Weaver Free Version Issues
Outside of the caching problems mentioned above, there have been very few issues with saving the Free version setting. It has been confirmed that the “White Screen of Death” memory problem can result in a failure to save options instead of total failure, but the solution is the same – you need to get your host to increase the amount of PHP memory.
There have also been a couple of reports of issues communicating with the mySQL database. But this is very rare, and is not an inherent issue with Weaver. It may be related to using some automatic script installs of WordPress, and doing a manual install of WordPress seems to fix this issue.
Weaver Premium Version Issues
There is one major difference between Premium and Free versions is in how your settings are reflected in the displayed site. Free includes all necessary CSS rules required to display your design inline in each page <head> section. The premium versions, on the other hand, by default will generate an external CSS file at
/wp-content/uploads/weaver-ii-subthemes/style-weaverii.css or the equivalent name for ‘aspen’ or ‘weaver-xtreme’.
There are two points of failure possible when this file is created and used. First, there can be a failure to create the file. This can only happen when the site admin does not have proper permission to create files in the
/wp-content/uploads directory. This will not happen in a standard WordPress installation. One thing to test is if you are able to add and display images in your media library, since those files area also stored in the
/wp-content/uploads directory. This problem will likely only happen on private or virtual private servers. It will very seldom happen on typical shared hosts. Sometimes file access permissions have been set improperly. The Weaver
/weaver-ii-(or aspen/weaver-xtreme)-subthemes directory needs read and write permission for the admin, and read permissions for the world.
The second problem can come if the visitor can’t read the
style-weaverii(aspen/weaver-xtreme).css file. There can only be three reasons for this – either the file doesn’t exist at all; the file path to the file is somehow being changed; or the file doesn’t have read permission to the world.
- If your settings aren’t “taking” for the Pro version, the first thing to try is to open the Weaver II Pro tab on the Weaver II admin panel. Check the first option: “Use Inline CSS”. For Aspen Pro, the inline option is on the “Advanced Options : Site Options” tab. In most cases this will both cause your site to display correctly, but also confirm there is an issue with the
style-weaverii(aspen).cssfile. Keep reading for possible things to fix.
style-weaverii(aspen).cssfile is not being created. You should be able to check this using your host control panel, or via FTP access. If the file is not being created, there is a permissions problem. You may have to contact your host to get this figured out. The directory must be write enabled for the WP site admin. Also, do be sure you can upload and use images to the site media library.
- The style-weaver-ii(aspen).css file exists – it just doesn’t work. This means the visitor’s browser is unable to find that file. The things to check:
- File permissions – be sure the file gives read access to the work.
- Permalinks – go to the dashboard Settings:Permalinks tab, and re-save your permalinks settings. This might possibly fix things.
- Be sure you don’t have some kind of plugin incompatibility – you may need to disable your plugins one at a time to test this.
- Issues with your .htaccess file. Perhaps you or some plugin has added extra rules to the site’s .htaccess file that prevents the user from reading the file (this also may stop it from being created.)
If all these measure fail, you may need to re-install WordPress. (You should be able to keep your WP database with all the content.) If you used a script install previously, a manual WordPress install might work the second time around.
But, again, please recognize that if you can’t save Weaver II or Weaver II Pro or Aspen settings, there almost certainly is some issue with how WordPress is setup and configured on you host.
Other Possibilities – Very Rare, but…
1. Entering Incorrect Color or CSS Values
It has been found that it is possible to enter incorrect values for colors that will have the effect of making it seem settings don’t take. This is because there is then incorrect CSS generated. One specific case is adding a leading paren ‘(‘ to a color – e.g. ‘(#181818’. This adds an extra ‘(‘ to the CSS, and confuses most (but not all) browsers. So after you’ve checked the more obvious problems discussed here, check that you have valid color values in all the color boxes.
And this problem can be generalized – if you enter custom CSS in a CSS+ box, or have custom CSS in the Custom CSS Rules box, then if you have a mistake in your CSS, that will cause incorrect CSS to be generated, and that in turn can make it seem other settings are not taking effect. Leaving off a closing ‘}’ or quotation mark (‘ or “) are common problems.
2. Site Address
Another way to “break” saving settings has been reported. Your Dashboard Settings -> General -> Site Address and WordPress address MUST be set correctly and pointing to your site. If you are creating a new, development version of a live site, you MUST NOT use the address of the live site for your development site! This problem can apparently also manifest if you are developing on a subdomain, and don’t specify the Site and WordPress URLs correctly.
3. Not enough $_POST variables allowed
When you save settings from the Weaver II or Aspen admin panel, all the settings (and there are over 450 of them!) are passed to the save code using the PHP $_POST variable. It is possible that your host has changed the default PHP configuration to limit the number of values allowed to be passed by changing a PHP setting called max_input_vars. There is also a PHP extension called Suhosin that can control the number of PHP settings allowed. If either of these are set (usually by your hosting company) to anything less than about 450, then is is likely that your Weaver II settings will not be saved properly in the WP database. You will likely see the settings reverting back to the default Antique Ivory theme. In that case, you must contact your host and get this limitation increased – preferably to at least 600 $_POST variables allowed. (And a big thanks to mjm4842 for discovering this, and reporting it on the forum!)