add theme settings configure page to domain_theme,

Will try to test next week, when back in the office. We initially passed on this feature in order to produce a stable release, but it is worth doing.

Did you use the existing 'settings' column in the {domain_theme} table? That's why that column is there.

just used it.

Please follow Drupal coding conventions.

The coder modules is your friend. Use it please. There are stub functions commented out here, misuse of spaces, tab stops. Not acceptable.

Subscribing, very interested in this also for Drupal 5!
greetings,
Martijn

What I would like long term is to list all the domains with the main theme settings as columns. If the Domain Theme module adds a row per domain with all the settings as a blob, I might work on an extension to move logo and other common fields out of the blob into separate columns.

An alternative might be a list that decodes the blob into a report we can use to find out what each theme contains so we can find the right sites when we want to change themes.

The following code in domain_theme.zip will pick up the settings from a random theme entry when the domain is not specified and more than one domain uses the specified theme. An improvement might be to order the result by domain_id ascending and select the first row so that the result is always from the first domain using the theme. Use limit 1 to return just the first row when there are many domains using the same theme.

I tweaked the code to apply against version 6.x-2.0rc5, cleaned up the formatting, and made a fresh patch, which is attached. Note that this isn't my code; it's the same as before, just a bit prettier. The functionality I actually wanted was to be able to configure per-theme theme settings per domain, and I may try to extend the patch further to accomplish that objective.

This version is updated with the functionality described in my last comment. Now, if a theme has been set for the domain, that theme's settings page is loaded in place of the default global settings page. Otherwise, it's the same as the last patch.

Nice work.

Is it possible to add more settings to change a theme like colour or fixed width size? Or would it be easier to copy the themes with a unique name for each site?

Themes can add additional settings via the Theme Settings API, and my second patch allows that behavior, so making domain-specific copies was exactly what I was trying to avoid.

this looks great functionality.
Will it be committed?
Thanks a lot in advance for considering!

Greetings,
Martijn

subscribe, looks good. When wil this be commited?

Has anyone actually tested it against HEAD?

This patch seems to work (rc5)
Only problem is that the domain_theme_settings_submit only implents a update query. Not an insert if no record exist in the domain_theme table.

Properly formatted patch. Untested.

Here is a working patch from domain root. There is some related menu cleanup to be done. But the patch seems to work.

Note that you can only have one active theme per domain.

Perhaps we should kill the 'configure' link for non-active themes?

Here is a more advanced patch, against HEAD, which allows per-domain settings per theme.

Requires running update.php.

I tested this with core themes, plus RootCandy, and was able to set the rootcandy icon size per domain. Nifty!

This patch will not allow color switching with Garland, because Color module doesn't seem to support having more than one set of files per theme.

We _could_ copy some logic from color module to rewrite its behavior, but I am not crazy about that idea.

Here is a patch for testing -- note that Color module forces us to re-order the menu entry, too.

This patch tricks Color module into saving multiple directories, but we still have an issue because Color module's unique variables are not being loaded properly.

Removed the debug krumo().

This versions is oh-so-close to working.

Still having issues with Color module deleting directories and not saving the proper logo file (or information).

Testers?

This version fixes the color module issues. Remaining to-do:

1) Uploaded logo files are not given unique enough names -- that is, all 'garland' theme logos are saved in 'files' as 'garland-logo'-- is there anything we can do? Perhaps temporarily set the files dir in $conf to 'files/domain_id/'?

2) We need to store the 'files' directory in the {domain_theme} table. That way, we _can_ delete directories that are not in use.

Mostly working patch -- anyone care to review?

agentrickard,

The patch you posted didn't work for me, but I think it is because I had the previous version of Domain Access installed. I will try my best to explain what I see.

Here's what I did. I used Eclipse to extract the latest Domain Access out of CVS as a project. Then applied your patch to Domain Access -- it said that it was 100% successful with a fuzzy factor of 2.

Then I zipped up the entire domain access module including the new Domain Access.

I turned off Domain Access in the modules, deleted the module -- unzipped the new CVS level, turned it back on -- ran update.php -- which did update some tables in the DB.

So far this all seems great.

Then I attempted the scenario that I care about -- I need to use the same theme on all my sub-domains but change the Logo image. So I went to my two domains and proceeded to set their default themes in the new Domain setup area. I made each domain directly point to a new image and then proceeded to test.

Neither of the two domains would honor the new logo info -- and what makes things even more interesting is that the template wasn't even coming close to honoring it. In fact, I noticed that it was returning a fully qualified path to another logo that I had tried to use on the previous version of Domain access when I attempted this feat before.

This suggests to me that I either have something that I need to clean out of my Database, or there is still something a little fishy with this module.

I tried dropping the domain_theme table and redoing all the previous steps (other than update.php) but that didn't seem to fix it either.

Any suggestions?

Did you read #23?

