Problem/Motivation
Domain node tokens are not available when a node is first created, causing problems with URL alias patterns that use [node:domain] or [node:domain:*] tokens.
Steps to reproduce
1. Enable Pathauto.
2. Set a content type's URL alias pattern to 'content/[node:domain]/[node:title]'.
3. Create a new node of the specific type in step 2, leaving the 'Automatic alias' checkbox checked. Also ensure the node is assigned to one domain.
Desired result
The node is assigned the URL alias 'content/mydomain-com/my-node-title'.
Actual result
The node is assigned the URL alias 'content/my-node-title'.
Explanation
This seems to be caused by the fact that domain does not save its access record data (e.g. $node->domains) when a node is saved - therefore in domain_tokens() the domain_get_node_match() function fails when run in hook_node_insert() from Pathauto.
Proposed resolution
Not sure - this seems to be a result of node access records not being able to be saved from inside node_save(). I'm not sure why we can't actually just save the records into {node_access} from a domain_node_insert() or domain_node_update().
Remaining tasks
- Figure out appropriate solution
- Write patch and tests
User interface changes
None as of yet
API changes
None as of yet
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | 1336698-domain-node-insert-tokens.patch | 10.67 KB | agentrickard |
| #15 | 1336698-domain-node-insert-tokens.patch | 11 KB | dave reid |
| #14 | 1336698-domain-node-insert-tokens.patch | 10.98 KB | dave reid |
| #13 | 1336698-domain-node-insert-tokens.patch | 10.92 KB | dave reid |
| #10 | 1336698-domain-node-insert-tokens.patch | 6.33 KB | dave reid |
Comments
Comment #1
dave reidThis is the workaround I had to implement for now:
Comment #2
agentrickardThis probably has to do with the callstack order in saving Drupal nodes.
I think this is also related to #1219746: Cannot static cache _load() calls.
When does pathauto / token fire? What state is the $node object in at that point? (e.g. has it been saved or is it about to be saved?)
There may not be a better workaround than this, because the node data you are requesting doesn't get saved until hook_node_access_records() runs.
Comment #3
agentrickardI assume this affects all the other tokens as well.
Best methods for testing?
Comment #4
agentrickardHere's a patch that seems to correct the issue.
Comment #5
agentrickardAs a bonus, this fixes #1140016: Unassigned nodes don't link properly
Comment #6
dave reidHere's the patch I had locally which also seemed to address it by writing the domain access records from within hook_node_insert() and hook_node_update(). Although this approach will be fragile if a module that also implements either hook runs *before* domain.module.
Comment #7
agentrickardI think we might merge the update / insert part of that with the new if/else handling of my patch.
Comment #8
agentrickardAnd here that is.
Comment #9
dave reidWorking on the tests...
Comment #10
dave reidHere is a patch with tests based off patch #8. It also fixes an error that allowed the [node:domain:*] tokens to work because domain_get_node_match() returned NULL, which doesn't match the condition
if ($domain == -1)in domain_tokens(). The sub-tokens would then erroneously use replace tokens with the default domain values because of the following code in domain_tokens():Comment #11
dave reidAlso the [node:domain] token should be returning the sitename and not the subdomain as the 'name' of the domain should be the default token.
Comment #12
dave reidI'm going to add some more test coverage for the tokens as well since this really should be covered prior to 3.0.
Comment #13
dave reidHere's a final patch with full test coverage for the domain tokens.
Summary of changes
Comment #14
dave reidRevised patch that allows the [node:machine_name] token to still work with existing token replacement, but essentially deprecates it.
Comment #15
dave reidRevised patch should fix failures in folder based install.
Comment #16
agentrickardAnd, we keep cross-posting.
Here's a patch with working tests. I'm punting the machine_name / machine-name token issue to a follow up.
Comment #17.0
(not verified) commentedUpdating remaining tasks