Nicolas Grekas has shared another tool that he's pulled out of his "Patchwork" framework to make it a stand-alone tool: the Patchwork-UTF8 helper that provides matching functions to those PHP already has for regular strings, but a little smarter to work with UTF8 correctly.

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).

On PHPMaster.com there's a new post by Michelle Sanver about The PHP People, a.k.a the PHP community, and some of the great resources you can use to get help on a problem or just reach out and meet some other PHP-ers in your area (or at a national conference!)

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.

In a new post to DZone.com Mitchell Pronschinske looks at closure object binding in PHP 5.4 applications (yes, we know PHP 5.4 isn't released yet). He explains what this is an shows some sample use cases for you to consider in your development.

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.

On the Agile Toolkit blog today there's and interesting article with a slightly misleading title - "How to Earn Money with Open Source?" It talks less about strategies of how to monetize your open source project and more about how other projects are doing it and why a good core team is important.

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.

On CodeIgniter.com there's a new post updating the community on more of the current happenings surrounding the project including the status of their move to github and another source for developers to find the CI help they need.

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

According to a new post to the CodeIgniter.com blog, there's been even more changes in the 2.0 version of the framework - including dropping PHP4 support all together.

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.

On the Ibuildings blog today Andy Thompson has a new post looking at some of the challenges of migrating PHP applications up from the now end-of-development-life PHP 5.2.x versions up to PHP 5.3.

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.

In a new post to his blog Marco Tabini has voiced his opinion on the decision made by the PHP development group to set the end of life of the PHP 5.2.x series with the latest release (5.2.14).

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.

There's some huge news from the WordPress blog today - an end of life announcement that the popular blogging platform will no longer be supporting PHP4 and MySQL 4.

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.

On the php|architect blog today Giorgio Sironi takes a look at the state of PHP 5.3 support both on the developer and on the server side and how well it's being adopted.

PHP 5.3 introduced namespaces and anonymous functions to the PHP world, which are surely great innovations for this programming language. For PHP 5.3 to be widely used, however, it needs to be supported by the various operating systems installed on development boxes and servers.

He talks about the three major platforms when it comes to web development and serving - Linux, Windows and OS X - and how easy it is to get this latest version of PHP up and running on each. He also briefly touches on the differences in adoption from the two halves of the development process - desktop versus server.