A short time ago today, I submitted a PHP RFC for discussion which proposes adding an SPL Escaper class and, quite possibly, a related set of functions dedicated to escaping data for output to HTML/XML to PHP: https://wiki.php.net/rfc/escaper. The RFC itself should be a good read if you want to understand why I'm proposing this but the basics are quite simple. Cross-Site Scripting (XSS) is one of the two most common security vulnerabilities in web applications - the other being SQL Injection. Despite this, PHP's offering of escaping functions is extremely limited.

He talks about what problems the proposed solution solves and how it could help protect PHP programmers more effectively than the more complicated methods they have to go through now. If you're interested in reading the conversations so far, you can start here and walk through the messages.

The PHP development migrated to a Git repository. With the integration with GitHub it became easier for non-core developers to submit pull requests with bug fixes and new feature improvements to PHP. Will this new possibility make it PHP core developers accept more contributions from non-core developers?

The episode also looks forward to the next release in the PHP 5.4.x series (5.4.1) and some of the stir that a recent post (to PHPClasses) about OOP caused in the community.

You can listen to this latest episode either via the in-page player, by downloading the mp3 or by subscribing to their podcast feed.

I thought about this question for a while and have some thoughts on what it really means to know how to not suck at building things using PHP. In my never even remotely humble opinion I think the key is to understand what PHP is really good at.

He talks about how PHP had the early-adoption advantage at first with Apache, but how things have changed so much since then. Now, he proposes, PHP's popularity and usefulness is based on what it can do as a language without messing with frameworks at all. He's worried that, once someone picks up a framework, it'll become so ingrained that they won't know what "plain old PHP" can do (or how to work with it).

So my advice to Travis is that he should worry about learning to use PHP like glue and correctly identify the problems he is trying to solve NOW instead of worrying about the problems he might have to solve later. There will be time to fix your problems. Some of those will be solved by using tools that are not written in PHP, but PHP can still glue them together.

Recently there has been a rather heated and intense discussion on whether the PSR-0 autoloader "standard" should be included as part of the PHP core (in ext/spl to be exact). I've tried to stay out of the discussion and have successfully done so. Until today. I feel that there's something that's been missing to the discussion. So rather then posting this to the internals list, I feel it's better served by a blog post on the subject. So here's my take on it.

As mentioned, he's not in favor of the inclusion for three different reasons:

• It's inconsistent with current PHP functionality and would bias development one way or another
• It's not an actual standard, just a loosely defined practice based on functionality already in place
• There's noting for core to gain by adopting it and could cause problems trying to make things fit a one-size-fits-all solution.

OpenSource is an amazing phenomena, but how safe open-source projects are? Would commercial project be safer over the community-supported project? Frameworks can't exist without their core team and In this article I look at how different PHP frameworks are supporting their core developers.

He talks briefly about the need for a good, solid group of core developers on a framework (or really any product) to provide a stable foundation if a product was created with it. Four projects are mentioned - Zend Framework, CodeIgniter, Symfony and Agile Toolkit - and why, because of the backing they have from a company and a large group of developers (and contributors) they're not "yet another framework" that'll disappear over time.

Making new frameworks is fun, however, if you share framework with others, be responsible about the support. Make realistic goals and try to have a plan for a next few years. If you are the author, think who will support the community when you decide to move on.

Today on twitter there was a conversation going on about the responsiveness of the core PHP developers to PHP users. [...] This post isn't necessarily to correct perceived errors, to stand behind correct statements, or to state what I believe the problem is. Rather, it is to add something to the conversation that I don't think I've seen much of. The Twitter conversation was, for me, more of a contemplation kickoff and so the purpose of this post is to propose some thoughts for consideration. I don't have sufficient karma to propose changes directly, but I have bet my career on PHP and I want to see it beat the crap out of every language out there.

He points out that most of the opinions out there seem to be of the "what" PHP is rather than the "why" PHP is. He notes that the discussions about the core development (and developers) that's been happening recently is more of a symptom of a larger problem - an unclear definition as to what PHP is and what problem it's there to solve.

Before getting into the original post, I wanted to a comment made in his edit with an apology for the original post coming across as more of an "irritated user" than an unopinionated observer.

PHP's development process has been broken for a long time, and the failures of that process have swelled since the first ripples began to appear many years ago. [...] This is no surprise given the very fluid history of PHP though, and the lack of any sustainable processes may have even been one of the key things that allowed PHP to evolve so quickly into one of the most used programming languages in the world. But that early success doesn't make the PHP development process any less broken.

He covers a few points where he has issues with the PHP project including the release management, test coverage and recent issues with bugs in releases. He gives suggestions on how things could be made better - a detailed release process, a voting process for new features and a emphasis on good code and tests in the core. He also notes that he thinks more contributors in the mix isn't the solution. While it's encouraged to join the project, he suggests that the current core development group are the ones that should work the hardest on making things better.

Be sure to check out the comments for some great responses from the PHP community - both for and against the statements from the original post.

think it's fair to say that the pace at which PHP core is being developed has slowed down considerably over the past couple of years, while the development of many projects based on it, like programming and application frameworks, has sped up and continues to grow at a fast pace. But this doesn't mean that we're running out of steam. The PHP ecosystem is simply refocusing outside of core, where it has a lot more freedom of action.

He suggests two reasons as to why this slowdown might be happening - first that there's not a sense of strong leadership in the core development group (a feature of the project done on purpose) and the change to move new library support out to PECL and PEAR instead of directly into the core of the language.

The risk facing us, as I see it, is not that Drupal, or WordPress, or whoever may decide to fork PHP or abandon it altogether. Rather, the problem is that there is no real way for these projects to provide upstream positive feedback to PHP core.

It was just a few months ago that the CodeIgniter community began to explode with a torrent of frustration that CodeIgniter simply wasn't progressing as a framework. There were also a few prominent developers considering abandoning the framework in favour of more active alternatives. [...] Before we go patting ourselves on the back, and heralding the reactor as a great success, there's a much wider question we need to look at: 'Are people actually upgrading?'.

He notes that, based on his experiences, people don't seem to be upgrading to this latest release and that several people still see Reactor as a "beta" and not a viable upgrade alternative. He suggests three things he think could help - a good upgrade guide, a stop of support in libraries for non-Reactor codebases and encouragement to use mercurial more (cloning the repo).

Today EllisLab and the CodeIgniter Reactor Engineers are proud to announce the first official release of CodeIgniter 2.0.0, which is being released in two flavors.

The "Core" version will be the branch that EllisLab uses for their internal applications and will be a bit slower moving. The "Reactor" branch, however, is more community-powered and headed up by a set of Engineers that will guide the framework and work to make it its best. Also mentioned as new in the post are the upcoming ability for users to contribute directly to the user guide, the creation of a standardized Authentication library and a more object-like model setup. If you're interested in the Reactor branch and want to try it out or contribute, head over to the bitbucket account for the project.