[closed] 500 server errors in webtop Manage Configuration pages after upgrade from Core 7.1.2 to 7.2.3

Hi all,

I have updated the core files on my dev server from 7.1.2 to 7.2.3. Ran an ?updateall=<myupdateappkey> and ?updateapp=<myupdateappkey> but after that I still get some 500 server errors when navigating in the Webtop/Manage Configuration/General Configuration page. The error also happens on the following links on that page Environment Configuration, Form Theme Configuration, Google Site Search, and Security Configuration.

The error is the same for all of the above links.

500 - Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed.
There was a problem with that last request
Please push "back" on your browser or go back home

Error Overview
Core Version:	7.2.3
Machine:	DevServer
Instance:	cfusion
Message:	Complex object types cannot be converted to simple values.
Browser:	Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36
DateTime:	{ts '2016-01-22 11:23:19'}
Host:	*******************
HTTPReferer:	https://***************/webtop/index.cfm?id=admin.general.settings.listfarconfig
QueryString:	objectid=CDD2A356-EAC8-2242-EB48790985762230&typename=farConfig&method=edit&ref=dialogiframe&iframe=1&dialogID=fcModal
RemoteAddress:	10.0.1.2
Bot:	not a bot
Error Details
Exception Type:	Expression
Detail:	The expression has requested a variable or an intermediate expression result as a simple value. However, the result cannot be converted to a simple value. Simple values are strings, numbers, boolean values, and date/time values. Queries, arrays, and COM objects are examples of complex values.
The most likely cause of the error is that you tried to use a complex value as a simple one. For example, you tried to use a query variable in a cfif tag.

Tag Context:	
D:\Web\Farcry\projects\linnbenton\packages\formtools\list.cfc (line: 25)
D:\Web\Farcry\Core\tags\formtools\object.cfm (line: 511)
D:\Web\Farcry\Core\tags\formtools\object.cfm (line: 500)
D:\Web\Farcry\Core\tags\formtools\object.cfm (line: 495)
D:\Web\Farcry\Core\tags\formtools\object.cfm (line: 341)
D:\Web\Farcry\Core\tags\formtools\object.cfm (line: 42)
D:\Web\Farcry\Core\tags\formtools\object.cfm (line: 1)
D:\Web\Farcry\Core\packages\types\farConfig.cfc (line: 123)
D:\Web\Farcry\Core\tags\formtools\object.cfm (line: 511)
D:\Web\Farcry\Core\tags\formtools\object.cfm (line: 500)
D:\Web\Farcry\Core\tags\formtools\object.cfm (line: 495)
D:\Web\Farcry\Core\tags\formtools\object.cfm (line: 341)
D:\Web\Farcry\Core\tags\formtools\object.cfm (line: 42)
D:\Web\Farcry\Core\tags\formtools\object.cfm (line: 1)
D:\Web\Farcry\Core\packages\types\farConfig.cfc (line: 493)
D:\Web\Farcry\Core\webtop\conjuror\invocation.cfm (line: 182)

Iā€™ve restarted the entire web server as well as multiple tries at updating the application. I also went to the COAPI and chose under resolve conflicts ā€˜Apply Default Resolutionsā€™. No change. No joy.

If anyone needs more info I can supply it. We are running ColdFusion 9.0.2 on a Windows 2008R2 server with IIS 7.

Thanks,

Michael

I sent the below reply a few days ago by email but it didnā€™t appear for some reasonā€¦

From the stack trace it looks like the ā€œlistā€ formtool has been overridden in your project:

D:\Web\Farcry\projects\linnbenton\packages\formtools\list.cfc (line: 25)

You will need to look at that line to debug the issue, the error message says:

Complex object types cannot be converted to simple values.

Hope that helps :slightly_smiling:

@dowlesm it might be worth publishing the entire list.cfc component here, so that we can see why this has been overriden. There might be something we can do to patch that code, or bring the change back into core.

A quick way to validate the rest of the upgrade would be to rename the file to list.cf_ so it doesnā€™t get picked up in the app initialisation.

Hi Justin and Modius,

I renamed the list.cfc file as you suggested to list.cf_ and after a site application reload the 500 errors went away for the configuration pages that were showing errors. Here is the list.cfc that was causing the problem.

<cfproperty name="ftShowIcon" required="false" default="false" options="true,false" hint="for radio and checkbox only, toggle on/off to show icons" />

