ZF-3543: Naming conflict when overriding Zend_View_Helpers


I created an App_View_Helper_Url for my project. Everything works fine, as long as no class with the name Zend_View_Helper_Url is loaded. But when that is the case, Zend_View_Helper_Url is used prefered over App_View_Helper_Url. That has the following reason:

The last search path for view helpers is "library/Zend/View/Helper", with prefix "Zend_View_Helper_". When adding your own library directory as helper path, it right comes before that one, in my case as "library/App/View/Helper" with prefix "App_View_Helper_". So far, everything is fine, and now comes the bad part:

addBasePath() of Zend_View is called by the ViewRenderer Action Helper. It adds "$module/views/helpers" with the prefix "Zend_View_Helper_" as very first option to choose view helpers.

Now when somewhere library/Zend/view/Helper/Url.php was loaded, Zend_View loops through the $_path['helper'], and first finds the helpers directory of the view, and checks "if (class_exists('Zend_View_Helper_Url'..." which is the case, even if that one has nothign to do with the module view helpers.

The really best and cleanest solution for this problem would be, to give the filters and helpers of $modules another prefix by default, like "Custom_View_" or such. I know that would mean a BC break, but every other solution would imho be a bad hack.

My personal workaround in my running project was to extend Zend_View and remove adding of module specific helpers and filters, as I don't need them yet, but that is really no fine way.


Wouldn't it be easier for you just to change the name of you helper from App_View_Helper_Url to something else, maybe App_View_Helper_Uri or App_View_Helper_Link, ... ?

It would just be a workaround, but no fix for the bug.

RE: Goran Juric

If you name it App_View_Helper_Uri and ZF gets Zend_View_Helper_Uri, you're forced to rename your helper again.

I'm not a huge fan of the way helpers are handled, since I've seen a few conflicts similar to this.

This flaw in the design will be addressed in 2.0