ZF-3447: when using _forward() viewrenderer tries to render wrong script


When from module/oldController/oldAction

i try forwarding to


i get exception because $this->render('newAction'), results in trying to render script from


this happened to me in every ZF version i think.

forwarding between actions of the same controller and module would work fine.


I recreated this same issue. from controllerA->indexAction I _forward() to controllerB->testAction() and I get an exception because it is looking for controllerA->testAction.

Forgot to mention I am on version 1.5.1

I cannot reproduce this issue. I've tried both forwarding to actions in different controllers within the same module, as well as actions in different controllers in different modules; in each case, the appropriate view script was loaded.

My testbed:

// in application/default/controllers/TestController.php
class TestController extends Zend_Controller_Action
    public function localForwardAction
        return $this->_forward('from-forward', 'foo');

    public function remoteForwardAction
        return $this->_forward('from-forward', 'foo', 'bar');

// in application/default/controllers/FooController.php
class FooController extends Zend_Controller_Action
    public function fromForwardAction

// in application/bar/controllers/FooController.php
class Bar_FooController extends Zend_Controller_Action
    public function fromForwardAction

// in application/default/views/scripts/foo/from-forward.phtml

// in application/bar/views/scripts/foo/from-forward.phtml

I then visited /test/local-forward and /test/remote-forward, and received the appropriate view scripts in each instance.

If you can recreate the issue, please post a minimum necessary testbed so I can independently verify. Otherwise, I will mark this issue as 'Cannot Reproduce'.

Downgrading from Blocker to Major, as cannot reproduce.

Forgot to mention, this happens when you _forward() from either init() or __construct() in an action controller.

ok, ive nailed a problem a bit more,

when i forward from one action to another it works, but if in the action im forwarding from i want to render explictly this creates a problem:


when i have this in my action i end up with exception, if i dont render explictly the forwards seems to take place fine...

Has this issue been looked into more yet? If not, is it Ok for me to try to look at the code and post a patch?

Could anyone please attach some code by which this can be reproduced?

This happened to me when using the built-in ErrorController. For example, when EXCEPTION_NO_CONTROLLER is thrown in "somemodule", it gets routed to the ErrorController in the "default" module. When I then try to:

$errors = $this->_getParam('error_handler'); $this->_forward('index', 'index', $errors->request->getModuleName());

This actually seems to dispatch to the correct index action in index controller in the originating module. However, the view script is still pulled from the "default" module. When I look at the View object in the ViewRenderer, it has bot the paths configured:

Zend_View Object ( [_useViewStream:Zend_View:private] => 1 [_useStreamWrapper:Zend_View:private] => [_path:Zend_View_Abstract:private] => Array ( [script] => Array ( [0] => ..\application\modules\default\views\scripts\ [1] => ..\application\modules\group\views\scripts\ )

        [helper] => Array

        [filter] => Array


Naturally, the _script method in Zend_View_Abstract chooses the first path and the wrong script get rendered.

For my case the workaround was to:


in the ErrorController before forwarding to a different module. Seems to clear the script path stack. Without exploring the innards too much, it seems to me that when switching before modules, the ViewRenderer's View scriptPath stack is not correctly maintained.

Is this still an issue? If so, should it be rectified in ZF1 at this late stage in it's lifecycle? In any event, controller-view integration is being reworked in ZF2, so the same fix will likely not be necessary there.

Fixing this now may introduce a backwards-compatibility break. Closing as won't fix.