Question

We are upgrading from 2x to 4.1.2 and are seeing problems with our forms.

I've traced it to the use of CGI.pm for building the radio group with not adding labels and values as two separate items. Probably other issues in the other types. Anyone with a fix or patch?

It relates to the use of labels vs values. Currently values are used in the printing and all html in the values are escaped, thus also escaping the labels and printing the html literally instead of properly formatted. It seems this happens by design in CGI.pm, in the radio_group function(and any other formfield generating function) as a test where labels are passed along.

Also(somewhat related..) the use of any TWiki variable in the values of a radio is now resolved and stored as the variable actual value, not the variable itself which is of course more useful and invalidates existing searches

This illustrates the problem: SandBox12

• The radio button in edit mode initially displays the value of the variable, but as escaped HTML (before this would be proper html)
• stored in the form will be the html, (before this would be the the variable )
• and finally rendered the end result is ok, as both now and before the html is displayed on the form in view mode, but searches won't work of course as the stored value is now HTML, not the variable.

Storing the variable is of course preferred as it gives us a proper code value setup where we can easily change display of the value.

The usage of this is quite extensive and is related to some TWiki applications we have built locally for managing software requirements and actions among other things. We use nicely colored and linked text for a lot of the options in the forms as that gives us a very user friendly setup (some of our major users are in our applications usability team). Images is also heavily used for options as illustrated in the Sandbox example.

thanks

olec

More investigation indicates that the variable expansion problem is related to DynamicFormOptionDefinitions. I should be able to get around that by wrapping my options table in a verbatim tag? I'm still unable however to not have CGI.pm escape all my pretty labels and values, thus having garbled edit mode output. Tried to hack in a autoEscape(0) which seems to be the way recommended without any luck. Any other suggestions on tricking CGI.pm to not escape my HTML values in the radio label?

-- OleCMeldahl - 14 May 2007

Finally was able to hack the code to skip the escaping, any thoughts of the safety of this?

[root@GST0KD lib]# diff TWiki/Form.pm TWiki/Form.pm.20070511 
438d437
<     my %labels;
616,617c615,616
<               { class=>'twikiRadioButton twikiEditFormRadioField'};              
<             $labels{$item} =  $session->handleCommonTags( $item, $web, $topic ) ;
---
>               { class=>'twikiRadioButton twikiEditFormRadioField',
>                 label=>$session->handleCommonTags( $item, $web, $topic ) };
622,624c621
<         my $q = new CGI("");
<         $q->autoEscape(0);
<         $value = $q->radio_group( -name => $name,
---
>         $value = CGI::radio_group( -name => $name,
626d622
<                    -labels => \%labels,

-- OleCMeldahl - 14 May 2007

Environment

-- OleCMeldahl - 11 May 2007

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

First time I see this reported. Could you try to update to the latest CGI module? See HowToInstallCpanModules.

-- PeterThoeny - 12 May 2007

Sorry, closing this after more than 30 days...

-- PeterThoeny - 06 Jul 2007