Last modified: 2012-02-16 19:52:49 UTC
Tested with MediaWiki 1.18.0, Semantic MediaWiki 1.7.0.1. * Steps to Reproduce: Create - a property "Website" of type "URL" - a template "URLtest" that contains a field called "URL", that outputs the field in two different ways: 1. {{{URL}}} 2. [[Website::{{{URL|}}}]] Use the template in a page, like this: {{URLtest|URL=http://example.com/}} * Actual Results: 1. Outputs the URL as expected 2. Outputs it as <a href="http:////example.com/">http://example.com/</a> In the factbox at the bottom of the page it is output as <a href="http:////example.com/">http:////example.com/</a> Live example: http://bibliotekhistorie.no/index.php/Norsk_Bibliotekforening Expected Results: Both 1. and 2. should output http://example.com/ and the link in the factbox should also be correct. * Additional Information: If I change the property of "Website" from "URL" to "Text", there are no extra slashes in the URL. Firefox will try to gloss over this problem - when you hover over a link it will not show the extra slashes and links will work, but if you view source or use the "insepect element" function of Firebug you can still see it. Internet Explorer is less "kind" and there the links with extra slashes will not work.
I have encountered this bug too. The template steps are not required (I am using SMW 1.7.0.2). Any property of type URL will show an incorrect URL in the SMW factbox, with extra forward slashes. I haven't noticed the problem anywhere else but the factbox. It appears properties can be queried and displayed normally, outside the factbox.
*** Bug 34312 has been marked as a duplicate of this bug. ***
As per badon. Thus changing to trivial, though a hopefully quick fix will be cool.
Workaround: use foo.bar instead of http://foo.bar as value. Hopeful fix: r111141 Would be great if this could be verified. I find this code rather confusing, so hope I did not break the URL stuff on some other place now...
I just tested your fix. The behaviour within the factbox is now as expected and it is also possible to query for URLs without side effects. The links work and everything looks fine. :) The workaround is not really feasible since you get validation errors then using forms. You are asked to include http://
I just run into this bug as well, good to see it already fixed. However, the newest release of SMW (updated via sudo svn switch http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/SemanticMediaWiki/REL_1_7_0_2 SemanticMediaWiki ) still seems to contain the bug. Do you recommend upgrading to unstable, or will there be a bug-fix release soon? (I would prefer the latter). This bug is fundamentally breaking SMW. It was also hard to find. We now understand that it does not break any of the testing browsers (IE 8/9, FF, Chrome) that we regularly use, it only breaks some browsers (definitely older IE, but we also have one smartphone report, not which browser that is).
SMW 1.7.1 will be around in approximately two weeks. I would wait for this release, since mostly ancient IE versions seem to be involved.
Yes, in two weeks. > This bug is fundamentally breaking SMW. It's a formatting issue of values in one of the lesser used data types, does not seem like a very fundamental issue :) > It was also hard to find. We now understand that it does not break any of the testing browser As far as I can see this is not browser related at all, so how do you figure it is?
> > This bug is fundamentally breaking SMW. > > It's a formatting issue of values in one of the lesser used data types, does > not seem like a very fundamental issue :) It makes the resulting pages unusable for users with certain browsers. They click on presumed links and report that it is "completely" broken. Whether that is "fundamental" or not depends of course. > > It was also hard to find. We now understand that it does not break any of the testing browser > > As far as I can see this is not browser related at all, so how do you figure it > is? FF, IE 8ff, Chrome are ERROR tolerant. To my knowledge it is not standard conformant for a domain name to start with two slashes, as in "http:////www...". So in this sense it is browser related, and because the reports were not reproducible in our test browsers, we did not understand them. I guess this is the reason why the bug remained unreported so long - we had the bug for a long time, but could not figure it out.
It may be browser related because some browsers might try to detect the problem and correct it transparently for the user. That's my best guess. I was able to work around the problem by adding a text URL property type that contains the same data. In any case, the text URL property type is the only way to gain control over link formatting, as far as I know, such as if you want to change the link text from a URL to something more descriptive ("click here to see X").
