I'm a bit confused about how this module handles layout for subdomains. Theming works via domain_theme, but if I try to use menus and blocks, changes are only made on the base install, system-wide for every subdomain. I just get a warning that "You are viewing subtest.example.com. This form may need to be entered from example.com".

I tried getting domain_prefix to create new tables for block and menu for each subdomain, but after creating the tables they don't seem to get used at all and I'm not even sure if that's the proper solution.

So yeah, as a feature request I'd like to see Domain Access handle other portions of "Site Building" along with Themes, namely Menus and Blocks, so they can be used individually for each subdomain.

Comments

sign’s picture

Its hoefully all there :)
I think you might missed one step while installing domain_prefix. You have to add one line to your settings.php which will include domain_prefix_settings.inc so drupal will know which prefix to use for other domain names.

Then you have to choose that you want to create new tables for your domain name in domain prefix settings.

Works for me very well. :)

agentrickard’s picture

Component: - Domain Theme » - Domain Prefix
Category: feature » support

I'm going to call this a support request. The Domain Prefix module works in order to prevent the need for duplicating the UI for Blocks, etc.

As sign says, make sure you have placed the necessary includes into your settings.php file.

For Blocks, you need to copy over the three tables listed under Blocks. For Menu, you need both the menu and cache_menu tables.

The warning message about which domain you are on can be ignored if you are using table prefixing for these two elements. It is there as a reminder for certain forms (like Site Information) that may _change_ if you are using the Domain Conf module.

Anonymous’s picture

Thanks for clearing up my confusion, I hadn't caught the instructions from the Install.txt within the domain_prefix directory, my mistake.

It's sort of working now, but it does seem inconsistent, it would be nice if there was a more complete solution. For instance, if I set the login block to "none" it still shows for anyone that isn't logged in unless I set it to at least one role (a workaround, but odd). I suppose it's not much different from a pure prefix setup in regards to menus and blocks.

canen's domain_menu addition helps, it solves any problems with primary and custom links / menus nicely, although they have to be recreated that way.

I have to say thanks overall for these sets of domain modules, it seems I've come to Drupal at a good time. =)

agentrickard’s picture

For instance, if I set the login block to "none" it still shows for anyone that isn't logged in unless I set it to at least one role (a workaround, but odd).

Do you have page caching turned on?

Anonymous’s picture

I've got caching turned off until I get closer to production.

Speaking of which though, how compatible are the domain modules with caching? I noticed that they're highlighted in the Performance admin with a warning about aggressive caching. This is a whole other issue though, so my apologies if it's derailing the topic.

agentrickard’s picture

That warning has to do with Node Access issues -- if you use OG, you get the same warning.

I tested DA with normal page caching, and I think it is ok. node_save runs a cache_clear_all(), so that should be sufficient.

See http://drupal.org/node/191573

agentrickard’s picture

Status: Active » Closed (fixed)
skizzo’s picture

For Blocks, you need to copy over the three tables listed under Blocks. For Menu, you need both the menu and cache_menu tables.

Having installed Canen's domain_menu module I can handle per-domain primary menus without duplicating menu tables. Every menu, primary or not, comes with a block. Blocks are configurable within themes (Garland at least): using domain_theme I can have a domain specific theme, therefore I can configure blocks on a domain-specific basis without duplicating Block tables either. As I am taking this approach, I would like to ask whether there are reasons for not going this way (I am somewhat wary of table duplication)

agentrickard’s picture

No. Your approach should be fine. Although remember that currently, theme settings are universal across all domains. That is, if you use BlueMarine for two of your domains, both of those domains will use the Blocks assigned to BlueMarine.

scedwar’s picture

Alternative solutions available at:
http://drupal.org/node/239989