I'd been wanting to dump WordPress for awhile. I'm extremely neutral on WordPress in general, but two things drove me nuts:

1) It took me way to long to make simple changes to themes or plugins. Probably my own fault, since I don't really know the WordPress API. But I hated dealing with any of the related code.

2) I had to choose between slow or crashy. I'm on the smallest SliceHost VM - which is generally fine for the dozen other sites that share it. But the two WordPress blogs felt so much slower. I tried the Super Cache plugin, which would bring down all the php-cgi processes randomly when running in "full" mode. Mostly this happened when I was composing a new post (something w/ the auto-save), but other times just randomly in the middle of the night. I was doing all that retarded shit to work around it, like running scripts in cron to check if the site was up and then restarting if need. I hate that.  I spent three hours rocking back and forth in the shower the day I turned that cron on.

What's Croogo?

Croogo is CakePHP CMS built by Fahad Ibnay Heylaal (@fahad19).  It is currently at version 1.2 (although I'm running trunk with no problems).  The full feature list is available on the wiki and their are a bunch of screenshots on Flickr. 

Why Croogo?

Because it's CakePHP based and it was released when I was at my most frustrated with WordPress. I'm really that easy.  I wanted something Cake based so it would be easy to tweak. Plus it uses Cake's theme, which I already know, so I was able to convert the old WordPress theme (with a few updates) in about 5 minutes. Also this allows me to eventually take all the (neglected) code running on sandbox.pseudocoder.com and move it here. I had been running the subdomain to keep Cake and WordPress separate.

How To Do It

It's actually not that hard...since I did all the work for you :)

1) Install Croogo following the instructions.

2) Head over to GitHub and grab the Bye WordPress plugin.  Follow the instructions.  I moved about 200 posts and 1000 comments for this site.  If you ever left a comment here please check to make sure it made it successfully.  Thanks.

3) Create a theme (or use the default one or the one theme that's been released)

There's Always a Catch

Ok, so it isn't quite that easy. Here's some things to watch out for.

1) Database character encoding.  I had some weird issues with angled quotes and em dash's. I never really sorted them out - I just fixed in the final database manually.

2) Manually copy uploads. The Bye WordPress plugin will move the DB records for the attachments, but not the actual attachments themselves. Just copy everything in /wp-content/uploads to /app/webroot/uploads. Croogo doesn't support sub directories in uploads the moment, but it works fine with the sub directory structure that you'll be taking from your WordPress install.

Note: WordPress references images by their full url including domain in your posts, so if you're doing the migration on a beta site (as you should) you'll still see broken images until you actually switch the domain over.

3) Spam protection. Croogo comes with Akismet support built in, but it isn't enough to set your API key (Admin -> Settings -> Service). You also need to turn it on for blog posts (Content -> Content types -> Blog -> Comments).

URLs

You'll probably want to maintain your old URLs. Thanks to Cake's routing this isn't hard. Here's a couple I used:

/archives/this-is-a-post-title

CroogoRouter::connect('/archives/:slug', array('controller' => 'nodes', 'action' => 'view', 'type' => 'blog'));

/2010/01/this-is-a-post-title

CroogoRouter::connect('/:year/:month/:slug', array('controller' => 'nodes', 'action' => 'view', 'type' => 'blog'), array('year' => '[12][0-9]{3}', 'month' => '0[1-9]|1[012]'));

/2010/01/11/this-is-a-post-title

CroogoRouter::connect('/archives/:year/:month/:day/:slug', array('controller' => 'nodes', 'action' => 'view', 'type' => 'blog'), array('year' => '[12][0-9]{3}', 'month' => '0[1-9]|1[012]', 'day' => '0[1-9]|[12][0-9]|3[01]'));

/page-title

CroogoRouter::connect('/:slug', array('controller' => 'nodes', 'action' => 'view', 'type' => 'page'), array('slug' => '[\w\n\-]+'));

Note: It's important where in /app/config/routes.php you put these lines. If a URL maps to multiple routes it will use the first one in the file. So put these all at the top or at least the top of the section they apply to.

