Thread:Project:Support desk/Too early HTML expansion of wiki code returned by if

When you use something like:



the  /   parser functions incorrectly assume that their return value will be the full content to expand to HTML, the result is: |Some text to display for the link as if it was:

It should be: Some text to display for the link as if it was:

So they expand the leading  as if it was at the start of a newline, and generate an indented block (the indented definition item in a definitions list: dl+dd elements in HTML), truncating the leading character from the link to generate here, and in fact breaking it completely.

Here this breaks the intent to generate an inline link to a category, but this could as well be an inline interwiki link to another language, or to a file or image (not to render in a thumbnail), for which we need the leading  in the return value.

The same happens when the return value of  starts by   (the bold defined term item in a definitions list: dl+dt elements in HTML), or   (bulleted item in an unordered list: ul+li elements in HTML), or   (numbered item in an ordered list: ol+li elements in HTML).

So the  parser function should not expand its return value out of its context, when it does not really know if it will be at the start of a wiki line, only the caller may do this where it knows that it follows a newline, or the caller should give instruction hints to #if about its current context of transclusion (i.e. if it is immediately after a newline; oatherwise the expansion should remain pending in the wiki code buffer and returned unchanged as a prefix to the caller that will perform the wiki code concatenation and expansion only when appropriate).

This may be caused by  or  returning a spurious leading newline in its return value


 * Note that this newline can't come from the source parameter given to be returned by  or , because these source parameters are trimmed from all their embedded HTML comments, and then from their leading and trailing whitespaces, including newlines. However numeric character entities are not parsed and replaced at this level — see the related bug below in the last example —, so   will not be considered whitespace and won't be trimmed, and these parser functions see each character entity as if it was multiple characters.

The bug does not affect the first parameter of  and , but it also affects the return value of  ,  , and possibly of some other functions returning some wiki text not intended to be used alone for generation of HTML...

Note that these tricks also do not work to generate the intended links:

|Some text to display for the link
 * same problem as above:
 * same problem as above:

|Some text to display for the link
 * no link generated, the brackets and pipe remain in visible text (even if this disables the generation of the definition list):
 * no link generated, the brackets and pipe remain in visible text (even if this disables the generation of the definition list):

|Some text to display for the link
 * broken result as well (additional bug, the numeric character entities containing  are not recognized correctly by the Mediawiki parser for links in double brackets, which incorrectly sees them as if they were containing an anchor)
 * broken result as well (additional bug, the numeric character entities containing  are not recognized correctly by the Mediawiki parser for links in double brackets, which incorrectly sees them as if they were containing an anchor)

There's currently no easy way for a conditional template using parser functions to safely return any undecorated value wiki-parsable in context and starting by,  ,   or. Except possibly by returning them by transclusion of another template, like  for returning pipes, the trick being usable as well for returning undecorated values starting by  ,  ,   or   (SPACE) in some cases where they need to preserve their special meanings at start of lines in the wiki syntax (or may be  ,  ,  ,  ,  ,  ,  ,  ,   as well, anywhere in lines ?).

Sometimes I really hate the wiki syntax with parser functions ! Thanks, now we can invoke the new Lua modules to replace all these damned parser functions in templates.