My plan for a long time now has been to move away from Wordpress as my blog engine. Wordpress has been great for me, and it does a lot of things right (for one, it just works and you can be up and running with a blog very rapidly), but it can be a pig. Anyway, I figure that by putting it in writing I’ll start to find the time to get this process started. So, my only decision is what will be my engine. Here is a list of choices that I have considered over the past few months, as well as reasons why I am not going in their direction:

Expression Engine (EE)

I have never built an EE site.  Twice now I have installed 1.6, only to be turned off by the administrative experience.  It seems clunky to me and not very fluid.  With that said, I have heard great things about this software.  I also like what I’ve heard about the framework that powers EE (CodeIgnitor), and I’m especially exited about the looks of 2.0 (where the hell are you).  I’m choosing not to go with EE because in the coming months I will get my fix through work.  I believe there are at least 2 projects coming up where we will be using EE.

CakePHP

I have considered building my blog from the ground up with CakePHP.  I am working on 3 projects now that are powered by CakePHP.  Cake has made me a better developer by keeping me organized (thanks MVC), making me follow conventions (but allowing me to break those conventions where necessary), and providing a host of valuable classes for a variety of tasks.  A lot of which take the mundane out of developing.  Let’s face it, developing can be mundane and repetitive.  I am choosing not to go with Cake because I am getting my Cake Fix at work.

CodeIgnitor and Doctrine

I have considered building my blog from the ground up with CodeIgnitor and Doctrine.  I have virtually no experience with Doctrine, and even less with CI, but I’ve heard great things about both.  Doctrine seems like it rocks the house, and EllisLabs (the guys responsible for CI) seem like they really have their act together.  I am choosing not to go this route because if I am building an app from the ground up, chances are very high that I will be choosing CakePHP.  Until the day comes where someone shows me overwhelming evidence as to why I should be using a framework other than Cake (and yes, I’ve seen Rasums’ presentation on frameworks), than I’ll continue baking.

And the Winner Is Django

Just in case you didn’t get it from my title, I’ll be choosing to go the route of Django for my rebuild.  In the few hours I’ve taken to read Django documentation and play around I have been thoroughly impressed.  The template system is awesome, and the automatic admin generation has me all hot and bothered (though I’ll really get hot and bothered after I give the tires a really good kick).  I’ve wanted to dive into python for a few years now, and I’ve been curious about Django for over a year, so I figure it is a good choice for me.

Anyway, there you have it.  With grad school and everything else I have going on (we have a super secret, earth shattering, take over the world project in the making at work), I just hope I won’t be looking back at this post in 6 months thinking, “what a set of donkey balls I was for writing that.  I haven’t done shit in 6 months”.  If you think you can persuade me to try something other than Django, give it a try.

Ok, so I’m in the mood to write a little bit. I finished my grad school homework a little early, so I’d like to talk about CakePHP. Specifically, updating your user model session data when the user model is edited.  Here is the scenario:

• Your are using CakePHP’s wonderful Auth Component.
• After a successful login, you have auth model data available to you via $this->Auth->user(’key’);
• It just so happens that this model data is stored in a session, in a format something like the following:

Array
(
    [Auth] => Array
    (
        [Model] => Array
        (
            [id] => 1
            [first_name] => Jason
            [last_name] => Leveille
        )
    )
)

• You use this data
• When you update your user model, you want this data updated as well

If you’re anything like I am, you make use of this data to display information to your authenticated user. For example, in your controller you might set a firstName variable for use in a welcome message.

$firstName = $this->Auth->user('first_name');
$this->set(compact('firstName'));

It’s very likely that you have provided an edit action in your auth userModel controller. It’s also likely that you have provided the user with the ability to modify their first name. In our welcome message, we are pulling our first name data from a session. If we want this data to be accurate, than the change to our user first name in the action will also need will not be reflected in this auth session. The solution of course is to merge $this->data[’$this-Auth->userModel] with our Auth.Model session.

//update the auth userModel data
$authUpdated = Set::merge(
    $this->Session->read(
        sprintf('Auth.%s', $this->Auth->userModel)
    ),
    $this->data[$this->Auth->userModel]
);
$this->Session->write(
    sprintf('Auth.%s', $this->Auth->userModel),
    $authUpdated
);

Again, this code would be part of your user model edit action, and would be included after a successful save operation.

I recently finished my first CakePHP application.  Not only was the application the largest I have ever written, but I had never worked with CakePHP before.  So, needless to say, not only did I have to overcome a learning curve, but I had to deal with all that comes with writing a large application.  Today I was contacted by the project manager regarding a bug which had surfaced in the application.  In my quest to squash the bug I discovered a script which was causing a section of the administrator to act very sluggish.  In examining exactly what was going on, I realized that there were 200+ calls being made to the database.  Ok.  That’s bad.  I’d like to clarify that I was the one who wrote the original offending code.  In about 2 minutes of work I was able to bring the query count down to 2, and reduce the page response time considerably. (more…)

I’ve had my focus in a lot of other areas for a few weeks, and in that time is seems like quite a bit has happened on the CakePHP front. It seems that there has been a subtle shift in how the framework will evolve from here forward. gwoo puts it much better than I can in his recent bakery article, “After 3 years, looking back and moving ahead“. In the grand scheme of things there are much more interesting things between the lines of what gwoo has written, however the thing that got me most excited was located at the very end:

Stay tuned for more new developments and expect the next 1.2 release in the coming weeks.

I recently had the need to set up some permanent redirects for an application built on CakePHP. My first thought was to use a simple .htaccess Redirect at the top of my www .htaccess file, like such:

Redirect 301 /foo /bar

However, the result of the redirect was actually the following url:

http://foobar.com/bar?url=foo

This has to do with the QSA flag in the last RewriteRule of the root htaccess file. The QSA flag indicates that a query string should be appended to the url. In our case, foo is recognized as the query string and it ultimately is appended at the end of the bar redirect. Not what I wanted, as the appending of foo to bar results in a 404 error. (more…)