Because we're in full throes of Zend Framework 2.0 development, I find myself with a variety of PHP binaries floating around my system from both the PHP 5.2 and 5.3 release series. We're at a point now where I'm wanting to test migrating applications from ZF 1.X to 2.0 to se see what works and what doesn't. But that means I need more than one PHP binary enabled on my server...
I use Zend Server on my development box; it's easy to install, and uses my native Ubuntu update manager to get updates. On Ubuntu, it installs the Debian Apache2 packages, so I get the added bonus of familiarity with the configuration structure.
I installed Zend Server some time ago, so I'm still on a PHP 5.2 mod_php binary. I have several PHP 5.3 binaries compiled and installed locally for running unit tests and sample scripts already -- so the question was how to keep my 5.2 mod_php running while simultaneously allowing the ability to run selected vhosts in 5.3?
The answer can be summed up in one acronym: FastCGI.
When I was at Symfony Live this past February, I assisted Stefan Koopmanschap in a full-day workshop on integrating Zend Framework in Symfony applications. During that workshop, Stefan demonstrated creating Symfony "tasks". These are classes that tie in to the Symfony command-line tooling -- basically allowing you to tie in to the CLI tool in order to create cronjobs, migration scripts, etc.
Of course, Zend Framework has an analogue to Symfony tasks in the Zend_Tool component's "providers". In this post, I'll demonstrate how you can create a simple provider that will return the most recent entry from an RSS or Atom feed.
The past few months have kept myself and my team quite busy, as we've turned our attentions from maintenance of the Zend Framework 1.X series to Zend Framework 2.0. I've been fielding questions regularly about ZF2 lately, and felt it was time to talk about the roadmap for ZF2, what we've done so far, and how the community can help.
I've been hearing about and reading about Gearman for a couple years now, but, due to the nature of my work, it's never really been something I needed to investigate; when you're writing backend code, scalability is something you leave to the end-users, right?
Wrong! But perhaps an explanation is in order.
For the third year running, I'm pleased to be speaking at the Dutch PHP Conference, held again in Amsterdam this coming 10-12 of June.
I'll be speaking this year at TEK-X, this year's incarnation of the php|tek conference, in Chicago in May.
For the past month, I've been immersed in PHP 5.3 as I and my team have started work on Zend Framework 2.0. PHP 5.3 offers a slew of new language features, many of which were developed to assist framework and library developers. Most of the time, these features are straight-forward, and you can simply use them; in other cases, however, we've run into behaviors that were unexpected. This post will detail several of these, so you either don't run into the same issues -- or can capitalize on some of our discoveries.
One possibility presented to us was the possibility of utilizing GPG signing of commit messages. Unfortunately, I was able to find little to no information on the 'net about how this might be done, so I started to experiment with some solutions.
The approach I chose utilizes git
hooks, specifically the
commit-msg hook client-side,
pre-receive hook server-side.
Brandon Savage approached me with an interesting issue regarding ZF bootstrap resources, and accessing them in your action controllers. Basically, he'd like to see any resource initialized by the bootstrap immediately available as simply a public member of his action controller.
So, for instance, if you were using the "DB" resource in your application,
your controller could access it via
I see a number of questions regularly about module bootstraps in Zend Framework, and decided it was time to write a post about them finally.
In Zend Framework 1.8.0, we added
Zend_Application, which is
intended to (a) formalize the bootstrapping process, and (b) make it
re-usable. One aspect of it was to allow bootstrapping of individual
application modules -- which are discrete collections of controllers, views,
The most common question I get regarding module bootstraps is:
Why are all module bootstraps run on every request, and not just the one for the requested module?
To answer that question, first I need to provide some background.