After installing the update, form variables being sent as a list, cannot be read as a simple values, they are now being sent as arrays.
error message is
Complex object types cannot be converted to simple values
<!doctype html> <cfparam name="form.testtext" default=""> <cfdump var="#form.testtext#" expand="yes"> <html> <head> <meta charset="utf-8"> <title>Untitled Document</title> </head> <body> <form action="test.cfm" method="post"> <input type="text" value="1" name="testtext"> <input type="text" value="2" name="testtext"> <input type="text" value="3" name="testtext"> <input type="text" value="4" name="testtext"> <input type="submit"> </form> </body> </html>
executing that prior to updating returns
after updating, it returns
I wasn't able to duplicate the issue you're seeing. I still get 1,2,3,4 as the result with CF2018 Update 11.
My test page had no application.cfm or application.cfc, so you might want to try that if you haven't already. The test was done on a Windows 10 system using the built in CF web server.
The form has nothing to do with CFML, as it is just text. ColdFusion was probably confused by:
<cfparam name="form.testtext" default=""> <!--- You've set the value of form.testtext to a string ---> <cfdump var="#form.testtext#" expand="yes"> <!--- Why dump a string? Why use the 'expand' attribute --->
What you perhaps mean is:
<cfparam name="form.testtext" default=""> <cfdump var="#form#" expand="yes">
I appreciate your answer BRBK, but I have the same issue - the problem is that the functionality of ColdFusion has changed. in some cases, where it used to return a set of comma separated values, it now returns an array.
Right now, i have no idea where the issue will crop up in my thousands of lines of legacy code, but it has disabled several pages.
I have to dig out where we were relying on the old functionality, and change it either to produce a comma separated value list in a new way, or to change the code that was expecting a comma separated value list to process an array Adobe needs to research this.
There is no question that this is a bug. Suppose, as in John's form (above), that the 4 input fields are returned as an array containing 4 elements. Then, for consistency, a single input field will have to be returned as an array containing 1 element. Which would be absurd. After all, the value of the field is text (a simple value), not an array (a complex type).
This is a known issue. The recent March cf updates changed this. And whether it is right or wrong (that they did that), there is at least a work-around. And no, you do NOT need to hunt down every program, just every CF application (at least until perhaps Adobe may offer a JVM arg to revert things instance-wide):
(Update: Note in both cases, there's an "s" after "form field" there. When I first wrote this, I mistakenly left it off, though I had it right in the other thread I refer to in a moment, as did some other folks writing here. Apologies for the finger fumble. )
As for where to raise a stink about this, you have choices:
Let us know if this helps.
This is strange. I have CF2016,0,17,325979 & CF2021,0,01,325996 (both Developer Edition) updated to the most recent version and they both return a string instead of an array. I verified that neither sameFormFieldsAsArray or sameURLFieldsAsArray are configured in the application.cfc.
QUESTION: Are duplicated URL parameters being treated like this too or only FORM parameters?
For the sake of comparison as a result of migration testing, I reviewed our tests using Lucee (server.coldfusion.productversion 2016,0,03,300357) and it didn't return an array for duplicated form or URL parameters.
James, I experienced that same vagary, when I first tried to help folks in that other thread that l listed above, and mentioned it in the bug report I filed (also listed above). It seems to vary at least based on OS, in an odd way. See those other two and comment there or here as you may see fit. Again, this is an odd one.
Charlie, you are a lifesaver!! thank you for the work-around.
Glad to have helped. It's been a curious issue.
I am trying to add this to our legacy application.cfm.
Unfortunately, we dont use a CFAPPLICATON though we do use an Application.cfm.
We dont use an Application.cfc either. Is there a way I can set this?
If you don't already have a cfapplication tag in your application.cfm then at the top of your application.cfm add
We got an error that states "Attribute validation error for tag CFAPPLICATION. It does not allow the attribute(s) SAMEFORMFIELDASARRAY." However, in the list there is another one:
So will attempt that one...
Ok followup, this worked. However had to use the following which is different from the answer:
<cfapplication name="Name_Of_App" SAMEFORMFIELDSASARRAY=false>
Name was required for the cfapp tag
I dont know why the S is required after the FIELD but our logs show that is a valid call.
We are using CF2018 with Java 11....
Benjamin, thanks so much for that. You are right: there is indeed an s after formfield in that attribute.
And I contributed to the mistake in that my first post here (since marked as the answer) made that mistake. I have just corrected it.
I wrote that first reply after offering the same info in another thread earlier that day (which I link to in the answer). I had it right in that one, and just finger-fumbled when I wrote my first reply here, just in a hurry to offer it to help.
And now I see that others here also sometimes got it right or wrong...and it led to some confusion. I apologize to everyone for starting that mistake. It's an easy one to make. Heck the attribute name itself is awkward.
But anyway, let's all be on the lookout for this going forward. And perhaps some of you who also referred to the wrong version could edit your comments here. I may offer a couple more replies to other responses here where I sense it may be valuable, if they may not necessarily see this.
Oh, and as for why a name was needed for your cfapplication tag (or a this.name if using application.cfc), that's controlled by a cf admin setting (in the "settings" page) that controls whether "unnamed" applications are allowed or not. So some folks will require it, while others will not. (FWIW, I offered a name in the example I first offered in the other post that I referred to, in my first answer here.)
I tried this in my application.cfm
no joy, same error.
my work around is this, but it requires mitigating all my codebase.
<cfset wklist = arraytolist(form.WK)>
<cfset wklist = form.WK>
<cfloop list="#wklist#" index="w">
You're creating a variable with <cfset sameformfieldasarray....
You need to put it in the cfapplication tag.
<cfapplication sameformfieldasarray=false .....
Thanks, that works.
George nailed it, but I wanted to also point out that you could reduce your shown code to a single line by using the "elvis" operator:
<cfloop list="#(isArray(form.WK) ? arrayToList(form.WK) : form.WK)#" index="w">
This is just an illustration, I didn't test it, but barring any typos it should work.
After more regression testing, found issues not fixed by sameformfieldasarray="false" the more issues which likely require your fix Eddie, thank you.
When you refer to "issues not fixed by sameformfieldasarray, are you saying such issues are specifically related to multiple values of a given form field showing as arrays, even when you set that to false? That would be odd.
If that's the case, I'd wonder if the code that is "failing to work" is somehow under the influence of a new and different application, that does NOT have this sameformfieldasarray=false set. You may want to use CF's GetApplicationMetadata function (perhaps even in a try/catch of the error) to see what it shows in that case.
I appreciate your help Charlie. I use application.cfm in my application, and the only CFAPPLICATION tag that exists is there.
this is a very old (and large) website that has moved up from CF10 to CF11 to CF2018. All I can say about it is that when hotfix11 is installed, I receive that error at various places in my code. Once I am done with my current development I will re-install hotfix11 and use GetApplicationMetadata to see what is happening.