Category: Zend Framework 1

Inserting binary data into SQL Server with ZF1 & PHP 7

If you want to insert binary data into SQL Server in Zend Framework 1 then you probably used the trick of setting an array as the parameter's value with the info required by the sqlsrv driver as noted in Some notes on SQL Server blobs with sqlsrv.

Essentially you do this;

Where $db is an instance of Zend_Db_Adapter_Sqlsrv.

If you use SQL Server with ZF1 and happen to have updated to PHP 7, then you may have found that you get this error:

(At least, that's what happened to me!)

Working through the problem, I discovered that this is due to Zend_Db_Statement_Sqlsrv converting the $params array to references with this code:

The Sqlsrv driver (v4) for PHP 7 does not like this!

As Zend Framework 1 is EOL, we can't get a fix into upstream and update the new release, so we have to write our solution.

We want to override Zend_Db_Statement_Sqlsrv::_execute() with our own code. To do this we firstly need to override Zend_Db_Adapter_Sqlsrv. (Also, let's assume we already have a App directory registered with the autoloader)

Firstly our adapter:


This class simply changes the default statement class to our new one. Now, we can write our Statement class:


This class, takes the _execute() method from Zend_Db_Statement_Sqlsrv and makes the necessary changes the section that creates parameter references. Specifically, we only create a reference if the parameter has a direction of SQLSRV_PARAM_OUT or SQLSRV_PARAM_INOUT:

Finally, we need to register our new adapter with Zend_Application's Database resource. This is done in the config file:


That's it.

We can now insert binary data into our SQL Server database from PHP 7 using the latest sqlsrv drivers.

Zend Framework 1 is not dead; ensure you upgrade!

I'm delighted to announce that Zend Framework 1.12.1 has been released! This release fixes 50 issues which is a great result. I'd like to thank everyone who submitted a patch to ZF1 and to Matthew Weier O'Phinney, Frank Brückner and Mike Willibanks in particular for their work on this release.

There's a few important things to note:

  • There's a security fix in 1.12.1. Please read ZF2012-05 if you use Zend_Feed_Rss or Zend_Feed_Atom.
  • The minimum PHP version for ZF 1.12.0 and ZF 1.11.12 is 5.2.11 due to security fixes for ZF2012-03.
  • Zend_Markup_Parser_Textile has been removed from 1.12.1 as it was significantly broken.

As I said in the title of this post, ZF1 isn't dead: we have committed to supporting it until at least 2014 so we will have more releases as required either due to security issues found or because we've accumulated enough bug fixes in the codebase. With that in mind, please continue to raise issues on the issue tracker if you find any issues in 1.12.1. We'd also appreciate your patches if you can fix any of the issues! I'm on IRC if you want any help (Akrabat in the channel on Freenode).

ZF1.12 is released

I'm extremely happy to note that Zend Framework 1.12 has been released and is available here.

The key changes are:

  • ZF2's StandardAutoloader and ClassMapAutoloader have been back ported to Zend_Loader.
  • ZF2's EventManager has been back ported to Zend_EventManager
  • New Zend_Http_UserAgent_Features_Adapter_Browscap component
  • New Zend_Mobile_Push component, contributed by Mike Willibanks
  • New Zend_Gdata_Analytics component, contributed by Daniel hartmann
  • Zend_Http_UserAgent_Features_Adapter_Wurfl has been removed due to WURFL licensing changes
  • Many many bug fixes! See the changelog

Getting ZF1.12 out of the door took longer than I imagined when I took on the release management role. I'd particularly like to thank Matthew Weier O'Phinney, Enrico Zimuel, Ralph Schindler, Adam Lundrigan, Frank Brückner and Martin Hujer for their work on the code. I'd also like thank the many people who ran the ZF1 unit test suite for us too.

You should upgrade if you're using 1.10 or 1.11 as it should be hassle free!

Vagrant in Zend Framework 1

I recently added support for vagrant to the Zend Framework codebase to enable easier testing. I was motivated by some work the folks have done to get a working development environment for development using Vagrant.

Vagrant is a fantastic tool that enables you to manage and run virtual machines from the command line, including automatic provisioning of them using puppet or chef. The really cool thing about it however from my point of view is that vagrant automatically sets up the VM with a folder called /vagrant that holds the code on your local hard drive from where you started the VM. This means that you can continue to edit your code in your local editor/IDE and test it within the VM easily.

I highly recommend checking it out.

ZF1's Vagrant set up

The Vagrant set up for ZF1 is designed for testing ZF1 against multiple PHP versions. As such it sets up a simple Ubuntu VM with the required toolchain for compiling PHP and provides a script called which will download and build any PHP 5.2, 5.3 or 5.4 version that you are interested in. I based this script on information in Derick Rethans' excellent Multiple PHP versions set-up article.

One thing that I discovered was that by default, the VM cannot create symlinks in /vagrant. The way to solve this is to add the following to the Vagrantfile:

I chose to use puppet to install the required packages and created a simple default.pp configuration. I'm sure this isn't optimal, but it works :)

Running ZF1 unit tests

The process to set up ZF1 to run unit tests in a VM using PHPUnit 3.4, follow these steps:

1. Install requirements for running the VM:

2. Checkout the ZF1 repository:

3. Start the process by running Vagrant.

This will take a long while as it has to download a VM image and then provision it. Once it has finished, it will exit and leave you back at the command prompt.

4. SSH into the VM

Vagrant sets up key-less ssh connections to the VM that "just works" :)

