Hi. We’re running coldbox 4.3 on ACF 10 on Windows Server 2012. The site is currently a mixture of old legacy cf code and new Coldbox code. We’re using the fileeventmap method in our application.cfc file’s OnRequestStart function to tell CF which pages to handle “normally” vs the ones to be processed by Coldbox.
I received a debug email today (sent to me from BugReport-Public.cfm, we modified the code in there to capture errors to our db and also send them via email) and noticed something interesting that I’m hoping I can get some help with.
Obviously, the page I’m asking about has been converted from the legacy code (/twitter/tweet.cfm) to Coldbox code (event = tweet.index).
The debug email shows the exception object’s message to be: The event: tweet.index is not valid registered event.
In trying to figure out what is going wrong, I noticed that the Coldbox_App_Root_Path in the variables struct has a value of “c:\inetpub\wwwroot\twitter\” instead of what I would have expected (c:\inetpub\wwwroot).
The handler for the event is in /handlers/tweet.cfc and the view is in /views/tweet.cfm.
I think the problem is that there is an application.cfc file in the /twitter director and that the application object there inherits from the root application object which of course inherits from coldbox.
We need the tweet.index event to fire based on the base path, not this sub-directory (I believe). So, should I just add a line of code to the /twitter/application.cfc file’s OnRequestStart function which sets the Coldbox_App_Root_Path = “c:\inetpub\wwwroot\” or is there a more appropriate way to fix this issue.
You’re on the right path. You just need to set the app mapping and app root path in your Application.cfc. Don’t do full paths though, that’s brittle if you ever move your code. See how I did it here in this sample app:
The problem comes in when the application times out (or the server restarts) and the FIRST request to the site hits a page that “looks” like it’s in a subfolder. When the ColdBox bootstrap loads, it calculates the root path dynamically based on the folder it thinks the site is living in. Setting those application.cfc variables will make the Coldbox framework lock into the correct root path, even if the first request down the pipe looks like it’s in a sub folder.
BugReport-Public.cfm, we modified the code in there to capture errors to our db and also send them via email
The better way to do that is to configure an E-mail and DB appender in LogBox and dial it down to only fire error and fatal severities.
Hi. We’re running coldbox 4.3 on ACF 10 on Windows Server 2012. The site is currently a mixture of old legacy cf code and new Coldbox code. We’re using the fileeventmap method in our application.cfc file’s OnRequestStart function to tell CF which pages to handle “normally” vs the ones to be processed by Coldbox.
We’re working on converting a legacy page to Coldbox (/causetoolbox/html/logout.cfm). We’ve created a handler (/handlers/causetoolbox.cfc) which is setting the view at the bottom:
event.setView(view=‘causetoolbox/logout’, args = data );
The new view is /views/causetoolbox/logout.cfm.
I know that the handler (causetoolbox.cfc) is running (put a writeoutput and abort in there to verify) as is the view (logout.cfm).
However, what is displayed is just a blank page. If I turn on CF debug output I can see that the layout pages and view are being called. If I add a into the view, then the view is rendered (except for the layout footer). Without the , we get a blank page. This only seems to happen for pages we are trying to setup in subdirectories. Handlers/views in the base folders don’t have this issue.
Any help that you can give would be most appreciated.
Firstly, turn off the request execution debugging times. Adobe has some serious performance issues with their debugging templates that I don’t think they’ve fixed.
I only turned on the adobe debugging information to see the trace of files hit to make sure the handler and view were being called. It is normally off.
Enablecfoutputonly is NOT turned on. I thought I mentioned that all of our handlers & views in the base /handers & /views folders work fine. The problem only occurs when in a subdirectory like /handlers/causetoolbox & /views/causetoolbox.
I should have mentioned the following… If you navigate directly to the Coldbox URL (/index.cfm/causetoolbox/logout) the handler & view work properly, the view is displayed. But if you hit the OLD legacy URL (/causetoolbox/html/logout.cfm) only a blank page is displayed. Further, to verify the handler & view were running when the legacy url was hit, I tested by putting writeoutput & abort into the handler (output was displayed) and then did a second test with a inserted at the bottom of the view. For the latter, the view displayed (except for the layout footer). So, something is happening to stop the output from being displayed.
If I move the files out of the causetoolbox directory to the main /handlers & /views folders and adjust the name of the handler in my application.cfc and the name of the view in the handler it all works. The problem is the subdirectory.
Remember though, with the files in the subdirectories, that accessing the page directly via coldbox without the application.cfc routing it works: /index.cfm/causetoolbox/logout