Cannot colorize more than one domain at any given time

You have several issues going on here, and have not provided enough information.

1) Where does the js file come from? Is it part of the theme? Something you reference in a template? Are you serving compressed JS files?

You may simply need to copy a version into the other folder, as we had some issues with how color.module moves (or cannot move) certain files.

2) Not consistently

Well, that is unhelpful. _When_ does it occur? _When_ does it _not_ occur?

3) should one expect a big difference in terms of performances

No, you should not.

What do you mean? Do you have benchmarks? Are you experiencing problems?

The problem is probably in http://api.drupal.org/api/function/drupal_build_js_cache/6 or http://api.drupal.org/api/function/_locale_rebuild_js/6.

You may not be able to use JS caching with theme-specific files.

1) I am not sure where the JS file came from. but indeed after disabling JS optimization I could not reproduce the error anymore. IIRC in D5 I could have excluded specific problematic JS files from consolidation, but in D6 JS optimization (in core) works as "all or nothing"

2) With JS optimization turned on the error occurred, sometimes, when saving the domain's theme settings (right after changing the Garland colour). With JS optimization turned off I don't see the error anymore, but still colorizing doesn't work fo me: when I colorize the domain-1 theme the directory domain-1/color/themename-xxxxx is created. I then move to domain 2 and domain-2/color/themename-yyyyy is created, but at the same time domain-1/color/themename-xxxxx gets removed. This is on unpatched rc8.

3) I don't have any benchmark. I have a setup based on multiple themes and it works nicely. I thought that using rc8 (theme setting, color, logo, etc...) in conjunction with domain_block I could achieve the same functionality, while simplifying administration. I also hoped that moving from N "cloned" themes (one per domain) to 1 single theme would benefit performances, but as I understand that is not the case. Thanks.

Are you using Garland or another theme?

Garland

From which path are you creating the new color schemes?

I tried creating the new color schemes from both main and non-main domain.

Could it be that the problem shows up when the theme name is equal to the domain name?
In my case the Garland theme, and theme directory, had been renamed to "foo"

It might. I never had this problem.

I am closing this issue, as it seems to be related only to my very specific setup.
I will also switch back to the previous multi-theme configuration, and re-enable
JS optimization. Thank you.

Well, this sounds like a good bug report, and I'd like to fix it if I can understand what is going on.

It doesn't look like a naming problem. I disabled all themes but one, which I renamed to something different from domain name. Then "Reset themes" (from page build/domain/batch). Verified that "Theme settings" (from page build/domain/batch) were pointing to renamed theme. Then moved to admin/build/domain/theme/themename/1/theme-settings (from main domain URL) and set color. Color directory is created in domain-1/color. Tried to do the same for domain 2: new directory is created in domain-2/color and previously created directory disappears. I.e.: I can't have more than a single color directory at any given time.
My domain name scheme is: foo.com (primary), one.foo.com, two.foo.com, ...
I changed the title issue to better reflect the nature of the problem.

I don't have this problem, and it took me weeks to get it working with core. But you are using contributed i18n module(s), right? I wonder if they are interfering....

We have to do quite a bit of variable juggling to keep from deleting the color directories. It is possible that you are using a module that interferes with this process. One of the key elements is in domain_theme_settings():

We also have to be very careful about the execution order that the form is processed in. Our function has to fire last, and the core theme submit handler cannot fire at all. See lines 144-151 of domain_theme.admin.inc:

So you may need to print the $form and look to see what the execution order is.

For more debugging, watch the function color_scheme_form_submit() which is responsible for deleting those directories. The code is in lines 276-282:

You may also need to set the default theme at least once, to something other than Bluemarine. Check what is being saved into the {variable} table (with the prefix color_) and to the {domain_theme} table.

Attached are proof pics.

Attachment	Size
Picture 1.png	19.33 KB
Picture 2.png	12.41 KB
Picture 3.png	12.16 KB
Picture 4.png	11.4 KB

No, I am not using i18n; only core Locale module. I am sorry but I can't do real debugging, only functional testing... I also noted that, when switching back from single (multicolor) Garland theme to multiple (colored) Garland themes, I could not make use of the batch admin page (foo.me/en/admin/build/domain/batch/site_theme), as I would get the following error:

I could however set the themes, one by one, selecting the "Default" checkbox in foo.com/en/admin/build/domain/theme/ID; then the batch admin page would report all the correct theme assignments. Thanks.

Well that suggests a database problem.

Why don't you uninstall Domain Theme and start over?

Is there a way to uninstall a single component, Domain Theme, leaving the rest of my Domain configuration untouched? (I can access my DB via phpMyAdmin)

Domain Theme is a standalone module and should be installed/uninstalled as such. @agentrickard is talking about uninstalling and reinstalling not disabling the module. Use the module listing page to disable and uninstall Domain Theme.

To be clear: Uninstalling Domain Theme will not affect the other modules in the Domain Access group.

Doh... anyway, I tried to start from scratch but still have problems:

1) disabled Domain Theme
2) unistalled Domain Theme
3) disabled all themes but one (sticking to a basic Garland, renamed)
4) enabled Domain Theme
5) set theme color to Ash (core theme configuration)
6) set all admin themes to my single enabled theme, via domain batch admin
7) from domain/theme/1 checked the only "Default" box, and clicked on "Set domain theme"
8) moved to .../1/theme-settings: the page shows up ok, but with "no theme color" (i.e.: white)
9) same as above if I enter .../1/theme-settings from main domain
10) I go ahead anyway and set scheme to Belgian Chocolate (from main domain)
11) I check domain-1/color: indeed the new color directory is there
12) I navigate to domain-1 home page, but it's "colorless"
13) I enter core theme settings, as in 5), from main domain
14) the page shows up with color scheme Belgian Chocolate
15) indeed the original Ash color scheme has been overwritten with Belgian Chocolate
16) I enter main domain homepage: it's Belgian Chocolate
17) I enter domain-1 homepage: it's colorless

The rest of my domain configuration works fine, but for some reason colors get "mixed up".
It must be a real pain in the neck to juggle with all these variables! It's a pain for me too,
as I had to return my mobo, and now I am on a 10 years old PC. Lots of JS timeouts :-)
Let's see if someone else steps into similar issues. Thank you.

I can only assume that something is stepping on the form submit handlers.

You are using the core color module, right? Not the "next gen" color module.

Any other theme related modules in your install? Other DA functions work as expected?

yes, I am using the core color module. I went through the list of enabled modules but don't see any theme related module, barring Domain theme. Tried to disable formfilter module, but that doesn't help. All other Domain Access functionalities are working smoothly; also Domain Theme works fine, when used with multiple themes. Have a nice weekend!

Does this patch help --> #527426: Cannot change domain theme settings (directory /domain-%id doesn't exist)

Yes, it does. Now everything is running fine. On a side note, I noticed that when removing a useless theme directory a large number of records referencing the deleted theme remain in the blocks table, 1 additional entry is also left in the variables table (theme_themename_settings). I assume that it is safe to manually delete those entries, right? Thank you.

I don't understand the second part of that. I believe that reloading the blocks page should rebuild the {blocks} table. It used to.

Those are core Drupal issues, not DA ones.

Automatically closed -- issue fixed for 2 weeks with no activity.