More Note: routes.php is included in the Croogo package, so if you do an update you could lose these changes.

Make It Fast

I updated my HTML Cache plugin so that it's Croogo compatible.  It generates static HTML files for pages, which are super fast to load.  Go ahead - refresh this page.  Bam!  Done!  The idea is basically the same as the SuperCache plugin for WordPress...except it doesn't crash the server.  I'll be adding that feature in a future version.

Mini Review

All thumbs up so far.  And since I decided to replace all the fingers on one hand with thumbs (thumbs are awesome!) that's like 6 thumbs up.  The docs are bit sparse, but if you're familar with Cake you should be able to dig in the code to figure stuff out.  Likewise the admin isn't as slick as WordPress', but it's certainly functional.  All the basic functionality you'd want for a blog is there - maybe missing some polish, but certainly working.

Wrap

I'd definitely recommend making the switch if you're frustrated with WordPress and would rather deal with a Cake based platform.  Plus it will give you something to blog about if it's been over a month since your last post.

If you missed part 1 you can check it out here.

From what I've seen the relationship between the maintainers of the top JavaScript frameworks is pretty friendly. How would characterize the relationship between the top PHP frameworks?

While there's been a fair bit of professional rivalry between different frameworks at different times, for the most part I'd say it's all in good fun. I've been fortunate enough to have met lead developers / prominent representatives from all the major PHP frameworks. They're all really great guys and I get along with all of them quite well, especially Paul M. Jones (of SolarPHP) and Matthew Weier O'Phinney (of Zend Framework). They're both very insightful, and I've never had an uninteresting conversation with either of them.

If you weren't the lead dev of CakePHP and Cake didn't exist what other framework would you be using (any language)?

Since we're going with any language, I'd have to say Node.js, which is (wait for it...) a JavaScript framework. I've always loved JavaScript, and it's probably the only language that would tempt me away from PHP for server-side development.

Do you get to code Cake apps at your day job? Are you able to work on the Cake core during the day or do you do everything off hours.

Well, my current job is with a startup, Hoopla Software, and I'm developing an app on Cake 1.3 that talks to SalesForce. I even wrote a database driver that speaks SalesForce SQL, which we plan on releasing later on. At my previous job with OmniTI, I'd say about 50% of my projects were in Cake. In both cases, work on the core itself usually happens in conjunction with something specifically work-related, with the occasional quick bugfix during the day. Both my current and previous employer are very supportive of Open Source, so I've been fortunate in that regard.

Favorite coding beverage during the day? for after hours?

I'd have to go with Coke for both. I was recently introduced to a drink called Club-Mate in Germany, but that stuff is dangerously powerful.

Favorite music to code to?

Well, I don't really have a favorite, and my musical tastes are pretty varied, so this list could go on for a while. Some of the highlights: The Who, Switchfoot, G. Love, The Police, Weezer, Bowie, The Beatles, Simon & Garfunkel, Guster, Jet, Sinatra, Death Cab, Café Tacuba, Cheap Trick, Cake (!), U2, Peter Gabriel, Relient K, The Proclaimers, The Caesars, The Specials, The Cure, Citizen Cope, Sanctus Real, Bob Marley, Elvis Costello, more Switchfoot, and Garrett's favorite: Oasis.

What apps have you built using the CakePHP framework?

Besides the one I'm working on right now, most of what I've worked on I'm not technically supposed to discuss, particularly not in print (see! if you were at CakeFest, you'd have heard the stories). In very general terms, I've written a tool related to security testing, a very big and high-profile tracking tool for a company that everybody's heard of, a bunch of smaller sites and tools around a database and suite of analytics tools for helping political campaigns analyze several terabytes of voter data, a portal for a football magazine, a couple of smaller, more personal CMS-y type stuff, mainly for the heck of it, a very JavaScript-heavy calendar app with iCal syncing, and a couple dozen smaller for-fun side-projects, most of which will probably never see the light of day.

Aside from those projects, on which I've been the principal developer (or one of), I've had my hands in or on several other CakePHP projects (and non-Cake / non-PHP projects), public, private and Open Source.

The End

