The Master Zend Framework site has continued their series covering Composer and some more advanced concepts than just the usual introduction. In this new tutorial Matthew Setter shows you how to work with forked repositories.

Have you ever submitted a patch to a repository which your application relies on, but, because that patch is vital to the uptime of your application, you can’t wait for it to be reviewed and merged into the next release?

In times like these, it’s fair to want them to move faster than they normally would, so that you don’t have to wait for the normal review, merge, and release cycles. [...] But, you may urgently need the patch to be applied and released. So, what do you do? In times like these, you can use Composer’s ability to use custom repositories, specifically a fork which you create and patch.

If this sounds appealing to you — because perhaps you’re in this very situation right now — let’s now step through the process of modifying your composer.json configuration so that you can use one.

He walks through the Composer configuration you'll need to update to work with the forked repository as you'd expect. He also covers changes that would need to be made for working with private repositories and using local files instead of remote.

Nils Adermann has a new post looking at a problem with Composer where it will install a fork of a project rather than the actual project repository. He points out that it is not a security vulnerability in Composer itself, and is usually cause by using the configuration incorrectly.

Recently there has been an increase of cases in which Composer installs a fork of a package instead of the package the user expects. Most frequently these are forks of packages using a “replace” statement in their composer.json. These forks are usually meant for private use only but are still published on Packagist.

The issue stems from the use of "replace" and the publishing of those forked repositories in the Packagist service. "Replace" is meant to define a fork that is still compatible with the original project. The way that Composer handles finding the correct package to install can cause a conflict and the wrong package could end up "winning".

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.

Jonathan Hill has posted the video of his recent presentation at the Atlanta PHP User Group, "Multi-tasking in PHP".

When it comes to multi-tasking and interacting with the operating system, PHP is no lightweight. In this December 6, 2012 presentation Jonathon Hill (@compwright) explores PHP's little-known POSIX, Process Control, and Semaphore extensions and shows you how to introduce a parallel dimension to your applications.

His presentation covers the use of multi-tasking to accomplish some common tasks in PHP (like batch processing or creating daemons). He talks about multi-processing vs multi-threading, forking, race conditions and semaphores.

You can watch the video of the presentation over on Vimeo and check out the software and links to other resources mentioned in the talk in this link bundle.

So you've been working on your own code for a while now but have been hearing about Github and how it makes it simple to contribute to other projects too. Maybe you haven't found the time to get into git and Github yet. Well, this new post (a reprinted article from php|architect) to Lorna Mitchell's blog will tell you all you need to know.

Often I find absolutely competent programmers, who aren't involved in open source, either because they don't know how to approach a project, or because they just aren't sure how the process even works. In this article we'll look at one example, the conference feedback site joind.in, and how you can use GitHub to start contributing code to this project. Since so many projects are hosted on github, this will help you get started with other projects, too.

She covers all you'll need to know to get in and get going with Github - forking a current repo (she uses Joind.in as an example), cloning your fork, making updates and submitting them as a pull request back to the main project. There's also some things about general git topics like branching, merging from the upstream source and using "git log" to view the changes.

Mike Purcell has a recent post to his blog looking at the rumors of a Symfony 1.x fork and some of his own thoughts on the matter.

It’s amazing that we are even having this type of discussion. We opted to use Symfony back in 0.x for some high traffic projects. [...] And now here we are on 1.4. Content and happy with the throughput the dev team is able to maintain. But now Symonfy says that 2.0 will be released and is completely different than 1.x? How is that fair to the companies, individuals, and hobbyists who have sunk time over the last four years ramping up to a point where we can take advantage of RAD (rapid app development) approach that Symfony provides?

He wonders if this same discussion will be being had years down the line when Symfony3 decides to come up on the horizon. Will there be such a major change in the architecture that developers, only a few years earlier making the major change to to Symfony2, will get burnt again?

PHPClasses.org has posted the latest episode of their "Lately In PHP" podcast series, a look at the cloud hosting PHPFog now offers including an interview with Lucas Carlson, CEO of PHPFog.

On the Lately in PHP podcast episode 13, Manuel Lemos and Ernani Joppert interview Lucas Carlson, founder and CEO of PHPFog, to tell us about the advantages of using a Cloud Hosting service that is optimized to address needs that are specific to PHP Web sites and applications. They also comment on the PHP 5.3.6 forked version released by Robert Eisele and the PHP features being voted for inclusion in version 5.4.

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

In this new post to his blog, Christian wonders if forking the 1.x branch of Symfony to create a 1.5 version is a real possibility.

The idea of forking came up. But is this really going to happen? And does it make any sense at all? What would be the benefit of forking symfony 1.4 and continuing development of the 1.x branch?

He suggests that it might be worth it because the branch is currently stable, it has a proven track record, there's already several plugins available and there's a comfort level among developers using it. He still asks the "why?" question, though:

Not switching to Symfony2 would essentially mean that you accept these flaws [in 1.x]. Now even if I don’t agree I can not see a reason to argue against this. Being pragmatic is not a bad thing as such.

On the PHPClasses.org blog today Manuel Lemos gives his perspective on the recently announced PHP fork by Robert Eisele that has the community buzzing with comments from both sides of the fence.

A fork is a new version of a project that a separate group of developers that want to give the project a different route. A new PHP forked version was created by Robert Eisele to address needs that he felt were important.

He mentions the forked version as updated with the changes Robert wanted to see made and a few other concerns that have come from it. One issue is the PHP name and licensing problems and another is whether or not you should use this fork (and what its future might be).

Robert Eisele has a new post (and some new source) on his blog today that has gotten the PHP community both up in arms and excited about the potential it offers - a fork of PHP that's been modified to include lots of little improvements for changes in performance, some new PHP functions, usability improvements and changes in the MySQLi/mysqlnd drivers.

It took me a while but here's a new toy. Today I publish my own PHP fork based on the PHP 5.3.6 code base with a few changes that make the everydays developer life more bearable. It includes some of the patches I've already published about 3 years ago, my defcon extension and also my infusion extension plus a good bunch of extra gimmickries.

Updates in his release available on github) include:

• Hardcoded constants
• Turn off $_REQUEST variable if it's not needed
• new methods like str_random, ob_fwrite, sigfig and strcal
• changes in foreach, strstr and binary number handling
• updates to MySQLi/mysqlnd to return matched rows and mysqi_return

The community reaction to this fork has been divided - some think the work put into these changes should have been submitted to the main PHP project instead and others see it as a good step forward for the language. Share your thoughts by commenting on the post.