Have run into an issue where delta theme settings are not being applied. When I change a setting such as activating/deactivating a library, css, region width, etc. none of the changes take place. When I go back into the settings, the setting are shown as being activated, but they don't actually apply. Basically this has prevented me from making any delta theme changes.

Comments

krisis’s picture

Hi PCateNumbersUSA,

First of all, make sure you clear your cache (admin/config/development/performance) everytime you change your settings. If this question was too obvious, or you have done this now but did not make a difference:

Can you please confirm that your issue might be being solved under this one?

When saving your delta settings, do you receive the mentioned error, if not: set your error reporting on the following page in your site: admin/config/development/logging and set it to 'All messages'. Try to save your delta settings again.

Otherwise, maybe you get a different error. Then post this information in here, and be as specific as you can. Thanks in advance!

krisis’s picture

Priority: Critical » Normal

I propose to lower the priority on this issue. For now, no answer on the posters behalf and it looks to be a duplicate of #1619360: Error when saving new delta. (delta_reduce).

PCateNumbersUSA’s picture

Sorry, for not responding sooner. Unfortunately I gave up fixing the error and simply recreated the deltas, which so far are working fine. The other bug report to sounds similar, but I already had "All Messages" turn on, and never received an error message.

krisis’s picture

No problem, but if you can and still want to: it would be helpful to have a list of steps and/or results which would explain the problem in more detail or could help others to try and reproduce the problem. If not, I'm afraid this issue will eventually be closed due to inactivity. But like you said, the problem can be avoided by building the delta(s) from scratch.

RKopacz’s picture

