Padraic Brady has posted part ten in his series on the construction of a blogging system with the Zend Framework. This part of the series focuses on the commenting system and using a reCAPTCHA and Akismet system on it to prevent spam.

Blogs all have two other features besides actual content. They allow readers to post comments, and they offer XML feeds of their content. With the blog application itself coming along nicely, and with Addendum #2's revised styling, it's a good time to take a peek at adding comments.

He has created a custom Service component for the framework that interfaces directly with the reCAPTCHA service (along with a form helper, view helper and validation methods) so that an element can be added just like anything else in a form. Code of its use is included.

He works this into his comment form, including the Controller and the action that would be called. He shows how to attach an Akismet call to the form too via the framework's own service methods. Finally, he handles the other side of things - the administrative piece and displaying the (hopefully non-spam) comments back out on the post.

On the ProDevTips blog today, Henrik has posted about an alternative to the popular Akismet plugin for the PHP blogging tool, WordPress, to help prevent even more comment spam from making it past - WP_Hashcash.

WP Hashcash is an antispam plugin that eradicates comment spam on Wordpress blogs. It works because your visitors must use obfuscated javascript to submit a proof-of-work that indicates they opened your website in a web browser, not a robot.

He includes the code that he needed to change to get the widget part of the plugin up and working correctly. You can find out more about this plugin from its page on Elliot Back's blog.

Michael Kimsal (and his bother Mark) were talking about the state of ecommerce applications, specifically about the latest "hot topic" software - Magento.

My brother Mark has been doing a long term project based on Magento doing a lot of custom work on top of it, and has told me many points, both good and bad, about it.

According to Michael and Mark, speed of the application is a big hindrance. They also mention two points that could help make an ecommerce system so much easier to integrate into the "blogosphere" - publishing a blog feed of some of the user feedback about orders/products/etc and accept trackbacks from an external blog post reviewing the products.

There's been a few posts about the upcoming namespace support in PHP from different bloggers in the community including:

• A post on the Stubbes blog by Frank Kleine and his discoveries of how the "use" keyword needs to be used in your applications
• A follow-up post from Frank as well correcting some of the problems in his first examples
• Some opinions from Richard Heyes on how useful they seem to him
• Brian Moon's comments on the level of traffic that the namespace discussion has been getting on the php.internals mailing list.

Right now there's so many ideas flying around about what namespaces should be and how they should be implemented that it'll be interesting to see which ideas finally come out on top.

Nick Halstead has posted a few more of his programming tips in the series he's running - three more to be exact dealing with readable code, aggregation, and code structure tips.

• Programming Tips #3 "Divide, Indent, Comment and Name": "We all started programming at some point in our life, some of us on our own, some under guidance of teachers, parents, but even now there are few tips, that should be known by everyone."
• Programming Tips #4 "Aggregation over Inheritance": "My favourite rule is to favour aggregation over inheritance."
• Programming Tips #5 "Readable Code": "It's easier to debug, and later to maintain. Make it readable by using descriptive identifiers, properly tabbing the code, and breaking down the application into functional and reusable pieces."

You can check out the full list of his programming tips in this list.

Demian Turner has passed along an "indepth and informative" comment from the PHP London mailing list he saw about WordPress involving some of the things that suck about it.

We did http://ftalphaville.ft.com using Wordpress, and speaking as someone who's actually had to wade through pretty much the whole codebase, let me tell you it seriously sucks.

Their highlights include messing with the raw POST data to limit access, function calls chained eight long and comments like "This probably isn't needed anymore" all over the place.

In response to an earlier blog post from another member of the PHP community, Greg Beaver has posted a few thoughts he's had on sharing what's really going on with the PEAR project.

Newly elected PEAR Group member Josh Eichorn posted a blog entry, "How would you improve PEAR" recently. I was impressed with the response, it seems many people outside of PEAR are monitoring it and have thought about how to make it better. However, I was also not so impressed with the poor job we've done letting people know about the newest improvements to PEAR. In my comments, I listed as many as I could think of, but Josh pointed out that I would do well to post these comments in a more public setting, so here goes.

He notes that most of the items mentioned in the comments of Joshua's post are already implemented, save for one - CVS over Subversion. He also shares his renewed obligation of working on the social issues surrounding the project and the efforts that the project is doing to help current developers (stable works the same) and development (get involved! get active!).

David Coallier points out a new feature of the main PEAR website (http://pear.php.net) - integration of the jQuery framework to help with the administration of a recent addition to the site, user comments.

http://pear.php.net is now using jQuery for some sections of the administration area in order to view user notes/comments and that I will be starting implementing more sections over the site within the next few weeks (Of course this will all be done once we have split the code completely into templates, views, controllers, MDB2 move, etc)

He also makes some comments about the number of Javascript frameworks out there and a mention of the roadmap for the rest of the features they plan to add to the PEAR site.

According to this new post from David Coallier, the PEAR website now includes a feature the main PHP manual has had for a while now - user comments.

For the past few days with the help of Greg Beaver (CelloG), I have been implementing user notes in the pear user documentation. This is now live and running using text-captcha-numeral and an administration backend where any developer can approve comments.

[...] Anyways, this is currently working, you have to go on a package's documentation link and then click on end-user documentation. You will then notice at the bottom a link that says "Add a note/comment".

He's also looking at adding some Javascript functionality to make it a bit more "pretty" (some jQuery features like popups/fading/etc). You can see an example of it already on the MDB2 documentation page.

Frank and Stehpan has posted two more items in their "PHP6 wishlist" series" today - both mentioning annotations.

In Stephan's post:

Porting JavaDoc comments to PHP was one of the best things, that ever happened to to PHP4. But like in Java 4, the DocBlocks in PHP evolved from plain documentation to a feature that adds meta information to classes, methods, properties and variables. IDEs, like Zend Studio, use the @var tag to enable type hinting for method return values, which would not possible without the DocBlock, as PHP is a dynamic languages.

And from Frank:

In part three of his wishlist for PHP 6 Stephan wrote that he would like to see annotations built into PHP 6 directly. I disagree with him about that. Annotations can be done in userland, without any problems. He already gave some examples of projects that accomplished this task. But if you look at them you see that every project has a different solution on how to implement annotations for PHP which leads to the problem that if you use different projects in your own application you have to handle all their ways of treating annotations. Annoying, isn't it?