Page MenuHomePhabricator

template markers in SF_FormPrinter.php do not work
Closed, ResolvedPublic

Description

Hi Yaron,

in SF_FormPrinter.php around line 1089 preg_replace( '/\}\}/m', '}�',... these template markers seem to cause trouble especially with partial forms. See also http://scratchpad.referata.com/wiki/Encoding_problems_with_partial_forms. So forms become more or less useless as no templates can be put into form fields. BTW this superscript 2 on http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SemanticForms/includes/SF_FormPrinter.php?revision=73948&view=markup becomes somehow a non utf-8 character � (�) but on our wiki we just downloaded SemanticForms with svn. Any fix for that?

Kind regards
Andreas


Version: unspecified
Severity: blocker

Details

Reference
bz25533

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 11:19 PM
bzimport set Reference to bz25533.

Using partial forms and saving them or getting just the preview after filling the form destroys the content if there is not just text, but also other wiki templates in a text field. Then the content becomes destroyed by a wrong replacement (see above). Maybe inner templates should not be replaced by } and a superscript 2? Just a guess.

Kind regards
Andreas

Please try to analyse the problem. This bug seems to be the same as

https://bugzilla.wikimedia.org/show_bug.cgi?id=23246

reported already in April, and where a patch was already proposed.

For me the problem is a total blocker. We have invested much effort into creating semantic forms, but have to keep them turned off as long as every use destroys previously the field content (e.g. a small template like {{smallcaps|the-text}} which we use a lot for formatting).

We use mediawiki 1.17 at SVN rev. 69050 at present.

About versions: on

http://scratchpad.referata.com/wiki/Form:Builder

the bug can be verified for Semantic Forms (Version 2.0.7rc1) (SVN r78505)
(http://scratchpad.referata.com/wiki/Special:Version)

As far as I know, this bug has been fixed in SVN; and the fix will go into the next version of SF, 2.0.8. Feel free to re-open if it's still a problem.