Page MenuHomePhabricator

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


Author: questpc

I have the following Semantic Template:TypeOfCountryData


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


{| class="travel-prop"





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="">Slashdot</a>}}

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

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

Even this one works:

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


$smwgLinksInValues = true;


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 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



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: (Gerrit Change I7fbf5a028fe4816edd215440c59848ac1a5f7636)

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

(In reply to comment #1)

Related URL: (Gerrit Change

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="">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 manually.

questpc wrote:

Found there is 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].


[2] {{#subobject:|Has demo=text property|Has description=<a href="">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

See [1], [2]



questpc wrote:

Can I add my own test pages to ?

Perhaps there is ?

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.


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:

MediaWiki 1.19alpha
Semantic MediaWiki (Version 1.8 alpha)

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

[[Has type::text]]

[[Has type::text]]


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


{| border="2"


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"?


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.


questpc wrote:

Has_description === "<a href="">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.