Thanks to Nate for being so open and giving some awesome answers. I will now freeze myself, Cartman stlye, rather then endure the wait for Cake3. Someone please remember to dig me out when it's released.

Intro

Yeah, yeah, I know. This has been done before. What can I say - I had questions, Nate had answers. This is part one and covers general Cake and Cake3 questions. Look for part two tomorrow, which has a bunch of random questions.

General Cake Questions

The end game looks like there will be three CakePHP versions, which can be confusing to new developers. I haven't seen this explicitly defined, so stop me if I'm wrong:
The 1.3 branch is for anyone developing for PHP4
The v2 branch is for anyone developing new projects for PHP5-5.2 OR for PHP 5.3 users looking for an easier upgrade for a 1.2 app.
The v3 branch is for 5.3 apps.

That's about right. Once the 1.3 branch goes stable, that'll close off principle development on the 1.x branch, barring bug and security fixes and so forth. We haven't completely ruled out the possibility of back-porting future 2.x features, but that will largely depend on demand, which at this point we don't expect; and yes, 2.0 should be a direct upgrade from 1.3 (which has very few API changes from 1.2). 3.0, on the other hand, is still under pretty heavy development, so it isn't recommended for anything other than experimental applications just yet.

How many people are actively contributing to the three new versions of Cake. Whats the breakdown in terms of # of developers working on each branch or does everyone work a bit on each branch?

Well, in total I think we have something like 16 active team members working on various different things, including things other than the code itself. 1.3 has had about a half-dozen active developers, with the bulk of the work being done by the Canuckistani dream team: Mark Story and Joël Perras. In order to manage the extra work, Larry has brought in a few developers from the Cake Development Corporation to help out on the 2.x branch, particularly Graham Weldon (a.k.a. Predominant) who's been doing a lot of the heavy lifting to get the current code base fully strict-mode compatible.

Finally, I'm leading development on the 3.0 branch, with Joël, Garrett, David Persson, and Tim & Felix (of Debuggable) contributing.

Cake3 Questions

