Skip to main content

Route default is not defined

Working this long with Zend Framework makes me do things that have become a real routine and I don't pay much attention to it. So when I just add few custom routes to my Zend Framework application, I don't make a big fuss out of it. But apparently people do struggle with it. They get messages like this:

Zend_Controller_Router_Exception: Route default is not defined

Apparently when you create custom routes, Zend Framework "forgets" about the default route, causing this error to appear.

To quickly resolve this issue, you just open up application/Bootstrap.php and add the following to your routines:

    protected function _initDefaultRoutes()
        $frontController = Zend_Controller_Front::getInstance();

If you already have routine for loading routes, just ensure you add the default routes!

    protected function _initRouteSetup()
        $frontController = Zend_Controller_Front::getInstance();
        $router = $frontController->getRouter();
        $config = new Zend_Config_Ini('/path/to/config.ini', APPLICATION_ENV);
        $router->addConfig($config, 'routes');

        // ensure you load the default routes as well!!!

With this blog article I hope to save a bunch of people a lot of time looking for an example and get on with building awesome applications.


  1. I can't remember if we really introduced that, as it would break BC. But usually, the default route was always added unless you explicitly disable it.

  2. Well, I can set up a test routine to prove this issue is genuine, but over the years I just adapted myself this habit of adding it specifically to the Bootstrap routine.

    Might be worth while to investigate further though…

  3. I would like to see your test code for this too. I have had to add default routes when I explicitly removed them... but by default, they are the first in the stack (last precedence) and any new routes you add act as FIFO stacked routes.


Post a Comment

Popular posts from this blog

PHP 7 and Apache on macOS Sierra

I posted several talks about compiling PHP from source, but everyone was trying to convince me that a package manager like Homebrew was a more convenient way to install. The purpose of Homebrew is simple: a package manager for macOS that will allow you to set up and install common packages easily and allows you to update frequently using simple commands. I used a clean installation of macOS Sierra to ensure all steps could be recorded and tested. In most cases you already have done work on your Mac, so chances are you can skip a few steps in this tutorial. APACHE AND PHP WITH HOMEBREW I’ve made this according to the installation instructions given on GetGrav. The installation procedures These installation procedures will set up your macOS Sierra with PHP 7.1 and Apache 2.4. Install Xcode command line tools (if not done yet)xcode-select --install Install Homebrew/usr/bin/ruby -e "$(curl -fsSL" Set up for in…

Sessions in PHP 7.1 and Redis

In case you have missed it, PHP 7.1.0 has been released recently. Now you can’t wait to upgrade your servers to the latest and greatest PHP version ever. But hold that thought a second… With PHP 7 lots of things have changed underneath the hood. But these changed features can also put unexpected challenges on your path. Our challenge One of these challenges that we faced was getting PHP 7.1 to play nice storing sessions in our Redis storage. In order to store sessions in Redis, we needed to install the Redis PHP extension that not only provides PHP functions for Redis, but also installs the PHP session handler for Redis. Because we upgraded our servers to PHP 7.1, we were looking to use the latest provided version for this Redis extension: redis-3.1.0. Once installed, we bumped against a nasty problem. Warning: session_start(): Failed to read session data: redis (path: tcp:// Searching the internet for this error, we didn’t got many hits that could point us into a dire…

Speeding up database calls with PDO and iterators

When you review lots of code, you often wonder why things were written the way they were. Especially when making expensive calls to a database, I still see things that could and should be improved.
No framework development When working with a framework, mostly these database calls are optimized for the developer and abstract the complex logic to improve and optimize the retrieval and usage of data. But then developers need to build something without a framework and end up using the basics of PHP in a sub-optimal way.

$pdo = new \PDO( $config['db']['dsn'], $config['db']['username'], $config['db']['password'] ); $sql = 'SELECT * FROM `gen_contact` ORDER BY `contact_modified` DESC'; $stmt = $pdo->prepare($sql); $stmt->execute(); $data = $stmt->fetchAll(\PDO::FETCH_OBJ); echo 'Getting the contacts that changed the last 3 months' . PHP_EOL; foreach ($data as $row) { $dt = new \DateTime('2015-04-…