In this new post to the PHPClasses.org blog Manuel Lemos talks some about the recent introduction of PHP into Google's App Engine offerings.

During Google I/O 2013 event a Google manager said PHP runs on 75% of the Web sites. So they decided to finally support PHP as in their AppEngine hosting service. Read this article to understand why this puts an end to years of false claims that PHP was losing market, as well what it means to Web developers using PHP or other languages.

He looks at the App Engine PHP offering and looks at whether or not its a good platform to use for hosting your application. He points out some advantages and disadvantages (including no local file system access and no remote resource access). He also includes five reasons why the "web platform war is over" and why PHP has come out victorious:

• Google Knows Because They Crawl the Whole Web
• Google Does Not Influence Web Developers so much
• Wordpress is the Dominant Blog Platform (not Blogger)
• Programming Does Not Have to Be Beautiful
• PHP Detractors Have the Wrong Focus

He admits, though, that PHP may not be dominant forever - it's not perfect, but there will always be a need for something that does what it can do (and does it well).

On the Google Developers Blog (and lots of places across the web) there's a major update that Google has done for their AppEngine service - the introduction of a PHP runtime to their offerings.

App Engine 1.8.0 is now available and includes a Limited Preview of the PHP runtime - your top requested feature. We're bringing one of the most popular web programming languages to App Engine so that you can run open source apps like Wordpress. It also offers deep integration with other parts of Cloud Platform including Google Cloud SQL and Cloud Storage.

You can get more information about how to use this new feature on Google App Engine site.

In a new post to her site Francesca Krihely starts looking at the developer experience - how developers relate to your service and product and what kinds of things you need to be doing to help engage them.

I had a great brainstorm a few weeks back with the members of the Developer Evangelists meetup on the topic of the User Journey, or as I'll call it now, the Developer Experience. The main problem we wanted to solve was how we convert new users into experts or awesoms users. In many ways, a Community Manager and/or Developer Evangelist is responsible for driving user adoption and making users successful, so this is a topic near and dear to all of our hearts. I walked away with three key things that help improve the developer experience: Great Product, Great Support and Empowerment.

This post talks about the first point - the "great product" - and notes that, if the product isn't useful and enjoyable to use, even developers won't bother with it. She also talks some about the need for quality documentation and how it can be seen as a sort of "marketing" to developers.

Work on making your product fit for an awesome developer experience. If you build it, they will come.

A discussion has started up on Reddit.com about the request for a "$_PUT" superglobal to match the already existing "$_POST" and "$_GET" (as is mentioned in this bug).

Data that is posted to PHP via the PUT method is not parsed at all and is not available to PHP. This is particularly problematic for data sent encoded as 'multipart/form-data'. [...] This is something that would help every RESTful interface that people are trying to do with PHP. There are many people who have these problems and have to implement (usually incomplete and/or buggy) PHP solutions.

In the Reddit post there's a mixed set of opinions - some say that things work well enough as is (content pulled from the raw stream) and others say that adding something like this makes the HTTP support more complete and functional.

Without a doubt, two of the most popular PHP-based projects out there are WordPress and Joomla. In this new post from SitePoint they compare the two on the basis of both their support and community (part 4 of a 5 part series).

Let's face it, an open-source content management system without a thorough user base, support system and community is destined for failure. We are comparing two giants in the CMS game here, so we already know they must be doing many things right in these departments. In this part of our series, we're going to be covering exactly what Joomla and WordPress have to offer when it comes to the support community.

Their comparison includes things like: WordPress.org vs Joomla.org, their respective support forums, other initiatives surrounding them and places you can find others to help you in your WordPress or Joomla work.

In this new post to his blog Phil Sturgeon talks about what he (and apparently several others) think is the "way forward for PHP" to make it a better language and ecosystem - packages.

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.

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.