Right now 1.3 and 2 are still licensed as MIT. Cake3 is BSD licensed (although some files are still MIT (stuff in app) and the license.txt file doesn't specify any particular license). Whats the deal with the change? How will this affect developers?

Practically speaking, this won't affect developers at all. In terms of what you can do with the software, the BSD license is just as permissive if not more so than MIT. The change was mainly due to my own personal preference: the BSD is an older license with a more distinguished Open Source history. Garrett was also very supportive of the change, as the BSD license includes a specific clause that shields the CakePHP brand and the CSF from being abused for commercial purposes, which we've always been very much against. We're really excited to see people building businesses off of the code we write, but people using our name to promote themselves is just not in the spirit of what we're trying to do.

As for the places where the MIT license still appears, that's just some cleaning up we have left to do from the old CakePHP distribution. It'll be all BSD all the time before a release goes out.

Cake3 is switching to returning objects for result sets instead of array. I'm probably remembering wrong, but I thought you preferred the array approach. Was this change something need to be convinced about or was it something planned all along.

Well, that's close. My position was always that I preferred the array approach in context. Since the context at the time was PHP4, and PHP4 had all the array-hacking functions you could ever hope for and a crippled object model, it was the natural choice. Now that we've progressed beyond that, there's just no need to stick with arrays anymore, which I'm all for, as it frees us from a lot of the restrictions we had on how we design things.

Was there anything that came from the google group "hate" thread that you hadn't planned to implement or prefer a different approach, but were swayed by the community?

Probably my biggest reversal of position (and this is in general, not only regarding the 'hate' thread) has been regarding multi-column key support. The thing about single-column keys is that they make things consistent and easy all the way up and down the stack (REST APIs, etc.), and that's great. But what I realize is that there are often (again, in context) some good arguments for using multi-column keys, and even if we don't support them at higher levels, this is something that any well-designed data abstraction layer should support.

Say I'm a pretty good developer, whose willing to dig through code, submit patches for bugs and I'm starting a project that won't be launched for at least a year. Would I be crazy to start that project in Cake3 right now?

Well, it depends on the app. For most things, I'd say it'd be a pretty big commitment, since right now a lot of basic things like pagination and session handling are still missing. A lot of that doesn't matter though, since with Cake's new structure, you can load in other classes and libraries fairly easily, eventually including things like using Doctrine in place of the default ORM. Also, a lot of the API should be pretty familiar to you if you're already a Cake developer, and much of that is unlikely to change.

If anyone has a really experimental app in the works and would like to contribute to the 3.0 branch, I'd be interesting in talking with them about contributing. The biggest thing that this new version has going for it is that the plugin architecture is already pretty well-developed, and plugins are handled in almost exactly the same way as an app, and even the core itself, so everything is very interchangeable. Another major architectural difference is that most class dependencies in the core can be swapped out for classes in a plugin or in your app.

What we're hoping to achieve with this is that once the core becomes more stabilized, all the interesting development can happen in plugins. This is really important, because the barrier to entry on contributing to a smaller project with a more constrained feature set is much lower. Development can happen in parallel, and features can be moved in and out of the core distribution with relatively little impact on application code.

What's going on with unit testing in Cake3? It looks like SimpleTest is being dropped and instead Cake3 will have it's own unit test tools.

Again, this is one of those decisions which was made for us previously, as SimpleTest was the only viable option for PHP4, short of writing our own test suite, which we've decided to bite the bullet on this time around. Several factors went into that decision, but mainly (a) that we wanted people to be able to run tests right out of the box, and (b) we wanted a testing infrastructure that was tailored to our needs and allowed us to measure things in a way that we wanted; things that would help people judge the quality of software distributions. Not just Cake itself, but plugins and applications. I'll be talking more about this later on.

However, we plan to keep our test suite fairly lightweight, and one thing that'll be revisited before a release is the API; specifically bringing it more in-line with PHPUnit, to streamline the upgrade process for those with more heavy-duty testing needs.

The filter system looks pretty sweet and has been talked about a bit. What Cake3 feature are you most excited about that hasn't received much attention?

At this point, I guess the biggest thing that I haven't talked very much about yet is the Media class. The Media class is interesting because it takes out a lot of the work that was previously required when serving or handling different content types. It sits between the controller and view layers, and allows you to attach different handlers for each content type, both input and output. This means that instead of having to create a view every time you want a controller method to render as JSON, you can just attach one handler, once, that tells all JSON responses to automatically assemble themselves from the variables you set in the controller. For HTML on the other hand, a view class is attached (by default) that works as normal, rendering templates from your views/ directory as normal; but even with in that there's an incredible amount of flexibility, and you now have one place to configure it, application-wide.

I'm still a little confused about how filters work. You tie a filter to a method, but don't have to specify if it's a "before" or "after" filter, right? If you want it to act as "before" you just run your code before calling return $chain->next(...). How would you do an after filter? Like this?

$ret = $chain->next($self, $params, $chain);
//my code
return $ret;

Yup, that's exactly right. You can think of writing a filter a lot like you'd think of overriding a method in a subclass, but instead of calling the parent method (i.e. $result = parent::methodName()), you're calling $chain->next(...). This has a lot of notable advantages over simple before and after filter methods, probably the biggest being that all related operations are kept together in the same scope. Not having to split things up between two methods means you don't have to worry about persisting things through parameters or object state (or worse, global state). Everything is neatly atomic and isolated. It also makes a lot more sense when you're browsing through code.

To Be Continued...

More from Nate tomorrow when we cover what music he codes to and much more. I bet you just can't wait for that.

Today I wrote a CakePHP plugin for localizing JavaScript files. Basically it allows you to use the translate convenience function, __(), in your JavaScript files and will cache the results so that the static file can be used on all subsequent requests. Way back I wrote an asset plugin that combines and compacts JS and CSS files automatically. I thought it would be cool if I could get the two plugins to work together, so that if they were both installed a localized, combined, and compacted JS file would be returned to the user.

Here's The Trick

In the asset plugin I needed to know if the localization plugin was also installed and if it was use it. Cake's App::import() function returns "boolean true if Class is already in memory or if file is found and loaded, false if not." Perfect. I moved the majority of the localization plugin code to a model, JsLang. Then I can simply do:

$this->Lang = false;
if (App::import('Model', 'Js.JsLang')) {
  //plugin is installed.
  $this->Lang = ClassRegistry::init('Js.JsLang');
}

From there I can simply check if $this->Lang is not false and then use it for added functionality.

Beta Warning

It's pretty late and I'm programming on fumes, so assume that something is messed up somewhere. Both plugins have pretty good test coverage, but that doesn't mean I didn't fuck something up somewhere.

Plugins: USE THEM

If you plan on releasing ANY CakePHP code, do it as a plugin. There isn't any reason not to. Even if it's the simplest of helpers, it's worth it just to be able to provide unit test coverage.

For those of you who just want the book

This is the download link ---> Super Awesome Advanced CakePHP Tips
Updated to V1.1, fixing a few small things.

For those that want a 1500 word blog post

I've been sitting on this thing for the last two weeks and figure it's about time I just let it out. Ahhhh....so much better. Now, about the book. What better way to introduce it then a fake interview? Off we go!

What exactly is this thing and why should I waste my precious bowl time reading it?
At the moment there is no lack of CakePHP books geared towards beginners. But, there really isn't much for anyone who has mastered the basics and wants to do more. This e-book is for you guys and gal (I'm sure there's at least one out there somewhere).

I suck at CakePHP. What's the best way to learn the basics so I can get up to speed and read your book?
Check out Chapter 2: "How to Learn CakePHP". It details two paths for learning the framework - a free one and a pay one. I'm interested in feedback here, since it's hard for me to remember what it's like learn the framework. I just remember being really frustrated at times and blacking out, only to awaken covered in blood and standing over a dead hobo. Not good times.

How much is this thing going to cost me?
Nothing. It's free.

No really.
Seriously. Free. You know how when you're watching an independent movie or playing an indy video game you cut it some extra slack and overlook a few minor flaws? Do that there too. Thanks.

When did you start working on this?
The original idea was hatched in December 2007. At the time I was planning on writing a series of Advanved CakePHP posts. After I had 12-15 or so I was going to roll them into an e-book. Naturally I fizzled out after 2 posts.

Fast Forward to Oct 08 and I'm sent a copy of CakePHP Application Development to review. I realized as I was reading it (and confirmed by one of the comments on that post) that there was a lack of upper level Cake books/documentation. I also realized that in the year since I'd given up on the advanced series I had a bunch of decent posts that, once I cleaned out all the cursing and porn references, would make a decent e-book.

It's kind of dick of you to spend all this time creating an e-book, but then hardly contribute to the Cookbook. Do you feel any remorse or are you so hell bent on personal glory that it has crushed all rational thought in your oddly shaped head?
I struggled with this - I really did. In my defense I would say most of the content of the book isn't really appropriate for the Cookbook. That still doesn't excuse why I haven't contributed more. Although the Cookbook is great there are gaps (though they're becoming harder to find). I don't know...maybe it's because I spend more time in the API or maybe I'm still bitter that tempdocs, which served me so well, was whacked without even given a chance to make a tearful deathbed speech.

