Last modified: 2012-04-24 06:50: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>
Discovered in 1.10.0, but still present when tested in this sandbox (http://meta.wikimedia.org/wiki/Meta:Sandbox) at version 1.11alpha
Use <pre> tag instead of indenting. However, the parsing of the code you provided (therefore the output) is pretty weird though.
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
This seems to still be present in 1.13.0, any change you will be fixing this?
(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?
(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?
This might or might not be fixed with Gerrit change #5174 to fix bug 11748.
(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.