What is a package? A package is a piece of reusable code that can be dropped into any application and be used without any tinkering to add functionality to that code. [...] Most package systems also allow for something called dependencies. [...] This is how most modern programming languages work, but to make a generalisation: PHP developers hate packages. Why? Well while other languages have great systems like CPAN for Perl, Gems for Ruby, PIP, PHP has had a terrible history with package management going back years.

He talks about one of the main current packaging systems, PEAR, and how, despite its attempts, it just hasn't seen the adoption the package management of other languages has. Phil makes a recommendation that is slowly becoming more and more popular in the PHP community - building "unframeworks". These sets of reusable components (similar to the ideas behind Aura, Symfony and Zend Framework 2) are designed to be dropped in and used without the dependencies of the frameworks they live in. He points to the Composer/Packagist dynamic duo as a way through all of the current packaging issues - a simple way to make any project an installable package just by adding a configuration file.

The PatchworkUtf8 class implements the quasi complete set of string functions that need UTF-8 grapheme clusters awareness. These functions are all static methods of the PatchworkUtf8 class. The best way to use them is to add a use PatchworkUtf8 as u; at the beginning of your files, then when UTF-8 awareness is required, prefix by u:: when calling them.

In the README for the tool he talks about the functions included in the current release that match PHP's string functions as well as some additional methods like "isUtf8", "bestFit" and "strtocasefold". It relies on the mbstring, iconv and intl extensions being installed, and if they aren't, it falls back to other functionality (list of those methods included).

If you're ever stuck on a problem, Google it and you'll find a swarm of users have most likely experienced the same issue and have already shared their solution. If it's not out there, ask in a public forum and people will help you find the answer. And if you've managed to solve it yourself, then write about it! That way you'll be contributing to helping others the same way others are willing to help you. That's one part of the PHP community that makes it really stand out - people share their knowledge and are more than willing to help others along their journey with PHP.

Some resources/places to meet like-minded developers include:

• StackOverflow
• Conferences like PFCongres 2011 or PHPNW 11
• Groups like PHPWomen or local user groups

The community in PHP is huge and is growing every day, and it's all about sharing. If you see someone in need and you're able to help, offer him guidance. If you see an open-source project that's great; contribute and help it grow.

For the people who read PHP's NEWS file, it's no surprise - but for all who don't here's is probably one of the biggest features of PHP 5.4: Closure Object Support is back. For me it's something I missed the most, when Closures were introduced in PHP 5.3. So I'm very happy, that's finally here (or back). I'm going to tell you about the rocky road which closure object binding support had and show you some simple use cases for it.

The functionality, based on this RFC, lets you more correctly bind closures to objects instead of having to pass the objects into the closure at create time. He includes an example from a Silex framework application and an example that refactors a helper method as a part of rendering a simple template.

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.

In less than two weeks since the announcement was made at CICON that CodeIgniter was moving to GitHub, we've seen some incredible results from the change. Already CodeIgniter is the 10th most watched PHP project at GitHub (currently 758), with 42 open pull requests, 53 merged pull requests, 170 forks, and 41 individual contributors. Incredible!

[...] We also noticed what seemed to be a spike in activity on the #CodeIgniter Freenode IRC channel, so we've decided to make it more prominent to encourage its continued use. You'll now notice an IRC tab in the main navigation, letting you access the #CodeIgniter IRC channel right here at CodeIgniter.com.

If you want more details on why they made the switch over to git, check out this blog entry from the EllisLab site for an explanation from Derek Jones

A few days ago a new repository popped up on our internal Mercurial server. We're not particularly creative with our naming, so it was simply CodeIgniterNoPhp4. [...] With only a handful of significant changes to its codebase, the release was pushed along. We want to make CI 2 worth its name, so starting today, we're requiring PHP 5.1.6 on our master branch.

They include a few things to watch out for including naming conventions, the change to __construct, a cleaner model object interface and chaining added to the email and validation libraries.

According to a recent Twitter poll, we found that over 50% of developers are already working with the latest 5.3 release. An additional 35% is already in the process of migrating to 5.3. This means that the majority of developers see the importance of upgrading and are already taking action, well before PHP's announcement.

He talks about how common migrations like this are in the IT industry and how dealing with multiple releases can only cause more issues. He also mentions some of the keys to successful migrations like compatibility testing and checking of any custom code you might have implemented in your codebase.

n case you missed it, the PHP team has just released 5.2.14, which effectively ends active support for the 5.2 branch. [...] The logic behind this decision is...puzzling.

He mentions the recent announcements of a few large PHP-based projects to officially support PHP 5.2 and how, because of the large jump in functionality from pre-5.2, it might be a good idea to reconsider this (preemptive?) retirement. He adds that making a move like this without consideration to these larger products could reflect negatively on the language itself. Be sure to check out the comments for more views from other members of the community.

Our approach with WordPress has always been to make it run on common server configurations. We want users to have flexibility when choosing a host for their precious content. Because of this strategy, WordPress runs pretty much anywhere. Web hosting platforms, however, change over time, and we occasionally are able to reevaluate some of the requirements for running WordPress. Now is one of those times. You probably guessed it from the title '" we're finally ready to announce the end of support for PHP 4 and MySQL 4!

The last version that will fully support PHP4 will be v3.1 and will be released in late 2010. The next version (v3.2) will jump the requirement up to PHP 5.2. According to their statistics, only around 10% of the installs are on PHP4. They also found that less than 6% of users were on MySQL 4. See the full post for complete details.