Fatal error: Class ” not found in path-to-cake\cake\libs\class_registry.php on line 140

Googling, clearing the CakePHP cache and several Apache restarts didn’t offer a solution. The problem turned out to be a stupid mistake in a model file that had a blank hasOne relationship setting:

var $hasOne = ”;

Fixing the half-completed model relationship fixed the issue (either remove the line or enter in the name of a model for the relationship).

Highlights

• Power strips were all over the place, under the seats, for laptop power. Thank you!
• It was neat getting to chat to members of the FogCreek team face to face
• The jQuery team does a great job of branding jQuery speakers; the slides were fantastic: expertly branded, logically ordered and compellingly supportive of the speaker
• Great keynote theme: “How does your software help me copy my DNA?”
• The between speaker interlude program was great (having a count down timer made it easy to spend the brief downtime efficiently and the twitter feed was compellingly interactive)
• The wifi actually worked
• Lunch was both accessible and yummy (a rarity for conference food)
• The discussion topic by area lunch was a great idea
• The opening [scrums] (sp?) video was funny
• All of the talks were great: jQuery, iPhone development, the problems of backwards compatibility in language design, ASP.NET MVC, Google App Engine and the keynote.

Low lights

• The front door staff actually asked for paper tickets; you can fly on a plane without a paper ticket
• The name badges didn’t have StackOverflow rep printed on them (nor did they have a space to write that in)
• Parking was a pain
• The seats in the venue (balcony at least)  had no leg room, even for your vertically challenged correspondent
• It would have been nice if Jeff Atwood was on hand
• Bruce Eckel’s presentation on the problems of backwards compatibility could have used additional visual support and a bit more dialog polish

This training outline worked really well:

• About
  • What Google Analytics tracks
  • So much data!
  • Logging in
• Core features
  • Understanding the layout
  • Using date ranges
  • Using the help icon
  • Using the export, email buttons
• Dashboard
• Main metrics
  • Visitors
  • Traffic sources
  • Content
• Key metrics
  • Top content
  • Top exit pages
  • Search keywords
  • Metrics for your site
• Advanced topics
  • Goals, not useful for them
  • Custom reports
• The Help section
• Questions

Tips for training:

1. Occasionally point out how the common page elements appear on various pages (email, export, date range, etc).
2. Occasionally point out how to add content to the dashboard, as you show metrics.
3. Show how easy it is to use the Google help site by searching for a term, and showing the glossary.
4. Just show and briefly explain the advanced topics are, don’t delve into them.
5. Spend two minutes thinking specifically about what the two metrics you would look at if you were responsible for the site, in order to be able to act on them.
6. This training takes about 45 minutes; expect 30 more minutes of questions.

And don’t forget to send an agenda to the team ahead of time:

1. About Google Analytics
2. Logging in
3. Core features
4. Dashboard
5. Main metrics
6. Key metrics
7. Advanced features
8. Questions & wrap-up

1. Edit your view
2. Add a display called “Feed”
3. Specify a path for the RSS, like /rss

Drupal should automatically add the RSS auto-discovery link to your site, but often this doesn’t happen. You can add this manually by editing the page.tpl.php file in your theme and following these directions.

If you want to customize the theme it gets a bit more tricky. You can add new files to your theme folder to customize the RSS feed:

1. Edit your view
2. Click on the feed display
3. Click on the “Theme Information” link

The first file lets you alter the RSS wrapper around your RSS content, and the second file lets you alter the style of each item in the feed. However, you don’t really have any additional information about your node, so you can’t add CCK fields or other information.

Nota bene: If you add either file be sure to click the “Rescan folder” icon, otherwise Drupal won’t see the file.

There is a great post over at TIMtheToon that has a great function you can add to your theme to add the full $node data to your RSS template file.

Nota bene: Don’t forget to reset the theme registry to Drupal detects changes to your theme file.

Adobe licensing error messages, including debug info.

Adobe makes some great software, but the licensing management experience for corporate licenses is an embarrassment.

Your correspondent purchased some additional corporate licenses for Adobe InCopy for two team members. In order to get the serial numbers for the software you need to log into the hapless Adobe Licensing site: http://licensing.adobe.com.

Unfortunately the licenses your correspondent purchased were associated to a new licensing.adobe.com login ID, but needed to be associated to the preexisting ID linked to  other Adobe software already purchased.

Your correspondent had two goals: obtain the license keys and merge this login ID to another login ID. Attempting this feat trivial task revealed a variety of problems:

1. There is no way to merge accounts in licensing.adobe.com.
2. It takes 6+ clicks to get from the contact us link on licensing.adobe.com to a support number (which isn’t the direct support line).
3. You must wait on hold and spend several minutes at the main support line until you are transferred to the licensing team, resulting in a lost queue position and additional hold time.
4. If you attempt to login with the wrong password several times your account is locked out and you must call into Adobe to get your account reactivated.
5. Your correspondent was transferred to a line that rang about 15 times and then soberly declared: “Your party is not answering. Your call will now be disconnected.”
6. Login error and alert messages appear in a tiny font and include actual debugging output.

There are a variety of lessons we can take-away from this:

1. Queue positions ought to be respected when transferred to different departments. If you wait for 10 minutes for the main team and then are transferred to another team queue you should be placed 10 minutes ahead of everyone else.
2. Unless you are creating the login routine for GetNukeLaunchCodes.gov, account lockouts should life after a set time automatically.
3. Licensing sites should include tools that actual help the busy IT professional, like an instant combine/merge accounts feature.
4. Search for and eliminate dead end phone paths. Phone menu systems, like software, need to fail well. In this case, that means routing a person back to a customer service rep (at the top of the queue) when transfers aren’t picked up properly.
5. Check the work of your programmers to ensure that debugging information isn’t revealed to the user on production systems. It’s unprofessional and possibly a security risk.