What IDE did you use to create the book?
I actually went through two before settling on Open Office. I started with Google Docs, because I figured it would be cool to be able to write whenever/wherever I got inspired. By about 30 pages Google Docs started to really choke, plus the PDF generation was mediocre at best.

I moved the whole thing to Word and spent like a week re-doing all the styles. But Word just gave me other problems. Whole pages would disappear until I scrolled around a bit and then they'd randomly re-appear. Plus I tried a bunch of different PDF printers and they all sucked.

Finally, I moved to Open Office and wasted another week fixing the styles again. This time everything worked pretty well and the built in PDF generator actually did a decent job.

Is this what you've been busy with and why you haven't blogged as much and when you do blog the posts blow?
Yea, pretty much. I'm also obsessed with converting all my open source Cake code into plugins. I'm all over plugins like a meathead frat dude trying to impress his buddies as a way to cope with his feelings of inadequacy when he sees a slightly unattractive chick with self esteem issues whose had too much to drink.

What's with the Mark Story sections?
This one is going to take a bit. Way back in the pre-RC days of 1.2 if you used the console to bake model tests the resulting test cases would have to extend the model and set the database to use the test_suite. This approached sucked and there was a better way. If you used the ClassRegistry to get an instance of the model it would set the database automatically. When I was putting the book together I knew I wanted to include a section of fixing the model unit test.

