On the Drupal4Hu.com site there's a recent post with a complaint about the OOP functionality in PHP and how Drupal developers should deal with its limitations.

While I was always complaining of PHP's inability of adding a method run-time, the problem we face is that you can't replace one either. So if you do what I did in the previous post, namely use the hook-alter patten (already an addition to PHP, I must say) to override the classname, that works. However, if two modules try to do this for two different methods, you fail.

He suggests to those Drupal developers out there that, for version 8 of the popular content management system, they drop the "closed crap that in PHP is called OOP" and work to make something better, implemented themselves. Something that would make it simpler for Drupal developers to create hooks into the main system for their plugins. Be sure to read the comments for other opinions on the post.

Craig Buckler has added a new post to the SitePoint PHP blog today that looks at some of the PHP configuration options and how you can change them from two different places (besides the php.ini file).

Configuring PHP is easy. You can change almost any aspect of the interpreter within the php.ini configuration file, e.g. modify error handling, increase memory usage, etc. Unfortunately, problems can occur when you move your application to a live hosting environment or are distributing the code to customers. ISPs usually lock down the php.ini configuration file - especially on shared hosting. This could cause your application to fail.

If you're lucky enough to be able to use htaccess files, his first method will work for you - using the "php_flag" or "php_value" directives to change settings for your entire application. The other option is more on an as needed basis - using the ini_set method to change configuration options. Be careful, though, only some configuration options can be changed using these methods. Some still require changes to the php.ini and a restart of the web server.

Alex Netkachov has found out something interesting - the default "file" stream wrapper can be overridden.

I find today that the default "file" stream wrapper in PHP is overwritable. You only need to call stream_wrapper_unregister and then stream_wrapper_register with your wrapper.

He gives an example of a situation where you might need to "catch" certain files as they're requested and replace them with another before they make it back to the source. His example code shows how to create the stream (using stream_open) and set methods to read, write, seek and work directly with the stream resource. It takes the file requested and replaces the "5" in the name - "test.php" is included instead of "test.php5".

On the PHP::Impact blog, Federico Cargnelutti has another helpful tip to use in Zend Framework applications - encapsulating routes into modules.

You can encapsulate routes into modules by splitting the routes into different files and extending the Zend_Controller_Router_Rewrite class. But, what if you want to use the Redirector helper to set a URL based on a registered route?

His method creates the routing instance and overwrites the default getRoute method with a custom one in the extending class.

Greg Beaver, noting some issues that Derick Rethans had pointed out about namespace support for upcoming PHP versions, has posted about a patch he submitted to solve the problem simply.

The issue Derick pointed out:

In PHP 5.3 this would alias the class Interval in the namespace PEAR::Date to the class Interval. For now, this code would work just fine. However, if PHP would introduce a class "Interval" at some point in the future (and PHP can do this as it owns the global namespace) then the above code would suddenly stop working.

Greg's patch makes it possible to "override" the internal class if need be, making it so that code currently working wouldn't break. All it takes is to "use" is like you normally would and and the magic happens behind the scenes.