Last modified: 2014-09-09 11:49:25 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T51302, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 49302 - Embedding Special:RunQuery effectively breaks rendering of preceding elements.
Embedding Special:RunQuery effectively breaks rendering of preceding elements.
Status: ASSIGNED
Product: MediaWiki extensions
Classification: Unclassified
SemanticForms (Other open bugs)
unspecified
PC Linux
: Unprioritized critical with 3 votes (vote)
: ---
Assigned To: s7eph4n
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-07 10:52 UTC by kim
Modified: 2014-09-09 11:49 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Screenshot (15.83 KB, image/png)
2013-06-07 10:52 UTC, kim
Details
Same problem (108.15 KB, image/png)
2013-10-10 23:55 UTC, Jaider Andrade Ferreira
Details

Description kim 2013-06-07 10:52:33 UTC
Created attachment 12492 [details]
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.
Comment 1 contrafibularity 2013-07-15 07:40:19 UTC
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.
Comment 2 Jaider Andrade Ferreira 2013-10-10 23:55:08 UTC
Created attachment 13474 [details]
Same problem

Just +1 image
Comment 3 Jaider Andrade Ferreira 2013-11-09 18:40:51 UTC
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)
Comment 4 Yaron Koren 2013-12-30 01:38:06 UTC
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?
Comment 5 MWJames 2014-01-11 17:50:59 UTC
(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.
Comment 6 contrafibularity 2014-04-04 08:26:55 UTC
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.)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links