It'd be really nice if one could use named anchors (fragments) in freelinks.
for instance: if I'd like to refer to comment #8 at issue 1036346 like so http://drupal.org/node/1036346#comment-4210696 I could just setup a freelink in the form of
[[nid:1036346#comment-4210696]]
I guess using something like
[[#1036346#comment-4210696]]
would break instantly. so using # as an identifier for the freelink and # as named anchor referral should exclude one another.
Is this possible or inherently problematic?
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | fragments-1434188-2.patch | 2.14 KB | misc |
Comments
Comment #1
misc commentedA first patch, more proof of concept, this for nid-plugin, checks if there is a anchor in the link, and if so use it. We also need to add so that the # is not encoded, that i have not done yet.
Comment #2
juampynr commentedThis would need to pass tests and may even need them to be updated/extended.
Comment #3
basvredelingPerhaps a count for the number of occurrences of #.
Comment #4
Tsudico commentedI have been able to add support for fragments in freelinking 7.x-3.2 for paths, I am not sure if the fragments work for additional types. In the freelinking.module file, starting at line 219 add the fragment section after the internal or external link check:
This may not cover all cases, but it has worked for basic paths that include fragments on the same page and for different pages. I have not tried to use this for nodes, but you are welcome to try it and see if it works.
Comment #5
gislePromoting this feature request to latest version.
However, I do not think this should be tied to a plugin that locates the fragment to a specific nid or path. The main utility of having links to fragment must be the ability to move a fragment from one node to another, and the link would still work.
I don't think this can be made workable without having a db table with unique fragment names and the nids they're live in. The table can be kept up to date by means of
hook_node_update().This means that fragments should be handled by a fragment pluging, e.g.
[[fragment:Introduction]].