Item446: Make redirectto aware of anchors in links

There is a general lacking of support for anchor and query params in links.

Concrete item: the redirectto parameter does not understand Web.Topic#Anchor syntax.

Overall, anchor syntax is largely not supported. It should not be difficult to add anchors and query parameters to a topic notation. The question is largely: where to add it?

Render.pm has the subroutine _handleWikiWord. But this is not used by Foswiki.pm code. Instead it uses normalizeWebTopicName a lot. With a small change that function could also return anchor and params:

( $web, $topic, $paramList, $anchor ) = $this->normalizeWebTopicName( 'Web.Topic?q=123#MyAnchor' );

• ArthurClemens - 13 Dec 2008

See also: Support.Question47.

-- ArthurClemens - 27 Jan 2009

See also: Item1245

-- CrawfordCurrie - 18 Mar 2009

---

Confirmed. However normalizeWebTopicName is not the place to add it; it relates to a topic name, not a general index, and is used in places where it would be quite inappropriate to do that.

Instead the params and anchor should be taken off only where it is appropriate to do so i.e. when parsing the target of a square bracket link, and when parsing a small subset of parameters such as redirectto. By all means provide a new function that fulfils the dual role of parsing off the args and normalizing the topic name, but don't muck with the existing normalizeWebTopicName function.

-- CrawfordCurrie - 06 Apr 2009

I have updated Foswiki.pm with a new function _splitAnchorFromUrl. Attached patch to incorporate in FW2.0:

• Foswiki_redirect_with_anchor.patch: patch for Foswiki.pm

What would be a good place for a unit test?

-- ArthurClemens - 20 Aug 2009

This was set "Waiting for release", but actually no checkins have been done.

Pending for a unit test.

Plus, I first regarded this as an enhancement, but it is a bug. For example with SendEmailPlugin after pressing submit, the redirect does not link to the feedback anchor with a possible error message. If that message is not in first view, it looks like the operation was succesful, while actually it failed. There must be a lot of other applications that rely on anchors that are now failing.

In other words, this fix should go into release branch as well.

-- ArthurClemens - 05 Jan 2010

Actually, I have no idea how to make a unit test for a redirect. I also cannot find any existing tests to guide me. Is this inherently difficult?

-- ArthurClemens - 05 Jan 2010

And the fix in the patch is not sufficient to deal with redirect_cache.

-- ArthurClemens - 05 Jan 2010

Better now. I have the fix ready for release branch as well.

-- ArthurClemens - 07 Jan 2010

Set this back to "New" (was closed). I assume this was supposed to be WaitingForRelease. But I've set back to new in case anybody has an idea on how to write the unit tests.

I've been hacking the REST stuff lately and I might have a go at it later next month, unless somebody tells me it's not possible.

-- PaulHarvey - 21 Apr 2010

It was closed because the bug was fixed and a release with the fix was released 1.0.9

This also means that the item should remain closed and a new bug raised if there is more related work. Otherwise people get confused when they click on the fixed bug list in the release notes and find a non closed bug.

And we get confused when we cannot identify in which release a bug is fixed.

And last we end up with same bug item in several releases.

Open a bug related to the unit tests which can be closed when fixed as unit tests are not part of the released product.

-- KennethLavrsen - 08 May 2010