I have, I think a similar problem. Using Delta with Context and Omega 7.x-3.1. All current versions of context and Delta. Removed the First sidebar in the original theme setting and have been using that look throughout the site. I wished to create a Basic Page which will (eventually) act as a members only dashboard (using Access Control to limit access, which is not yet engaged). I wished to re-add the First sidebar to the page, so I created a delta, and then created a context to use that delta. I also changed the widths of the sidebars and content area (was using an 8-4 two column layout, now wish to go back to 3-6-3 just for this page. I am limiting the context to just that path. But it is not picking up the new context which uses the 3-6-3 delta. Note that it is adding blocks contextually, so the context is recognizing the condition and providing reactions. It just isn't providing a reaction for the delta module (ie, still getting

I think the problem is a question of hierarchy. I have created a context applying a two column format Delta to all Basic Page node types. It seems that Context gives that precedence when a context is applied to a node type, over a Path type of condition. It seems to me it should be the other way around (if I have a context which covers all Basic page content types, but wish to exclude one based on path, then I should be able to do it, yes?).

That Basic Page context which applies the two column Delta and seems to be taking precedence is simply providing blocks in some preface regions, and it leaves the Second sidebar region empty.

If anyone has any ideas or can point me to guidance as to Context's system of hierarchies it would be good.

Thank you in advance for any help.

johnpitcairn’s picture

Version: 7.x-3.0-beta11 » 7.x-3.0-beta10

I am currently having a similar problem. It does not appear to be a duplicate of #1619360: Error when saving new delta. (delta_reduce), since I have no error message and no errors in the log. Changes to Delta settings simply will not save. There is no "your settings were saved" message either, so something is preventing the save from happening. Troubleshooting:

Uninstalled all Delta and Context modules.
Reinstalled Delta API and Delta UI.
Add a new Delta, set to "preserve".
Change setting: toggle display > site name.
Save.
Settings do not save.
No save success message.
No error messages displayed or logged.

Change Delta tempate to "override". Same result.

The problem occurs for me on the staging server, but not on the development server, so perhaps there is some permissions issue or a PHP security setting or memory issue that is preventing Delta from saving. Troubleshooting:

Check temp directory permissions: server-writable.
php.ini: comment out disable_functions and open_basedir directives, restart Apache. No effect.
vhosts file: increase php memory limit from 128MB to 256MB, restart Apache. No effect.

I'm stumped. Any suggestions?

johnpitcairn’s picture

Version: 7.x-3.0-beta10 » 7.x-3.0-beta11

>> beta 11

iam_serg’s picture

Version: 7.x-3.0-beta10 » 7.x-3.0-beta11

I'm having a similar problem. I change regions and zones to -none- and nothing happens. I get message that the settings have been saved, but they are not applied. However, I can move a region to another zone. And I can move regions that are on the unassigned zones to and from different zones and also back to the -none- (unassigned) zone.
Not sure what to do... Can someone help?

iam_serg’s picture

Upgrading to 7.x-3.x-dev fixed my problem.

Buckle It Up’s picture

I ran into this problem when trying to initiate a Delta snapshot on the server. I tried clearing cache, deleting the delta module and reinstalling a fresh new version. It didn't work...however I did find that changing the default theme to my subtheme before trying to edit the Delta snapshot fixed my issue.

Håvard’s picture

Same problem over here. Sometimes the Delta snapshots work and sometimes not. When saving the default theme no layout is activated, and when saving one of the Delta snapshots, the layout chosen in the default theme is activated in spite of that the layout extension is deactivated (default theme) and it overrides any Delta snapshot (layout extension activated) initiated by the Context module. I´m using Omega 7.x-4.0-beta3, Context 7.x-3.0-beta6 and Delta 7.x-3.x-dev.

estenat’s picture

Same problem using 7.x-3.0-beta11. I verified that context module (7.x-3.0-beta6) is reactive (for example it works disabling a region) except delta option: the default theme does not change. I tested this issue in production (CentOS 6.3, php 5.3.3-14, apache 2.2.15-15, mysql 5.1.67-1) and in a test plant (Acquia DAMP 7.9.9). Omega is not involved because the problem occurs even choosing standard themes. I have enabled ThemeKey, temporarily, because I have to finish a job, but I would have Delta fully operating because it has a great flexibility more than other modules.
However, any further suggestion about the debugging path? It is not so easy, for me, but we have to solve...

metakel’s picture

Issue summary: View changes

I have the same problem. I found that it is the wrong path of the favicon in Windows preventing the delta to be saved.

I have to use Windows style path (i.e. c:\folder\to\drupal\favicon\favicon.ico) to make it work.

quantos’s picture

Hi guys. I have a very similar brand new problem to the above and Iam_serg's #8 issue. I've used and nearly always build sites using Omega/Delta/Context but my problem (since Context 7.x-3.6 at least) is that whenever I remove several Delta Regions (setting them Zone=none) and then Clear Cache's everything (all the multiple Delta region variations) revert back to their previous settings.

I can't for the life of me see what's going on. I can even save all new removed delta variations and restore the backup but that has the same affect: the new changes are all reverted to previous versions. It seems as though the changes are only saved in cache (although I'm not caching any content). I.E. Clearing cache will revert the region settings 100% of the time whereas all changes work fine until then.

Before raising a fresh issue I was hoping one of you guys might have come across this while exploring the main issue "Delta theme settings not being applied."

Modules used are the latest: Omega 7.x-3.1, Delta 7.x-3.0-beta11 and Context 7.x-3.6. On the same site/set-up I'm also using the Domain Access 7.x-3.11 and the Content Access 7.x-1.2-beta2 modules - all of which have worked flawlessly together for over two years. The only other change since the problem surfaced has been a switch to XAMPP 5.5.19 (running php 5.5.19). I haven't seen the same problem on my other Omega/Delta/Context builds (of which we have at least a dozen) so I'm hopeful it's something unique to this particular set-up and perhaps the recently released Context 7.x-3.6 module?

Any pointers/ideas would be much appreciated.

Q.

neubreed’s picture

We just had a similar issue. You can't edit the theme setting of a delta. We copied our theme and renamed it but the delta theme setting was still the old one causing it not to be selected.

The workaround is to export your old delta settings and change this:

$delta->theme = 'your_theme_name';

Delete your old delta and reimport with the new theme associated.

An easier fix is to use phpMyAdmin to edit your delta table, updating the theme to your theme name

SEINEN’s picture

This problem (in my case) has to be in the definition of the Delta.

In Appereance/Delta/(Select your Delta)/Edit

Instead of:
Only override different values

Select
Override ALL values
(This setting controls the way that settings are being stored and overriden.)

SAVE
-This works for me-

twistedindustries’s picture

I've tried multiple different versions and I keep coming back to this topic. I can't get this to work no matter what I do. It looks like the function delta_inject is supposed to handle this but even after messing with it I come up blank. Is $before supposed to return empty? What should this function do?

EDIT: Wanted to update this, in my particular case disabling the block module fixed the issue. However, I need the block module, anyone know a work around?

twistedindustries’s picture

Tracing this down further, I've got it narrowed down to this part of code in theme/omega/omega/includes/omega.inc

if (($cache = &drupal_static(__FUNCTION__)) !== NULL) {
    return $cache;
  }

If I comment out this line everything works properly. Maybe I should post an issue with the Omega theme?