odd behaviour of {fullurl:...}

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

odd behaviour of {fullurl:...}

William Allen Simpson-2
A couple of us were trying to figure out the syntax to add a working
link to Special:Log in a template.

  [{{fullurl:Special:Log|page={{{1}}}{{{2}}}}} log]

Works fine as long as parameter 2 is only one word.  With a space in 2,
only the first word shows up in the URL.

Tried wrapping {{fullurl:{{{1}}}{{{2}}}}}, but page= won't take a full
page name.

  [{{fullurl:Special:Whatlinkshere/{{{1}}}{{{2}}}|limit=999}} links]

Always works.

Is there some reason that fullurl stops encoding spaces to underscores
when it runs into a pipe?

And speaking of syntax, why {{fullurl: instead of {{#fullurl: to match
the latest parser syntax?
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: odd behaviour of {fullurl:...}

Locke Cole
On 4/25/06, William Allen Simpson <[hidden email]> wrote:

>   [{{fullurl:Special:Whatlinkshere/{{{1}}}{{{2}}}|limit=999}} links]
>
> Always works.

Because it's part of the full URL generated (see below).

> Is there some reason that fullurl stops encoding spaces to underscores
> when it runs into a pipe?

The pipe adds parameters, basically {{fullurl:...}} seems to take this:

{{fullurl:<page>|<param-1>|<param-2>|...|<param-n>}}

And convert it into:

<page: converted to full URL>?<param-1>&<param-2>&...&<param-n>

> And speaking of syntax, why {{fullurl: instead of {{#fullurl: to match
> the latest parser syntax?

Probably because the latter would break existing pages relying upon
{{fullurl: ...}}. Also, my understanding of {{# was that it was only
used for parser extensions (not built-in magic words/functions).

Anyways, getting back to the problem of spaces in parameters, I don't
think URL encoding parameters would work. A better solution (IMO)
would be to add two new magic words:

{{urlencode:<string>}}
{{urldecode:<string>}}

Which would allow us to encode/decode URL parameters as necessary. Now
if a dev could be convinced this is wise, we'd be set. =)

-L
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: odd behaviour of {fullurl:...}

William Allen Simpson-2
Locke Cole wrote:
> William Allen Simpson wrote:
>>   [{{fullurl:Special:Whatlinkshere/{{{1}}}{{{2}}}|limit=999}} links]
>>
>> Always works.
>
> Because it's part of the full URL generated (see below).
>
Look it is carefully.  It uses a / to indicate the parameter, yet when
you use the navigation bar, it generates:
   http://en.wikipedia.org/w/index.php?title=
   Special:Whatlinkshere&target=User%3AWilliam_Allen_Simpson

I just tried hand typing:
   http://en.wikipedia.org/w/index.php?title=
   Special:Whatlinkshere/User%3AWilliam_Allen_Simpson

So, both forms work, and I'm guessing that the slash form was created as
a workaround for the parsing issue.


>> Is there some reason that fullurl stops encoding spaces to underscores
>> when it runs into a pipe?
>
> The pipe adds parameters, basically {{fullurl:...}} seems to take this:
>
> {{fullurl:<page>|<param-1>|<param-2>|...|<param-n>}}
>
> And convert it into:
>
> <page: converted to full URL>?<param-1>&<param-2>&...&<param-n>
>
Yes, but it's parsing the parameters, yet failing to do the escaping on
them.  Seems like a *bug* to me.  However, there might be a good reason,
it's just not documented....


>> And speaking of syntax, why {{fullurl: instead of {{#fullurl: to match
>> the latest parser syntax?
>
> Probably because the latter would break existing pages relying upon
> {{fullurl: ...}}. Also, my understanding of {{# was that it was only
> used for parser extensions (not built-in magic words/functions).
>
The "{{#if:" started using the standard PHP "if", although it now is
a variant more like CPP #ifdef.

I'm not clear on the difference between parser extensions and magic
functions.  But I've not really looked at the code yet....


> Anyways, getting back to the problem of spaces in parameters, I don't
> think URL encoding parameters would work. A better solution (IMO)
> would be to add two new magic words:
>
> {{urlencode:<string>}}
> {{urldecode:<string>}}
>
> Which would allow us to encode/decode URL parameters as necessary. Now
> if a dev could be convinced this is wise, we'd be set. =)
>
But urlencode and urldecode (and rawurlencode and rawurldecode) are PHP
functions.  They don't work the way we'd like, they encode spaces as '+'
"for historical reasons" (that is, M$ visual basic), while we need '_'.

Maybe something like that is needed, but I'd rather concentrate on fixing
possible bugs in this function before going off and making yet another
almost but not quite the same as a floor wax and a dessert topping.
(Mixing Hitchhikers Guide with Firesign Theatre metaphors.)
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: odd behaviour of {fullurl:...}

Locke Cole
On 4/25/06, William Allen Simpson <[hidden email]> wrote:

> But urlencode and urldecode (and rawurlencode and rawurldecode) are PHP
> functions.  They don't work the way we'd like, they encode spaces as '+'
> "for historical reasons" (that is, M$ visual basic), while we need '_'.

The method used need not be the standard PHP urlencode/urldecode
functions. But I've rethought things a little, see below.

> Maybe something like that is needed, but I'd rather concentrate on fixing
> possible bugs in this function before going off and making yet another
> almost but not quite the same as a floor wax and a dessert topping.
> (Mixing Hitchhikers Guide with Firesign Theatre metaphors.)

Agreed. And I've entered what I believe to be an accurate (or at
least, accurate enough to diagnose and fix the issue) bug report at--

http://bugzilla.wikimedia.org/show_bug.cgi?id=5720

Vote/comment/etc. as you see fit. =)

-L
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: odd behaviour of {fullurl:...}

Rob Church
In reply to this post by William Allen Simpson-2
On 26/04/06, William Allen Simpson <[hidden email]> wrote:
> And speaking of syntax, why {{fullurl: instead of {{#fullurl: to match
> the latest parser syntax?

Because the "latest" syntax comes from an extension written a long
time after the first magic words were.


Rob Church
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: odd behaviour of {fullurl:...}

William Allen Simpson-2
Rob Church wrote:
> On 26/04/06, William Allen Simpson <[hidden email]> wrote:
>> And speaking of syntax, why {{fullurl: instead of {{#fullurl: to match
>> the latest parser syntax?
>
> Because the "latest" syntax comes from an extension written a long
> time after the first magic words were.
>
Sorry, my query wasn't sufficiently explicit.

What are the technical reasons for the syntax "{{fullurl:"?

What are the technical reasons for the syntax "{{#if:"?

My underlying question: are these planned differences or arbitrary?

And this may be related to my lack of understanding of the difference
between "magic words" and "parser extensions"....

Could somebody please explain?
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: odd behaviour of {fullurl:...}

Reinhardt-2
In reply to this post by William Allen Simpson-2
On Tue, 25 Apr 2006 19:38:55 -0400
 William Allen Simpson <[hidden email]> wrote:

> A couple of us were trying to figure out the syntax to add a working
> link to Special:Log in a template.
>
>   [{{fullurl:Special:Log|page={{{1}}}{{{2}}}}} log]
>
> Works fine as long as parameter 2 is only one word.  With a space in 2,
> only the first word shows up in the URL.
>
> Tried wrapping {{fullurl:{{{1}}}{{{2}}}}}, but page= won't take a full
> page name.
>
>   [{{fullurl:Special:Whatlinkshere/{{{1}}}{{{2}}}|limit=999}} links]
>
> Always works.

As far as I know this will fail if Special:Whatlinkshere/{{{1}}}{{{2}}} is
longer then 255 characters. In such case one should / might use "&target=".

> Is there some reason that fullurl stops encoding spaces to underscores
> when it runs into a pipe?
>
> And speaking of syntax, why {{fullurl: instead of {{#fullurl: to match
> the latest parser syntax?

regards reinhardt [[user:gangleri]]
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: odd behaviour of {fullurl:...}

William Allen Simpson-2
In reply to this post by Locke Cole
Locke Cole wrote:
> Agreed. And I've entered what I believe to be an accurate (or at
> least, accurate enough to diagnose and fix the issue) bug report at--
>
> http://bugzilla.wikimedia.org/show_bug.cgi?id=5720
>
> Vote/comment/etc. as you see fit. =)
>
A fine report.  And disconcerting to find that this has been a problem
since http://bugzilla.wikimedia.org/show_bug.cgi?id=839 (2004-11-07).

Meanwhile, I'm still hoping that somebody can remember why the escaping
stopped at the pipe, while the piped '|' arguments are properly converted
to '&' arguments.  This must have been a deliberate design decision.

And, while I'm thinking about it, what exactly the difference is between
fullurl and fullurle?  I haven't been able to find any documentation.
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: odd behaviour of {fullurl:...}

Bugzilla from rowan.collins@gmail.com
On 26/04/06, William Allen Simpson <[hidden email]> wrote:
> And, while I'm thinking about it, what exactly the difference is between
> fullurl and fullurle?  I haven't been able to find any documentation.

As noted on http://meta.wikimedia.org/wiki/Help:Variable
"Localurle and its counterpart fullurle perform additional character
escaping on the resulting link, are intended for internal use only,
and work in wikitext only for backwards-compatibility reasons. The
unescaped versions should always be used in wikitext."

As I remember it, {{fullurle}} was implemented purely for the sake of
completeness - since {{fullurl}} is just {{SERVER}}{{localurl}}, it
seemed logical to create a counterpart for {{SERVER}}{{localurle}},
even though it's never actually used, and never has been.

--
Rowan Collins BSc
[IMSoP]
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: odd behaviour of {fullurl:...}

Platonides
In reply to this post by William Allen Simpson-2

"William Allen Simpson"

> Locke Cole wrote:
>> William Allen Simpson wrote:
>>>   [{{fullurl:Special:Whatlinkshere/{{{1}}}{{{2}}}|limit=999}} links]
>>>
>>> Always works.
>>
>> Because it's part of the full URL generated (see below).
>>
> Look it is carefully.  It uses a / to indicate the parameter, yet when
> you use the navigation bar, it generates:
>   http://en.wikipedia.org/w/index.php?title=
>   Special:Whatlinkshere&target=User%3AWilliam_Allen_Simpson
>
> I just tried hand typing:
>   http://en.wikipedia.org/w/index.php?title=
>   Special:Whatlinkshere/User%3AWilliam_Allen_Simpson
>
> So, both forms work, and I'm guessing that the slash form was created as
> a workaround for the parsing issue.

Have into accont that you can use the slash form with a simple wiki link
[[Special:Whatlinkshere/User:William_Allen_Simpson]] while {{fullurl is
intended to use when you need to pass extra parameter which cannot be
created with wiki links, so you need a full url syntax.


>
>>> And speaking of syntax, why {{fullurl: instead of {{#fullurl: to match
>>> the latest parser syntax?
>>
>> Probably because the latter would break existing pages relying upon
>> {{fullurl: ...}}. Also, my understanding of {{# was that it was only
>> used for parser extensions (not built-in magic words/functions).
>>
> The "{{#if:" started using the standard PHP "if", although it now is
> a variant more like CPP #ifdef.
>
> I'm not clear on the difference between parser extensions and magic
> functions.  But I've not really looked at the code yet....

Magic words are like environment variables. Parser extensions are functions
called by a spell-word.

>> Anyways, getting back to the problem of spaces in parameters, I don't
>> think URL encoding parameters would work. A better solution (IMO)
>> would be to add two new magic words:
>>
>> {{urlencode:<string>}}
>> {{urldecode:<string>}}
>>
>> Which would allow us to encode/decode URL parameters as necessary. Now
>> if a dev could be convinced this is wise, we'd be set. =)
>>
> But urlencode and urldecode (and rawurlencode and rawurldecode) are PHP
> functions.  They don't work the way we'd like, they encode spaces as '+'
> "for historical reasons" (that is, M$ visual basic), while we need '_'.

You can use then str_replace(urlencode(<whatever>), "+", "_");
If there were plus signs into whatever they would've been %aged so  you're
using a urlencode-like function which replaces spaces into underscores.

What does MS VB have to do into it? The + sign is defined as a valid space
encoding at RFCs.

AFAIK, at the beginning, a way to encode a space was needed in order to
avoid it mistanding with the separator for the HTTP version field on the
request. Then more symbols needed escaping, thus developing the more
advanced %hex way, having the + form a %20 synonim.



_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: odd behaviour of {fullurl:...}

Jakob Voss-2
In reply to this post by William Allen Simpson-2
William Allen Simpson asked:

> Sorry, my query wasn't sufficiently explicit.
>
> What are the technical reasons for the syntax "{{fullurl:"?
>
> What are the technical reasons for the syntax "{{#if:"?

There are no technical but historical reasons.

> My underlying question: are these planned differences or arbitrary?

Wikisyntax is not planned. It evolves and mutates. Some people say that
there is a cabala to make the languages consist of brackets and pipes
only in the end. I don't think so because I don't think that there will
be an end (maybe praying to RFC, W3C, ISO or the God of Wiki helps?).

> And this may be related to my lack of understanding of the difference
> between "magic words" and "parser extensions"....
>
> Could somebody please explain?

In a perfect world you first design a language, test it and specify it
so you can create a parser and applications that understand the
language. We don't live in this world.

Greetings,
Jakob

P.S: How about an obscure Wikisyntax writing contest at Wikimania?

P.P.S: If you interested in a wiki markup standard then you should join
this list:
http://www.wikisym.org/cgi-bin/mailman/listinfo/wiki-standards

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l