The question, however, has always been "how useful is this feature really and does it bring more harm than good?". It's not that easy to answer since there are so many notes submitted by a wide range of users and some will likely go unnoticed while others seem to get undue attention due to their positioning near the top of the user-notes section of a particularly trafficked page.

The poster proposes a few things that could help make them a bit more effective (and useful overall) including voting on the note contents, flagging potential issues and sorting the notes based on popularity/age. He's put together a proof of concept as seen here with some of the new features.

This morning, I was reviewing the weekly list of topics with the most comments throughout the PHP manual, and I stumbled upon the following code in the documentation for the date() function. This code is designed to tell you the day of the week for any valid date you give it. [...] I'm sure that this user put a lot of work and effort into this function. I'm sure they were excited to share it with the PHP community. I'm sure they thought they had stumbled on a solution to a problem that everyone needed to solve. I'm sure they had no idea that this code is a great example of using PHP precisely the wrong way.

His example, one that uses around 30 lines of code to do something that date could accomplish in one, is a perfect example of why blindly following the advice of others without thinking things through can be disastrous for your code. Do a bit of research before you cut and paste and remember that with someone else's code could come someone else's problems - think before you implement.

I've had a couple of whinges on IRC lately about why I'm not thrilled with having user notes in their current form in the PHP manual; we get entirely too many questions in ##php from people who've copied code out of a note and are then annoyed when it turns out the code is wrong, broken, horrible, or all of the above.

His gives an example (one of many currently in the manual) that shows a round-about way of getting a date string that could be done better in a single "format()" function call on a DateTime object.

I don't know what the answer is - moderation has its own problems to do with workload, as PEAR can attest - but a system that's letting that go up as recommended practice (and stay up for a month) has to be looked at.

Taking advantage of php|tek bringing a lot of people together, we had a PHP developers meeting over 2 days before the conference. Day 1 was dedicated to technical issues in PHP 5 and 6, and day 2 was spent discussing potential features, migration issues, current roadblocks, etc.

The notes cover PHP versions 5.3, a possible 5.4 and looks forward to 6.0. There's some interesting stuff in there, so read over it if you get a chance.

I just listened to the PHP User group Panel discussion from the Unconference session at ZendCon. While I listened I took some notes to try and help our Irish PHP Users Group be awesome like some of the other groups out there. I reckon the podcast and great tips it contains will help other User Groups out there too (not just PHP).

Some of the observations/comments she mentions include:

• Freelancing PHP developers may not feel like attending a group with "the competition"
• Several factors dissuade developers from attending (distance, confusing schedules, timing)
• Some ideas that groups out there could use to attract and keep more members
• Why the groups can make you a better developer
• and some sponsorship/promotion ideas to help grow and better the group

This is a great post packed with some good suggestions and observations. If you're involved at all in your local group (or would like to be) be sure to read it.

Just as views can be automated'"that is, you don't have to instantiate a Zend_View object; the controller does it all for you when you call $this->render() from any controller action'"you do not have to explicitly tell Zend_View where your helpers reside, as the manual suggests. Instead, place your helpers in a special "helpers" folder where the Zend_Controller_Action's initView() can find them.

He includes how the directory structure would be altered (the addition of the helpers folder) and how to name the helpers so they can be used in an application (Zend_View_Helper_*). Also, check out the post for some of his interesting thoughts on a recent visit of his to New York City.

Source Documentation

• PHPDoc is the defacto documentation standard, it can be parsed by PHPDocumentor and Doxygen
  
• Use @category and @package to manage your documentation
• Using PHPDoc allows all developers to immediately understand your code

I was just browsing through my OLD advogato profile and thought I would link to these two posts (from mid 2002) which talk about one of the many CMSs which forked off the original PHPNuke code base.

Part one talks about the split between Postnuke and PHPNuke as well as what some of the differences are. Zope is also mentioned.

In part two, he notes a bit of a change in his thoughts on Postnuke (related to a change in the code for a templaing engine).

It's interesting to look back and see how far some projects have come...

It's a good summary of what the talk was about, and provides a few bits that weren't covered in the slides. If you're looking for a good place to start with researching PDO and its associated technologies, her list is a good place to start.

Each heading is accompanied by at least three points, clearly written as to include the most information. Some examples of the topics covered include: "Why PDO?", "Persistent Connections", "Prepared Statements", and "Retrieving information using PDO".

He also mentions a great "impromptu event" the Thursday night of the conference - a dinner that ended with a speed beed drinking contest. And yes, ther's documented proof - check out these movies of it over on Sare Goleman's blog.