mitchell_neill wrote:

Here's the generated html for the above example:
<td>
*Point 1
<ul><li>Point 2
</li><li>Point 3
</li></ul>
</td>

So for some reason the first line of the text field is not being parsed correctly.

I cannot reproduce the problem: http://sandbox.semantic-mediawiki.org/wiki/Bug_24513

This page looks as expected.

The rendering of complex wiki markup in property is known to have various limitations, e.g., since enumerations must start directly at the beginning of a line. For example, it does not work in Factboxes where many values are printed one after the other. But this does not seem to be the concern of this report, so I close this as worksforme. If the problem persists under some circumstances, the bug should be reopened with a pointer to a page where the problem can be seen.

mitchell_neill wrote:

Hi.

Thanks for your response. Sorry, I realise my report is not clear enough.

This does this in text fields populated by Semantic Forms. I originally raised this as a bug in SF, but Yaron closed it saying it was a problem with SMW.

I think I may see what is happening here. Somehow a space is being put into the property before the first *. I suspect SF is putting the space character in. I have simulated this on the sandbox in Test 1.

This would also explain other parsing issues I see. Perhaps Yaron could comment?

ikehecht wrote:

There is likely an extra space in the template that the form is using. I have not been able to duplicate this with SF.

mitchell_neill wrote:

There is definitely no space in the template. I have replicated this problem here:
http://scratchpad.referata.com/wiki/Bullet_Test

You can see in the Description field that the first bullet is not rendered and the second one is.

Uses the form - Form:Mandatory Field Test Form
and the template - Template:Mandatory Field Test Template

SF has always done this for me and two other users I know.

Cheers
Neill.

ikehecht wrote:

After seeing your examples, I tracked it down. It is really a Mediawiki issue that comes up when using lists in a table at the beginning of a cell.

At any rate, the solution is to begin the list on the next line (after the pipe). Here's the issue and the fix:

{|
! Does not display first bullet

• Second Bullet

{|
! This is a fix

• First Bullet
• Second Bullet

I have updated the above pages to demonstrate this.

I hope this resolves your issue.

ikehecht wrote:

I should add that, even with the fix, it doesn't display correctly in the Factbox, so perhaps there is an SMW issue here as well.

mitchell_neill wrote:

The trouble is I can't expect my users to enter a pipe character in SF text fields. These are normal users who can't be expected to muck about remembering special workaround characters like this.

Perhaps the SF code could add the pipe?

Thanks
Neill.

ikehecht wrote:

I think you misunderstood. The modified code has to go in the template page, not the "content" page. In your example, the template would look something like this:

{| class="wikitable"

...

! Description

[[Description Property::{{{Description|}}}]]

...

The users can then fill out the SF text field "Description" beginning with an asterisk and everything should display correctly. There is no need for users to enter a pipe.

Going through old bugs - I'm marking this as "invalid" since, as Ike Hecht pointed out, this is just a template-formatting issue.

mitchell_neill wrote:

Guys, as can be seen on the above scratchpad.referata example I did, this is NOT the template. You can see there is no space in the template.

This has been a really long standing issue. It would to get to the bottom of it once and for all.

Thanks.

ikehecht wrote:

After seeing your example, I retracted what I had guessed about there being an extra space. I don't think I can explain this any better than I did. Yaron?

I don't understand - that page
(http://scratchpad.referata.com/wiki/Bullet_Test) clearly shows both the
problem, and the solution for it - the template field just needs to be on a new
line. Even if you think a newline shouldn't be required, that's a MediaWiki
issue, not an SMW one.

I haven't looked at this particular bug very closely, but r80430 (and possibly other commits) seem related. This bug could probably be a blocker of bug 529 or something. As Yaron notes, it's likely an issue with MediaWiki and not this particular extension, but that doesn't necessarily mean this bug is invalid.

mitchell_neill wrote:

Hi all.

Unfortunately putting a newline before the template field only seems to work in trivial templates. In more complex ones it does not fix the problem.

I'm pretty sure it is not a MW issue because as Ike demonstrates in comment 6, you can replicate it in MW if you put a space in, but if there is no space then it is fine. It only ever happens with SMW property fields.

Cheers
Neill.

Neill - sorry, I don't understand. The basic issue is this: if an asterisk is the very first character on a line, then it shows up as a bullet; otherwise, it shows up as an asterisk. There are some people who want that behavior changed in MediaWiki, but there's already a separate bug report for that. I think it's worth closing this one, because (again) I don't see how SMW relates to this.

mitchell_neill wrote:

Hi Yaron.
No, the problem is that when an asterisk is the first character in an SMW text field then it is not showing up as a bullet. It is showing up as an asterisk. That is the problem :)

Cheers
Neill.

Hi - it doesn't matter whether the character is the first one in an SMW text field - SMW gets its formatting cues from MediaWiki, and if MediaWiki decides it's an asterisk and not a bullet, then that's what SMW does. If you're asking for SMW to be smarter than MediaWiki, I don't think that's going to happen (nor should it).

mitchell_neill wrote:

Hi.

Sorry for banging on about this, but * and # behave perfectly in Mediawiki tables as Ike demonstrated. I know I'm sounding like a parrot here, but it only does not work with a SMW text property field in a SF form/template. I suspect SMW/SF is passing it to the MW parser with a space or other char before the * possibly? Could someone please do a code inspection around that area perhaps?

I initially raised this as a bug in MW, but it could be demonstrated that MW was not at fault. The fact that adding a newline in the SF template sometimes fixes it indicates to me that something odd is going on here that is nothing to do with MW itself.

Cheers
Neill.

Hi, I still don't think I understand. Could you point to an example where a * or # is the first character on a line (or the first one other than an SMW property call), and it doesn't get displayed correctly?

mitchell_neill wrote:

Ah, looks like scratchpad.referata has been cleaned since I posted the example. I'll re-create it on there when I have a minute.

Thanks for your patience :)

Actually, never mind - now I think I get it. You were talking about the display of the value in the factbox. Okay, that's true - but, as Markus notes above, that too is a MediaWiki issue, since it's just a table being displayed. The actual value being stored is simply the string of characters, with the '*'s - no formatting there.

Renamed to what I think is a more descriptive title: "* or # in first line of a Text property is not displayed correctly in SMW factbox".

Also changed severity from "critical" to "minor".