Closed (outdated)
Project:
Domain
Version:
6.x-2.11
Component:
- Domain Theme
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
7 Jul 2011 at 13:39 UTC
Updated:
3 Sep 2024 at 22:38 UTC
Jump to comment: Most recent
Comments
Comment #1
skizzo commentedI stepped into the same problem few days ago. Simply re-saving the main site theme configuration (that is: admin/build/themes/settings) fixed it for me, in Garland.
Comment #2
LoyC commentedYes it fixes it, but after adding another domain I got same problem. Temporary fix is chmod files/color/ folder so that module can't write and delete theme information, but I think this is a bug and should be fixed.
Comment #3
agentrickardI don't know that it is fixable. This keeps coming up over and over again.
It's a problem with how color module stores data.
The 6.x branch is essentially critical bugfix only, so I don't intend to even look at this issue unless there is a patch.
Comment #4
agentrickardBTW: I think this only happens if the main domain isn't set (is using 'default'). So the fix may be to simply save settings for the primary domain first.
Comment #5
agentrickard*crashes* is the wrong term here.
Comment #6
agentrickardSteps to replicate.
-- Set the primary domain theme.
-- Set a secondary domain theme to 'default'. It will inherit settings from the primary domain.
-- Set the secondary domain theme to something other than default. It will remove the settings for the primary domain.
If you can figure out how to stop this behavior, go for it, but color.module is a nightmare.
Comment #7
agentrickardYou might be able to trick this by removing the 'Bluemarine (default)' option on domain-specific settings forms. Just replace it with parameters that are 1 off. (e.g. #dc1234 becomes #dc1233). That should fool color.module.
Comment #8
agentrickardWell, it does fool color.module, but then it thinks you have saved a custom theme.
Comment #9
dqd