Andi Gutmans has posted a reminder about the upcoming Zend/PHP Conference and Expo happening Spetember 15th through 18th in Santa Clara, CA.

I can't believe it's already ZendCon time again! I've been meeting with the planning committee and I'm really excited about this year's conference. All the usual things are back to make it great: we have a great lineup of speakers, the Meet the Teams session, and special guests like noted PHP security expert Stefan Esser, Dion Almaer and Ben Galbraith of ajaxian.com, and Alex Russell from Dojo.

He mentions things like the unconference (with even more great speakers, just in a more "unofficial" setting) and about the conference wiki with more details on who will be there and what they'll be attending.

There's still seats open for this year's conference, so reserve your spot today - check out the registration page on the ZendCon site for more information.

In a new post to his blog David Parra talks about compiling extension on Windows (specifically his ktaglib one).

This is actually the reason to not even try to compile my ktaglib extensions under Windows. Well but this approach is doomed to fail as most of the developers out there use Windows as their operating system. [...] So actually I ended up booting up windows again (well after searching for the harddisk that contains a running windows) and try to compile it. Otherwise my fellow collegues wouldn't be able to fix my buggy PHP code.

He talks about the pecl2 updates and how it makes compiling on a Windows system easier than before and two resources that budding Windows extension developers can use to get started - the PHP.net wiki and a screencast from Elizabeth Smith that can help out quite a bit.

Chuck Burgess has a quick post pointing out the next "PEAR triage days":

PEAR's next Bug Triage days are this weekend: Saturday 4 PM - 9 PM UTC and Sunday 4 PM - 10 PM UTC.

You can find the schedule and more information about joining in at this page on the PEAR wiki. You can find others working on the triage on the EFNet's IRC network in the #pear-bugs channel.

A new entry has been posted to the PEAR blog with the latest minutes for the group's July 13th meeting.

Some highlights from the meeting include new/upcoming RFCs for package naming schemes, exception handling in PHP 5.3, and a vote on extending the current PEAR2 Policies. Heavy stuff, check it out!

You can check out the full notes here on the PEAR portion of the PHP.net wiki.

Today on the SitePoint PHP blog Troels Knak-Nielsen reminds the community about a "one-stop resource" that they can use to keep up to date on some of the latest happenings with the PHP language, the PHP.net wiki.

Since March, there has been a wiki at wiki.php.net. The most interesting section is probably wiki.php.net/rfc, which - as the name implies - contains RFC's for improvements of the language. I've rambled on about closures and lambdas before, but as you can see, there is now an accepted patch. Whether it'll make it into 5.3 is unlikely at this point, but it looks like it'll at least be coming with 5.4 and/or 6.0.

He also points out the php-internals mailing list and the summaries that Steph Fox has written up weekly about the list's latest conversations.

Lukas Smith has posted a quick emPHPower update to his blog today concerning recent thoughts and progress he's made on the initiative.

I hope this all will lead to a few people to step up and really start getting involved deeply in emPHPower. Aside from this Sebastian has handed in a BOF session on emPHPower for OSCON. I hope this one will work out.

A spot has also been set aside at the upcoming Zend/PHP Conference & Expo's unconference for someone to speak on the subject and to get a feel for things from the business perspective. Lukas has also been working up more details about the effort and has set up a mailing list to help with collaboration.

Lukas Smith has just become the co-release manager for the much anticipated next stable release in the PHP 5.x series - PHP 5.3.

Its quite an honor and a challenge. [...] We hope together we have enough brain cycles to push put what is probably the biggest minor release in the history of PHP. Just take a look at the todo list and the scratchpad detailing all the additions.

He also asks for any help they can get to help identify all of the changes for the new release and to do the usual testing against the current CVS version with applications to see if there's any breakage. The more you test now, the less that has to be fixed post-release - so get out there and get testing!

According to this new post to the CodeIgniter blog, they've added a new feature to their Wiki - a link between them and the CodeIgniter forums.

Threads will be automatically created and linked for you via the discussion links found at the bottom of wiki articles. More details about this integration can be found at a blog post made in the ExpressionEngine blog, as well as a free ExpressionEngine extension to implement this on your own sites that utilize the ExpressionEngine wiki and discussion forum.

The plugin (the "Wiki Forum Talk" extension) bridges the two components and either makes a new topic when a new wiki entry is added or, if there's already a forum topic for the entry, it automatically links to it.

Elizabeth Naramore has posted about a new addition to the site for the PHP Appalachia conference website - a wiki:

Hey, we now have a wiki for PHP Appalachia, so if you're attending be sure to list your name on there. I could do it myself but what do I know; you may want to keep that your little secret. Plus, I'm lazy.

They're looking for some good contributions for potential attendees (or people from the area) on places to eat or something fun to do while in the area. There's still some spots open, so if you're interested in hanging out with some fellow PHPers at a camp in Tennessee, head over and check out the site to get more information on the whens and wheres and how to reserve your spot.

In an effort to keep things a bit more secure (after finding out about this) the symfony team has officially released their own security policy to help prevent issues like that in the future.

You may be wondering why it has been taking us such a long time to react. Here's the main reason: we had not a very strong security alert reporting and qualifying process. This has been fixed recently. So as of now, if you find a security bug in symfony, please send an email to security at symfony-project.com, with as much details as you can and ideally a patch if you can provide one.

The wiki has a whole section on how to report security issues to get them to the right place.