Larry Garfield has posted the results of some of his research into popular PHP frameworks and projects and see how they handle their structure as it relates to the PSR-0 standard.

As Drupal is in the process of considering how to restructure code to best leverage the PSR-0 standard, I figured it would be wise to take a quick survey of how some other major projects organize their code bases. This is not a complete rundown of every project, simply roughly comparable notes for those areas Drupal is currently discussing. I am posting it here in the hopes that it will be useful to more than just Drupal.

The projects he looked to for his examples were:

• CakePHP
• Symfony2
• Silex
• CodeIgniter
• Zend Framework 2
• Composer

As Lukas Smith mentions in his latest post, the Drupal project has made a switch to use the HttpFoundation component of the Symfony2 project as a integral part of their HTTP handling.

[...] The fact that Drupal8 will use Symfony'2 HttpFoundation component is huge, because it will make integration a breeze. Basically Symfony2 converts a Request instance to a Response. So if both Symfony2 and Drupal8 use the same Request and Response classes it means that creating a sub-request and handing the response from Drupal8 into Symfony2 (or vice versa) will require no conversion at all.

He also points out Drupal's use of the ClassLoader component will make integration even easier. This is great news for Symfony fans out there that have been needing to work directly with a Drupal install (or even those wanting to create new Drupal additions in the environment they're familiar with). You'll have to wait for Drupal 8 to get these benefits, though.

Artur Graniszewski has written up a comparison of the performance of a standard Durpal 7 installation using HipHop versus APC to handle the optimization of the application.

There have been many suggestions on improving Drupal performance, some of them recommend the use of APC module, data caching, or even compilation of the entire system through HipHop for PHP. While the first two solutions have been successfully implemented, no one was able to perform the build process. After many battles with the the compiler and the Drupal code, I present you results of the first successful translation of Drupal 7 to C++ language

He introduces the methods he used and the statistics of the platform (hardware) he tested with. He also includes the software used and compile commands used to create the compiled Drupal version. Included in the post are graphs showing CPU usage comparing the two types of testing (HipHop and APC) versus a normal PHP-based installation. It also briefly touches on concurrency levels and the different optimizations that could be made with the gcc compiler.

On the Zend Developer Zone Cal Evans has posted some encouragement about sharing your own thoughts about the post from Dried Buytaert about the future of PHP and Drupal.

As Dries says in his blog:

It seems that we have arrived at a point in which there is a symbiotic relationship between PHP and the most popular PHP applications. A relationship that did not exist when PHP was created. Symbiotic relationships are obligatory: we depend entirely on each other for survival. And yet, I feel like we've been living apart. It makes sense for us (i.e, application developers) to contribute to the development of PHP, and for the PHP core developers to work more closely with the developers of the most popular PHP applications.

He points out that, in Acquia's case, there's just not enough time for the group to contribute back to the PHP project. Other posts surrounding this same discussion have also noted that there's not a good mechanism for people to "give back" to the PHP project and that getting involved requires a certain skillset that lots of developers don't have.

Inspired by some of the recent discussions in the PHP community about the future of the language and the software that uses it, Till Klampaeckel has posted some of his own thoughts on the matter.

Last week the usual round of PEAR-bashing on Twitter took place, then this morning Marco Tabini asked if PHP (core) was running out of scratches to itch. He also suggests he got this idea from Cal Evan's blog post about Drupal forking PHP.

Till talks about a few different points others have made in their comments and tries to clear a few things up - the state of PECL, Drupal and PHP (and forking), PEAR and how some of this infighting might be doing more harm than good for the community.

In a recent post Cal Evans shares his opinion on why he thinks the Drupal project should fork PHP and what benefits he sees for them in doing it.

Obviously moving the functionality [of Drupal] - not to mention the existing userbase - to a new language would be a herculean task; but what if the new language was just a version of the old. What if Drupal forked PHP and began working on its own version? With that thought in mind, I began to think hard about reasons they would want to do this. Here are the four best I came up with.

Cal list of advantages include an improved development process based on Drupal practices, the creation of a tailor made language they could tweak to just their needs, tighter integration between language and application and, of course, the ability to control the future of the language according to their needs.

Cal Evans has a new post to his blog today listing some of the more popular Drupal podcasts that he's found for his wife to listen to on her way in to work.

The lovely and talented Kathy has been working with Drupal now for a year and has decided that she really likes it. Since I believe in using commute time to learn, I decided to see what I could find for her to listen to on her daily commute. I found several active Drupal podcasts and vidcasts. Here's the list I gave to her, if you are into Drupal, give them a listen and quit wasting that morning commute waiting for the shock-jocks to actually say something funny.

The podcasts on his list include the Acquia Podcast Series, the Lullabot Drupal Podcast and the Learn By The Drop Videos.

One of the ways you can help to secure your web application is to use the Apache module mod_security. It allows you to specify extra rules and settings to help prevent issues that would normally pass on through. Unfortunately, it may not play nicely with all web-based applications. In this new article on the O'Reilly Broadcast, Caitlyn Matrin describes some of the steps she took to get mod_security and Drupal to cooperate.

Deploying Drupal on an Apache web server with mod_security or adding mod_security to an Apache server with Drupal running should be as easy as installing the relevant packages. Unfortunately, on Red Hat Enterprise Linux (RHEL) 5.4 and 5.5 servers it just isn't so. This is due to a combination of a bug and an outdated Core Rule Set (CRS) in the current mod_security package in the EPEL (Extra Packages for Enterprise Linux) repository. I've seen lots of posts online where people were struggling with this combination so I decided a how-to article was in order.

She walks you through the install process for mod_security (assuming you already have Apache and Drupal installed), what settings to change, directories and permissions to add and how to replace the old Core Rule Set with a newer version.

Larry Garfield has a recent post to his blog that outlines what he thinks are some of the top priorities you should take into consideration when architecting your next application - small or large - and lays that structure on top of what the Drupal project is doing.

Understanding architecture, and the trade-offs that different architectures imply, is an important part of any software project. [...] To be able to speak and think about the design of your system properly, though, you need to understand the trade-offs that come with it. There is no such thing as a free lunch, and designing a system to be powerful in one way invariably tends to harm it in another. It is important to know what your priorities are before you start building; and in a distributed collaborative environment like Drupal to all agree what those priorities are, at least to a large extent.

Talks about software architecture design patterns (like Model-View-Controller or Naked objects) including one that's not so much a pattern as an evolution - monolithic architecture. Among the list of things he suggests considering are subjects like:

• Modifiability
• Testability
• Performance
• Scalability
• Usability
• Maintainability

He compares this list to how the Drupal project is run and finds a large emphasis on extensibility, modularity, scalability. These came at the cost of testability, verifiability and understandability however.

Mike Bernat has a new post to his blog today talking about what he considers the problem to be with both WordPress and Drupal - despite doing what they do well, they're not good examples for developers.

If a young developer said to you 'I want to learn by looking at existing code from a successful PHP project. Can you point me in the right direction?' Would you ever feel comfortable sitting them down in front of Drupal or WordPress code? What if they responded by saying: 'But they are the most well-known free, and open, products that use PHP. They're obviously doing something right, so why shouldn't I try to learn from their example?'

In his opinion, developers should set their sights elsewhere if they're looking for good examples. Both tools use what he calls the "old way architecture" that could hold developers back from some of the wonderful new enhancements that the language has to offer and best practices that might not be found in their codebase.

While some of the techniques used in WordPress/Drupal are undoubtedly solid and still state-of-the-art, the majority of the frameworks are ancient in web-development terms. PHP is growing as a language, and I for one want to see it regain some of the respect its lost.