With all debugging boxes unchecked, the grid and block debug boxes continue showing up by default. They can be clicked and turned off but apparently something is wrong since they should not show up at all.

They are defined as alpha-grid-toggle and alpha-block-toggle.

Attached screenshot shows the layout config panel with all boxes unchecked.

I did clear cache a couple times and also the browser cache.

CommentFileSizeAuthor
12-28-2011 8-09-34 PM.jpg93.19 KBwindtrader
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

marcoka’s picture

marcoka CreditAttribution: marcoka commented

hm i never had that. maybe check the variables that are beeing set.

Cellar Door’s picture

Cellar Door CreditAttribution: Cellar Door commented

Are you running any deltas? You'll want to disable them there as well. This is the most common reason that it remains after saving.

marcoka’s picture

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

what browser?
tested on a clean install or with a bunch of contribs that add there js too?

lex0r’s picture

lex0r CreditAttribution: lex0r commented

I'm in a similar situation. When reverting settings using "Revert settings" they are not actually reverting the grid that should be turned off. Also, settings edit form shows grid toggle as checked. Only manual unchecking and saving helps.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

I'm having a very simular if not the same issue.

Basically, I install Omega, make a subtheme (done it with both Drush script and manually with the starter kit) and then try to turn off the grid, and it doesn't save this configuration. Then I realize it doesn't save any configuration I try to make to the subtheme. It does however let me make changes to the core Omega theme through the UI. Totally confused. I think it must be a server setting because I can get this to work on different servers OS X, CentOS 6, but not on my Debian Linode. It also happens when all I have installed is Drupal 7, Omega, Omega Tools, Omega UI, and CTools so basically a clean install.

Does anyone know what is causing this? It's frustrating to no end. I can't save any settings what so ever through the theme settings UI on only my Debian Server.

One thing I should add is that if I remove or comment out the zone settings in the MYTHEME.info file it DOES allow me to make changes to the theme,

PS: I also posted about this over on Zen from a simular thread, it might be a Drupal thing and not Omega for all I know. http://drupal.org/node/1180882

DigitalFrontiersMedia’s picture

DigitalFrontiersMedia
Location Sarasota, FL
CreditAttribution: DigitalFrontiersMedia commented

Likewise, I can make no configuration changes to my HTML5 Omega subtheme through the UI. I have to go in and manually change settings in the subtheme's .info file. Practically negates half of all of Omega's features.

DigitalFrontiersMedia’s picture

DigitalFrontiersMedia
Location Sarasota, FL
CreditAttribution: DigitalFrontiersMedia commented

I resolved this for my circumstances.

I went back and hit the edit button for my subtheme's .info file and went through it again. Oddly, I noticed that a lot of the settings that were originally in the file for debugging settings did not appear under the Advanced settings part where you can edit the .info settings from the UI. Hitting save and going back to look at it at the command line, all the settings I was setting manually as I described above were gone. I'm still not sure how/why these settings were originally included in the initial subtheme .info file.

I then noticed that if you have the subtheme set to use the default favicon yet the favicon in the Drupal root is 404, the settings page may fail silently preventing the configuration settings from being saved. Simply making sure I had a favicon.ico in the Drupal root changed the behavior.

Between these two changes, all seems to be working well for me again.

kempoller’s picture

kempoller CreditAttribution: kempoller commented

I've run into this same problem, where no changes being made in the admin UI were being saved. Also on a Debian based server, though running SuPHP, not sure if this is the same for everyone experiencing the problem.

What it turned out to be in the end in my case was a limit on the number of POST variables enforced by SuPHP, spotted in Apache error logs.
I had to add the following to my PHP setup for the site in question:

[suhosin]
suhosin.request.max_vars = 1000
suhosin.post.max_vars = 1000

Maybe a little high on the vars there, but hopefully it may help someone in the same situation.

Cheers.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

kempoller++

I confirm on my Debian server, adding the following you suggested to my php.ini file (restart Apache) fixed this problem. OMEGA-YAY!

vi php.ini

suhosin.request.max_vars = 1000
suhosin.post.max_vars = 1000

kempoller’s picture

kempoller CreditAttribution: kempoller commented

Just to update this, I figured the values were a little high to fix this, potentially negated any security gains from SuPHP, on my setup the default value is 200 and can confirm setting both of these values to 500 still enabled the changes in the admin UI to be saved.

So this should do it:

suhosin.request.max_vars = 500
suhosin.post.max_vars = 500

Cellar Door’s picture

Cellar Door CreditAttribution: Cellar Door commented
Category: bug » support
Status: Postponed (maintainer needs more info) » Closed (works as designed)

Just saw this.... good to know as this has come up a couple times in the IRC room. I'll be sure to reference them to this post in the future.

Marking as closed as it's not an omega thing but a server setting.