I also had an inkling I wanted to do a proper view unit test section. It would have been a gaping goatse-esq hole if I had a section of M(odels) and V(iews) and not C(ontrollers). Before I could get my shit together and write it Mark's article came out. Fuck. It was good and I really hated the thought of re-writing the same thing.

So, I got the brilliant idea to get others to contribute sections. I emailed Mark and a bunch of other Cake devs to see if they were interested. Predictably, everyone was too busy raking in that phat CakePHP bank to contribute. Except for Mark who not only agreed to let me use that piece, but also his forthcoming (at the time), landmark, life altering, spiritually awakening piece on mock objects. *genuflect*

Why not charge $$$ for this thing?
Another long answer. Continuing the above section...sometime later I realized that Cake had actually fixed the core to generate better tests and my Model section was pretty much shot. But at this point I already had Mark on board, so to sell this thing I would either have to a)cut his part and lose like 1/3 of the book or b) negotiate some sort of split.

Realistically I knew this thing wasn't going to make a ton of loot. Certainly not enough add another wing to the PseudoCoder estate. Take a look at this post from John Resig. It's a little unclear how much he's made on that book, since he never reveals how much he received up front $7500. What is clear is that he isn't killing it. I mean, if the fricking creator of jQuery can't make a fuck ton of cash on a JavaScript book...really, what chance do the rest of us have? It's John Fucking Resign, writing about JavaFuckingScript! Shouldn't this be the #1 best seller of all time, crushing The Bible like an empty Miller High Life against it's forehead?

This book is so full of typos, grammar mistakes and bad code. Where should I send my bitchy emails?
Take your pick - all of these people took the time to proof read it and gave me immensely helpful feedback.
Paddy Foran (blog) - Paddy sent me about 100 pages of speling, grammer and typeos, which is amazing since the book is only 64 pages. I dare you to find a mistake that he missed and then harass him endlessly about it. I DARE YOU.

Shawn Poulson (blog, friendfeed, twitter) - Shawn helped fix my atrocious PERL regular expression skills as well as suggesting using the Heredoc syntax when including JavaScript in views.

Jonathan Langevin (site, cakephp forum) - Jonathan sent me a bunch of spelling errors, which I probably could have figured out on my own if I those damn squiggly red lines under the words weren't distracting me so much.

Heath and Sohaib - both challenged me on the "Getting the Logged In User from Anywhere" section.

Felix Geisendörfer (site) - Felix is a superstar and provided some great pointers.

I'm sure I'm missing someone. If you're that someone, know that as angry as you are for not being mentioned, I feel 1/8 as bad for missing you.

What as the most significant thing you learned while writing this?
I feel like a moron for not knowing this. Apparently the correct slang is friggin'. But for years I've been using "friggen" - which has a completely different meaning. It's no wonder that my friends would act strange when I'd ask "anyone want to hang at my place and play video games and other friggen stuff?" Then they'd show up five minutes later and always seem disappointed at 3AM when I said I was going to bed...like they were expecting more...

This brings up an important issue. Has there ever been cursing in a programming book before?
Not that I've ever seen, but I'd be interested in hearing about it. My goal is to have the first NSFW programming book. Set your dreams high, kids.

I have question/comment about the book. How should I contact you?
Send me an email. Hit me up on twitter. Leave a comment on this post.

What's next?
Not much for the book. I'll probably fix it up and add new sections from time to time. I've already received a few good suggestions. I have a couple good blog posts ready, including "How To Program While Shitfaced Drunk" and "Stop Fucking With Your JavaScript". They just need a few more drunken tangents and they'll be ready to go. Keep an eye out next week.