Last modified: 2013-01-24 18:07:31 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 T45932, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 43932 - SMW\ListResultPrinter support html tags for non-list types
SMW\ListResultPrinter support html tags for non-list types
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
master
PC Linux
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-13 18:55 UTC by Noah
Modified: 2013-01-24 18:07 UTC (History)
5 users (show)

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


Attachments

Description Noah 2013-01-13 18:55:05 UTC
I'm running into what may be a bug with SMW 1.8 in combination with a recent version of MediaWiki.

Suppose Property:Words is of type Text.  Now create a page with the text below.  On both my old Wiki (SMW 1.7.1, MW 1.19.2, PHP 5.3.16, MySQL 5.5.21), and on sandbox.semantic-mediawiki.org, this works as I believe it should.  The two sides of the equation are both formatted as subscripts.

[[Words::<sub>Subscript</sub>]] = {{#show:{{PAGENAME}}|?words}}

However on my new Wiki (SMW 1.8, MediaWiki 1.20.2, PHP 5.4.10, MySQL 5.5.28) the html formatting is lost on the right side.  I believe the general behavior is that any html tags are getting stripped out of inline query results.  You can try playing around with an example here:

  http://new-server-9285b0.bitnamiapp.com/mediawiki/index.php/Testing

Any ideas what's going on?

Thanks,

  -- Noah
Comment 1 MWJames 2013-01-13 19:21:44 UTC
If I correctly remember, the #show uses the list printer as basis for the output representation but when the list printer is used in its normal mode any html tag that is included in a text entity can create distortion therefore 

$result .= Sanitizer::stripAllTags( $text );

It can not be assured that an user that includes an opening tag also closes the tag correctly which potentially leaves tags unresolved and results in broken list displays. (e.g. breaks badly any <ul><li></li></ul> chain etc.)

See Change-Id: I0dc962e87e857528030d71ee840ac0766c7da3b0
Comment 2 MWJames 2013-01-13 19:35:24 UTC
In this respect the list printer works correctly namely to ensure that text representations are properly sanitized in order to format a list output. Of course the question would be if the #show parser should rely on the list printer as vehicle for its result formatting.
Comment 3 Noah 2013-01-13 20:28:20 UTC
Thanks for this clarifying that this is now the expected behavior, and pointing to where to change it.  I'd personally be in favor of having the #show parser not depend on lists.  I've found it useful to be able to store and query for html-formatted text, and it seems unintuitive that a Text property can store html but #show can't query for it.
Comment 4 MWJames 2013-01-23 10:51:11 UTC
As of change [1], SMW\ListResultPrinter will support #show content (and html tags) that are of not of a list type format.

[1] https://gerrit.wikimedia.org/r/#/c/44572/2

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


Navigation
Links