As more and more projects adopt composer they will not only start using 3rd party code, they will also come to realize how easy it is for them to expose their code to 3rd parties. Obviously NIH syndrome will not be purged from the planet and maybe it should never get purged entirely anyway. But its already quite clear how much the landscape of the PHP community is changing with Symfony2, Doctrine, Zend Framework2, TYPO3 and many other projects having adopted composer.

He notes, however, that there still seem to be those clinging to "the old ways" and keeping things tightly bound to the technologies they're designed to work with. He's coming from the point of view of a Symfony2 user, so he gives the examples of some of the Bundles that are out there, reinventing functionality they could have pulled in from 3rd party libraries.

The release of the first RC (release candidate) of Zend Framework 2 is getting close. One last beta (beta5) and then the RC will be announced! With the current pace of modules spawning on GitHub, I think it is a good idea to give some insights in how you can use 3rd party modules. In this blog post I will focus on MVC modules: modules with routes pointing to controllers and view scripts for rendering. Because using a 3rd party MVC module does not mean you are enforced to follow their routing scheme, use their view scripts or use the predefined forms, I will explain how you can modify those options to your needs.

He covers the three steps needed for integration - adding a new route to handle the requests to the module, adding a view script to handle its output and working with a Form instance to add a bit more handling.

The age old private vs protected debate has been re-ignited in the PHP community recently following the decision of Doctrine2 and Symfony2 to make all class methods private until there is a very clear and proven reason to change them to protected or public. The intention is a good one - to ensure they are providing a clear and stable API through intentional and known extension points that they can better test and support. [...] The problem is that this kind of thinking is a slippery slope that kills the spirit of programming.

He suggests that, by limiting the scoping down to private, you're taking away the very thing that gets most people excited about third-party tools - the extensibility. In his opinion, it sends a strong message to other developers that they're "not welcome" to make suggestions or updates to the application/tool.

If you have your photos in Flickr, your videos in YouTube, and your TV shows in Hulu, how do you bring them all into your blog posts on Blogger? Of course, you can do this by hyperlinking to the appropriate content, but wouldn't it be nicer if you could just embed them into your post at the appropriate place? Enter oEmbed.

He gives examples showing how to pull in content from a few different places - a video from YouTube, one from Revision3 and an image from deviantART. He also talks about using the oohEmbed service to access additional content on things like Wikipedia, Slideshare and Amazon. There's also a bit at the end looking at an alternative PHP library that could be used to do similar things, php-oembed.

After using Codeigniter, CakePHP and Zend Framework for a while I decided to build my own framework. I wanted to include some features that I couldn't find the way I like them in none of the projects I tested. These are some lessons I learned the hard way. I hope you'd find some useful tips for your software projects.

The post looks a a few different topics - doing good planning before development starts, using third-party libraries, planning out the syntax the components inside of your framework will use, how to handle debugging and two tools you can use to benchmark the end result.

Log analysis is a fairly common task in the field of web development, most often analysis of web server traffic logs or what Wikipedia refers to as web analytics. PHP has no officially supported extensions designed specifically for log analysis. There are no related extensions in PECL. The only remotely related extension in PEAR is PEAR_Log, which for generating logs rather than parsing or analyzing them. In short, there is no common solution here.

He looks at the options that developers do have - make their own solution or go with a third party option. He believes, though, that a PECL extension would be more the way to go, integrating with PHP more closely and allow for easier parsing and manipulating of the data in their own log files.

From time to time I get the question why I recommend enabling open_basedir and on the other hand call it a solution flawed by design. This is actually a good question, because the untrained PHP user might get a little bit confused about this and might believe that I change my opinion on a daily basis.

He talks about his reasoning - how it does it's job protecting PHP developers from being able to get to those file, but how it's also flawed with issues due to some 3rd party libraries that have their own problems.