Last modified: 2008-09-04 12:53:22 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 14595 - SMWSQLStore2 - attribute values are HTML-encoded
SMWSQLStore2 - attribute values are HTML-encoded
Status: RESOLVED INVALID
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: 2008-06-19 21:17 UTC by Yaron Koren
Modified: 2008-09-04 12:53 UTC (History)
1 user (show)

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


Attachments

Description Yaron Koren 2008-06-19 21:17:07 UTC
The values being returned for attributes in SMWSQLStore2 are being HTML-encoded (i.e., "<" is returned as "&lt;"), which I don't think should happen (it doesn't happen for SMWSQLStore). I don't know what the ideal way to fix this is, but one way is to change line 174 of /includes/storage/SMW_SQLStore2.php from:

                                        $dv->setXSDValue($row->value, $row->unit);

to:

                                        $dv->setXSDValue(html_entity_decode($row->value), $row->unit);
Comment 1 Markus Krötzsch 2008-07-06 18:56:20 UTC
Strangely, the old SQLStore does not use any decoding either, so I do not see where the difference could come from. Normally, the "XSD value" should be encoded properly, and getWikiValue() or getShort*Text() should be used to retrieve the decoded version. If this fails, the afected datatype (string?) should be fixed.
Comment 2 Siebrand Mazeland 2008-08-11 11:05:25 UTC
Re-assign to extension developer for triage/comments.
Comment 3 Markus Krötzsch 2008-09-04 10:03:07 UTC
I should clarify further: the store holds strings in the format given by the datavalue implementations. It does not do any encoding/decoding of its own. It just stores what it is given. So if anything changed, then hopefully not depending on the storage implementation alone.

If there is a decoding/encoding problem anywhere, then this must be blamed on the affected datatype implementation (DV-class). The store does not return a value that is encoded in any way; it returns a objects. If you wish to display the value of such an object, you can use the get-methods of the datavalue and they will take care of all escaping/unescaping for you. This is where the encoding/decoding happens. So please specify which method of which datatype troubles you.

I also do not actually see the problem yet (apparently you could just decode &lt; by yourself). Is it that you want to distinguish between literal user input "<" and entity input "&lt;"? But this distinction is fairly difficult to make anyway since such things may change even during parsing. So what is the problem?
Comment 4 Yaron Koren 2008-09-04 12:53:22 UTC
No, problem, really; I somehow figured that this was incorrect behavior. I'm changing this to "invalid".

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


Navigation
Links