Page MenuHomePhabricator

* and # are not always replaced following <pre> in list
Closed, ResolvedPublic

Description

Author: cyril.cauchois

Description:
Here is the text I enter in the edit form :

  • '''Gras''' : <pre> '''Mon texte en gras''' </pre>
  • ''Italique'' : <pre> ''Mon texte en italique'' </pre>
  • '''''Gras Italique''''' : <pre> '''''Mon texte en gras italique''''' </pre>
  • <cite>Police à chasse fixe</cite> : <pre> <cite>Police à chasse fixe</cite> </pre>
  • Un Titre de niveau 1 : <pre>=== mon titre 1 ===</pre>
  • Un Titre de niveau 2 : <pre>== mon titre 2 ==</pre>
  • Un Titre de niveau 3 : <pre>= mon titre 3 =</pre>

The 3rd and the 6th line, the * is not replaced by a bullet ; it appears * in the
rendered page.


Version: 1.4.x
Severity: minor
URL: http://meta.wikimedia.org/wiki/Sandbox/785

Details

Commits
Unknown Object (Diffusion Commit)
Reference
bz785

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 7:08 PM
bzimport added projects: MediaWiki-Parser, Parser.
bzimport set Reference to bz785.

leercontainer-bugzilla wrote:

I have confirmed this here:
http://nn.wikipedia.org/w/wiki.phtml?title=Brukar:Dittaeva/Sandkasse&oldid=2352.

The way the text is made you solve the problem by writing it like here
http://nn.wikipedia.org/wiki/Brukar:Dittaeva/Sandkasse, using a space in as
the first character of a new line, instead of <pre></pre> on the same line as
the description.

cyril.cauchois wrote:

(In reply to comment #1)

I have confirmed this here:
http://nn.wikipedia.org/w/wiki.phtml?title=Brukar:Dittaeva/Sandkasse&oldid=2352.
The way the text is made you solve the problem by writing it like here
http://nn.wikipedia.org/wiki/Brukar:Dittaeva/Sandkasse, using a space in as
the first character of a new line, instead of <pre></pre> on the same line as
the description.

Ok this way, the text is framed, but it is interpreted. I used <pre> in order to see formatting
characters ; I don't want them to be rendered.

leercontainer-bugzilla wrote:

(In reply to comment #2)

Ok this way, the text is framed, but it is interpreted. I used <pre> in order

to see formatting

characters ; I don't want them to be rendered.

True, I didn't notice that. It iterprets and formats the bold and italic text
but not the headers. I think that is also a bug!?

hashar added a comment.Nov 9 2004, 3:41 PM

confirmed in HEAD.

hashar added a comment.Nov 9 2004, 4:01 PM

Simplier test case:

--[Cut below]-------

  • <pre>foo1</pre>
  • <pre>bar2</pre>
  • another list item

--[Cut above]-------

brion added a comment.Jan 29 2005, 7:27 AM

Confirmed still present in REL1_4 and HEAD.

ccurtis wrote:

I think this bug is more generic than what is stated. Here is the problem I've
found in the latest (2005-02-08) release:

#Item 1<pre>pre1</pre>
#Item 2<pre>pre2</pre>
#Item 3<pre>pre3</pre>
#Item 4<pre>pre4</pre>
#Item 5<pre>pre5</pre>
#Item 6<pre>pre6</pre>

And you can't just add newlines with spaces because it breaks the numbering, so
there is no workaround (that I've been able to find).

brion added a comment.Feb 16 2005, 7:11 AM

(In reply to comment #7)

I think this bug is more generic than what is stated. Here is the problem I've
found in the latest (2005-02-08) release:

That looks exactly like the samples already provided. All list types are processed with the same code, so it would be
surprising for numbered lists to behave differently from bullet lists here.

c.dittberner wrote:

(In reply to comment #7)

I think this bug is more generic than what is stated. Here is the problem I've
found in the latest (2005-02-08) release:
#Item 1<pre>pre1</pre>
#Item 2<pre>pre2</pre>
#Item 3<pre>pre3</pre>
#Item 4<pre>pre4</pre>
#Item 5<pre>pre5</pre>
#Item 6<pre>pre6</pre>
And you can't just add newlines with spaces because it breaks the numbering, so
there is no workaround (that I've been able to find).

If you look at the parser code in includes/Parser.php there is a handling for a
pre-open tag but no handling if the pre-close tag is in the same line. Something
like this should solve the problem:
old:
$preOpenMatch = preg_match('/<pre/i', $oLine);

new:
$preOpenMatch = preg_match('/<pre(.*)$/i', $oLine,$preOpenMatches );
$preOpenCloseMatch = preg_match('/\s*\/\s*pre\s*>/i', $preOpenMatches[1] );
$preOpenMatch -= $preOpenCloseMatch;

c.dittberner wrote:

patch for closing pre-tag on single line

attachment Parser.php.pre_single_line.patch ignored as obsolete

c.dittberner wrote:

Comment on attachment 313
patch for closing pre-tag on single line

mediawiki 1.4rc1

jeluf wrote:

Notice: Undefined offset: 1 in /var/www-phase3/includes/Parser.php on line 1518
Patch apparently doesn't work when there's no <pre> within the page

jeluf wrote:

*** Bug 1873 has been marked as a duplicate of this bug. ***

hashar added a comment.Jul 8 2005, 7:43 AM

Probably got a fix for it. Under testing at the momment.

hashar added a comment.Jul 8 2005, 8:06 AM

Created attachment 679
correctly get out of a pre element when using list

  • remove a test to find if the parser is in a pre block. This is already done

at the beginning of the foreach.

  • correctly get out of pre block when we have </pre>

Attached:

hashar added a comment.Jul 8 2005, 8:08 AM

My patch need review. It passes the parser test but I am not sure
it is the best way to get out of the pre block.
Somewhere above in the code, there must be a point where the pre
block is closed. That's where the patch should occur. Unfortunatly
I haven't been able to find that point :(

Commiting, I haven't found a better way to do it.
Parser test already in cvs.

zigger wrote:

*** Bug 2914 has been marked as a duplicate of this bug. ***

brion added a comment.Sep 8 2005, 8:50 AM
  • Bug 3396 has been marked as a duplicate of this bug. ***
epriestley added a commit: Unknown Object (Diffusion Commit).Mar 4 2015, 8:21 AM