<cffunction name="edit" access="public" output="false" returntype="string" hint="his will return a string of formatted HTML text to enable the user to edit the data">
	<cfargument name="typename" required="true" type="string" hint="The name of the type that this field is part of.">
	<cfargument name="stObject" required="true" type="struct" hint="The object of the record that this field is part of.">
	<cfargument name="stMetadata" required="true" type="struct" hint="This is the metadata that is either setup as part of the type.cfc or overridden when calling ft:object by using the stMetadata argument.">
	<cfargument name="fieldname" required="true" type="string" hint="This is the name that will be used for the form field. It includes the prefix that will be used by ft:processform.">

	<cfset var html = "" />
	<cfset var optionValue = "" />
	<cfset var rListData = "" />
	<cfset var i = "" />
	<cfset var oList = "" />
	<cfset var lData = "" />


	<cfset lData = getListData(	objectid="#arguments.stobject.objectid#", 
								typename="#arguments.typename#",
								property="#arguments.stMetadata.name#",
								stPropMetadata="#arguments.stMetadata#") /> 
	
	<cfif listLen(lData)>
		<cfswitch expression="#arguments.stMetadata.ftRenderType#">
			
			<cfcase value="dropdown">								
				<cfsavecontent variable="html">
				
					<cfoutput><select id="#arguments.fieldname#" name="#arguments.fieldname#" class="selectInput #arguments.stMetadata.ftClass#" style="#arguments.stMetadata.ftStyle#"<cfif arguments.stMetadata.ftSelectMultiple> multiple="multiple"</cfif>></cfoutput>
					<cfloop list="#lData#" index="i">
						<cfif Left(i, 1) EQ ":">
							<cfset optionValue = "" /><!--- This means that the developer wants the value to be an empty string --->
						<cfelse>
							<cfset optionValue = ListFirst(i,":") />
						</cfif>
						<cfoutput><option value="#optionValue#"<cfif listFindNoCase(arguments.stMetadata.value, optionValue) or arguments.stMetadata.value eq optionValue> selected="selected"</cfif>>#ListLast(i , ":")#</option></cfoutput>
					</cfloop>
					<cfoutput></select><input type="hidden" name="#arguments.fieldname#" value=""></cfoutput>
					
				</cfsavecontent>					
			</cfcase>
			
			<cfcase value="checkbox">
				<cfsavecontent variable="html">
					
					<cfoutput>
					<div class="multiField">	
						<cfset tmpCount=0>
						<cfloop list="#lData#" index="i">
							<cfset tmpCount=tmpCount + 1>
							<cfif Left(i, 1) EQ ":">
								<cfset optionValue = "" /><!--- This means that the developer wants the value to be an empty string --->
							<cfelse>
								<cfset optionValue = ListFirst(i,":") />
							</cfif>
							<label>
								<input type="checkbox" name="#arguments.fieldname#" class="checkboxInput #IIF(listLen(lData) eq tmpCount ,DE(" #arguments.stMetadata.ftClass#"),DE(""))#" id="#arguments.fieldname#" value="#optionValue#"<cfif listFindNoCase(arguments.stMetadata.value, optionValue)> checked="checked"</cfif> />										
								<!--- <label class="fieldsectionlabel" class="fieldsectionlabel" for="#arguments.fieldname#">#ListLast(i , ":")#</label> --->
								<!--- MPS: styles aren't working so we are removing label for now until we have time to look at the css --->
								#ListLast(i , ":")#
								<cfif arguments.stMetadata.ftMultipleLines><br class="fieldsectionbreak" /></cfif> 
							</label />
						</cfloop>
						<input type="hidden" name="#arguments.fieldname#" value="">	
					</div>																		
					</cfoutput>
								
				</cfsavecontent>
			</cfcase>
			
			<cfcase value="radio">
				<cfsavecontent variable="html">
					<cfif arguments.stMetadata.ftShowicon>
						<cfoutput>
							<link rel="stylesheet" type="text/css" href="/css/font-awesome.css">
							<div class="multiField">	
								<cfset tmpCount=0>
								<table>
									<cfloop list="#lData#" index="i">
										<cfif not tmpCount mod 7>
											<tr>
										</cfif>
											<td style="width:105px;">
												<cfset tmpCount=tmpCount + 1>
												<cfif Left(i, 1) EQ ":">
													<cfset optionValue = "" /><!--- This means that the developer wants the value to be an empty string --->
												<cfelse>
													<cfset optionValue = ListFirst(i,":") />
												</cfif>
												<label>
													<input style="float:left;margin:3px 8px 0px 0px;" type="radio" name="#arguments.fieldname#" id="#arguments.fieldname#"  class="required #IIF(listLen(lData) eq tmpCount,DE(" #arguments.stMetadata.ftClass#"),DE(""))#" value="#optionValue#"<cfif listFindNoCase(arguments.stMetadata.value, optionValue)> checked="checked"</cfif> />
													<!--- <label class="fieldsectionlabel" class="fieldsectionlabel" for="#arguments.fieldname#">#ListLast(i , ":")#</label> --->
													<!--- MPS: styles aren't working so we are removing label for now until we have time to look at the css --->
													<div style="font-size:20px;">#ListLast(i , ":")#</div>
													<cfif arguments.stMetadata.ftMultipleLines><br class="fieldsectionbreak" /></cfif> 
												</label>
											</td>
										<cfif not tmpCount mod 7></tr></cfif>
									</cfloop>
								</table>
								<input type="hidden" name="#arguments.fieldname#" value="">
							
							</div>
						</cfoutput>				
					<cfelse>
						<cfoutput>
							<div class="multiField">	
								<cfset tmpCount=0>
								<cfloop list="#lData#" index="i">
									<cfset tmpCount=tmpCount + 1>
									<cfif Left(i, 1) EQ ":">
										<cfset optionValue = "" /><!--- This means that the developer wants the value to be an empty string --->
									<cfelse>
										<cfset optionValue = ListFirst(i,":") />
									</cfif>
									<label>
										<input  type="radio" name="#arguments.fieldname#" id="#arguments.fieldname#"  class="required #IIF(listLen(lData) eq tmpCount,DE(" #arguments.stMetadata.ftClass#"),DE(""))#" value="#optionValue#"<cfif listFindNoCase(arguments.stMetadata.value, optionValue)> checked="checked"</cfif> />
										<!--- <label class="fieldsectionlabel" class="fieldsectionlabel" for="#arguments.fieldname#">#ListLast(i , ":")#</label> --->
										<!--- MPS: styles aren't working so we are removing label for now until we have time to look at the css --->
										#ListLast(i , ":")#
										<cfif arguments.stMetadata.ftMultipleLines><br class="fieldsectionbreak" /></cfif> 
									</label>
								</cfloop>
								<input type="hidden" name="#arguments.fieldname#" value="">
							
							</div>
						</cfoutput>
					</cfif>		
				</cfsavecontent>
			</cfcase>
			
			<cfdefaultcase></cfdefaultcase>
				
		</cfswitch>
	</cfif>


	<cfreturn html />

