Tested on MW 1.28.0, 1.28.1 and 1.30.0
Template parameters containing a table with html tags inside of the cells (<br>, <i> etc) are incorrectly parsed when opening a form. It seems like it's trying to encode the first half of the tags (e.g. <br> becomes <b>).
I have set up a demo page here: https://wikibase.nl/index.php/Page_forms_test
Awesome. Unfortunately the sandbox wiki has been overwritten as time went by. Would you like me to recreate it?
I've restored the page. Sorry that it took some time..
The sandbox environment runs on MW 1.28.3 where the bug also exists, in addition to 1.28.0 and 1.28.1
Is it possible that the encoding is done this way( <br> instead of <br> ) intentionally. Maybe the parser is made to parse < instead of < for some reason.
What are your thoughts?
Pretty unlikely. Yaron (author of Page Forms) said it's most likely a bug:
Yes, that looks an error... please create a bug report for it on Phabricator, if you can.
On Thu, Jun 22, 2017 at 10:02 AM, Viktor Schelling <viktor@wikibase.nl> wrote: Hi Yaron, I found a bug in Page Forms (PF 4.1.2 and 4.1.1 (tested on MW 1.28.0 and 1.28.2)). Template parameters containing a table with html tags inside of the cells (<br>, <i> etc) are incorrectly parsed when opening a form. It seems like it's trying to encode the first half of the tags (e.g. <br> becomes <b>). I have set up a demo page on our sandbox wiki here: https://sandbox.wikibase.nl/index.php/Page_forms_bug_visualization I hope it's clear this way! Kind regards, Viktor Schelling Wikibase Solutions
WikiWorks · MediaWiki Consulting · http://wikiworks.com
Also, if you save the page using the form (with the encoded characters wrongfully loaded) it submits it to the source code of the page leaving the wiki-parser unable to convert it to proper html
Ok. Got it. So it should be most likely a bug in ParserFunctions.php in Pageforms includes folder.
I believe ParserFunctions.php sets the functionality for {{#formlink}} and other MW Parser functions.
I am new to wikimedia (rookie). So I am hell of a lot confused right now with what's going here. So I'll try to search for the solution but it's gonna take quite a while.
If you know @WSViktorS , would you Kindly tell me in which php file would the error probably exist. As far as I searched it seem to be a general wikipedia parsing in its visual editor as in https://en.wikipedia.org/wiki/Help:Table#Converting_spreadsheets_and_database_tables_to_wikitable_format.
My best guess would be PF_FormPrinter.php, although I'm very inexperienced with MW Extension structures and PHP in general.
Hi.
Could you tell me where and how did you create the sandbox in the Description. I want to reproduce it in my vagrant environment.
Hi WSViktorS.
I tried to reproduce the bug but the parsing was correct in my local environment i.e. <br> instead of <br>
Hi there! As far as I know, it only exists on MW 1.28.x (any version).
I've tested it with Page Forms 4.1.2 and 4.1.1
@WSViktorS: 1.28 is an old unsupported version. Did you test this with 1.30 (or 1.29)? If yes, what were the results?
I should note that Page Forms still supports MW 1.28 (and even older versions than that). Still, it would indeed be good to know if this problem still exists with newer MW versions.
I do not have any wiki running 1.29 at the moment unfortunately (I can set it up if you'd like), but it's present on MW 1.30 + Page Forms 4.1.2 + PHP 7
@Himanshuc3: I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!). Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task. Please claim this task again when you plan to work on it (via Add Action... → Assign / Claim in the dropdown menu) - it would be welcome. Thanks for your understanding!
Well, after a long delay, I just tried this problem out (now on MW 1.39), with the following text in one field of the template:
Text above the table.
{{{!}}
! Header <i>column</i>.
{{!}} Text<br />with<br />breaks.
{{!}}}
Text below the table.This all went into a textarea in the form, and the form displayed and handled it fine, including those HTML tags. So I'm guessing that this problem has been fixed at some point, either within Page Forms or in MediaWiki itself.