Base href messing up internal anchor links

Update: This is not an issue (see comment at Base href messing up internal anchor links)
The standard behaviour for Plone is to generate a base tag for each page.
This can be overriden in the theming-control panel advanced settings > absolute path prefix.

This is often useful to ensure that resources like images and stylesheets are loaded properly but there is one negative repercussion. Internal links to ids and anchor tags are also affected by the base tag. The most problematic scenario is when viewing a folder's default view (this is because the base href is set to the URL of the default view not the folder itself) the classic scenario is that a link on a page served from that looks like this::

 <a href="#top">go to top</a>

assuming it is associated with a page named 'front-page', is treated as if it were:

 <a href="">go to top</a>

Instead of simply linking to the top of the page, this forces a page refresh as it attempts to go directly to /front-page#top.

It seems the best way to fix this is use JS to detect the current location and then append the internal anchor link. Still investigating. I could remove the base href info but I think that might have some undesirable repercussions.

Possilble fix
In the future it might be useful to force the algorithm that determines the base href to always look at the folder URL rather than appending the defined default view URL. This, of course, does not address situations when the base href is set in the theming controlpanel.

I thought Plone 5 no longer generates a base tag? And that there was a merged PR for Plone 4, too, that removed the base tag?

I was able to confirm that, out of the box, Plone 5.0.6 doesn't set a <base href>. It seems the only time it is set is when the absolute path prefix is set in the theming-control-panel. My scenario relates to the case of the absolute path prefix setting a <base href>.

Okay... this was all caused by my own meddling, I reviewed my diazo theme and realized that I was dynamically injecting a <base href>. In other words, you can safely disregard this reported issue... nothing to see here... move on...

1 Like