</cffunction>

It looks like the list formtoolā€™s getListData method signature was changed recently in 7.2 to return a query and not a string (list):

This means that the lData variable is now a query rather than a string, so the function you pasted above would need to be changed a little to work with and loop over the query rather than treating it as a string and using list methods ā€“ i.e. anywhere the lData variable is used the function would need to be changed.

The query result has 2 columns in it, name and value.

Ok. So this is a Farcry Core file right? I am a server admin and when you say I would have to modify the lData variable Iā€™m thinking ā€œNo. This was something that was changed by the Farcry Developers so Iā€™m not messing with anythingā€ Is this list.cfc file necessary to the functioning of the underlying web site? If the file is required what do my developers need to do to make it work again?

Iā€™m just looking at making sure I can update the production site and not run into a problem down the line.

Itā€™s not immediately apparent why the developers have chosen to override this formtool; the list component is pretty generic.

The following comments by MPS suggest that the formtool was extended to correct some visual issues:

<!--- <label class="fieldsectionlabel" class="fieldsectionlabel" for="#arguments.fieldname#">#ListLast(i , ":")#</label> --->
<!--- MPS: styles aren't working so we are removing label for now until we have time to look at the css --->

Iā€™d be inclined to remove list.cfc from the project and to fall back to the framework; then hunt for some forms on the front-end of the website that might be using a select list that has some funky formatting.

If Iā€™m right about this being a visual CSS issue, then this should really be addressed with CSS changes rather than a component change. And styling issues are normally very easy to correct.

Itā€™s a project file that is trying to customise a Core feature, so itā€™s something that was custom written for the project. As modius suggested, you could try removing the file, otherwise itā€™s a relatively simple change for a developer to make to get it working again. For now you could use 7.1.4 rather than upgrade to the 7.2.x release.

Thank you all for the replies. Iā€™ll talk with the developer and see if they can identify what needs to change.

Hello, Web Developer that works with @dowlesm here.

We are finally preparing to jump on an upgrade that this bug was getting in the way of.

We have a few questions before we go forward with this, mostly as a sanity check and second opinion. My understanding is that an updated version of getListData() found in ./core/packages/formtools/list.cfc was giving a query while code in our own ./projects/#ourproject#/packages/formtools/list.cfc was expecting a string list. We had two options already proposed in previous conversation here that I was going to consider.

Instead of doing these fixes though I first tried pasting the old getListData() into our own list.cfc just above where it is called, so this one gets referenced instead.

Where my questions come up is if there is any way this wonā€™t solve our problem, even if itā€™s just a bandaid. Second, if there are any other gotchas, or problems this solution could cause. And third, would there be any useful functionality that we may be missing here by referencing the outdated method instead of the new one.

I will share that in my opinion we should eventually execute a proper fix, so Iā€™m primarily interested in knowing any reasons this wonā€™t hold up until such a time. If code is needed for more context Iā€™ll be happy to share it upon request.

My guess is that the fix is to remove the customised list.cfc from the project and everything should work fine.

If the list.cfc has additional customisations that arenā€™t mentioned in this thread above and you need to retain them for some reason, then the correct path would be to correct the offending getListData function to return the query, just as the 7.2 version of Core does. It should be about 10-15 minutes work to do.

1 Like