Page MenuHomePhabricator

Subobject text type property value does not permit to store a href links
Closed, DeclinedPublic

Description

Author: questpc

Description:
I have the following Semantic Template:TypeOfCountryData

<includeonly>{{#subobject:|

Title of topic={{{1}}}
Description={{{2}}}
Additional info={{{3}}}

}}

{| class="travel-prop"
!{{{1|}}}

-
{{{2}}}

{{#if:{{{3|}}}|

{{{3}}}}}

}</includeonly>

Property:Title_of_topic, Property:Description, Property:Additional_info all are defined as

[[Has type::text]]

The page content samples are below.

This one does NOT work (no subobject value for Property:Description):

{{TypeOfCountryData|A web site link|<a href="http://slashdot.org">Slashdot</a>}}

While this works (Property:Description === "Slashdot"):

{{TypeOfCountryData|A web site link|Slashdot}}

Even this one works:

{{TypeOfCountryData|A web site link|[http://slashdot.org Slashdot]}}

Placing

$smwgLinksInValues = true;

after

include_once( "$IP/extensions/SemanticMediaWiki/SemanticMediaWiki.php" );

makes no difference.

So it seems that specifying "a href" as part of text property is broken in SMW 1.8.0.4. At least for subobjects.

Should I try switch to 1.9 perhaps? I didn't want because it's not an release yet.

BR and a lot of tags work just fine for subobject values, but A HREF. I really need it because I import automatically generated content into pages.


Version: REL1_20-branch
Severity: normal

Details

Reference
bz49530

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 1:46 AM
bzimport set Reference to bz49530.
bzimport added a subscriber: Unknown Object (MLST).

Related URL: https://gerrit.wikimedia.org/r/68420 (Gerrit Change I7fbf5a028fe4816edd215440c59848ac1a5f7636)

Unknown Object (User) added a comment.Jun 13 2013, 4:53 PM

(In reply to comment #1)

Related URL: https://gerrit.wikimedia.org/r/68420 (Gerrit Change
I7fbf5a028fe4816edd215440c59848ac1a5f7636)

The added unit test covers text storage/[1] in a subobject and does not show any deviation in the expected text representation.

In case the unit test failed to verify the expected output, this issue should be re-opened with appropriate data that can be modelled but the current master (SMW 1.9) does render text properties (with href) as specified in the test.

PS: Unit tests are run against the current master, questions related to a non master release (SMW < 1.9) are not covered by the unit test.

[1] <a href="http://username@example.org/path">Example</a>

questpc wrote:

How much stable master is? I'll try to install master tomorrow, then will check the link - although that's extra work.

Is there any chance unit test might be OK while the real world case fail?

Maybe I'll try to add unit test to 1.8.0.4 manually.

questpc wrote:

Found there is 1.8.0.5 already, upgraded by simply overwriting, issue is still here. 1.9.x tomorrow.

questpc wrote:

No, the subobject property with value containing A HREF is still not being stored in

mw.1.22wmf6 600734e5bcb259f8ec270a2023110e3ddcc4a91a
SemanticMediaWiki 1.9a e9e681c19aa940ebea12d139a96d64b9369e2121
DataValues 9379abf42b47c65438a29cc3605c8a7c450fdfe0
Validator d47e6803e2d8e4c96392fe2ddd0f83c99b83bbc8

All are master of very close to master.

How can I run SMW unit tests at my hosting? I see that unit testing for MW gives very cumbersome restrictions:

Make sure your LocalSetting.php has language set to English. (This is bug 26464):

$wgLanguageCode = "en";

Unit tests fail might when run with locale enabled, therefore you should unset LANG, LC_ALL, LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, LC_TIME environment variables or make sure they are set to C (This is bug 35114).

My wiki is $wgLanguageCode = "ru";

But I believe the tests will probably pass, unlikely they are to fail.

I suspect that Parser does something with A HREF links which SMW does not like.

questpc wrote:

I installed phpunit and it's dependencies.

Please give me a hint how to run /extensions/SemanticMediaWiki/tests/phpunit/includes/SubobjectTest.php locally.

Unknown Object (User) added a comment.Jun 14 2013, 7:57 AM

Well, the test does work as specified and so does the text storage. You might have a look at [1] which does exactly what the unit test does by storing [2] and using a #ask query to display the stored value [3].

[1] http://www.semantic-mediawiki.org/wiki/Demo:Subobject

[2] {{#subobject:|Has demo=text property|Has description=<a href="http://username@example.org/path">Example</a>}}

[3] {{#ask: [[Has demo::text property]]|?Has description}}

Unknown Object (User) added a comment.Jun 14 2013, 8:00 AM

(In reply to comment #6)

I installed phpunit and it's dependencies.

Please give me a hint how to run
/extensions/SemanticMediaWiki/tests/phpunit/includes/SubobjectTest.php
locally.

See [1], [2]

[1] https://www.mediawiki.org/wiki/Unit_test

[2] http://www.semantic-mediawiki.org/wiki/Category:Testing

questpc wrote:

Can I add my own test pages to http://www.semantic-mediawiki.org ?

Perhaps there is test.semantic-mediawiki.org ?

I use template, not direct #subobject

Unknown Object (User) added a comment.Jun 14 2013, 8:47 AM

You can use [1] but as far as I know those are not operating with the current master (SMW 1.9) and therefore might not be comparable with any findings stated in this bug.

#subobject (it classes and parser function) does not account for any custom specific interaction and therefore are not part of the specification nor its tests.

[1] http://www.semantic-mediawiki.org/wiki/Sandbox

PS: Please only re-open the bug in case where the notion that href is not supported by #subobject is valid but given the unit test result and the cited example this bug is invalid due to the given examples.

questpc wrote:

http://sandbox.semantic-mediawiki.org/wiki/Special:Version

MediaWiki 1.19alpha
Semantic MediaWiki (Version 1.8 alpha)

http://sandbox.semantic-mediawiki.org/wiki/%D0%93%D0%B5%D1%80%D0%BC%D0%B0%D0%BD%D0%B8%D1%8F

{{СтранаТипИнформации|Посольства РФ за рубежом|<a href="http://slashdot.org/">slashdot.org</a>}}
{{СтранаТипИнформации|Посольства иностранных государств в РФ|test}}

http://sandbox.semantic-mediawiki.org/wiki/Property:%D0%97%D0%B0%D0%B3%D0%BE%D0%BB%D0%BE%D0%B2%D0%BE%D0%BA_%D1%82%D0%B5%D0%BC%D1%8B

[[Has type::text]]

http://sandbox.semantic-mediawiki.org/wiki/Property:%D0%9E%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5_%D1%82%D0%B5%D0%BC%D1%8B

[[Has type::text]]

https://mediawiki.dev.travelsystem.ru/index.php/%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:%D0%A1%D1%82%D1%80%D0%B0%D0%BD%D0%B0%D0%A2%D0%B8%D0%BF%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%B8

http://sandbox.semantic-mediawiki.org/wiki/Template:%D0%A1%D1%82%D1%80%D0%B0%D0%BD%D0%B0%D0%A2%D0%B8%D0%BF%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%B8

<includeonly>{{#subobject:|

Заголовок темы={{{1}}}
Описание темы={{{2}}}

}}

{| border="2"
!{{{1|}}}

-
{{{2}}}
}</includeonly>

It does NOT WORK. A HREF is NOT being stored as value of subobject text type property. NEITHER in sandbox wiki NOR in local MW / SMW master.

Unknown Object (User) added a comment.Jun 14 2013, 9:55 AM

If this is true then what is displayed in [1] as property "Has description"?

[1] http://www.semantic-mediawiki.org/wiki/Demo:Subobject

questpc wrote:

Please convert that to template call similar to my first original example at top.

My site requires Semantic Forms, which cannot manipulate #subobject function calls directly.

Unknown Object (User) added a comment.Jun 14 2013, 10:16 AM

I rest my case, the smw-core has an unit test that covers the example cited in [1] which does what is expected of, beyond this point I will excuse myself from this discussion.

[1] http://www.semantic-mediawiki.org/wiki/Demo:Subobject

questpc wrote:

http://www.semantic-mediawiki.org/wiki/Demo:Subobject_template_with_href

http://www.semantic-mediawiki.org/wiki/Template:SubobjectDemoDesc

Has_description === "<a href="http://www.mediawiki.org/">MediaWiki</a>" is not being created.

But you are probably right - that more looks like MediaWiki Parser issue with A HREF as template parameter. Need to investigate further. I'll close this bug.

However it's really unfortunate resolution, because that prevents me from using Semantic Forms.