The display toggle settings for the following elements does not get saved as part of the export code

Site name
Site slogan
User pictures in posts
User pictures in comments
User verification status in comments
Shortcut icon
Main menu
Secondary menu

When you then install the theme on another site, or revert the theme settings to the code defaults in an existing site, the display settings for all of those elements get lost, and revert to being set to display=true. This means that, for example, if you are working on a theme locally, and then then you export all of the theme settings to code, and go to your live site and revert to suck in all of your changes, things like logos and navigation suddenly start to disaply where they had previously not been doing so. The result is an incredibly broken looking theme with 2 sets of menus and logos (I'm using the logos and menu blocks provided by delta_blocks rather than the theme variable based ones.

My guess is that it's because these settings arte provided by the core, and not by the theme - but even so, if that were the case, why should revering a themes settings back to those defined in code then also revert the display settings for theses elements?


fubhy’s picture

Status: Active » Postponed (maintainer needs more info)

Are you speaking of the Delta export feature or the Omega tools export feature for the plain theme settings? Delta exports work... Omega tools is not yet working with 3.x and I do not recommend using it yet because it can cause problems (nothing bad, just headaches).

So I guess you are speaking of the Omega tools export?

mrfelton’s picture

Status: Postponed (maintainer needs more info) » Active

I'm talking about the 'export theme settings' fieldset that appears on admin/appearance/settings/alumni - which I think is provided by Omega Tools? It seems to work very well, with this one exception (that I have noticed)

fubhy’s picture

Status: Active » Closed (won't fix)

Yep... Omega tools still has some minor problems. I will release a fresh version with a lot of cool stuff really soon but for now you have to take it as it is I am afraid :/.

Delta exports work tho! So if you export your Deltas you should NOT experience that bug. Please check that and report back in any case. I will place a note in here as soon as Omega Tools is released.

mrfelton’s picture

Status: Closed (won't fix) » Active

Ok, but...

Delta provides you with a way to set different theme settings based on contexts. However, with context I can not see a way to specify that the 'default' site context should use one set of delta configurations, and that other sections (say, a landing page, or set of paths) use another.

You can use context to *override* the *default* theme settings by using a delta preset when specific conditions are met. But what about the fallback? ie, when none of the specific conditions are met? In this case it would fall back to the theme's default settings, right? - the non-delata managed ones, and it is with these default settings that the problem exists.

If I can have the default theme settings managed by Context, then its not a problem, but I don't think there is a way within context to define a context that should apply when no other contexts satisfy any conditions, is there?

I'm not sure that this ticket should be marked as won't fix, as the problem is a legitimate and valid problem. When you revert the default theme settings, some of the display toggle settings are lost.

fubhy’s picture

Status: Active » Closed (won't fix)

This is a won't fix for Omega because there is just no problem with Omega. This problem is related to Omega Tools and the fact that it is not functioning right with the latest 3.x version of Omega. If you want to use the features of Omega Tools you should wait until we have a proper release for that. You have two options:

- Export the settings with Omega Tools and manually place them in your file and then fix them manually (re-read them and make sure they are correct and contain the toggle logo, site_name, etc. settings).

- Use Delta with Context in a SITEWIDE CONTEXT! (yes you can tell a context to be active _always_ by setting it to "sitewide" context). In this long run this is not preferable because its always good to have the true theme settings as base.

I repeat: There is NO! problem with Omega (the theme). It is working 100% accurately with all theme settings and does NOT have any bad impact on what you are describing here. This is ALL and ENTIRELY related to how Omega tools exports the theme settings => Omega Tools fails here. And since you are reverting to what Omega tool exported you as theme settings before those toggle settings are (of course) lost.

This is a "won't fix" for the Omega issue queue because there is just nothing wrong with Omega and there is also no reason to keep this active for Omega tools because the new version is already on the way and has completely new code so it won't have this problem anyways.

For now you should just do it manually and uninstall Omega tools if you don't feel like debugging it all the time.

fubhy’s picture

I suggest you just do it manually ... It is really not much of an effort to write the theme settings into your .info file by hand (remember, you only have to do that once!). The fact that exporting the base theme settings (not deltas) does not work at the moment sucks, i know, but I have too much other stuff to do and dont want to waste my time fixing a bug that is not going to be in the final 3.x release of Omega Tools anyways.

mrfelton’s picture

Fair enough. Thanks for the detailed explanation. I think I'll just add those settings to my .info file manually.

I knew about sitewide contexts with context, but context doesn't yet provide a way to weight contexts. So, if I had a sitewide context which loaded in a set of delta base settings for my theme, I don't think there is any way to guarantee that the settings of another context would override that one. I mean, you can have multiple contexts applied at once. So, if the sitewide context is active, and so is some other context, which one takes preference in regards to delta settings?

fubhy’s picture

The only solution for weighting contexts right now is to order them by name by preceding numbers or something. Thats how context sorts it currently. Regarding that you are right! Deltas can override each other without a problem though.

JThan’s picture

Project: Omega » Omega Tools
Version: 7.x-3.x-dev » 7.x-3.0-rc4
Status: Closed (won't fix) » Active

Changing this to Omega Tools Project. It happened to me on a new install today. So this is still a bug :)

danbohea’s picture

This is still a bug. The shortcut icon settings get lost too.

If I write these settings to .info manually, will a future export overwrite my manual changes?

danbohea’s picture

Ah, just answered my own question. The settings get written to .info just fine so I'm guessing the issue is with the reading back in of the info file? That would make the suggestion to manually write your settings in #6 kind of pointless?

danbohea’s picture

Wow, not really used Delta before. While it feels like using a sledge hammer to crack this particular nut, it does look very, very cool. Theme settings in Features! YES! :D

dbassendine’s picture

I'm seeing this issue too. The "Toggle Display" and "Logo Image Settings" settings are saved to the .info file, but they're not being recognised when theme settings are reverted. Instead, the theme just reverts to its default settings (eg. the default logo).

mkadin’s picture

I can confirm this happening with zone weight as well. .info file looks good, but reverting to those settings isn't working properly.

draenen’s picture

Status: Active » Needs review
434 bytes

The problem is that some settings are stored as global theme settings. The global 'theme_settings' variable needs to be deleted in addition to the theme specific settings variable.

A patch is attached.

Note the following from theme_get_setting()

The final setting is obtained from the last value found in the following sources:
- the default global settings specified in this function
- the default theme-specific settings defined in any base theme's .info file
- the default theme-specific settings defined in the theme's .info file
- the saved values from the global theme settings form
- the saved values from the theme's settings form

DamienMcKenna’s picture

Deleting the global setting could be (slightly) dangerous as Omega Tools doesn't export those settings, only what is defined for the individual theme. I'd wager this should be either a "won't fix", or "needs work" and expand OT to also export all non-overridden values from the main theme_settings variable too.

draenen’s picture

Status: Needs review » Needs work

Yeah, this is "needs work" to export theme_settings also. I like to maintain all settings in the .info file for source control instead of using the UI. The revert tool is basically useless if it doesn't revert global settings as well. I'll work on a better patch as I have time.

joelcollinsdc’s picture

Title: Some toggle display settings lost on revert » Better handling of global theme settings
6.13 KB

So I would agree that it is definitely confusing that once you export theme settings, the global settings that are overridden in the file are lost. I made a patch that should provide the user with better guidance, and fixed some other issues along the way...

  1. Allow the user to delete the theme_settings variable
  2. Warn the user when reverting theme settings if there is a global variable that exists that will override exported theme settings
  3. Prevent the omega tools action buttons from showing up on non-omega themes
  4. Provide the user a way of telling if the theme settings are overridden or default.

Hope this gets accepted!

joelcollinsdc’s picture

added a some rubuild theme calls after clearing out the variable

joelcollinsdc’s picture

fixed some errors, added some more description text

joelcollinsdc’s picture

Status: Needs work » Needs review
joelcollinsdc’s picture

Version: 7.x-3.0-rc4 » 7.x-3.x-dev