Embedding Special:RunQuery effectively breaks rendering of preceding elements.
Open, Needs TriagePublic

Description

Author: kim

Description:
Screenshot

Create an mediawiki article with the contents:

<nowiki>Insert non-formatted text here</nowiki>

{{Special:RunQuery/Car}}

<nowiki>Insert non-formatted text here</nowiki>

As a result this will cause the preceeding <nowiki> tag to be rendered with the a text similar to: UNIQ11c27ba27c17122f-nowiki-00000000-QINU when the expected behavior is to replace "UNIQ11c27ba27c17122f-nowiki-00000000-QINU" with the actual html formatted nowiki element.

The error seems to be caused by the following line in SF_RunQuery.php:

list ( $form_text, $javascript_text, $data_text, $form_page_title ) = $sfgFormPrinter->formHTML( $form_definition, $form_submitted, $is_text_source, $form_title->getArticleID(), $edit_content, null, null, true, $embedded );

Commenting out this line correctly renders the above nowiki element, however the special page is not embedded.


Version: unspecified
Severity: critical
OS: Linux
Platform: PC

Attached:

Details

Reference
bz49302
bzimport created this task.Jun 7 2013, 10:52 AM

This bug appears to have come with the latest version, SF 2.5.3 (I also tried the latest version from Git, but that one was marred by another bug). I've just reverted to SF 2.5.2 and everything, apart from bug 41780, is working fine again.

Created attachment 13474
Same problem

Just +1 image

Attached:

Another strange behavior of transcluding {{Special:RunQuery/...}}:

When there is a SMW query result on the page, it appears "SMW::off" and "SMW::on" before and after the result.

See: http://wikincat.org/w/index.php?title=Wikincat&oldid=5396

Semantic Forms (Version 2.6)
Semantic MediaWiki (Version 1.9 beta-1)
Semantic Result Formats (Version 1.9 alpha)

Stephan - I just looked into this, and it looks like the problem can be traced back to this change:

https://git.wikimedia.org/commitdiff/mediawiki%2Fextensions%2FSemanticForms.git/ca8d126424c19df723c0f8d39bc6ca21cb49be5c

In other words, it's related to the dreaded serialization/closure problem. You noted in that commit that the removal of the deep clone would lead to bugs, and this is one of them.

I'm re-assigning this to you, but I'm willing to help in any way with this issue. Is there some way to manually do a deep clone? Or some totally different way to do the parsing in the first place?

Unknown Object (User) added a comment.Jan 11 2014, 5:50 PM

(In reply to comment #3)

Another strange behavior of transcluding {{Special:RunQuery/...}}:

When there is a SMW query result on the page, it appears "SMW::off" and
"SMW::on" before and after the result.

As for the "SMW::off" and "SMW::on" topic, see #58991.

Cavila added a comment.Apr 4 2014, 8:26 AM

Just a note that at least the UNIQ...QINU symptom might be (partially) remedied if all wikitext for headings and subheadings is replaced with its equivalent in HTML (<h1>...</h1>, <h2>...</h2>, etc.).

(It does not entirely solve things, as you may still get odd behaviour such as the page title being replaced with the title of the special page.)

Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptJan 1 2016, 12:12 AM

The problem also affects widgets from the Widgets extension. All widgets in a page with a transcluded Special:RunQuery page are replaced by a UNIQ.... string.

For the page title problem, there is a workaround: to use the DISPLAYTITLE magic word to display the correct title. But you must first set $wgRestrictDisplayTitle to false, what may not be desired in some wikis.

This problem has prevented me to upgrade to a newer version than SF 2.5.2, which also blocks using a newer Semantic MediaWiki version than 1.8 (SF <=2.5.2 does not work with SMW >=1.9).

Add Comment