5. Build a version of PHP.

This also takes a while as it compiles PHP for you! It also installs PHPUnit 3.4 as that's the version we need to unit test ZF1.

Each version of PHP that you compile is stored in /usr/local/php/{version number}. You can compile any version; I have 5.2.4, 5.2.12, 5.3.3 and 5.3.11 installed at the moment…

6. Select PHP to use:

pe is a handy shell function that Derick wrote that changes your PHP environment to whichever version your specify.

7. Run tests

Alternatively, you can run each component's tests individually:

Obviously, you repeat steps 5 through 7 for each version of PHP you want to test on.

To stop your Vagrant VM, exit the SSH shell and type vagrant halt or vagrant suspend. For more details on controlling your Vagrant VM, I recommend Lorna's article

Running unit tests on Zend Framework 1 is now considerably easier!

Unit testing Zend Framework 1

As part of our release process for Zend Framework 1.12, I've been working through the unit tests and running them on PHP 5.2.4 as it seems that recent changes weren't being tested with that version. This isn't totally surprising as Open Source contributors are, almost by definition, interested in new things and so are much more likely to be running PHP 5.4 rather than 5.2! This is, of course, a compelling reason for using continuous integration and I'm quite excited with Travis-CI and we are using it with ZF2.

Installing PHPUnit 3.4

The first challenge that I encountered was that ZF1's unit test are not compatible with PHPUnit 3.6. As there are over 14,000 ZF1 unit tests which have been written since 2006, there hasn't been much enthusiasm for rewriting them to be PHPUnit 3.6 compatible. (However, if someone wants to volunteer, please contact me!)

As I have PHPUnit 3.6 installed for testing other projects, I needed to install PHPUnit 3.4 side-by-side with version 3.6 This turns out to be relatively easy and has been documented by Christer Edvartsen in his article Running Multiple Versions of PHPUnit.

I ran into one problem with his instructions though and needed this code to be added to the top of phpunit:

Having done this though, PHPUnit 3.4 works correctly and we can run ZF1 unit tests.

Running the ZF1 unit tests

To run ZF1's unit tests, you first need to check out the code from the Subversion repository.

Due to the number of tests and the memory that they take up, you should run tests for each component individually.

The command to use is:


  • --stderr pipes PHPUnit's output to stderr which means that any tests that rely on header() will work. (i,e. don't test Zend_Session without it!)
  • -d memory_limit=-1 will turn off PHP's memory_limit setting. The ZF1 unit tests use a lot of memory, so this is easiest.
  • The tests rely on being set up correctly. This is done using AllTests.php so don't forget this. Tests will fail if you forget!

All that needs to happen now is that any failing tests are fixed!

One-to-many joins with Zend_Db_Table_Select

Let's say that you want to set up a one-to-many relationship between two tables: Artists and Albums because you've refactored my ZF1 tutorial.

Let's assume that an artist has many albums. These are the basic table definitions:

artists table: id, artist
albums table: id, artist_id, title

When you list the albums, you obviously want to see the artist name rather than the id, so clearly you use a join!

Assuming you're using Zend_Db_Table, the easiest way is to turn off the integrity check and do a join in a mapper or table method.

Something like this:

class AlbumTable extends Zend_Db_Table_Abstract
protected $_name = 'album';

public function fetchAllWithArtistName($order = array('title ASC'))
$select = $this->select();

$select->joinLeft('artist', 'album.artist_id =',
array('artist_name' => 'name'));

$rows = $this->fetchAll($select);
return $rows;


The row set returned will have all the columns from the albums table and one additional column called artist_name which is an alias of the name column from the artists table.

