In domain.module on domain_form_alter:
// If SEO is turned on, then form actions need to be absolute paths
// to the currently active domain. See http://drupal.org/node/196217.
Right, but the Domain Content module change the active domain on domain_content_view form, and if i see the content of domain2 from domain1, and will change someting with multiple features, then form action redirect to domain2.

Comments

agentrickard’s picture

What? Please be more clear.

Are you actually experiencing an error?

agentrickard’s picture

Category: bug » support
Status: Active » Postponed (maintainer needs more info)
ibis’s picture

Category: support » bug
Status: Postponed (maintainer needs more info) » Active

Yes, this one error.
Enable Domain Access and Domain Content module.
Create two domain (primary and secondary).
Create nodes to domains.
Enable SEO url rewriting.
With user 1 on primary domain navigate to /admin/domain/content/2 and see what is in the action of two forms ('node-filter-form' and 'domain-content-form') -> http://secondary/admin/domain/content/2 and not http://primary/admin/domain/content/2 .
And the source of bug:
in domain_content.admin.inc file in function domain_content_view() change the active domain and in domain.module file in function domain_form_alter produced wrong action to forms above.

ibis’s picture

Status: Active » Needs review
StatusFileSize
new3.83 KB

Also the problem is that: the domain_content_view() change de active domain, and not simulate the change.
Here's the patch for domain_content.admin.inc for simulate the change.

agentrickard’s picture

Why not just use hook_domainignore()?

ibis’s picture

You write in domain.module:
// If SEO is turned on, then form actions need to be absolute paths
// to the currently active domain. See http://drupal.org/node/196217.

and this's right!
Whit hook_domainignore() become the form actions to relative.

agentrickard’s picture

This may be deliberate. There was likely a reason why this is done in this manner.

Is any DATA corruption caused?

ibis’s picture

I tested with core and contributed modules (eg. pathauto - refresh aliases, nodewords - delete metatags, image - rebuild derivative images), and work. No corruption in database.

agentrickard’s picture

So the issue is simply that you change domain when you don't expect to do so?

ibis’s picture

Yes. The issue is that: on path http://primary/admin/domain/content/2 when i submit the forms above, fires domain change, and become 403 page on secondary domain. And the source of domain change is documented above.

agentrickard’s picture

Because your domains do not share a top-level, right, and therefore don't share login cookies? That would explain why I have trouble replicating the problem.

ibis’s picture

Yes-yes. I don't share login cookies, but i will administrate all of my domains from primary domain.

agentrickard’s picture

OK, now I can test this reasonably. Thanks for hanging in there!

agentrickard’s picture

StatusFileSize
new1 KB

I looked at this. domain_content_view() _does_ simulate a domain change properly, AFAIK, so that part of the patch is not needed.

AFAIK, all you need is hook_domainignore().

agentrickard’s picture

If the domain_set_domain() routine is not working for you, there may be a different problem.

ibis’s picture

The domain_set_domain() routine change the active domain (the global $_domain variable!) and this produced the problem above in domain_content_view function. But. I tested the domain_set_domain() only with domain_content_view() and i don't know where implemented this routine yet and what produced there.
The hook_domainignore() not help in this situation (see #6) !

agentrickard’s picture

domain_set_domain() is doing exactly what I expect it to do. I simply do not understand the "bug" aside from accidentally redirecting form submissions, which the patch fixes.

Please start over with a step-by-step description of any issues you encounter while using the patch.

ibis’s picture

Okay.
Applied your patch. (I tested domain_set_domain() soon in #6, but yet test with your patch).
Make the test in #3.
The node(s) to secondary domain set affiliate only to secondary domain (not all affiliate!).
With user 1 on primary domain navigate to http://primary/admin/domain/content/2 and see what is in the action of two forms ('node-filter-form' and 'domain-content-form') -> /admin/domain/content/2 and not http://primary/admin/domain/content/2 .
Yet. Set one or more nodes from the list, and apply to eg. Publish from Update option list. What happend? The domain change to secondary and become 403 page.

agentrickard’s picture

Oh, I know what that might be. Try this.

Find the function domain_node_save_redirect(). And edit it. This is in domain.module.

function domain_node_save_redirect() {
  return;
 // rest of function.
}

If that fixes it, then I know what the problem is.

ibis’s picture

Bingo, that fixes it ( with line domain_goto($source); change to //domain_goto($source); ).

agentrickard’s picture

I know what the problem is then. Thanks.

agentrickard’s picture

StatusFileSize
new3.01 KB

The problem is that for two functions, we need to use the actual domain, not the active domain. This patch should fix everything.

Revert the old patch and apply this one.

ibis’s picture

Super, with thises modifications work all fine, but the patch is unapplycable to 6.x-2.1 version of domain.bootstrap.inc ( $Id: domain.bootstrap.inc,v 1.10 2009/08/22 22:30:36 agentken Exp $ ), because this file have only 237 line. But i implemented your function manually and work all fine. Thanks your help and attention!

agentrickard’s picture

Status: Needs review » Reviewed & tested by the community

Well, this was a tricky issue. Thanks for going over it until I understood.

agentrickard’s picture

Status: Reviewed & tested by the community » Fixed

Committed!

Status: Fixed » Closed (fixed)

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