Drupal 7 - Preserve Mode Not Working as intended.

I can confirm the bug with 3.0 on three separate websites.

Just tried editing the settings array direct in the database. From what I can see, I suspect that the issue is the Delta UI. The entire settings array had been stored. When I manually edited the settings in the database, leaving only the settings I wanted to override, it all worked as expected.

I'm assuming the same will also be true of Delta's defined in code (just about to test), so I hope that helps some people.

same problem .... it is kind of annoying to create several deltas and then make a change to the base layout and not see it reflected in the deltas ;-(

I am also experiencing this same issue. Thank you to whoever is looking into it. I'm able to just manually override any changes as I don't have that many Delta themes right now, but this would be a nice feature to have.

If you're able to do things through code, you could create sub themes, though if you've got code access I would suggest creating the delta in code, as then overrides do work properly... Other than that I'm not sure...

Added link to duplicate issue.

Closed #1305584: Preserve mode appears to only preserve from when it was created. and #1319284: Drupal 7 Omega - Preserve mode Not working with Delta as duplicates of this issue. I unintentionally edited the issue summary as well, but that's been reverted.

I tested this with both parent and child Delta Templates, and this is a reproducible bug. However I found a temporary workaround:

Once you have created your Delta template with the changes (for instance I changed the column numbers for my sidebars), click "Export" to see the array that andrewbelcher is referring to. I then removed all the code that didn't have to do with sidebar_first, sidebar_second, or the content area settings. (attached).

I then imported this code as a new Delta template, and used that instead. Just delete the original one. I made a change to the original theme settings, (adjusted the footer region widths), cleared the cache, and this change was reflected on the pages using my new Delta template, as expected.

@starryeyez024 I just tested your workaround and it worked well. I didn't even have to clear cache. Thanks for finding a "temporary" fix.

+1 on this issue - I've not tried @starryeyez024's workaround, but it would be nice not to have to do that for each Delta.

Just an update on starryeyez024's work around - I tried it out, and it does indeed work - once.

If you make *any* changes to the delta, and hit save, further changes to your root theme settings are ignored/overriden by the delta.

Anybody know if this has been fixed? I'm using a subtheme of Omega and almost all of my delta layouts went tits-up last night. In both preserve and override modes, theme regions have been set to one column wide and weights to -50. When I go in to change them back to their former settings, the configuration doesn't save (though things still look right in the Export view). I'm pulling my hair out. Anybody know what might have caused this?

This is going to be part of the overhaul of Delta in the upcoming releases. The vision for it isn't fully executed but should be fixed in future updates. Till then it looks like we'll have to track the deltas separately and keep them updated on their own (PITA I know).

Fubhy has a clear image in his head of what has to happen, I'm not sure I know the full extent but try finding him in IRC to figure out the method and if you can create a patch it'd be greatly appreciated!

joelsmith - I'm not sure I've ever seen that happen before. Maybe the variables table was touched by another module that edited the wrong entries? Sorry to hear it happened!

Any idea how to fix such a thing?

Has any progress been made on this? The lack of this feature really makes development a big PITA.

I suspect this has something to do with the delta_reduce function which is supposed to detect differences between settings in the delta and the original theme. Were the delta's which do not update by any chance created against an unsaved theme? In issue #1619360: Error when saving new delta. (delta_reduce) we discovered that (at least for omega) the base theme settings don't contain any data until you save them (not sure if a change is neccesary). This means that all settings in the delta (so all settings for the theme) are different from the base theme if you create it before saving the basetheme and so all possible settings get stored in the delta.

Does this problem also occur when you create a new delta from a changed base theme? Saving your old delta would call delta_reduce but since it's settings are different from the base theme these differences are stored anyway, but a new delta would contain no data in the first place so it should only store the differences from the base theme.

You might be on to something there. Previously I have not been saving the base theme to its theme.info file. I'll try that later today and let you know.

A new fix was just released for the delta_reduce function. See if this helps... if not let us know and we can look further into it

I'm running into this problem in beta11. None of my changes in "Preserve mode" are reflected within the context I've assigned. Only the original settings seem to take effect.

Sorry, my mistake. Everything's fine now. I had a context set to "site wide". That's why things weren't changing. My bad.

I've just tested this on beta 11, and noticed values are preserved - provided there is a cache clear.

For all those not reading this thread, it would be helpful if they could have a warning message after changing an omega theme or a delta template with children. Something like "Flush theme registry required"

#22 - I'm not sure this would be useful, or annoying. Generally, anyone who themes will know that after a certain change the theme registry will need to be cleared.

Also, this particular comment should really be a new feature request - it doesn't really reflect this issue :)

I'm encountering this problem in beta 11, with base theme settings and delta settings both exported to code and delta in preserve mode.

As a test, if I edit the base theme's .info file to show the site name, the base theme shows the site name but the delta theme does not (clearing all caches).

A delta export includes all values, which will override everything. Presumably there's no way for delta to figure what is overridden if all values are exported.

Hand-editing the exported delta settings to contain only relevant changed values works, with the caveat that if you change settings for a region you are effectively overriding all settings for that region, not just the single changed setting.

This is also very error-prone. In my case getting it wrong may result in a non-expandable region settings fieldset on the delta configuration page.

Hand-editing the exported delta settings to contain only relevant changed values works, with the caveat that if you change settings for a region you are effectively overriding all settings for that region, not just the single changed setting.

Not true, you can override a single region setting in code. But to reduce the likelihood of error, my recommendation would be:

A Delta export in preserve mode should include all settings, but settings that do not override the base theme settings should simply be commented out. Or perhaps there should be some other syntax to define a non-overridden setting.

Well that's weird. Now I am getting an export of only the overridden settings. I was definitely getting all settings a while ago.

I still think exporting all settings but commenting or marking non-overridden settings would make management in code easier. You'd be able to override or revert a setting directly, without using the UI, and without needing to compare anything with the base theme .info file.

I'm new to using this module so I might not be getting the full picture. IMO, the approach is flawed. Wether the export includes all the settings or not is not the problem. The intent of preserve mode should be the default and there should be clear indicators on what the delta settings are overriding.

The two choices (preserve vs. override) results in the same end-effect. The choice is only telling it how the data should be stored which shouldn't be a choice at all.

A lot of gray areas can appear as the base settings and deltas are changed. There is no clear connection on how the settings (base vs. delta) will interact in preserve mode and the override mode changes way too much which can become a maintenance nightmare.

Have one mode but show very clearly what has changed from its base settings.

Thanks for the issue summary update @dvessel, apparently I didn't revert my change after all (#7).

I was digging into this over the weekend and found out why it's so inconsistent about the exports.

If the default theme settings are never saved, it has no clue about what the settings are. Try to revert the default theme settings and do an export from a delta and you'll get everything. Save the default settings and try it again, you'll see only the differences.

This is because of delta_injection()->presave() within delta_injection.inc. It uses `variable_get()` which will not be set unless the default theme settings are saved into the db. Core's `theme_get_setting` takes care of reading the saved db settings and falling back to the .info settings but this module doesn't do the same.

@#29, thanks, thats the problem. You can't have your theme settings exported if you want to create a delta in preserve mode.

+1 for getting this fixed...

Can someone chime in on how to go about a patch for this? theme_get_setting doens't seem to be an option... there has to be a way to get all the theme settings for the theme in question, right?

Removed link in issue summary referencing this very issue.