Zend_Form and Zend_Loader_PluginLoader SNAFU

I’ve spoken on this blog before about scaling Zend_Form for larger forms by having it use a central set of plugin loaders for all elements contained within a form, rather than allowing each element to implicitly create its own instances. Another way to accomplish the same goal is to have form elements use the same loaders that the form has already created for itself.


class FastloadingForm extends Zend_Form
    public function addElement($element, $name = null, $options = null)
        if (!is_array($options)) {
            $options = array();

        // A plugin loader is implicitly created if default decorators are loaded
        $options['disableLoadDefaultDecorators'] = true;

        // Add the element to the form
        parent::addElement($element, $name, $options);

        // Configure the element to use the form's plugin loaders
        $element = $this->getElement($name);
        foreach ($this->_loaders as $type => $loader) {
            if ($type != 'ELEMENT') {
                $element->setPluginLoader($loader, $type);

        // Now load default decorators for the element

        return $this;

However, this approach can cause an issue if subforms are being used because of a bug in Zend_Loader_PluginLoader.

The bug entails Zend_Loader_PluginLoader allowing multiple instances of the same path to be added per prefix. This becomes an issue because of how Zend_Form handles adding subforms: it automatically calls addPrefixPath() on the subform for each path contained in each of the form’s own plugin loaders. If both the form and subform are using the same plugin loaders, the bug causes the same paths to be added multiple times. When plugins are subsequently loaded, the duplicate paths are all searched individually, creating a bottleneck as more subforms are added.

The issue in the JIRA bug tracker for ZF has patches for both the issue itself and the unit test suite for the Zend_Loader_PluginLoader component. Please view the bug report and vote to ensure that the issue receives attention and is fixed in a release in the near future.


  1. Matthew Turland’s Blog: Zend_Form and Zend_Loader_PluginLoader SNAFU | Cole Design Studios says:

    … Matthew Turland’s Blog: Zend_Form and Zend_Loader_PluginLoader SNAFU Matthew Turland has ammended a previous technique he suggested about using a centralized set of plugin loaders for Zend_Form elements (part of the

  2. Kiran says:

    can you please give some brief on addPrefixPath()

  3. admin says:

    @Kiran Not sure I understand your question. addPrefixPath() is a method of Zend_Form. It’s used to add custom paths to class files and class name prefixes for the classes contained within those files for form components like elements, decorators, and so on. The issue I describe above is how the list of path-class name prefix pairs is not kept unique.