Appearance check boxes not working

You are talking about theme settings not working?

Can you confirm that other themes settings are getting saved/toggled as it should?

Since the theme is work in progress, not sure if it is supposed to work. Should we keep this open as a reminder or close?

I believe the issue is likely coming from an issue with max_input_vars being set to 1000 now in PHP. There are many issues on D.O. regarding the issue for various circumstances where a form could pass more than 1000 vars for processing.

The latest dev version 'solved' that issue by not passing all the layout data, and only instead passing the one that was selected for editing.

Another alpha will be coming shortly today.

Also, the starterkit in alpha1 was untouched from its previous state and I'm unsure how well it was working...

Give it some testing around with using Omega core as the theme, and see if the issue persists. Otherwise, I have not seen that issue .

@himerus thank you. What commit tried to address this?

Check your local settings: php -i | grep max_input_vars If your setup uses more then one php.ini find them by running php --ini.

Not sure which of the many latest commits addressed the max_input_vars issue. However, when I was running into the issue, the entire system failed, and it was obvious when the error was triggered.

The latest dev version and newly packaged alpha2 version do not have that issue in my testing.

Please re-verify issue exists in latest release(s).

@Internet Could you take latest dev for a spin?

I believe the issue you are now experiencing may be because the .yml data for the layouts (front, primary) in the starterkit may be out of sync with the generated SCSS/CSS for the layout in the repository.

When saving a layout (one at a time mind you), the backend does a check to see if the settings passed matched those in the layout.yml and layout-generated.yml settings variables. If the SCSS/CSS was out of date, it would require changing at least one region width type setting for the layout in order to do a full regen and save the new layout CSS.

So for testing, on one of the layouts in the starterkit, edit the width of all the preface or postscript regions, and then hit the "Save & Generate Layout" submit button, and see if it works. It should throw messages if/when the SCSS/CSS files are overwritten. If it doesn't, then it's not actually performing the regeneration.

Assuming a layout has been properly updated, you should see the following in $messages;

• Layout front updated: omega_starterkit.layout.front
• Layout front updated: omega_starterkit.layout.front.generated
• SCSS file saved: themes/omega/starterkits/omega_starterkit/style/scss/layout/front-layout.scss
• CSS file saved: themes/omega/starterkits/omega_starterkit/style/css/layout/front-layout.css
• The configuration options have been saved.

I'll be working some more on further testing with the default starterkit, creating a new, slimmer starterkit, and sub-sub-theme test tomorrow and getting another packaged version out quickly.

So I'll at that time ensure that the default installed layout settings, and CSS/SCSS match up as they should. I'm sure that's what's going on as once I uninstalled/re-installed the starterkit, the front layout is displaying postscript at 6/6/6/6 and the settings reflect 4/8/8/4 respectively.

Setting this to fixed. All configuration options are saving as expected now in Omega core and subthemes as requested.

If there is a persisting issue of discrepancies between the layout settings visible in the Layout Builder interface, and what is rendered on the front end, a separate, more specific ticket should be created.