Username Password
Bookmark and Share
View All Tickets
hing value|label pairs cause parsing error after upgrade to 7.10  (#12340)


Thingys created in 7.9 generate parsing errors during upgrade to 7.10, and when viewing/editing Things after the upgrade. (The errors during upgrade came during re-indexing in the 7.9.34 to 7.10.22 step.) They appear to be related to Thing Fields that haver multiple pre-defined values in value|label pairs. The errors generated suggest that there are problems handling the newlines/carriage returns between value|label pairs.

I have attempted to create a demo package (for 7.10.22) with a simple Thingy, however my tests to import this package into another 7.10.22 WebGUI site have failed. I'll attach it here in case others can make it work.

Without this package, you can easily replicate the bug, starting in 7.10 (no upgrade necessary):

  1. Create a Thingy
  2. Add a Thing
  3. Add a Thing Field of the Radio List type
  4. Add possible values:
  5. Save.

When you go to view or edit the thing, you should see errors in modperl.error.log that look like this (yes, formatted with these odd line breaks):

Bareword found where operator expected at (eval 1520) line 1, near "1label"
        (Missing operator before label?)
Number found where operator expected at (eval 1520) line 2, near "label
        (Do you need to predeclare label?)

4/10/2012 5:09 pm
Update: I've returned to this issue, and I've learned more about it, including the fact that this bug was NOT created during the recent update, but existed as far back as 7.9.20.

I've been able to replicate the errors on a system still running 7.9.20. I had not seen the errors before because I had not created any Thingys that include the particular components that lead to the errors appearing. I just happened to be working on a new Thingy and using the same system to run upgrade tests about the same time, which caused the misinterpretation that they were somehow related.

The problem as far as I have determined is related to the parsing of Thing fields that have multi-line possible-values fields. Certain types of keys and/or labels will cause the parsing errors if included as possible values:

1. Values/labels that start with a digit. For example, you can not have a list of years to select from, because this will cause the parsing error. In my original example with this bug, the keys are 1, 2 and 3, which cause the error. It's behaving as if Perl's "scalars can't start with numbers" rule is being invoked.

2. Single or double quotes. Trying to resolve the number problem by wrapping the numbers in quotes in hopes of making them appear to be scalar values also causes the parsing errors. However, enclosing text in quotes ALSO causes the parsing errors, so there may be a separate problem with quotes. (If there is, then the hover help for the possible values field should be updated to note that quotes are not allowed here.)

3. When using the key|value structure, the parsing errors can occur in EITHER position -- it's not just the first character in the row that is important. So, for example, I tried making a select list of years where the year key value started with an "_", but the label was the number itself: _2012|2012 the parsing error appeared. It went away when I added an underscore before BOTH years: _2012|_2012. There appears to be no way that you can have a key or label value in this field type that starts with a number.

4/12/2012 5:00 pm
Update 2: I've tracked the problem down to the use of secureEval, which runs the possible values through the CPAN Safe module. If you go into getFormPlugin in and replace

my $values = WebGUI::Operation::Shared::secureEval($session,$data->{possibleValues});

with  my $values = $data->{possibleValues};

The errors stop, though you bypass any security that Safe gave you.

Side note: I found that in the Wiki, there are actually two ways to define key/value pairs listed, the one in the hoverhelp that has you just use newlines and pipes (1.c.), and one further down (1.h.) that uses more traditional object structure { key=>value } (but the wiki has the curly braces reversed). Both are describing how to define possible values for fields. When I converted my own Thingy to the object-style format, the errors went away.

However, the select options lost their numerical/alphabetical order, which is another bug of WebGUI's that I need to file...

At least I have a temporary solution to the errors themselves. However, I'm not sure what the solution to the secureEval problem should be.
Ticket Status Pending  
Submitted ByTrex 
Date Submitted2012-03-06 
Assigned To unassigned  
Date Assigned2023-05-30 
Assigned By 
Severity Minor (annoying, but not harmful)  
What's the bug in? WebGUI Stable  
WebGUI / WRE Version 7.10.22  
Related Files
Ticket History
12:29 AM
Ticket created Trex
© 2023 Plain Black Corporation | All Rights Reserved