So, I’ve been playing with CakePHP lately for a project I’m working up. I have to admit, it’s nice – very nice. I can see what all of the fuss is about.

Having used the Zend Framework for a project (a pretty important one, at least to me), I’ve had a bit of experience with the whole MVC style of development. I understaood what the parts did and how they fit together, but the actual development process was still a bit of a mystery to me until I really got into the ZF. I developed my application, worked up a pretty good site, and had things going along swimmingly.

Then I figured I’d give another framework a try for this other project. So, being the (brave?) soul that I am, I switched over to Cake. I have to admit, right off the bat, I almost ran screaming back to the Zend Framework. I was faced with a fully installed framework with a different structure than I was used to, different naming conventions and locations than I knew, and one big thing I wasn’t used to using coming from Zend – models.

So far, I’ve only used the models to act as interfaces to the database tables of their same name, but I know there’s more to them than that. Those working with the Zend Framework might not quite get how they’re used if you’ve never done any other MVC work outside of the Zend Framework, so here’s a bit of a basic summary as best I can tell:

Models are a “go between” for the controller and the view. The controller can look at and use the view to understand what the resource is like behind the scenes and use that to run code to output to the view. In the Zend Framework, since models aren’t even there, pulling information from and pushing data into database tables requires ensuring you have your SQL statements right to make the updates. In Cake, it’s as easy as calling the save() function in the controller and letting the framework (including the model for the table) so the rest.

Switching from one to the other was interesting – naming conventions and locations are less important to the Zend Framework as they are to Cake. Cake has a place for everything and everything in its place. There are directories under the views for the pages of each controller, helpers for each of the MVC components (components for controllers, helpers for views, and behaviors for models), and plenty of “magic methods” to go around.

I know I’m only getting started with Cake, but I do like what I’ve seen so far, and I know that there’s so many features of the framework that I’ve only touched on, but I’ll get there. I promise.

Oh, and, in a parting note, I have to compliment both frameworks on doing an excellent job on documenting their functionality. There might be a few little issues here and there, but over all, they both make life a lot easier through a few simple web pages.

I’ll just start off with it – comment spam sucks.

Well, okay – really, any kind of spam sucks, but comment spam has been the bane of my existence lately. Initially, just to stop the incoming flow, I resorted to keyword matching. I grabbed strings from the current comments (around 6 thousand of them) and put them into a big array to help blog the evil little baddies hellbent on posting their worthless crap all over my comments (me? bitter? never!)

Sure it works, but it’s a pain to have to go back in each time and readd something when a new spam comes along. So, I told myself, “Self, surely there has to be a better way”. All hail the happiness that is Google – I found an answer within the first few pages of results, and that solution’s name is Akismet.

Now, I know what you’re thinking, “That’s just a WordPress plugin, right?” Wrong. They actually have a pretty slick (and simple! yay!) API to interface with their vast repository of spam-related things. All you have to do is provide them with the contents of the comment you’ve just recieved and they give you a “yay” or “nay” as to if it’s spam or not. The API takes in a traditional POST request and returns a normal response, in this case with either the string “true” or “false” (true meaning that it is spam).

Since it is a pretty easy interface to work with, I decided to throw together a little PHP class to make the connection and check to see if the message is spam (as well as check to see if your WordPress key is valid). Oh, did I mention that you need a WordPress key to get the setup working? You’ll need to go signup over on WordPress.com and, once logged in, go to your “My Dashboard” (top left link), go to the “Users” tab at the top, hit “Your Profile”, and right there at the top of the page you’ll see “Your WordPress.com API key is…”. Easy as pie.

With that in hand, you can grab the PHP class and go to town. What’s that? You want to know a little bit more about it? Well, okay…but just this once. And because I like you.

The class (made for PHP5, but is pretty simple to go back to PHP4 with) basically has seven functions:

• Akismet() – the constructor, it just sets some class variables
• _makeRequest() – actually does the work of sending the data off and getting the response back
• _encodeRequest() – a simple function that loops and urlencodes an array
• checkSpam() – generates the request to send off to the API to see if something is spam
• checkKey() – calls a different server to see if the WordPress key you’re using is valid
• submitSpam() – placeholder, for now.
• submitHam() – placeholder for now.

Most of the class is pretty self-explanitory and is made to be used by just calling checkSpam() with the right parameters. As their documentation mentions, the more information you send along the better, but the simplest call I’ve seen that’s valid sends the content and author fields (comment_content and comment_author). The other fields that you can send are also listed in the documentation.

I know you’re hungry for some actual code by now, so we’ll get to the point. To make a simple checkSpam() call, here’s an example:
[php]
$arr=array(
‘comment_content’=>”viagra-test-123″,
‘comment_author’=>”enygma”
);
include_once(“/path/to/Akismet.php”);
$ak=new Akismet();
if($ak->checkSpam($arr)){
echo “this is spam and it sucks!”;
}else{
echo “we have an all-clear!”;
}
[/php]

Pretty easy, right? And any of the other fields you add into $arr (like permalink, comment_author_email, or comment_type) will be automatically included in the POST request out to the Akismet service.

It’s not the most robust system and there’s some other classes out there that are more well-developed than this one, but it’s light, easy, and it worked for what I needed it to do. Hopefully, it’ll help someone else out there too…

Oh, and incase you missed it – source: Akismet.phps