I’m wanting to upgrade from 6.0.15 to 6.2.8 and running into problems with the site afterwards.
Because it was a point upgrade, I assume it was just a matter of replacing the core directory and running ?updateApp=[your-app-key]. Is this not correct?
The problem I’m running into is:
The TYPENAME argument passed to the getWebskins function is not of type string.
With the stack trace:
/vagrant/app/farcry/core/packages/coapi/coapiadmin.cfc (line: 320)
/vagrant/app/farcry/core/packages/fourq/fourq.cfc (line: 1252)
/vagrant/app/farcry/core/packages/farcry/alterType.cfc (line: 282)
/vagrant/app/farcry/core/packages/farcry/alterType.cfc (line: 398)
/vagrant/app/farcry/core/tags/farcry/_farcryApplicationInit.cfm (line: 109)
/vagrant/app/farcry/core/Application.cfc (line: 269)
/vagrant/app/farcry/core/Application.cfc (line: 196)
/vagrant/app/Application.cfc (line: 26)
I’m running ColdFusion 10 (all patched up) on Ubuntu 12.04.4 LTS (over vagrant).
Has anyone experienced any errors with this before? Am I doing something wrong? I’ve updated the app a number of times, and restarted CF a number of times too. I even double checked the upgrade of the files by doing it all again.
Thanks in advance.
Have you checked the COPAI Tools under ADMIN to see if there are any schema changes that need to be deployed?
Well I tried, but I receive that error message even when trying to access /farcry/… strange eh?
Hmm… you should be able to access the webtop. If you can’t reach the webtop then it sounds like something fishy
Any reason you are not upgrading to 6.3.x or even 7.0.x?
I didn’t realise 6.3.x was available actually. It’s not mentioned on the
FarCry downloads page.
As for 7.0.x, not ready for that step with this client just yet. Will get there soon, but simply wanted to unlock the tablet, mobile specific website functionality…
Hmm… I’ll have to dig deeper and work out what is going on.
Thanks for your help.
Aye, we have been a bit slack.
Github is the source of truth.
6.3.x is only suitable for those not wanting to upgrade to 7.0, but still wanting the sweet CDN magic for files, images, etc.
Seems like a strange error… For typename to not be a string when passed to getWebskins(), there must be something weird happening with the metadata that is returned for the component…
Can you find this line that calls coapiadmin getWebskins() and just before it log the value of the “componentname” variable to a log file?
<!--- Set up default attributes --->
<cfparam name="stReturnMetadata.bAutoSetLabel" default="true" />
<cfparam name="stReturnMetadata.bObjectBroker" default="false" />
<cfparam name="stReturnMetadata.lObjectBrokerWebskins" default="" />
<cfparam name="stReturnMetadata.objectBrokerWebskinCacheTimeout" default="1400" /> <!--- This a value in minutes (ie. 1 day) --->
<cfparam name="stReturnMetadata.excludeWebskins" default="" /> <!--- This enables projects to exclude webskins that may be contained in plugins. --->
<cfparam name="stReturnMetadata.fuAlias" default="#lcase(rereplace(stReturnMetadata.displayname,'[^\w]+','-','ALL'))#" /> <!--- This will store the alias of the typename that can be used by Friendly URLS --->
<!--- Get webkins: webskins for this type, then webskins for extends types --->
<cfset stReturnMetadata.qWebskins = application.coapi.coapiAdmin.getWebskins(typename="#componentname#", bForceRefresh="true", excludeWebskins="#stReturnMetadata.excludeWebskins#",packagepath=stReturnMetadata.packagepath,aExtends=stReturnMetadata.aExtends) />
<cfset stReturnMetadata.stWebskins = duplicate(request.fc.stWebskins[componentname]) />
<!--- Setup a location to store all the webskins that need to be watched for CRUD changes --->
<cfset stReturnMetadata.stTypeWatchWebskins = structNew() />
NEED TO LOOP THROUGH ALL THE WEBSKINS AND CHECK EACH ONE FOR WILDCARDS.
IF WILD CARDS EXIST, FIND ALL WEBSKINS THAT MATCH AND ADD THEM TO THE LIST
THIS WILL OVERRIDE ANY METADATA SPECIFIED IN THE ACTUAL WEBSKIN
Then you can check the log and see if there are any funky values in there (or see if it crashes with something else).
The component name simple comes from the last part of the component path in fourq getTypeName(), so if the above log file doesn’t turn anything up, you could try dumping the data returned by the call to getMetadata() in that method:
P.S. In general for upgrades within the same minor version (6.0.x to a newer 6.0.x tag) it should only require an updateapp, but upgrades to a newer minor version (from 6.0.x to 6.1.x/6.2.x) may require a COAPI deploy as well.
Thank you. I’ll give these a shot!
Okay, this is getting strange.
I went ahead and did this, and then received the following error message:
Complex object types cannot be converted to simple values.
It should have been a string, so I decided to convert it to wddx and then log that value. I received a bunch of normal results, such as:
But this very strange one too!
<wddxPacket version='1.0'><header/><data><recordset rowCount='9' fieldNames='value,name' type='coldfusion.sql.QueryTable'><field name='value'><string>fcbContact</string><string>dmEvent</string><string>dmFacts</string><string>dmFile</string><string>dmHTML</string><string>dmLink</string><string>dmNews</string><string>fcbProductCategory</string><string>fcbTestimonial</string></field><field name='name'><string>Contact</string><string>Events</string><string>Fact</string><string>File</string><string>HTML</string><string>Link</string><string>News</string><string>Product Category Page</string><string>Testimonial</string></field></recordset></data></wddxPacket>
I went further up the stack trace and output various things. One particular type CFC seemed to be coming up all the time. After investigating that, I found that someone had overridden getTypename and returned a query
Problem solved. Thanks for your help.
Ouch! Yeah it most definitely needs to return a string… Glad you found it