Issues

ZF-2204: wrong stacking of plugins.

Description

It's description of Matthew Weier O'Phinney: "Let's say you have 3 plugins, one registered with no stackIndex, one with a stackIndex of 99, and another with one of 50. If you register another, it will get a stackIndex of 3, when it should get a stackIndex of 1. "


    public function registerPlugin(Zend_Controller_Plugin_Abstract $plugin, $stackIndex = null)
    {
        //code
        } else {
            $stackIndex = count($this->_plugins); // why?
            while (isset($this->_plugins[$stackIndex])) {
                ++$stackIndex;
            }
            $this->_plugins[$stackIndex] = $plugin;
        }
        //code
    }

Comments

Scheduling for 1.0.3

Postponing to 1.1.0. Right now, I can't figure out a way to do stack ordering that's (a) easily user manipulable (b) maintains reasonable internal index order when indices are automatically generated, and (c) retains backwards compatibility. When I can sit down with the code and ensure (c) in particular can be met, while meeting (a) and (b), we can proceed -- and that will need to wait for 1.1.0.

Attaching patch that fixes this bug.

This doesn't appear to have been fixed in 1.5.0. Please update if this is not correct.

Updating project management info.

Assigning to Ralph.

This actually works very similar to how php would increment stack index. Notice:


~/tmp$ cat php-array-indexes.php 
<?php

$stack = array();
$stack[-99] = 'foo';
$stack[-50] = 'bar';
$stack[] = 'baz';

var_dump($stack);

$stack[50] = 'bar2';
$stack[] = 'baz2';

var_dump($stack);
~/tmp$ php php-array-indexes.php 
array(3) {
  [-99]=>
  string(3) "foo"
  [-50]=>
  string(3) "bar"
  [0]=>
  string(3) "baz"
}
array(5) {
  [-99]=>
  string(3) "foo"
  [-50]=>
  string(3) "bar"
  [0]=>
  string(3) "baz"
  [50]=>
  string(4) "bar2"
  [51]=>
  string(4) "baz2"
}

In our case, the next number represents both the next available positive index AS WELL as the number (if none was provided) of the plugin that was pushed onto the stack. I think this behavior is correct. On the other hand, i think the actual index and top/bottom of the stack might need to be re-evaluated.