One task that gets a lot of work on various sites (at least that I work on) involves changing the URL of a node for one reason or another. Sometimes it's not ideal to simply have all nodes in the same tree. For my purposes, being able to override the URL of a node could allow me to add context information about how one gets to the node.
This patch creates a new function which then creates a new node hook and a new nodeapi hook to let nodes define their URLs. If it's acceptable, we will need to go through core and remove all hard-coded references to the node and use node_url() instead.
| Comment | File | Size | Author |
|---|---|---|---|
| node_url.patch | 836 bytes | merlinofchaos |
Comments
Comment #1
dmitrig01 commentednot sure I understand. what does this do? how can a node define it's url in a nodeapi hook. isn't that a module function
Comment #2
merlinofchaos commentedTo explain further, I have a particular use case.
A common feature request for Views is the ability to add next/prev links to a node. At the moment, that feature is basically not possible. It's almost possible using $_SESSION but that doesn't work for a couple of other reasons.
Why is it not possible? There is no way to tell where a particular node view came from. What I want to be able to do is modify the node URL to provide some context. I cannot tell from a given node what view it was even in, let alone next and previous links. Worse, the next/prev operation is very expensive unless I know where in the view the node came from.
Now, were this feature fully implemented -- which is more than just this base patch, it'll require going through core and replacing all instances of node/XXX with node_url($node) -- views could implement hook_nodeapi and, if the moon and stars are in the right position, embed context information into that node URL.
That way, when a node is being viewed, it could ADD next/prev links properly into hook_links. It could change breadcrumbs to match the view. It could do all sorts of things.
However, none of this is currently possible, because views cannot control
1) What node URL gets printed by the system when the node is being viewed
2) While 1) above could be alleviated with some ugly str_replace code, Views also cannot control where a node goes to after, say, a comment has been filed (this state information would need to be retained throughout the life of a node).
I think this patch likely needs some work -- after discussion with killes, it probably needs to actually provide an array suitable for use with url() or l() rather than just the base path, because for my purposes, $_GET variables are safer than trying to append context information onto the actual node URL itself.
Comment #3
catchI'm pretty sure merlin's got this working in Panels 2, but bumping version just in case I'm missing something rather than marking as fixed.
Comment #4
merlinofchaos commentedNo, Panels 2 doesn't address the problem this patch was trying to address.
Comment #5
Jaza commented@merlinofchaos: not sure why you need nodes to be able to "change their URL". From the use case you described, it sounds like you should be able to simply request the standard 'node/%node' path, and append arbitrary GET parameters to the request, and that in turn should provide all the views-centric context information you might need.
Perhaps I don't fully understand the intent of this patch - but it seems to be that this is potentially a change with a big overhead, that achieves a goal that can be accomplished using simpler alternative methods.
Anyway, if you're still interested, feel free to pursue this further in D8 dev.
Comment #6
mgiffordI'm assuming we can just leave this closed.