Embedding Special:RunQuery effectively breaks rendering of preceding elements.


Author: kim


Create an mediawiki article with the contents:

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


<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


bzimport set Reference to bz49302.
bzimport created this task.Via LegacyJun 7 2013, 10:52 AM
Cavila added a comment.Via ConduitJul 15 2013, 7:40 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.

Jaideraf added a comment.Via ConduitOct 10 2013, 11:55 PM

Created attachment 13474
Same problem

Just +1 image


Jaideraf added a comment.Via ConduitNov 9 2013, 6:40 PM

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)

Yaron_Koren added a comment.Via ConduitDec 30 2013, 1:38 AM

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


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.Via ConduitJan 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.Via ConduitApr 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.)

Daniel5000 added a subscriber: Daniel5000.Via WebJan 1 2016, 12:12 AM
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptVia HeraldJan 1 2016, 12:12 AM
Daniel5000 added a comment.Via WebMon, Jan 18, 10:58 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