Vance Lucas has tossed his hat into the ring in the debate about private versus protected scope in PHP projects with this new post to his blog.

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.

On IBM's developerWorks there's a recent article from Vikram Vaswani about using the oEmbed tool to pull content into your site from sources like YouTube, Twitter and Facebook.

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.

If you're thinking of trying your hand at creating your own PHP framework, you might want to check out this post from Matrin Rusev about some of the lessons he learned (the hard way) about framework construction.

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.

In a new post, Matthew Turland looks at one thing that he feels is missing from a lot of the PHP functionality currently available in the community today - log analysis features.

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.

Stefan Esser is trying to clear up some confusion in a new post to the PHP Security Blog today about his stand on enabling open_basedir on your PHP installation.

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.