Allow named anchors to work without specifying full path to node

Dries, mind telling us what the fix was?

I suspect a bug in a recent version of book.module. I experience this on one of my own sites with footnotes created & referenced by Textile. (The bug occurs on a corporate intranet site so I can't give you the URL. :-( ) I am using mod_rewrite on this site, but the browser is IE6 on Windows not Mozilla. I had previously suspected textile.module.

Sorry. Did not intend to change the project tag in previous update.

It wasn't a book module bug but simply incorrect HTML code in the book page's body.

Actually, I think that there is still something wrong with named anchors in drupal, not specific to book pages.

I am converting a static html site into drupal, using some automated tools to stick the body of the html pages into drupal nodes. The static html pages contain named anchors referencing footnotes on the same page. They look like this:

(<A HREF="#anchor888520">1</A>)

When this is interpreted in the context of a static page (http://myoldsite.com/faq/statistics.html), the browser correctly jumps to the footnote further down the page.

When the very same named anchor link is interpreted in the context of a drupal node, the browser jumps to an invalid link, which goes to the front page (http://myoldsite.com/drupal/#anchor888520), similar to what was originally reported by Ber Kessels for drupal's book pages. In a future drupal release, it will go to a 404.

I've been poking around for several hours, and can't figure out why this is happening. The link code is absolutely identical. It must be something in the page context, outside the body of the node. This happens with out-of-the-box xtemplate, marvin, and example themes. It happens with Safari and with IE 5.2.

The "fixed" named anchor links in the book page now look like this:

<a href="book/view/324#cvs_diff_visual">visual</a>)

But to do this, the content of the page must know it's actual node id -- this html will break if cut and pasted into another node.

And it increases the complexity of automating conversion of static html -- the converter will have to rewrite jump anchors (named anchors to same page) to reference the node id of the drupal page they are moved to. Since human editors will probably do a fair amount of cutting and pasting immediately after conversion to drupal, these links are traps for the unwary.

Drupal's base HREF confuses things here. Browsers will prepend any relative links, like "#foo", with this base URL.

Possible solutions include writing a filter module to replace these anchor links with links that include the path to the page, or changing url() to output root-relative links and removing the base HREF tag.

This is serious problem. I don't know how other people have gotten around it, but any in-document (relative) anchors don't work when Drupal specifies a base href.

The only workaround is to use absolute links, which causes the page to reload. Anyone got a fix for this?

There's a filter approach described in a forum post at http://drupal.org/node/13080, but the real solution is to remove the base tags and fix any relative links that depend on them.

I'd really like to see the base tags go, but until then it would be great to have a working filter available.

In the absence of that, it would great to have a variable giving the value of request_uri(). to make it available in Xtemplate and PHPtemplate.

Otherwise there is no way that an Xtemplate ot PHPtemplate can provide a "skip navigation" link for users without stylesheets, as required by the WAI guidelines.

So instead of

<div class="hide"><a href=" {request_uri}#skipnav" title="Skip navigation" accesskey="s">Skip navigation</a>.</div>

... the only way to do it is to write a native PHP theme:

$output .= "<div class=\"hide\"><a href=\"" . request_uri() . "#skipnav\" title=\"Skip navigation\" accesskey=\"s\">Skip navigation</a>.</div>\n";

Can we fix the basic problem for the full Drupal CMS, please?

The solution I came up with for a modified "bluemarine" theme (in this case to add a link to "top of the page" on all nodes) was to add...

<a name="top"></a>

...after the body tag and...

<a href="{link}#top">top of the page</a>

... to the node code in xtemplate.xtmpl, as in....

...
...
</head>
<body{onload_attributes}>
<div class="page_background">
<a name="top"></a>
<table border="0" cellpadding="0" cellspacing="0" id="header">
...
...
...
...

<!-- BEGIN: node -->
  <div class="node {sticky}">
	<!-- BEGIN: picture -->
    {picture}
    <!-- END: picture -->
    <!-- BEGIN: title -->
    <h2 class="title"><a href="{link}">{title}</a></h2>
    <!-- END: title -->
    <span class="submitted">{submitted}</span>
    <!-- BEGIN: taxonomy -->
    <span class="taxonomy">{taxonomy}</span>
    <!-- END: taxonomy -->
    <div class="content">{content}</div>
    <!-- BEGIN: links -->
    <div class="links">&raquo; {links}</div>
    <!-- END: links -->
    <div class="toplink">&raquo; <a href="{link}#top">haut de page</a></div>
  </div>
<!-- END: node -->

This is still a real pain, and I really don't think it should be the user's responsibility to figure out how to make an input filter in order to link to simple page anchors. It should be supported by default.

What about using :

So if I want to make a link to jump to the anchor "#example" on the same page, I would just use

<a href="<!--#example-->">jump to example</a>

Basically it uses the exact same syntax as

which seems to work fine.

Oops, left off the code tags.

What about using :

should have been

What about using: <!--#example-->

for those that want base href to go, please test out the patch on http://drupal.org/node/13148 and put a comment on that bug report.

It works in 4.7.