We're updating the issue view to help you get more done. 

Page not found errors for certain types


Got a weird one here.

We've been getting some periodic errors with pages on a new site we're building. We have a content type set to bUseInTree = true so it can be attached to a nav node.

Sometimes when viewing this page it will return a 404 error as if the page were in draft (it works fine when logged in). This content type does NOT extend versions.

I dug into core and found that in navajo/display.cfm around line 146 of the current p720 branch it checks for a valid status. The status key of the record in question (which should not even exist) was set to an empty string.

Digging further I found that in webtopTreeChildRows.cfm (a webskin of dmNavigation) I see there is code that sets status to an empty string if it is not already set (as well as sets bHasVersion, versionid keys). This is around line 283.

The problem is that in CF structs are passed by reference, so if this is the first time that getData has been called for a record then those keys in the struct actually added not only to the struct being used for that webskin but also the copy that is in the session's tempObjectStore and apparently gets as far as the object in the objectBroker. So all subsequent calls to getData that respect the cache get a copy of the object with a status key set to an empty string.

You can rereate this by restarting ColdFusion, the logging into the webtop, go to the site tab so that you can view the tree. If you have a content type in the tree that does not extend versions, then you will see a 404 error if you go to view that page in an other browser (not logged into FarCry). So if a call to webtopTreeChildRows is the FIRST time the record is called via getData then those keys end up in the cache.

Obviously this is a big issue if you use content types that don't extend versions in the tree.

Ways to fix this:

  • Create duplicates of the structs in webtopTreeChildRows and modify those instead of the referenced struct.

  • Or instead of setting status to an empty string, set it to approved. If it doesn't extend versions then it should be considered approved anyway. (This is the option I'd suggest)

  • Modify navajo/display.cfm to be aware that status might be an empty string and if it is, assume it is approved. (Might be a good idea anyway just in case there are other places in the code that might incorrectly set status to an empty string)

If you'd rather I submit a pull request to fix it, let me know.







Sean Coyne



Fix versions

Affects versions