Ask with format=template breaks HTML output

[jongfeli]

The move from SMW 2.2.3 to SMW 2.3 seems to break HTML in a {{#ask:... query with format=template. We have some buttons on which users can press which automatically update properties or values on a page but they are not working anymore. Example of the issue on: http://sandbox.semantic-mediawiki.org/wiki/User:Jongfeli

http://sandbox.semantic-mediawiki.org/wiki/Issue/1255

I tested this on MW 1.24.1 and SMW 2.1, 2.2, 2.2.3 & 2.3.0 but it is only happening in SMW 2.3.0

Below how it looks in SMW 2.2.3 (I noticed it shows 2.2.2 (D540302) on the MW version page).

[mwjames]

#1068 added option $smwgEnabledResultFormatsWithRecursiveAnnotationSupport to allow listed formats to use a "full parse" instead of a '[[SMW::off]]' . $wgParser->replaceVariables( $result ) . '[[SMW::on]]'. If you remove template from that list or set $smwgEnabledResultFormatsWithRecursiveAnnotationSupport = array() then it should return to your expected form.

Test cases that describe behaviour when activated

• https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/fd777541ce0f455f6ae5c7774a66850fd1dcbcd9/tests/phpunit/Integration/ByJsonScript/Fixtures/p-0406%20%5B%231055%5D%20unrestricted%20intext%20annotation%20via%20template%20ask%20parse.json
• https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/fd777541ce0f455f6ae5c7774a66850fd1dcbcd9/tests/phpunit/Integration/ByJsonScript/Fixtures/p-0701%20%5B%23711%5D%20ask%20template%20invert%20annotation.json
• https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/fd777541ce0f455f6ae5c7774a66850fd1dcbcd9/tests/phpunit/Integration/ByJsonScript/Fixtures/p-0205%20%5B%231055%5D%20set%20ask%20parser%20recursive%20annotation%20via%20template.json

[mwjames]

@jongfeli I'd be grateful if you can come up with a test case that doesn't involve SF but would return something similar for when $smwgEnabledResultFormatsWithRecursiveAnnotationSupport doesn't include template so we can include this as test case for future reference.

@kghbln FYI

[kghbln]

In general I think that for such things a configuration parameter is the better choice. However I see that it would make sense to have control of this on a query level instead of the wiki level. @JeroenDeDauw What's your opinion on this?

[mwjames]

#1257 makes it an query specific behaviour instead of a format specific one.

[0] https://semantic-mediawiki.org/wiki/Examples/Parser/Ask_with_template_to_annotate_invert_property (need to be changed to add the parameter)

[jongfeli]

@mwjames I had a go at coming up with an example that does not need SF or any other extension that generates this problem, which has the same result but with no luck. It is not possible to insert any html on a wiki page that is not allowed [0], you "need" extensions for that.

If I understand this correctly then a wikipage does not get parsed completely, so all extensions can do there trick, when recursive-parse=false? As a result the generated HTML gets blocked or/and is incomplete? This is not limited to SF but applies to all extensions that generate HTML.

For this test to work you need a test that runs against MW + SMW, no other extensions enabled?

[0] https://www.mediawiki.org/wiki/HTML_restriction

[jongfeli]

OK, I used recur-anno and the fix works fine. I noticed that the default value for recursive-parse actually makes it work again and not the other way around like I previously mentioned.

I am all for control on query level here but I am having a hard time even understanding what recursive-parse actually does when it is set to true, when do you need this? I see that it has something to do with being able to use Visual Editor but to me the name recursive-parse seems way to "softwarish" for most people to understand.

[mwjames]

I had a go at coming up with an example that does not need SF or any other extension that generates this problem, which has the same result but with no luck.

Thanks for trying.

hard time even understanding what recursive-parse actually does when it is set to true, when do you need this?

When you have templates to create invert annotation or you want to import annotations depending on the #ask outcome (== variable with the query).. Mainly for annotations to be conditional when #ask queries are involved.

the name recursive-parse seems way to "softwarish" for most people to understand.

I'm wondering whether I should change the name to import-annotation (recursive because the process that runs through #ask result is done recursively only limited by $maxRecursionDepth)?

[mwjames]

• The default behaviour has been restored with Support recursive annotation per query, refs #1255, #1068 #1257
• Recursive annotation import functionality is now only available for queries that use the import-annotation parameter (which by default is set false).
• Addition made available by Support recursive annotation per query, refs #1255, #1068 #1257 for 2.4 will also be deployed with 2.3.1
• Changes should be visible in [0]

...
 |format=list
 |template=AskTemplateToAddPropertyAnnotation
 |import-annotation=true
}}

[0] http://sandbox.semantic-mediawiki.org/wiki/Issue/1255

[jongfeli]

Thanks @mwjames. 👍

To be clear on the test, if we would be able to generate a test for this, would it run against MW + SMW only? No other extensions can be used?

[mwjames]

To be clear on the test, if we would be able to generate a test for this, would it run against MW + SMW only? No other extensions can be used?

The simple answer is yes because

In general, tests should be agnostic (== depend on as less as possible) to govern its execution in a wide range of environments without making it depend on extensions that would require interdependency monitoring.

What if you require an additional extension for those tests? You would have to track possible changes that can influence a test result. #1208 (comment) is a prime example where changes in MW (as we depend on it) causes effort (research the issue, fixing it, testing it === time that could be spent differently) to make the existing test outcome stable again to what it was designed before the changes appeared.

Simplify a test environment by trying to exercise the ceteris paribus clause where possible.

[kghbln]

import-annonation now documented.

@jongfeli The example somehow looks broken. Could you have a look ...?