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
parameter does not understand
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?
has the subroutine
. But this is not used by
code. Instead it uses
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' );
See also: Support.Question47
- 27 Jan 2009
See also: Item1245
- 18 Mar 2009
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
. 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
- 06 Apr 2009
I have updated Foswiki.pm with a new function
. Attached patch to incorporate in FW2.0:
What would be a good place for a unit test?
- 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.
- 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?
- 05 Jan 2010
And the fix in the patch is not sufficient to deal with
- 05 Jan 2010
Better now. I have the fix ready for release branch as well.
- 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.
- 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.
- 08 May 2010