Site URL not showing when using CCK node reference tokens in the path
| Project: | Custom Breadcrumbs |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Hi,
Here is the situation. I have 2 CCK node types. Let's call them Tree and Leaf. Each Leaf can reference a Tree (via a CCK node reference field).
When I view a Leaf node, I want the breadcrumb to show the Tree that Leaf belongs to. For instance Leaf1, referencing Tree1, would show: Home > Tree1.
I then added a new Custom Breadcrumb for Node, which applies to the Leaf node type. In the Title and Paths section, I used a couple of node reference tokens, which look like:
Title:
[field_tree-title]
Paths:
[field_tree-path]
When I view my Leaf page, the breadcrumb looks ok but the link to the Tree is messed up.
I was expecting: "Home > Tree1" pointing to "http://mysite.com > http://mysite.com/tree-1"
But I effectively got: "Home > Tree1" pointing to "http://mysite.com > http://tree-1"
After some digging in the custom_breadcrumbs.module, function _custom_breadcrumbs_create_crumb (line 382), I found two things.
One, although [field_tree-path] is said to return a relative path, it actually returns /relative/path (with a leading slash). But this is not such an issue when we look at ...
Two, the parse_url function (used to extract the path from the $original_path passed to the function - lines 387, 400) also returns a /relative/path (with a leading slash) when used with a full url (http://mysite.com/tree1 for instance, which returns /tree1).
So in theory, if we remove that leading slash, drupal will then understand those URLs as a true relative URLs and prepend "http://mysite.com" to them.
I tested this by replacing - line 406
<?php
$crumb = l($title, $options['path'], $options);
?>by
<?php
$crumb = l($title, substr($options['path'],1), $options);
?>Obviously this is not a valid solution as it will remove the first character of each path, whether it starts by a "/" or not, but it did work for those paths with a leading slash, and "Tree1" now points to "http://mysite.com/tree1" (instead of http://tree1).
I can provide a patch for this if you think the approach is correct.
Thanks,
Matt
#1
Actually, this was not so much work so here is a patch that removes the leading slash from a breadcrumb path if it finds one.
This patch has been tested against 6-x-2.0-beta1 but should run OK against -dev as both files are equal.
Thanks,
Matt
#2
I believe this is a duplicate of #543536: CCK nodereference paths cause invalid links and has already been fixed in the latest 6.x-2.x-dev release. Can you try the latest code and see if fixes the problem?
Thanks.
#3
Thanks for the link, the issue had already been addressed indeed ... don't know how I missed it!
I tried the dev code and it does solve my issue. However, I am not sure I fully understand the logic behind it. Here is what I saw when printing a couple of temp paths on screen:
1- when passed to _custom_breadcrumbs_create_crumb, $original_path is set to "http://mysite.com/tree1" (if I work with *-url tokens).
2- the regexs brought by the patch #543536: CCK nodereference paths cause invalid links turn it into "http:/mysite.com/tree1" (only one slash after the protocol).
3- parse_url returns /mysite.com/tree1 as the path.
4- drupal's l() function then returns "http://mysite.com/tree1"
The problem with this is that step 2 creates an malformed URL, and parse_url tries its best to understand it. It fails (mysite.com should not be part of the path) but l() recreates a correct url by prepending http:// to the absolute path (/mysite.com/tree1).
As I understand it, we get the correct output but through a wrong procedure. The fact that we rely on parse_url's error handling mechanism might bring some problems in the future.
Should I see things differently?
Matt
#4
What are you putting in for paths?
It should be the drupal path, not an absolute url. From you example, it should be just tree1 instead of "http://mysite.com/tree1". I can see how there could be problems with absolute url's.
EDIT:
Ok, if i read more carefully, I can answer my own question:
Use the *-path tokens instead and everything should work as expected. Perhaps this needs to be made more clear in the documentation. All of the example show relative paths, but it never explicitly says to use relative paths...
#5
Yes, you're right, it's all good now. I shouldn't have used the *-url token in the first place. I started experimenting with it as the *-path one wasn't behaving the way I wanted and forgot to switch back.
As for the documentation, I don't think there is a real need for updating it. After reading it (again), it is pretty clear that relative paths should be used and -path tokens are the only ones to offer those precious relative paths (and again, I only went for the -url because the -path wasn't working so I guess most people will instinctively go for the -path).
Thanks again for your time and support, I'll be more careful next time I post a new issue. I'll let you close if appropriate.
Matt
#6
Thanks for the feedback!