Hello,
I am trying to use Domain Access for a multisite set up in which a few sites will be sharing a large volume of content- 100k+ nodes. The site is primarily based around Views.

Essentially I only really need a couple of things to vary in each site:
1) Theme
2) Navigation (effectively achieved by having different blocks, as that is where my menu links and other navigation sit).
[ 3) I may later also look to change Panels page templates by domain, although this is not an immediate priority ]

With the navigation different, effectively each site would be pointing to different Views (and these to different nodes) and I would achieve the domain based site differences I want.

However, installing Domain Access, by default, seems to create granular domain access rules for each node - whether or not they are needed. This creates a large (and in my case, presumably unnecessary) domain_access table within the DB, and adds complexity to queries.
More problematically, I have also come across the well documented Drupal core bug that causes duplicate nodes to appear in Views (most recently discussed in the Domain Access queue here- http://drupal.org/node/579018)- there is still no agreed solution for this and existing remedies involve patching Drupal core or introducing "Distinct" clauses into views queries- causing serious performance issues. While Domain Access is not the source of this bug, it does unfortunately make domain access unusable at present for any sites making extensive use of Views.

As a solution to this core bug and also as a means of reducing complexity where not needed, I was wondering whether it might be possible to disable node access by domain for the domain_access module? Ideally node access by domain would be one optional subcomponent of the Domain Access module (in the same way, eg, that domain_theme is), rather than a default. I can envisage numerous multi domain use cases where this functionality is not needed, and it would be great to have the option of disabling, in view of some of the complexities it raises.

I'd be interested in any thoughts, and thanks very much for the module.

NB - I'm very new to Domain Access, so apologise if I have misunderstood how the module works. If there is an easier or existing way of achieving what I want please let me know.

Comments

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

See the hooks documented in API.php. You want to disable DA for most cases, you can either stop the records from being written (hook_domainrecords) or from being applied (hook_domaingrants).

For example, to disable DA rules on all domains, do this in your custom.module:

function custom_domaingrants(&$grants) {
  $grants = array();
}

You can do the same for custom_domainrecords(), and then nothing will be written to either {domain_access} or {node_access}.

danieldd’s picture

danieldd commented

Thanks for this advice. I've done exactly what you suggested, and implemented a custom module with these two functions. And great news, the sites work, And the duplicates bug in views/ core appears completely resolved. domain_theme, domain_configuration and domain_blocks work fine with this set up. I will test some of the other domain submodules later.

So thank you very much - I was not expecting it to be this simple!

However, there are still some things that are not fully working that I would ideally like to fix as I'm hoping to implement this on a production site.

Firstly, on install, domain_access still creates a domain_access table and writes domain node records here (in my case I got a PHP memory error during this process, presumably due to the number of nodes - only some of the node records were in fact written). Although once installed, the module does not appear to write further records here on creation of new nodes, nor does it prompt for settings to be rebuilt. Ideally, of course, the module would not create this table on install, or at least not write unneeded records here.

Secondly, domain_access node related forms continue to be exposed in the UI, even though the forms now do not write data to the DB. In particular, node/add and node/edit continues to display "domain access options" and these forms do not submit unless this info is completed. I am wondering if there is any way to prevent these forms from being displayed, now they are not writing data?

Any help you can provide on this would be great - sadly my own ability to solve this one is pretty limited!

I wonder if it might be worthwhile packaging this as an optional submodule within domain_access, as I would not be surprised if there are others with similar use cases?

Thanks again - great module and very helpful advice

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

The tables are there because 99% of users want them. What you are doing is special. Nothing gets written there because of the changes you implemented from #1. It also won't prompt for Node Access rebuild because your version of domain_node_grants() is returning nothing.

See http://api.drupal.org/api/function/node_access_acquire_grants/6 and similar functions.

You can use hook_schema_alter() to remove that table if you like, I believe. But I don't recommend it.

To remove the form, simply don't give anyone access to it, using permissions. If that fails, use hook_form_alter() to remove it from the form. It is also exposed to CCK, so CCK might be able to remove it for you. It should have a default value set, so even though it's required, the form should still submit. (Unless that functionality breaks when you stop saving to the {domain_access} table, which means its your module's responsibility to adapt the form.

The only way to remove these items on install is to abstract the node access parts of the module out into a separate module that becomes optional. That's really not on the table for D6, and I really don't think its going to happen in D7, either.

It sounds like you're doing a multi-site Drupal install using DA as a shortcut. While that's possible with the module, it really isn't supported.

danieldd’s picture

danieldd commented

Thanks very much for this.

Using permissions/ default values does seem to work, so far, in suppressing the "domain access options" form.

Regarding the creation of domain_access & node_access tables (and the writing of records to domain_access on install) if this does not adversely affect the functioning of the site under my set up, I guess I can ignore this issue.

Although one other thing I have noticed- Although no records are created in the node_access table on install, records are added to this table whenever I add or edit a node. Although they do not seem to affect the functioning of the site, is there anything I can add to the custom module to prevent this? Unfortunately solving this issue is beyond my current technical ability.

I realise this use of the module is not supported, but in general, would you expect it to function reliably (without domain based node access as I have configured it) or are there serious bugs/ risks I should look out for? So far, all seems fine.

FYI, I am not looking to use DA as a substitute for multi site. I've used multi site under different scenarios, but as far as I am aware multi site does not allow for (easy) sharing of data between sites. I absolutely need to share (mainly CCK) data across multiple sites. Each site uses different Views to expose different parts of and presentations of, data that sits across the same nodes. As far as I am aware DA is the only module that approaches this potential use-case (although, as you say, it does not support it, or at least not without granular node access functionality). Although if you know of other/better solutions please let me know!

Thanks very much, again. This is a great module and I hope I will be able to use it in this way.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Can you show me the sample data that's getting written to {node_access}? This data shouldn't matter, since if hook_node_grants() returns NULL, then no records are checked.

It could be the 'domain_all' record that we put in there is still present. In that case, your custom_domaingrants() function should probably return:

if ($op == 'view') {
  $grants['domain_all'] = 1;
}
danieldd’s picture

danieldd commented

For each node that is added or edited I am getting the following record added to node_access
nid= 200012 (for example)
gid= 0
realm= all
grant_view= 1
grant_update= 0
grant_delete= 0

Thanks- hope this clarifies

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Right. Right. This is the default value that core is placing there because there is a registered hook_node_grants() function that returns empty results.

See http://api.drupal.org/api/function/node_access_write_grants/6

These are harmless -- they say "Hey, anyone can view this node" -- but you will get one per node on the site(s). The only way to truly stop this is to comment out domain_node_grants(), which I don't advise.

It would be a pretty large change to re-architect the module to not assume you want the node access features.

You can't really do anything about this, since grants are written to the database after hook_nodeapi() runs.

See http://api.drupal.org/api/function/node_save/6

danieldd’s picture

danieldd commented

Thanks very much for the explanation.

Could I effectively just ignore this table then, let the node_access records build up and periodically delete them (at the moment these records are in any case not complete as they are only being added for new nodes, not existing ones)?

With DA set up in this way with the custom module, do you think it is likely to be stable or are there some big issues I should look out for and test before implementing in a production environment? As mentioned, everything seems to work fine (leaving aside the issues I've already mentioned).

In a worst case scenario with the module set up this way, if things don't work out presumably I could still uninstall DA and revert to the single site set up without damaging data?

Really grateful for you advice,

danieldd’s picture

danieldd commented

OK, I've experimented further with the module configured this way. Here is what I have found:
- Generally, it seems to work fine and as I was hoping. I have also tested it configured this way with domain_blocks, domain_theme, domain_configuration and domain_ctools and all of these work as intended.
- The "domain access options" on each node add/ edit form can be suppressed with permissions. Without permissions there is a prompt to fill this form in.
- On installation the module creates a series of domain_access records (and times out due to PHP memory errors in my case). But subsequently no records are added to the domain_access table on editing or adding nodes.
- On installation no records are added to the node_access table, and there is no prompt for settings to be rebuilt. However, when nodes are added/ edited individual records are written to this table. Also when the module is disabled then reenabled there is a prompt to rebuild "content access permissions". This then brings up the bulk updater which (in a lengthy process) writes a record to node_access for each node, as you mentioned above. Should I aim to rebuild these permissions or is it inconsequential whether I do or not?
- The module seems to uninstall cleanly without damaging/ affecting data from the original single site installation.
- The module also seems to work with Boost caching, which I was uncertain about.

So, overall it feels like it is working as I hoped, set up in this way (notwithstanding the -in my case- redundant forms and data added to the database- which I can live with providing this does not affect performance). Although, before I implement in a production environment, just wanted to ask anyone who is more familiar with the module whether there was anything else I should be aware of, or should be testing? This module makes some fundamental changes and I am still a little concerned about the risk of damaging data or implementing something which cannot be reversed.

Thanks again for all the advice and this great module!

andy_read’s picture

andy_read commented

I've been working with Daniel on this issue and we've pretty much settled on this solution.

As previously mentioned, we're using:

hook_domaingrants(&$grants) { $grants = array(); }
hook_domainrecords(&$grants) { $grants = array(); }

I was also using hook_form_alter() to remove the domain options from the node add/edit pages, but have now switched to using the much neater hook_domainignore() (although this hook requires an exact list of forms and doesn't handle wildcards).

A battery of tests have shown that the duplicate values in views have been fixed by the hook_domaingrants() taking node access out of the circuit. All other domain access functionality seems to be working fine, including switching themes, blocks, etc.

Reading around the various discussions mentioned above seems to be an absolute minefield with regard to node access producing duplicate results or potentially poor performance due to excessive use of distinct generated by db_rewrite_sql(). However I'm aware that the DB layer and Node Access functionality have had a significant rewrite in D7. Are core developers confident that these long-standing problems are fixed in D7?

These significant changes certainly add further weight to agentrickard's argument in #7 that it's not worth trying to do more to tidy up the node access table, let alone re-architect anything.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Active » Closed (fixed)