Last modified: 2009-05-13 18:52:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 10687 - ParserFunctions insert a newline character before the returned result
ParserFunctions insert a newline character before the returned result
Status: RESOLVED DUPLICATE of bug 12974
Product: MediaWiki extensions
Classification: Unclassified
ParserFunctions (Other open bugs)
unspecified
All All
: Normal normal with 3 votes (vote)
: ---
Assigned To: George Dowding
http://test.wikipedia.org/wiki/Bug_10687
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-25 01:14 UTC by Fibonacci
Modified: 2009-05-13 18:52 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Fibonacci 2007-07-25 01:14:30 UTC
Some (if not all) of the ParserFunctions appear to be inserting a newline character before the returned string. For example, if the wiki source contains this:
a{{#if:x|#1}}

Instead of rendering it as a#1, MediaWiki produces this in the HTML source:
<p>a</p>
<ol>
<li>1</li>
</ol>

Which is what I would have expected if the wiki source had been this:
a
#1

If the character before 1 is an asterisk, the same problem can be noticed. However, a{{#if:x|1}} renders as expected - understandable, since if there were a newline right after the "a", the result would be the same as if there were none.
Comment 1 George Dowding 2007-12-16 14:24:50 UTC
*** Bug 11262 has been marked as a duplicate of this bug. ***
Comment 2 George Dowding 2007-12-17 01:39:34 UTC
This appears to have been fixed in the trunk.

The following wiki source:
a{{#if:true|#foo|#bar}}

lorem{{#if:true|#foo|#bar}}ipsum

Produces:
			<p>a#foo
</p><p>lorem#fooipsum
</p>

Browsing the changes to ParserFunctions.php, I am unable to identify a change that fixed this problem.

Comment 3 Jelte (WebBoy) 2008-08-11 19:17:26 UTC
Bug still exists. See http://test.wikipedia.org/wiki/Bug_10687 .
Comment 4 Jelte (WebBoy) 2008-08-11 19:48:59 UTC
*** Bug 8199 has been marked as a duplicate of this bug. ***
Comment 5 Jelte (WebBoy) 2008-08-11 20:49:17 UTC
*** Bug 14036 has been marked as a duplicate of this bug. ***
Comment 6 Melancholie 2008-08-12 09:53:25 UTC
Copied from duplicated bug 14036 [semicolon]:

Since some time #ifexist: is producing a line break for the first condition!

If page exists the value is shown with a line break in front. If page does not
exist everything is fine!

See:
* http://de.wiktionary.org/wiki/Benutzer:Melancholie/bug (rendered text)
*
http://de.wiktionary.org/w/index.php?title=Benutzer:Melancholie/bug&action=raw&ctype=text/css
(source text)


Note: I could replace the semicolon by &#59; (I know)
http://de.wiktionary.org/w/index.php?title=Benutzer:Melancholie/bug&diff=787160&oldid=787156
(unknown IP),

but it should also work with ";"!
Comment 7 aliter 2008-09-08 17:01:02 UTC
I use #if:, but the problem is the same: It looks like inside the if, the semicolon is interpreted as the start of a definition.
Comment 8 Splarka 2009-05-13 18:52:42 UTC
Duping up, bug 12974 properly indicates it is a core problem and affects more than just parserfunctions/extensions.

*** This bug has been marked as a duplicate of bug 12974 ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links