Closed (fixed)
Project:
Domain
Version:
6.x-2.1
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
6 Feb 2010 at 13:40 UTC
Updated:
27 Feb 2010 at 19:40 UTC
Jump to comment: Most recent file
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.
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | 706490-redirect.patch | 3.01 KB | agentrickard |
| #14 | 706490-form.patch | 1 KB | agentrickard |
| #4 | domain_change_to_simulate.patch | 3.83 KB | ibis |
Comments
Comment #1
agentrickardWhat? Please be more clear.
Are you actually experiencing an error?
Comment #2
agentrickardComment #3
ibis commentedYes, 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 nothttp://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.
Comment #4
ibis commentedAlso 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.
Comment #5
agentrickardWhy not just use hook_domainignore()?
Comment #6
ibis commentedYou 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.
Comment #7
agentrickardThis may be deliberate. There was likely a reason why this is done in this manner.
Is any DATA corruption caused?
Comment #8
ibis commentedI tested with core and contributed modules (eg. pathauto - refresh aliases, nodewords - delete metatags, image - rebuild derivative images), and work. No corruption in database.
Comment #9
agentrickardSo the issue is simply that you change domain when you don't expect to do so?
Comment #10
ibis commentedYes. 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.
Comment #11
agentrickardBecause 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.
Comment #12
ibis commentedYes-yes. I don't share login cookies, but i will administrate all of my domains from primary domain.
Comment #13
agentrickardOK, now I can test this reasonably. Thanks for hanging in there!
Comment #14
agentrickardI 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().
Comment #15
agentrickardIf the domain_set_domain() routine is not working for you, there may be a different problem.
Comment #16
ibis commentedThe 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) !
Comment #17
agentrickarddomain_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.
Comment #18
ibis commentedOkay.
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.
Comment #19
agentrickardOh, I know what that might be. Try this.
Find the function domain_node_save_redirect(). And edit it. This is in domain.module.
If that fixes it, then I know what the problem is.
Comment #20
ibis commentedBingo, that fixes it ( with line domain_goto($source); change to //domain_goto($source); ).
Comment #21
agentrickardI know what the problem is then. Thanks.
Comment #22
agentrickardThe 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.
Comment #23
ibis commentedSuper, 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!
Comment #24
agentrickardWell, this was a tricky issue. Thanks for going over it until I understood.
Comment #25
agentrickardCommitted!