If a topic is the result of some processing involving url parameters, the TOC does not work correctly. The links generated for the TOC do not reflect the url parameter that generated the topic, so when clicking on the link it puts you to the original topic, which may be meaningless.

Example: I generate a weekly report for all my staff from many topics, which results in a page

http://localhost/twiki/bin/view/Saydo/WeeklyUpdate?date=29+May+2006&skin=print.pattern

This topic includes a TOC. However, when clicking on a line in the TOC, it brings us to, say,

http://localhost/twiki/bin/view/Saydo/WeeklyUpdate#Portfolio_Management 

which is just a skeleton for the real page.

I tried to disable the linking by putting tags around the TOC, but that did not work...

---

I guess the assumption of the author of TOC was that parameterised links are not idempotent (for example, the paramaters might have been passed in from a search form or similar). Off the top of my head I can't see why that should be so, but perhaps someone can see what I can't.

CC

---

I think it is very clear to a user that when you click on a table of content entry, you should get to that section in whatever you are looking (if that section is there), not to a section in a document that you are not looking at.

Secondly, it appears to be a defect that one cannot turn off linking for the TOC using the <noautlink> tag.... --TW

---

I implemented the following workaround: I added an "args" parameter to %TOC%. This parameter is then appended to the links generated for the TOC entries. Thus, clicking on the TOC entry will get you to the designated topic with the additional parameters supplied.

Maybe a better workaround would be to change the handling of the topic default parameter to pull off the "?" parameters from there, but that requires some change in the TOC handling code.

Of course, the best thing would be to make TOC work correctly without these workarounds... This could be accomplished by fetching all the cgi parameters with $cgi->param, assuming $cgi points to the query object, and then retrieving all the values by looping over this list. This would build up the args list mentioned above.... -- TW

---

Rewrote the TOC patch to get all the URL parameters and pass them on to the TOC.

Also had to fix a bug in TWiki::getScriptUrl which had put the anchor before the URL parameters, thus causing the URL parameters not to be seen (at least on IE).

There still is a problem in that clicking an anchor presents the same URL in a different format than when sending data from a form, thus causing a reread of the topic.

Here are the variations:

• Sending parameters from form: ?date=7+August+2006&template=viewprint#Development
• Via getScriptUrl: ?date=7%20August%202006&template=viewprint#Development

Actually, the original TOC also used ; instead of & to separate the fields. getScriptUrl encodes the parameters, but even if not encoding, the browser changes the spaces to %20 characters. --TW

Any idea of how to change what the browser does (either to avoid getting the + in the first case, or the %20 in the second)? -- TW

---

I don't think you can avoid that. Different browsers use different synonyms for whitespace and parameters. Besides, if the URL is the result of a method="GET" action from a form, how can you be sure the parameters will always be in the same order? I'm pretty sure it will be random, or at least browser-dependant.

Where is this patch?

CC

I wanted to get this last problem solved. Right now the first time one clicks one has to reload because of the difference in appearance of the URL. I would like to avoid that if at all feasible... --TW

---

Addressed the issue described above. I also fixed a problem in the current code where the #anchor is put before the URL parameters. Factored out a function TWiki::_make_params that is used both in TWiki::getScriptUrl and TWiki::_TOC, for consistency.

Clicking on a TOC link now correctly uses any URL parameters that might have been passed into the page, and does not reload the page when staying on the same topic.

Added a unit test test/unit/TOCTests.pm. -- TW

---

While the change correctly fixes the %TOC% problem, it should be pointed out that the actual problem is that the <base href="..."> in templates/twiki.tmpl does not retain URL parameters. Having simple hand-made relative anchors like #AnotherSection in a topic and linking to them with #AnotherSection fails in the same way if the topic is used with url parameters. Note that TW's fix is "robust" even if the base tag is going to be fixed some day. -- haj

4.1.0 released

KJL