Here are four quick tips:

1. Your first/title slide should include the presentation title, your name, your title, your company and some kind of contact (this all lends credibility);
2. When showing an image on a slide make the image as large as the slide;
3. Limit to 2-3 words per slide; and,
4. Do not read slides, have a conversation (each slide should either remind you of key themes to touch on during the chatter for that slide or evoke a reaction — thought, laughter, emotion, etc — in the audience).

You can do all this with an .htaccess file.

The great power of .htaccess files is that they can include rewrite rules via Apache’s mod_rewrite module. There are loads of things rewrite rules can do, so we decided to create a standard file that would handle a few things:

1. Redirect all HTTPS/SSL traffic to the same URL but to HTTP;
2. Redirect all traffic without a “www” entered to the same URL but with a “www.” added; and,
3. Compress all HTML, CSS and JavaScript files (to speed up website browsing).

The goal is that requests to:

https://example.com/some/page

will be gracefully redirected to

http://www.example.com/some/page

A clean, standard URL with no risk of SSL confusion.

The .htaccess file

# Standard .htaccess file
# – Compress text documents for speed
# – Rewrite https to http and no www to www

<IfModule mod_rewrite.c>
RewriteEngine on
# move off of https
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301]

#move to www if no www is entered
RewriteCond %{HTTP_HOST} !^(www\.).*
RewriteRule (.*) http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

# compress stuff for faster delivery
AddOutputFilterByType DEFLATE text/css text/javascript application/x-javascript text/html
Header append Vary User-Agent

Sadly, must of these firewall configuration screens are painful to use.

Take the Linksys RV042, a reliable business-class router well suited for a small office. Managing the firewall can involve updates to three separate screens. Even the buttons on the edit rule screen (see right), are confusing: “Return”, “Save Settings” and “Cancel Changes”.

There are probably several reasons why this happens — limited budget, schedule, etc — but the likely explanation is that when the engineers schedule designing the new router they leave the admin interface as the last task, hate doing it and spend as little amount of time as possible on this “tail-end” work.

The ironic part of this logic is that it’s the admin interface where your customers spend 90% of their interaction time with the product. Sure, your customers appreciate (in the broadest sense) how quickly your little box moves tiny packets around, but they really don’t care so long as:

1. It doesn’t crash; and,
2. The admin interface isn’t too painful.

Given this, I’ve come up with a few really simple design guidelines for firewall interface designs.

Firewall configuration user experience design screen rules:

1. No pagination. Pagination of firewall rules is as pointless as pagination on online news stories: there is rarely enough content to justify it.
2. Poor or non-existent labeling. As soon as you write your 11th firewall rule you start to forget for what the first 10 rules are used. Firewall configuration should support both tracking a rule name and labels on individual IP ranges.
3. Allow multiple, user-entered IP ranges. Users should be able to enter in IPs in three formats: single IPs, human ranges (like 2.5.7.1-2.5.7.123) and in netmask form (for the nerds). And you must allow users to enter in a mix of all three.
4. Clear interface. This should be a no-brainer, but loads of configuration screens have glaring UI gaffes. Keep it simple and standard.
5. Combine stuff. Port forwarding, NAT, firewall, etc, can be combined into a single interface for most routers.

Mock-Up Screens

To demonstrate some of these ideas, your correspondent has created a set of HTML mock-up screens. Sure, this interface won’t work for a high-end Cisco router, but it should include the functionality you might expect from a home or small business router.

These are simple mock-ups; there are a few things missing like support for multiple ports and a way to move a rule several positions with one click. However, these screens hopefully demonstrate that firewall configuration screens can be made to be user friendly.

Your correspondent ran into a problem with a CakePHP site where the login and sign-up pages used an SSL connection, but the rest of the site forced non-SSL connections.

Why blend SSL and non-SSL? The application itself didn’t contain any sensitive information, and SSL is a massive CPU drain. So to save cycles, we forced non-SSL for all pages but login and sign up (passwords and credit cards).

The problem was that after the user was redirected from the SSL login process page to the logged-in homepage, the cookie that stored the session reference for the user didn’t exist in the non-SSL site and thus the session didn’t exist and the user was immediately logged out.

A post over at stackoverflow and some quick Googling strongly hinted that that PHP was configured on the server to create secure cookies, that is cookies that are only accessible over SSL. However, your correspondent tried disabled secure cookies with ini_set(), to no avail.

Further digging revealed the real issue: the cookies were being created as secure cookies on login — in spite of my override setting in the bootstrap file — because the core CakePHP routine for cookie creation sets the “create secure cookies” PHP setting on-the-fly just before creating the cookie, whenever a page is running under SSL.

The solution was a foreced modification to CakePHP core, something to be avoided at all costs but something that had to be done.

The solution is to comment out this snippet in /cake/lib/session.php, around line 420:

if ($ini_set && env(’HTTPS’)) {
ini_set(’session.cookie_secure’, 1);
}

CakePHP has a handy helper to redirect users to another page, used in controllers:

$this->redirect(’controller/action’)

Be careful: Apparently in CakePHP 1.1 and earlier this->redirect() doesn’t call exit() after the header redirect is set, so the PHP code after the redirect in your controller will get executed. Yikes! That’s a major security hole.

Happily, this issue is fixed in CakePHP 1.2, which defaults to calling exit after the redirect. Even so, the proper syntax for writing a CakePHP redirect is:

$this->redirect(’controller/action’,null,true);

The second parameter lets you specify an HTTP response code to return with the redirect command. The last parameter (which defaults to true), specifies whether to call exit() after the redirect. Even though it defaults to true, you really should write your redirects this way.