Phil Sturgeon has posted a guide to his site about running tests and contributing back to packages that live in Composer.

While Composer has been around for a while now, many packages are still in their infancy (< 1.0) or sometimes are just not as feature filled as they could be. To be fair there is always more to be done. It can always do more, or do the same thing more efficiently. Whatever the case, pull requests are going to be a common thing for the PHP community to be doing to these packages and this needs to be done safely, with unit-testing. So, how do you run their test suite and add your own tests?

He includes a step-by-step guide to getting the environment set up to run the package's tests and how to add some of your own. He includes the commands to send the pull request back up to Github (on your own fork, of course) and how to use that same fork as your package resource until the main project is updated.

7PHP.com has another community interview posted today - this time it's with Jakub Vrana, a co-author that works on the official PHP manual.

In this edition I talked with Jakub Vrana who is a co-author of The Official PHP Manual. Adminer and NotORM. I invite you to know him better and to learn from his 7php PHP interview.

The interview shares Jakub's answers about things like:

• His history as a PHP developer
• What he sees as good and bad parts of it
• His preferred tools
• His choices on frameworks and ORMs
• How to get started contributing to the documentation/manual
• Some about his book "1001 tips and tricks for PHP"

Stefan Koopmanschap, a speaker at the upcoming PHP North West Conference (in Manchester, UK the first part of October) is doing something interesting with a ticket he purchased - he's giving it back to the community and is taking nominations for the recipients.

It all started last year: I decided I wanted to go to PHPNW even if I wasn't accepted as a speaker. Being Dutch, I made sure to purchase my ticket for the conference during the blind bird period to save some money. But then I got accepted as a speaker. Part of the speaker package is a ticket to the conference, so I had this spare ticket. One option would be to get a refund. The PHPNW crew had no problem with this. But then I figured I could actually also try and do some good for the PHP community with the ticket. I'd spent the money already, why not use it for someone's benefit.

He wants to try to provide the same kind of experience and community interaction he did when he first got started with the language, so he's donating his ticket to PHPNW back to the cause. If there's someone you'd like to nominate for is ticket, send an email with their name, contact info and why you think they should be selected over to phpnw12@ingewikkeld.net. He'll select a winner on August 15th so they'll have plenty of time to make arrangements for travel and accommodations.

In response to some of the recent talk about the quality of PHP and some of the recent suggestions about the right and wrong ways to write PHP, the PHP The Right Way site has been lunched.

There's a lot of bad information on the Web (I'm looking at you, W3Schools) that leads new PHP users astray, propagating bad practices and bad code. This must stop. PHP: The Right Way is an easy-to-read, quick reference for PHP best practices, accepted coding standards, and links to authoritative tutorials around the Web. It is important to understand there is no canonical way to use PHP. That's the beauty of it. This website introduces new PHP developers to best practices, available options, and good information.

The site has some "getting started" tips for working with PHP 5.4, links to some of the current PSR standards and gets into some of the best practices for things like proper OOP structure, namespacing and using the SPL. There's also hints on using Composer for package management, working with databases and some basic parts on security and testing.

Additionally, the site is also an open source project so you can contribute your own content (it'll have to be approved before merging) on topics you might not see or want to improve.

As is mentioned by Matthew Weier O'Phinney (and expanded on by Robert Basic) beginning immediately, the Zend Framework 2 project will no longer require developers to sign a CLA before submitting their code.

In #zf2 news, effective immediately, we no longer require a CLA for #zf2 contributions. Let the pull requests flow!

Robert gives a bit more detail in his post, pointing out the official git repo, the issues list, section on the wiki and the mailing list/IRC meetings. There's also a blog to follow to get the latest updates for the project.

If you'd like to find out more about this new version of the framework, check out this video from ZendCon by Matthew.

Philip Olson has a (tongue-in-cheek) post to his blog today about how PHP can make the most of its popularity financially.

Today Rasmus mentioned that he received a $500 offer for the php.net domain name. Discussion ensued, which ultimately led to the indisputable belief that php.net is worth over 10 million US dollars. Therefore, let's think about this further...

He compares the worth of several popular languages (with a "reliable source") and does some math where PHP.net account holders would profit from the popularity over other languages. On a bit more serious note, though, he points out a few ways that you can contribute or get involved in the PHP project on several fronts:

• Help by editing documentation
• Sign up for a mailing list or three
• Get a SVN account and start contributing back to the code

On the Zend Developer Zone Cal Evans has posted some encouragement about sharing your own thoughts about the post from Dried Buytaert about the future of PHP and Drupal.

As Dries says in his blog:

It seems that we have arrived at a point in which there is a symbiotic relationship between PHP and the most popular PHP applications. A relationship that did not exist when PHP was created. Symbiotic relationships are obligatory: we depend entirely on each other for survival. And yet, I feel like we've been living apart. It makes sense for us (i.e, application developers) to contribute to the development of PHP, and for the PHP core developers to work more closely with the developers of the most popular PHP applications.

He points out that, in Acquia's case, there's just not enough time for the group to contribute back to the PHP project. Other posts surrounding this same discussion have also noted that there's not a good mechanism for people to "give back" to the PHP project and that getting involved requires a certain skillset that lots of developers don't have.

If you've been looking to get involved in the Zend Framework project but haven't known where to get started, Matthew Weier O'Phinney has just to guide for you. It gives you the "short and sweet" things you'll need to know about contributing back to the project.

ZF2 development is ramping up. We've been at it for some time now, but mostly taking care of infrastructure: converting to namespaces, re-working our exception strategy, improving our test suites, and improving our autoloading and plugin loading strategies to be more performant and flexible. Today, we're actively working on the MVC milestone, which we expect to be one of the last major pieces necessary for developers to start developing on top of ZF2. A question I receive often is: "How can I contribute to ZF2?" Consider this your guide.

He talks about what you'll need to get started (including getting a CLA) and includes a few links to some resources to help you get the code you'll need and find some bugs to fix (or file one yourself). He also talks about the details of the project (like naming conventions), where it stands now and what sorts of things you can get started doing right away.

Till Klampaeckel has posted a few suggestions for you if you'd like the take the reigns of a PEAR package when it's not maintained.

One of the more frequent questions I see on the mailing lists and IRC is, "How do I take over a package?". Very often people start to use a PEAR package and then at some point encounter either a bug or they miss a certain feature. The package's state however is inactive or flat unmaintained.

He recommends a few different courses of action - first asking if there's a way to help out, then stepping it up and pushing the fixes in yourself and, finally, deciding if you really do want to maintain the package (and show it by contributing).

If you've been looking for an open source project to get involved with and have thought about one of the many PHP frameworks out there as a viable option, you should take a look at Phil Sturgeon's guide to getting involved with CodeIgniter and some of the recent major changes the project's seen.

Now that CodeIgniter (Reactor) 2.0 is out people are starting to get involved, which is great. [...] what makes Reactor so much more different than CodeIgniter has been in the past? Well that is easy, anyone can be involved whether you are a hard-core developer who is happy to jump into the codebase and start changing things and adding features, or a new user who just wants to request some new features, you can do this on the UserVoice.

He talks about some of the things you can expect from the Engineers (the team heading up the development of the Reactor branch) and some of the things you can do with your code contribution to help it get accepted more readily.