Show domain 2 content on domain 1 in a block

Here's the problem, and here's why I wanted this issue moved.

You can't do this with Views in a block, because db_rewrite_sql() will interfere. Since it does, the content has to be assigned to 'all affiliates' in order to be visible in a block.

There are a number of reasons for this, and a possible patch direction.

Note that this _is_ possible for page Views, because we can set a global kill for the page load that disables DA's node grants. See the logic in domain_grant_all().

It might be possible to apply this logic at the Views level (or in a query_alter()).

For now, you have to write a custom block to handle this, and you would have to _not_ wrap that query in db_rewrite_sql(), but doing so is technically a violation of Drupal's security standards.

Or, you could build a page View instead of a block view, and then add the path to the 'Special page requests' setting.

I actually made progress with this.

It appears we can set a $conf value to disable DA on a per-query basis. AFAIK, the only thing missing is a setting for the View, and I haven't figured out how to register the plugin.

This is a two-part patch. The first edits DA to allow this behavior. The second is the Views plugin, which needs work.

What we do is run domain_views_query_alter() to set the 'disable' flag. The code should be pretty clear.

merlinofchaos confirms that this cannot be a plugin setting, so it must be a filter plugin.

The attached patch is very very close to working. However, the function node_access_view_all_nodes() statically caches and seems to create problems when Views is running the query.

Testing welcome.

http://api.drupal.org/api/function/node_access_view_all_nodes/6

To use this patch, apply from domain's root directory. It will create a new Views filter called 'Domain Access: Disable'. Set that to TRUE.

Patch seems to be slightly off.

Patch is against DRUPAL--6-2.

No no. Its against the Domain Access branch DRUPAL-6--2. Not against the 6.x.2.0 release.

Run the patch from domain's root directory.

You have to apply it against the DRUPAL-6--2 checkout from cvs.

I disagree. To properly test the patch, you have to test the following, and I don't think what we're trying to do is possible in Drupal.

-- Create 2 Views, one with the new "disable domain access rules" setting, one without.

-- Place both in blocks on the page. Make sure the one _with_ the new setting loads first.

-- Check to see that the output from _both_ blocks follows the rules correctly.

It won't.

The problem is that http://api.drupal.org/api/function/node_access_view_all_nodes/6 statically caches the node grants, so they can only be set _once_ per page call (and Views hooks into this information). This is why an earlier attempt at this patch failed and was never committed.

I think you will end up having to write custom queries that don't use db_rewrite_sql(). You may be able to get around this using hook_views_query_alter(), but I don't see how.

Howdy folks. Maybe this falls in the "no duh" category, but having the same problem as all of you, I discovered a solution that doesn't involve any hacks or patches, and is way less cumbersome than the "solution" those poor guys in #2 were forced to do. All you do is:

1. Create the view you want to be a block, but instead of making it a block, make it a page. Give it a URL, and make sure it is viewable from all the domains you want the block to be seen on.
2. Go to domain access settings and add a special page request for the views page you just created.
3. Go to admin/build/block and make a new block. Give it all the properties you want it to have.
4. In the body text of the block (you need php filter enabled) type this:
   

   print views_embed_view('view_name', 'page_1'); 
   

   (if this isn't the first page you created in this view, change the 'page_1' value accordingly.)

No, this is not obvious and looks like a very elegant workaround. (Though php in blocks is a little ugly.)

Will test to confirm.

No. That does not work either. It only appears to work if you have the 'administer nodes' permission or view the block from the domain you pull the nodes from. (See the attached pics and test view.)

Now, if you pulled that back from an AJAX callback, then it should work. I bet CTools might help with that.

You're right, I apologize for inadequate testing. It did seem too good to be true.
Any luck with the Ajax approach?

No. I hit a wall trying to use views_ajax(), which operates on $_REQUEST values. I think it's definitely possible, though. I would check CTools for a generic AJAX handler.

I'm surprised Views doesn't have a simple "ignore permissions" toggle. It has such an option for viewing the view itself ("access: unrestricted"), but of course that doesn't apply to the stuff the view is displaying. Such an option would be a great addition to views, in my uneducated opinion. You could then use filters to make your own decisions about what content the view would display.

Views is not the problem. The problem is in http://api.drupal.org/api/function/node_access_view_all_nodes/6 which sets a static variable that cannot be reset.

The patch approach provides the toggle you ask for, but it doesn't really work because node access cannot be altered in the middle of a page request, due to the static variable in the above function.

This is why DA allows you to disable it's access rules for specific page paths, but it cannot be disabled for blocks.

A simple patch that would allow the resetting of the static would fix this problem, and I believe we might be able to fix this in D7.

For reference, see the patch in #423822: Update node module to use drupal_static() which fixes this for D7 by using the new drupal_static() function.

A simpler solution (for me) has been to switch to the Subdomain module. I've found it to be easy, straightforward, and elegant. It doesn't boast of many (or any) of the dozens of features that Domain Access has... but then again, lots of those 'features' are just workarounds for the problems caused by a permissions-based approach to subdomains, whereas Subdomain's url-alias-based approach doesn't give me any lip; it just works.
Cheers.

@colemanw -- that's totally OT.

The two modules have different use-cases. Subdomains is a great little module.

Subdomains module won't do this, either, AFAIK, unless the content is viewable by all users, which is not always the case with Group-based subdomains.

I think your acronym is either telling me I'm on-target or off-topic... probably both, AFAIK (so to speak). One footnote and I'll sign off this thread: I'm clearly not going to be any help fixing this issue.

Views will never display content that is not viewable to a given user. Because the Subdomain module doesn't get involved with permissions, it won't do anything to help or hinder this situation. If a user has permission to see a piece of content, it will show up for them in a view (block, page, whatever), regardless of what subdomain it, or they, are on. This is very different behavior from the Domain Access suite (see: all previous entries in this thread) and, as you said, the two modules are both good and have very different uses.

I think your first comment is Off Topic, but the second is On Target. Subdomain inherits permissions from other modules (generally OG). Because OG Access is an access control module, you can't really do this with Subdomains, either, unless the post is visible to all users. (In that case, it would be "show group 2 posts on group 1 domain").

The question at hand is how to show domain 2 content on domain 1 without making that content "belong to" domain 1.

In D7, we should be able to do this because we can reset the grants array _per query_ if we need to, which would allow for the selective alteration of access rules, something that is not possible in D6 (or D5).

Unfixable.

Re-opening this issue since I've run into the same problem myself but in a bit different context. Normal node reference fields don't work with DA if you want to reference nodes not visible to the user on the current domain unless the user has administer nodes permission.
The workaround here would be to use a view based reference which sadly won't work either.

I know we will only put bug fixes in D6 and this really should qualify as a bug or should be noted on the project page as one of the issues with this module.

New issue, please, for documentation. That issue is not related to this core limitation.

I can't really call it a bug, since this is a core Drupal behavior. Node reference fields don't work with node access.

Adding a proper tag

There is one way to get around the access check in a view without patching anything: Instead of using node as the view base table, use node_revision.

I've tried this in conjunction with the Revisioning module, adding a revision = current revision filter to skip all the unwanted node revisions. It works.

subscribe...

Note: the cross-domain nodereference discussion is http://drupal.org/node/842338

The above comments imply there is a way to do this in D7 but not D6. Is there a thread that discusses how to do this in D7?