Logo image is a known issue at this time, since the auto-upload feature will name the file the same thing for every domain (something like 'logo-garland.png').

If you have logo files on the server and enter the path (not using the upload feature) it should work.

Firstly, thanks for the efforts so far :)

However I'm getting an error when trying to customize my site's theme:

Fatal error: Call to undefined function color_get_info() in C:\xampp\htdocs\sites\all\modules\domain\domain_theme\domain_theme.module on line 271

I'm using the latest 303406-theme-settings.patch, applied against the domain_theme from /head

One important thing to mention: I'm using the 'next gen' color module (color_soc08) here: http://drupal.org/project/color_soc08

I'm also using my own custom-developed theme.

More than likely it's something I've done wrong, I'll try and investigate the problem and will post back if I get anywhere.

[edited: more information]

I re-added the color_get_info function (from drupal 6's color.module) to the color.database.inc that comes with color_soc08:

Then in line 280 of domain_theme_module I then had a php error - the $theme parameter passed to array_key_exists is not a string. I guess my patched-in color_get_info function changed the value of $theme to an array rather than the theme-name - my hack was to re-issue the statement $theme = arg(4); before the call to array_key_exists. This caused the error to go away.

However, the next barrior seems to be the color module - which appears to be unsupported by domain_themes at present. The individual color-schemes that a color-module aware theme can support do not appear to work under the control of domain_themes (selecting color schemes always reverts back to the default).

I will try and find a solution, but my drupal/php knowledge is very limited. Apologies if my comments and work-arounds seem a little amateur-ish - I'm very new to drupal!

It works and has been tested with core D6 color module, not the version you are using. I have been able to get Garland to change colors without any of the errors you report.

I do not plan to support Color Next Gen at this time. Note from the project page:

Not for production use yet! Under active development. Documentation and code are changing. Refer to the Handbook for the latest color.module syntax!

Back to the work at hand.

Here is a patch that _almost_ works as desired. It forces each domain to move files into a specific directory (files/domain-1, files/domain-2 and so on) and fixes the naming issue with logo and icon uploads.

Still to do, if possible:

1) Delete unused color directories inside the domain-x folder. Right now, these just pile up, creating a new directory for each configuration. The core files/color directory continues to store only one copy, though.

2) Try to make it work with modules like Vertical Tabs, which have their own CSS files to copy. The problem there is that VT module reads the variable value for the color directory from the main site, and, due to the way forms are processed, I don't think we can force it to recognize our directory correctly.

So it may be that this gets committed as is, with some caveats.

The Vertical Tabs issue may be unsolvable, as that module writes to the variable table and we cannot control it.

This patch seems to work.

Note that with this patch, you must configure the primary (global) theme from the primary domain.

This is exactly what I have been trying to achieve with Domain Access! However I can't quite get this patch to work.

I've done a fresh install of Drupal, added domain access module and patched the files in the domain_theme folder, when i go to edit a domains theme settings ( admin/build/domain/theme/subsite/2/theme-settings) I get an error 'The directory /domain-2 does not exist.'

I've tried creating the directory 'domain-2' in sites/default/files, site/all/files and various other places but it still gives me the error...

Adding the filepath of a logo file and submitting the form gives the following error:

* The directory /domain-2 does not exist.
* The settings have not been saved because of the errors.

Any ideas?

It should just append that value to whatever you have configured your files directory to be. You should not create the directory manually, it should be created for you.

You are using Public file method?
You ran update.php (or installed the module after patching domain_theme)?
You rebuilt your menus?
The 'files' directory is writable by the webserver?

Committing to HEAD.

For reference.

I installed 6.x-2.0-rc7 and received the following error. Below is a patch against 6.x-2.0-rc7

Fatal error: Call to undefined function color_get_info() in /home/alliance/public_html/sites/all/modules/domain/domain_theme/domain_theme.admin.inc on line 133

This happened because I do not have color.module enabled, so the color_get_info() function doesn't exist. I see above that the same error occurred due to Color Next Gen module, but I am NOT using it or any other color related module.

I inspected the code and thought the use of module_exists() was appropriate and I consolidated all of the color specific code within an if statement and removed the return statement. I patched the code and tested with and without the color module enabled with success.

Please let me know if I should create an entirely new issue instead of re-opening a "fixed" issue. I didn't see any details in http://drupal.org/patch/submit about the proper protocol for handling a "fixed" issue that had a bug.

No. This is a good patch. Color module is on by default so I never tested whether someone would turn it off.

Here is a simpler version of the patch, which simply returns if no color settings.

Commtted! Thanks!

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

Hi there,

I've stared playign around with the domain access module. And I've come across this issue in the latest release (rc8)
According to the conversation and patches it should be fixed, but I still get this error:

"The directory /domain-2 does not exist."

It is a clean install of Drupal 6.12 and RC8

Any suggestions?

Don't comment on closed issues, for one. No one will see it.