Page MenuHomePhabricator

Embedding Special:RunQuery effectively breaks rendering of preceding elements.
Closed, ResolvedPublicBUG REPORT


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


2013-06-07--1370601931_468x425_scrot.png (425×468 px, 15 KB)



Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 1:59 AM
bzimport set Reference to bz49302.

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


SF_2.5.3.png (481×960 px, 108 KB)

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.


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:

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.

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

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

I just got Special:RunQuery embedding working again, but unfortunately this parsing problem is still there... five-year bug.

Foxtrott subscribed.
Aklapper triaged this task as Low priority.Feb 4 2022, 8:07 PM
Aklapper changed the subtype of this task from "Task" to "Bug Report".
Yaron_Koren claimed this task.

This problem seems to have been fixed at some point in the last five years, thankfully.