Last modified: 2012-04-24 06:50:11 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 10893 - Wikitext in list items written in HTML not properly parsed
Wikitext in list items written in HTML not properly parsed
Status: NEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.15.x
All All
: Low normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-12 14:49 UTC by Jonathan
Modified: 2012-04-24 06:50 UTC (History)
3 users (show)

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


Attachments

Description Jonathan 2007-08-12 14:49:11 UTC
With the following code I have issues getting the first list item to render properly, unless I add a </li> in front of the first list item open tag. Indented lines in the first list item are not rendered the same as is done in subsequent list items.

The same holds for list items where the close item from the previous list item and the opening tag of the next list item are not on the same line, I think there is some issue with the rendering logic as only list items starting with </li><li> are rendered properly.

The text from my sandbox test:
<ol>
<li>Open a SME Server shell as root user and document the current setting of the PHPBaseDir directive by writing down the output of the following command:
 db accounts getprop ibayname PHPBaseDir 
Be careful to write it down to the letter as we need it in the next step
For the Primary ibay the ouptut of above command would normally look like this:
 /home/e-smith/files/ibays/Primary/html/
</li><li>Decide on what directory you would like to add and issue the following:
 db accounts setprop PHPBaseDir ibayname value

replacing ibayname with the name of the ibay and value with the old value for the PHPBaseDir directive you have written down and a colon (:) followed by the full path to the directory you would like to add with a tailing slash (/), e.g.
 db accounts setprop PHPBasedir Primary /home/e-smith/files/ibays/Primary/html/:/opt/gallery2/

Above command would allow for invocation of scripts in the /opt/gallery2 path from the Primary ibay html folder by PHP.
<!--TODO: Check if it is true that PHP can by default write into the files folder of an ibay.

{{Warning box|Some applications need to store temporary files. Sometimes installation instructions tell you to therefore add the /tmp folder to the open basedir configuration setting. This is not preferred as it could breach security of your server. Instead make a folder in the files folder of the ibay or write temporary data there. Most applications should have a possibility to define the location of temporary files. You should not need to modify the PHPBaseDir setting for that to work.}}-->

</li>
<li>After defining the new setting we need to reflect the change in the configuration file of the web server and have the web server reload it's configuration file. This is done by issuing the following command:
 signal-event ibay-modify ibayname

Be sure to replace ibayname with the name of the ibay you have just modified.
</li></ol>
Comment 1 Jonathan 2007-08-12 14:57:51 UTC
Discovered in 1.10.0, but still present when tested in this sandbox (http://meta.wikimedia.org/wiki/Meta:Sandbox) at version 1.11alpha
Comment 2 Danny B. 2007-08-13 04:08:34 UTC
Use <pre> tag instead of indenting.

However, the parsing of the code you provided (therefore the output) is pretty weird though.
Comment 3 Danny B. 2007-08-13 04:21:10 UTC
Since I played with it a bit more, I'm changing the summary to more general, because:

* not only first item is rendered wrong, also others
* not only ordered lists, also unordered

Some observation:

<ol>$
<li>$
lorem ipsum$
 foo bar$
dolor sit amet$
</li>$
</ol>

$ = have zero or more newlines on that place, tested (hopefully) all possible combinations

always renders

1. lorem ipsum foo bar dolor sit amet

instead of awaited

1. lorem ipsum
   +------------------+
   | foo bar          |
   +------------------+
   dolor sit amet

but

<ol>
<li>
lorem ipsum
<pre>foo bar</pre>
dolor sit amet
</li>
</ol>

renders properly
Comment 4 Jonathan 2008-08-17 19:26:00 UTC
This seems to still be present in 1.13.0, any change you will be fixing this?
Comment 5 Jonathan 2009-02-20 11:54:48 UTC
(In reply to comment #4)
> This seems to still be present in 1.13.0, any change you will be fixing this?

It is even still present in 1.13.4, and changes on this being fixed or looked after?
Comment 6 Jonathan 2009-06-17 19:21:36 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > This seems to still be present in 1.13.0, any change you will be fixing this?
> 
> It is even still present in 1.13.4, and changes on this being fixed or looked
> after?
> 

Even 1.15.0 is still suffering this. Anyone looking at this bug?
Comment 7 Marcin Cieślak 2012-04-23 22:36:39 UTC
This might or might not be fixed with Gerrit change #5174 to fix bug 11748.
Comment 8 Gabriel Wicke 2012-04-24 06:50:11 UTC
(In reply to comment #7)
> This might or might not be fixed with Gerrit change #5174 to fix bug 11748.

Gerrit change #5174 only fixes the handling of self-closing tags when Tidy is disabled. All Wikimedia wikis have Tidy enabled, so it won't fix any bugs reproducible on those.

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


Navigation
Links