Last modified: 2011-04-13 00:23:48 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T26513, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 24513 - * or # in first line of a Text property is not displayed correctly in SMW factbox
* or # in first line of a Text property is not displayed correctly in SMW fac...
Status: REOPENED
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: Normal minor (vote)
: ---
Assigned To: Markus Krötzsch
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-23 16:24 UTC by Neill Mitchell
Modified: 2011-04-13 00:23 UTC (History)
3 users (show)

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


Attachments

Description Neill Mitchell 2010-07-23 16:24:41 UTC
Hi.

If I have:

* Point 1
* Point 2
* Point 3

in a SMW Text property field the first * is not parsed. It gets displayed as a raw *. The 2nd and 3rd do get displayed as bullet points.

The same is true for #. You only get the number from the second line on.

Interestingly, looking at the HTML, I see that the
Point 2
Point 3
are wrapped in a <p></p> whereas Point 1 is not.
Comment 1 Neill Mitchell 2010-07-23 16:33:31 UTC
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.
Comment 2 Markus Krötzsch 2010-08-29 19:13:02 UTC
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.
Comment 3 Neill Mitchell 2010-09-02 10:14:36 UTC
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?
Comment 4 Ike Hecht 2010-10-06 01:47:45 UTC
There is likely an extra space in the template that the form is using. I have not been able to duplicate this with SF.
Comment 5 Neill Mitchell 2010-10-08 16:52:01 UTC
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.
Comment 6 Ike Hecht 2010-10-08 17:22:02 UTC
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
|* 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.
Comment 7 Ike Hecht 2010-10-08 17:28:26 UTC
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.
Comment 8 Neill Mitchell 2010-10-11 08:28:40 UTC
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.
Comment 9 Ike Hecht 2010-10-11 12:49:36 UTC
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.
Comment 10 Yaron Koren 2011-01-20 19:02:51 UTC
Going through old bugs - I'm marking this as "invalid" since, as Ike Hecht pointed out, this is just a template-formatting issue.
Comment 11 Neill Mitchell 2011-01-20 20:54:25 UTC
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.
Comment 12 Ike Hecht 2011-01-20 21:01:34 UTC
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?
Comment 13 Yaron Koren 2011-01-20 21:02:22 UTC
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.
Comment 14 MZMcBride 2011-01-21 00:46:21 UTC
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.
Comment 15 Neill Mitchell 2011-01-21 09:49:41 UTC
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.
Comment 16 Yaron Koren 2011-01-21 20:21:50 UTC
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.
Comment 17 Neill Mitchell 2011-01-24 11:02:04 UTC
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.
Comment 18 Yaron Koren 2011-01-24 13:05:12 UTC
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).
Comment 19 Neill Mitchell 2011-01-24 15:42:31 UTC
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.
Comment 20 Yaron Koren 2011-01-24 15:51:46 UTC
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?
Comment 21 Neill Mitchell 2011-01-24 15:54:03 UTC
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 :)
Comment 22 Yaron Koren 2011-01-24 15:57:02 UTC
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.
Comment 23 Yaron Koren 2011-04-11 14:06:51 UTC
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".
Comment 24 Yaron Koren 2011-04-13 00:23:48 UTC
Also changed severity from "critical" to "minor".

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


Navigation
Links