Item598: URLs to Subwebs without topic name with or without a trailing slash do not correctly open the WebHome below
Priority: Urgent
Current State: Closed
Released In: 1.0.0
Target Release: patch
Applies To: Engine
Component:
Branches:
both mistakenly think we're going to the Tasks/Item1234
web
Why is that a bad assumption? Well, ok, it could be smarter, but it's not the end of the world.
--
CrawfordCurrie - 30 Dec 2008
I would even say this is what I would expect
--
KennethLavrsen - 31 Dec 2008
As long as users typing this are trying to get to Tasks/Item1234 and not somewhere else, this would be a feature and not a bug.
If sub-webs still work and nothing is effected, i would love to see this stay like Tasks/Item1234/
--
EugenMayer - 01 Jan 2009
Actually looking at TWiki 4.2.4 vs Foswiki subweb no longer works at it should.
We have broken URL compatibility.
When you write
http://merlin.lavrsen.dk/trunk/bin/view/Myweb/Mysub/ you are supposed to end up in
http://merlin.lavrsen.dk/trunk/bin/view/Myweb/Mysub/WebHome. You always did that in TWiki. You do not in Foswiki.
someone broke URL compatibility which is a death sin.
It works on the root webs.
http://merlin.lavrsen.dk/trunk/bin/view/Myweb correctly opens
WebHome of Myweb.
So there is a regex for subwebs that has been goofed up recently.
Release blocker. This behavior MUST be restored. Otherwise we will have users where links TO their site upgraded from TWiki to Foswiki stop working.
I am rewording the headline to affect the real bug.
The test cases should be
do not count on the actual links to always work as I am constantly bringing this server up and down and checking out older versions when tracing where bugs were injected.
--
KennethLavrsen - 01 Jan 2009
the spec I'd like, is
- if it is clear (ie, only one of subweb or topic exist) it should ignore the slash and just go to the right place
- the trailing slash will have to be significant if, and only if both the topic and web exist
this does not change the reality that we need a fix for the
both topic and subweb exist case Kenneth shows above.
As I think about it I prefer that the behavior is predictable. Ie I do not like the idea that Foswiki tries to guess. I think for the user it is better to always know what a URL tries to reach.
But I am not religious about it. If many think Sven's spec is best then I will not fight against. I just ask the community to think about the pros and cons.
But we agree that if the subweb exists then the trailing / must lead to the
WebHome of the subweb. This as Sven also says is the important spec to meet so we do not break URLs.
I have checked in the fix. It was in SVN994 that Sven broke the syntax - even adding the remark that trailing / does not mean
WebHome. And this we now agree was a wrong assumption.
Crawford later changed the code to do the same wrong
Removing the one code line I checked in all works normal again.
The links above work.
These work.
- Mysub - must link to the Mysub topic in Myweb
- Main - must link to the web home of Main
- Myweb/WebHome - must link to the web home of Myweb
- Myweb/ - must link to the web home of Myweb
which can be seen live in
http://merlin.lavrsen.dk/trunk/bin/view/Myweb/LinksTest
The fix I did can later be expanded to guess for looking for the topic name when the sub web does not exist. But I see a risk in that and I would like to wait with that till a 1.0.1 patch release.
The new unit tests fails still so we need to look into that
It was the unit tests that were wrong. Both the Viewscript and Viewfilescript unit tests assumed that a trailing / should be ignored instead of assuming a subweb name.
For the viewscript I fixed the unit tests. If we decide for the fall back feature that Sven has suggested we need to create unit tests for these cases also.
For the Viewfile I disabled the tests and added very clearly a "Note 1" text that refers back to this bug item.
If we decide to implement Sven's proposal in 1.0.1 we can reactivate these unit tests very quickly. Deleting them would have been wrong and waste of time.
I am setting this as Closed and opening a feature proposal instead.
Feature proposal is
FallBackToTopicWhenTrailingSpaceAndNoSuchSubweb
I hope I have done things with the correct respect to the original report.
I have attempted so.