On my remote server:

  • Changing the settings in admin/settings/appearance/subtheme do not save (i.e. I do not get a "your changes have been saved" confirmation).
  • Changing the settings in admin/settings/appearance/omega do not save.
  • Changing the settings in admin/settings/appearance/alpha DO save (I get the confirmation message).

On my local machine (MAMP), all settings for all omega-related themes (subtheme, etc) save just fine.

My only conclusion would be that it is the remote server setup that is to blame (file permissions, etc), but the fact that the alpha theme takes hold of the changes no problem makes me think twice about that conclusion.

I've checked all the file permissions and nothing seems out of place. The file owners and groups are the same for subtheme, omega, and alpha.

I've seen some other issues (#1179006: UI LAYOUT SETTINGS > Primary layout - cannot disable layouts, #1218126: If I deactivate the breadcrumbs admin/appearance/settings/MYSUBTHEME after save they're on again) that address similar problems, but there isn't much detail on the fixes.

Not expecting a server diagnosis here, but any ideas would help - because at this point I haven't got much hair left to pull out ; )

Thanks.

Comments

bxtaylor’s picture

bxtaylor CreditAttribution: bxtaylor commented

Follow up:

I've gone through the process of creating another subtheme using a different base theme (zen) and the settings on this subtheme save without a hitch. The subtheme settings are getting saved to the variables table.

I switched back to the omega subtheme and tried to save the settings again. Still no luck and looking at the variables table shows that theme_omega-subtheme_settings is not there, which makes sense since I can't get the confirmation message when trying to save any settings.

bxtaylor’s picture

bxtaylor CreditAttribution: bxtaylor commented
Issue summary: View changes

Linked issue #'s to their issues

fubhy’s picture

fubhy CreditAttribution: fubhy commented
Status: Active » Postponed (maintainer needs more info)

To me this sounds like your php.ini is configured with a post data limit that is too low for submitting that form. Omega does not alter much in the theme settings submit process and really just adds its own form elements / settings to the form. Please check that your php.ini is configured correctly. Check stuff like post_max_size, memory_limit and max_execution_time. Also, if that does not help: Turn php error reporting on to find the problem.

bxtaylor’s picture

bxtaylor CreditAttribution: bxtaylor commented

I'll check those settings and report back. Thanks!

Hordor’s picture

Hordor CreditAttribution: Hordor commented

Changing to Drupal 7 now I am looking for a decent new standard starting point. I figured out the same problem like bxtaylor. However - as my Hoster is in holidays know I can't look for the php.ini right now. It would be nice, If the problem could be figured out, as I decided to use the omega-Subtheme as my new standard...

maritimefist’s picture

maritimefist CreditAttribution: maritimefist commented

+1

bxtaylor’s picture

bxtaylor CreditAttribution: bxtaylor commented

Here are the php settings I have right now:

post_max_size = 8M
memory_limit = 128M
max_execution_time = 30

Those all seem like reasonable numbers to me, especially this this is a brand new install with only a few modules enabled.

The Error log, however, has this bit repeated over and over:

ALERT - configured POST variable limit exceeded - dropped variable 'alpha_region_footer_second_prefix'

I think it might be a suhosin setting. Proposed solution here: http://simonlane.com/site/?q=node/13

bxtaylor’s picture

bxtaylor CreditAttribution: bxtaylor commented
Status: Postponed (maintainer needs more info) » Closed (fixed)

Confirmed - It was definitely the suhosin settings.

I changed these two settings: suhosin.request.max_vars and suhosin.post.max_vars.

Both had default values set to 200. I set them at 500 each and the subtheme settings were able to be saved.

Hordor’s picture

Hordor CreditAttribution: Hordor commented

This solution worked for me out too. Thanks for that!

hedac’s picture

hedac CreditAttribution: hedac commented

I have the issue of not saved settings but nothing in the error log or suhosin :/

sahaj’s picture

sahaj CreditAttribution: sahaj commented

Same trouble as #9, no suhosin, local install (MAMP) with lot of memory in php.ini

UPDATE 01.10.2012 : just find out that my Delta module settings confused me. Now everything is working well for me.

JimSmith’s picture

JimSmith CreditAttribution: JimSmith commented

I'm running Nginx. In my php.ini file I find these settings:

suhosin.request.max_vars = 8000
suhosin.post.max_vars = 8000

I am also not able to save settings.

JimSmith’s picture

JimSmith CreditAttribution: JimSmith commented

Not sure why this issue was marked as a fixed support request. Would it not be fair to say it is neither?

tomrenner’s picture

tomrenner CreditAttribution: tomrenner commented

Raising the request.max_varsand post.max_vars to 1000 has helped me, too! Were set to 200 by default. Another fresh suhosin webserver of mine didn't have these limits set at all, that's why the problem didn't occur there at all. THX!!!

chefnelone’s picture

chefnelone CreditAttribution: chefnelone commented
Priority: Normal » Major

same problem here.

I added this lines to htaccess, but not fixed:

php_value suhosin.post.max_vars 8000
php_value suhosin.request.max_vars 8000
dhalbert’s picture

dhalbert CreditAttribution: dhalbert commented

Depending on the server-wide suhosin settings on your server, it may not be possible to change suhosin settings in .htacess. Look at /admin/reports/status/php on your site, and check the value of suhosin.perdir. On my host it is set to 0, which means I can't change any suhosin settings myself in .htacess, and had to ask sysadmins to bump up some suhosin settings.

Here's a good explanation of suhosin.perdir: http://www.mattzuba.com/2011/04/suhosins-suhosin-perdir-directive/ .

chefnelone’s picture

chefnelone CreditAttribution: chefnelone commented

@dhalbert
I asked my hosting provider to change the suhosin values. They told that if we set a value of 1000 this could dramatically increase the RAM use.
Just wondering if is there any other way to solve this?

dhalbert’s picture

dhalbert CreditAttribution: dhalbert commented

@chefnelone - # 16: I think you may be stuck if your hosting provider is not willing to increase the values. I am not they really understand what these values do. Memory use would only increase dramatically if someone was sending huge malicious HTTP requests with very long and many values, and there are other suhosin ways to set absolute memory limits that would mitigate that. For actual use by Omega, it is not an issue.

On my Drupal-oriented shared hosting provider, these values are set to 3000. (Feel free to contact me via drupal.org if you want the provider name, etc.)

rmorelli’s picture

rmorelli CreditAttribution: rmorelli commented

Same problem here but I don't have php5-suhosin installed so I can't change anything.
Still my setting are not saving...
Any hints?

bauhaus’s picture

bauhaus CreditAttribution: bauhaus commented

Hi,
I spent 2h checking my configs and logs. Using Community Media theme (Omega subtheme) had same problem.

Check your theme settings! For some reason I had wrong logo path. No error was reported at all (logs, config page). When I changed logo path theme saved normally.

bauhaus’s picture

bauhaus CreditAttribution: bauhaus commented
Issue summary: View changes

typo fix