Zend_Config_Ini and a string

One thing that is different between Zend_Config_Xml and Zend_Config_Ini is that with Zend_Config_Xml you can pass in an XML string as the first parameter of the constructor and it will work. This doesn't work with Zend_Config_Ini as we use parse_ini_file() under the hood.

With PHP 5.3 however there is is a new function called parse_ini_string() which will allow us to load arbitrary ini string into Zend_Config objects. This can't go into Zend Framework 1 though due to our PHP 5.2.4 minimum version requirement.

As I needed this for a project, I extended Zend_Config_Ini to support this feature, which means simply overloading a single method

class App_Config_Ini extends Zend_Config_Ini
* Load the INI file from disk using parse_ini_file(). Use a private error
* handler to convert any loading errors into a Zend_Config_Exception
* @param string $filename
* @throws Zend_Config_Exception
* @return array
protected function _parseIniFile($filename)
set_error_handler(array($this, '_loadFileErrorHandler'));
if (substr($filename, -4) == '.ini') {
$iniArray = parse_ini_file($filename, true);
} else {
$iniArray = parse_ini_string($filename, true);

// Check if there was a error while loading file
if ($this->_loadFileErrorStr !== null) {
* @see Zend_Config_Exception
require_once 'Zend/Config/Exception.php';
throw new Zend_Config_Exception($this->_loadFileErrorStr);

return $iniArray;

The actual change is to see if the last 4 characters of the filename are ".ini" and if they aren't then use parse_ini_string() instead of parse_ini_file(). The rest of the code is just error handling.

This is one area where I really like it when a class implements methods that done just one thing.

Exploring Zend_Paginator

One area of displaying lists on web pages that I've generally disliked doing is pagination as it's a bit of a faff. Recently, I needed to do just this though as I couldn't delegate it as my colleague was too busy on other work. As a result, I thought that I should look into Zend_Paginator this time. Turns out that it's really easy to use and the documentation is great too.

The really useful thing about Zend_Paginator is that it uses adapters to collect its data. There are a variety of adapters, including array, dbSelect, dbTableSelect and iterator. The interesting ones for me being dbSelect and dbTableSelect as I use Zend_Db based data access layers.

This is how I used it with a Zend_Db based data mapper within TodoIt.

Setting up the paginator

My current method looks like this:
class Application_Model_TaskMapper
public function fetchOutstanding()
$db = $this->getDbAdapter();
$select = $db->select();
$select->where('date_completed IS NULL');
$select->order(array('due_date ASC', 'id DESC'));
$rows = $db->fetchAll($select);
foreach ($rows as $row) {
$task = new Application_Model_Task($row);
$tasks[] = $task;
return $tasks;

// etc

This is pretty standard code for a data mapper. We select the data from the database and convert it to an array of entities. For the paginator to do its stuff though, we have to pass it the select object so that it can set the limit() on the select object.

The code therefore becomes:
public function fetchOutstanding()
$db = $this->getDbAdapter();
$select = $db->select();
$select->where('date_completed IS NULL');
$select->order(array('date_completed DESC', 'id DESC'));

$adapter = new Zend_Paginator_Adapter_DbSelect($select);
$paginator = new Zend_Paginator($adapter);
return $paginator;

As you can see, we create an instance of Zend_Paginator_Adapter_DbSelect which takes the $select object and the instantiate a Zend_Paginator and return it. The Zend_Paginator object implements Interator, so you can use it exactly like an array in a foreach loop and hence, in theory, your view script doesn't need to change.

However, the code that consumes TaskMapper expects an array of Task objects, not an array of arrays. To tell the paginator to create our objects, we extend Zend_Paginator_Adapter_DbSelect and override getItems() like this:

class Application_Model_Paginator_TaskAdapter extends Zend_Paginator_Adapter_DbSelect
* Returns an array of items for a page.
* @param integer $offset Page offset
* @param integer $itemCountPerPage Number of items per page
* @return array
public function getItems($offset, $itemCountPerPage)
$rows = parent::getItems($offset, $itemCountPerPage);

$tasks = array();
foreach ($rows as $row) {
$task = new Application_Model_Task($row);
$tasks[] = $task;
return $tasks;

Here, we've used the entity-creation code that was in our original implementation of fetchOutstanding() and placed it in getItems().

Obviously we have to update fetchOutstanding() to use our new adapter, so we replace
$adapter = new Zend_Paginator_Adapter_DbSelect($select); with $adapter = new Application_Model_Paginator_TaskAdapter($select);

Now, when we iterate over the pagination object, we get instances of Task and all is well with the world.

Using the paginator

Now that we have a paginator in place, we need to use it. Specifically we need to tell the paginator which page number we want to view and how many items are on a page. Within TodoIt, this is done in the ServiceLayer object and looks something like this:

class Application_Service_TaskService
// ...

public function fetchOutstanding($page, $numberPerPage = 25)
$mapper = new Application_Model_TaskMapper();
$tasks = $mapper->fetchOutstanding();
return $tasks;

// ...

Clearly the $page parameter comes via the URL at some point, so the controller looks something like this:

class IndexController extends Zend_Controller_Action
public function indexAction()
$page = $this->_getParam('page', 1);

$taskService = new Application_Service_TaskService();
$this->view->outstandingTasks = $taskService->fetchOutstanding($page);

$messenger = $this->_helper->flashMessenger;
$this->view->messages = $messenger->getMessages();


and then the view uses a foreach as you'd expect.

Adding the paging controls

Finally, to complete a paged list, we have to provide the user a mechanism to select the next and previous pages along with maybe jumping to a specific page. This is done using a separate view script that you pass to the paginator. In your view script, you put something like:

<?php echo $this->paginationControl($this-> outstandingTasks,
'pagination_control.phtml'); ?>

The first parameter is your paginator object. The second is the 'scrolling style' to use. There are four choices documented in the manual: All, Elastic, Jumping and Sliding. Personally, I have chosen to not display the page numbers themselves, so it doesn't matter which one I pick. The last parameter is the partial view script that you want to be rendered. This allows you to have complete customisation of the HTML.

Here's what I'm using which is based heavily on and example in the documentation:
<?php if ($this->pageCount): ?>
<div class="pagination-control">
<!-- Previous page link -->
<?php if (isset($this->previous)): ?>
<a href="<?php echo $this->url(array('page' => $this->previous)); ?>">
</a> |
<?php else: ?>
<span class="disabled">&lt; Previous</span> |
<?php endif; ?>

<!-- Next page link -->
<?php if (isset($this->next)): ?>
<a href="<?php echo $this->url(array('page' => $this->next)); ?>">
Next &gt;
<?php else: ?>
<span class="disabled">Next &gt;</span>
<?php endif; ?>
<span class="pagecount">
Page <?php echo $this->current; ?> of <?php echo $this->pageCount; ?>
<?php endif; ?>

And that's it; I now have paginated tasks in TodoIt and as you can see, Zend_Paginator is very easy to use and, more importantly, simple to customise to your own needs.

A Zend Framwork compound form element for dates

A while ago I needed to ask a user for their date of birth on a Zend_Form. The design showed three separate select elements to do this:

Screen shot of a 3 select boxes for a date on a form

A little bit of googling found this site which has now unfortunately disappeared, so the code in this article owes a lot of the author of that article.

It turns out to be remarkably simple to create a single Zend Form element that is rendered as multiple form elements. We create an element object and a view helper object and we're done. Usage then looks like:

Obviously, this form lives in application/forms/Detail.php and is rendered as usual in a view script. In our form definition, we have added an element called 'date' and with the addition of the addPrefixPath call have told the form that in addition to using the standard Zend Framework form elements, also look in library/App/Form. (Incidentally, we can also now override any supplied form element by simply dropping a replacement into the libraryApp/Form folder.)

The date form element lives in library/App/Form/Element/Date.php as Zend_Form knows to look in a subfolder for App/Form called Elements for any element objects and will look in the Decorator/ sub folder for decorator objects.

The Date element looks like this:

There's quite a lot going on here, but it should be fairly clear. Firstly we specify the name of the view helper to use when rendering this element to be formDate which we will write. We know this element is going to consist of three select boxes and so these will end up being an array of posted data for day, month and year. As a result, we need to override isValid() to turn our array back into a string and then call up to the parent's isValid() in order to do the actual validation required. We also need to override getValue() in the same way to ensure that it is also a string. Again we call up to the parent's getValue() as that does filtering.

That's all there is to the element itself, so now we turn out attention to the view helper that will render the element. This lives in library/App/View/Helpers/FormDate.php and as per my view helpers post, we need to tell the view about that folder via application.ini:

autoloadernamespaces[] = "App_"
resources.view.helperPath.App_View_Helper = "App/View/Helper"

The formDate view helper code looks like this:

Again, there's a fair amount of code, but I expect that it's pretty self-explanatory. Essentially, we have a lot of set up in order to render three select boxes; one for the day, month and year. I decided to use month names but it's easy enough to change to numbers. In terms of configuration, you need to be able to specify the start and stop year numbers. These are then passed in as options when calling addElement.

That's about it. Two separate files is all you need to create a Zend_Form element object that is implemented via compound elements. It also follows that you can do the same for any other conceptual element that you want to be rendered as multiple elements in the page.

Zend Framework View Helpers

I can't seem to find an article here that consolidates my thoughts on Zend Framework's view helper system, so I thought I'd better correct that. Zend Framework's Zend_View component supports helper methods known as view helpers. They are used like this in a view script:

<?php echo $this->myHelper('myParam1'); ?>

Behind the scenes, this is implemented as a method within a class something like this:


class Zend_View_Helper_MyHelper extends Zend_View_Helper_Abstract
public function myHelper($myParam1)
$html = '';
// some logic that fills in $html.
return $html;

Note that by convention, view helpers return the string and then the view script echos it and the Zend_View_Helper_ section of the class name is known as the prefix.

A typical Zend Framework project using Zend_Application, such as that generated using the zf command line tool, will have a folder called helpers within the views folder for each module. There will also be a helpers folder within the layouts folder too. If you place your view helper in one of these helpers folders, then the prefix is Zend_View_Helper_.

We can also tell the view object about our own view helper folder. Typically this will live in the library/App/View/Helper/ folder and so, you probably want a prefix of App_View_Helper_. To do this, we simply add this line to application.ini:

resources.view.helperPath.App_View_Helper_ = "App/View/Helper/"

The view helper now lives in App/View/Helper/MyHelper.php and looks like this:


class App_View_Helper_MyHelper extends Zend_View_Helper_Abstract
public function myHelper($myParam1)
$html = '';
// some logic that fills in $html.
return $html;

Due to the way Zend Framework's plugin loader works, our view script doesn't change at all as the view object's plugin loader will look across all registered paths to find the view helper specified in the view script.

I tend to prefer using the App folder over the helpers folder within layouts as I like to have one place to go to for my "site-wide" classes and so my App folder contains front controller plugins, validators, filters, form elements as well.

As you have extended Zend_View_Helper_Abstract for creating your own helper, you have access to the view object itself too. This is helpful for accessing other view helpers, such as escape. My personal preference is for my view helpers to manage their own escaping as requires as that way I can include html tags within my helper.

For example, suppose we want to create a table from an array that looks like this:

$data = array();
$data[] = array('Name', 'Email');
$data[] = array('Alison', '');
$data[] = array('Bert', '');
$data[] = array('Charlie', '');

Our view script may look like this:

<?php echo $this->tabulate($this->data, array('class'=>'tabulated')); ?>

(assuming our designer wants a class name attached to the table for styling.)

The view helper itself would then look something like:


class App_View_Helper_Tabulate extends Zend_View_Helper_Abstract
public function tabulate ($data, $attribs = array())
$attribString = '';
foreach ($attribs as $key => $value) {
$attribString .= ' ' . $key .'="' . $value . '"';

$header = array_shift($data);
$html = "<table $attribString>\n<tr>\n";
foreach ($header as $cell) {
$escapedCell = $this->view->escape($cell);
$html .= "<th>$escapedCell</th>\n";
$html .= "</tr>\n";
foreach ($data as $row) {
$html .= "<tr>\n";
foreach ($row as $cell) {
$escapedCell = $this->view->escape($cell);
$html .= "<td>$escapedCell</td>\n";
$html .= "</tr>\n";

$html .= '</table>';
return $html;

As you can see, we cannot escape the output of the view helper, so the view helper has to do its own escaping via the view property.

If you end up using the same set of view helpers on each project you do, then consider putting then into a vendor library. This is the same concept as using the App folder, but you use a different name (I use Akrabat) and store them in a separate vcs repository. This allows you easy reuse. You add a new line to application.ini to pick them up:

resources.view.helperPath.Akrabat_View_Helper_ = "Akrabat/View/Helper/"

and you're done. Note that the order of the helperPath in application.ini is important. You want the vendor path before the App path so that you can override your vendor ones specifically within a project if you need to.

resources.view.helperPath.Akrabat_View_Helper_ = "Akrabat/View/Helper/"
resources.view.helperPath.App_View_Helper_ = "App/View/Helper/"

Plugin helper path order is one of the more frustrating things about the plugin loaders used within Zend Framework and affects form elements, validators, filters and view helpers to name but a few. So if you discover that a view helper isn't being called when you think it ought to be, then check that it's not being overridden further down the chain. You can of course use this to your advantage and override a default Zend Framework view helper by simply creating an App version with the same name.