Bradezone

You know, I actually do have some blog posts that are aching to be released into the wild. Soon, my sweets, soon… Until then, nourish yourselves with a helping of Brade-approved bonus content, courtesy of Bradezone’s newest feature: Items of Intrigue. Naught more than a lode of links meticulously selected by yours truly, these nuggets will no doubt tide you over between my official musings, and are available atop each page of this website, where you may also subscribe to them with your feed reader of choice. Speaking of which, if you haven’t already subscribed to the main blog itself, it’s time to rectify.

What’s up, all you savvy web developers? Question: do you enjoy using Firebug to make coding and debugging a blissful experience? Does it indeed make you feel warm and fuzzy inside? Well, good for you, because things are about to change. Turns out “awesome” wasn’t a good enough standard for the Firebug devs, so they’ve set out to fix what wasn’t broken and completely change the activation model, completely disposing of domain whitelisting and blacklisting. Ummm, thanks? Anyhow, I decided to voice my thoughts on the matter via the official Google Group:

This new “activation model” is patently insane and just made my life 100 times more difficult. If someone were to create a fork of Firebug 1.3 that preserved domain whitelisting/blacklisting, I would pay $50 for it easily. johnjbarton [the resident firebug developer], since you seem oblivious to how the new version is problematic, let me spell out some common scenarios I have tried:

Previously I enabled firebug for localhost, since that’s where I do most of my testing and developing. Then I would browse from page to page (without the panel open) until the “script error” message came up on the status bar. Then I’d open the firebug panel and troubleshoot. I’d fix it then perhaps browse around a few more pages, with the panel still open. When I was happy I’d solved the problem, I minimized firebug (back in those halcyon days, I could click the “x” button or the little firebug icon to remove the panel—it didn’t matter). But firebug stayed active, so I would be alerted to script errors if they happened.

Fast forward to today. Seems firebug now remembers panel position PER PAGE, which is ludicrously stupid. So as I browse from one page to the next, the panel is randomly disappearing and reappearing. And of course I can no longer simply tell firebug to be active only for localhost. WOW, WHAT SOME GREAT NEW FEATURES, GUYS!

The new system is completely absurd, and I hope now you can begin to see why. When a tool as ubiquitous as firebug gets changed so drastically, the question is WHY? We all loved it before, so please stop butchering it. And again, I put out the call to some developer out there who would want to continue the awesomeness of firebug 1.3 and perhaps rename it. That person would be regarded as a hero at this point…

I received an immediate response that at least acknowledged the legitimacy of my point of view:

Work on Firebug 1.4 is complete. Your scenario description is a good one, I wish we had it back when we were working on this feature. I’d love for Firebug to be perfect for everyone, but in every change there will be some winners and losers I guess.

The activation model in 1.4 was designed to allow extensions to provide special activation solutions.  If anyone wants to create one for this use case we’d be happy to give advice. (Just to set expectations, I have no plans to do any more work on activation myself).

As you can see, it seems this train is already moving at full speed, and those of us who loved the way Firebug formerly behaved will unfortunately have to endure (for the time being) the headache it has become. We can only hope a proper “extension” is released that brings back the wholly intuitive domain-based activation scheme that worked perfectly before. Until then, a single tear shall roll perpetually down my cheek.

We all know CakePHP is the bee’s knees for developing web applications, but what’s not so hot is Cake’s handling of error pages. Most developers discover soon enough that they can customize their error pages, most commonly the 404 “not found” page, by creating an appropriately named file, e.g. error404.ctp, within the views/errors folder. Easy peasy, right? Sure, but lurking in the bowels of Cake’s code is a significantly more obscure problem that manifests itself in various ways. Simply put, CakePHP fails to load components and does not run the beforeFilter() function of the AppController, deviating from its normal page-loading process. This can lead to utterly maddening behavior if you do anything important in beforeFilter(), which would be almost always.

An application I’m developing at work runs critical code in beforeFilter() that checks if a user is logged in and uses the results to set the website title and which links appear in the main menu. So you could say that’s fairly important. But on my error pages, Cake would conveniently display no title or main menu whatsoever. Because no debugging messages were displayed, I thought the issue might have been a minor case of a different layout file being used for error pages. But after a thorough combing of Cake’s library code, I discovered the ugly truth within the cake/libs/error.php file: the CakeErrorController class, which is used by the accompanying ErrorHandler class, never calls the beforeFilter() function. This contrasts with the Dispatcher class in cake/dispatcher.php that is responsible for most normal pages—this code eventually runs beforeFilter() within the controller’s _invoke() function, but before that it also calls the controller’s constructClasses() function, which turned out to be a critical part of my solution to this now unwieldy problem.

After attempting several ways of making the error pages run my beforeFilter() code, I found that simply adding $this->beforeFilter(); as the last line of the CakeErrorController constructor seemed to work. The problem with doing this, however, is that I had to change a core file within Cake. As my fellow developers know, this is not an option, so I had to make it work from within my own code. But luckily I was on the right track: the constructor inherits from the AppController constructor, which I was free to modify. So within my application’s app_controller.php file, I added a constructor and copied the code from CakeErrorController, making sure to add my call to beforeFilter() at the end. Amazingly it seemed to work, so I then proceeded to see which lines I could safely comment out, until I was left with just a few lines of code. The constructClasses() function in particular seems to be Cake’s succinct way of loading the components used by the application. After testing several normal pages and error pages alike, I feel fairly confident that I have solved my initial problem. Here’s the code I added to app_controller.php:

function __construct() {
    parent::__construct();
    if ($this->name == 'CakeError') {
        $this->constructClasses();
        $this->beforeFilter();
    }
}

Since I was forced to put the code in the main AppController class, some side effects may exist: beforeFilter() is potentially called twice on standard pages and perhaps earlier than normal. From what I can tell, this doesn’t affect the application’s performance or behavior. So hopefully this solution will help other CakePHP developers who want their error pages to behave as expected. But surely I am not alone in hoping that future versions of CakePHP will make this workaround unnecessary.

UPDATE: I tweaked the code to include an explicit check for CakeErrorController before running the extra lines of code in the constructor. I found a fail case that had to do with adding new users via the Auth component—new passwords were being hashed twice. So this new snippet should successfully eliminate the possibility of code running twice needlessly.