This is the final part of our ‘Hello World’ series. In ‘Hello World Part 2’ we created the Controller, Module classes and set up the module configuration with the ‘ServiceManager’ and the autoloading. Now it’s time to add the views so we can see some results for this. Remember we set up the ‘ViewManager’  in the module configuration, in our ‘template_map’ we made reference to four view scripts now we will create those view files.

View Scripts

OK fist make the directories we need:

First lets make the first view script we need which is the ‘indexAction’ script called (wonderfully) ‘index.phtml’. This will be render when we access the ‘home’ route.

And then add this HTML code to it.

Now for the error view scrips, first the 404 error

and add this code to it

I am not going to get into detail what this script is doing as it just prints out the route error and any exceptions that were thrown. you may of noticed we also make a call to $this->escapeHtml() whenever we print out a string we want to make sure it’s clean so we pass it through the view helper called ‘escapeHtml’ (for all available view helper see here).

Our index error page is also similar so let make it now.

and put this in it:

So with our error scripts done, it’s time for our last view script, the layout script will render our main layout.

and put this into it:

Here again we are using view helpers, so what are these helpers, well this is how Zend Framework put it

In your view scripts, often it is necessary to perform certain complex functions over and over: e.g., formatting a date, generating form elements, or displaying action links. You can use helper, or plugin, classes to perform these behaviors for you.

A helper is simply a class that implements Zend\View\Helper\HelperInterface and it simply defines two methods, setView(), which accepts a Zend\View\Renderer\RendererInterface instance/implementation, and getView(), used to retrieve that instance. Zend\View\Renderer\PhpRenderer composes a plugin manager, allowing you to retrieve helpers, and also provides some method overloading capabilities that allow proxying method calls to helpers.

For more info on view helper see here helpers we are using are listed below with a short description taken from the Zend Framework manual, you can click on each description to read more about each helper.


Valid HTML and XHTML documents should include a DOCTYPE declaration. Besides being difficult to remember,
these can also affect how certain elements in your document should be rendered (for instance, CDATA escaping in
<script> and <style> elements).


The HTML <title> element is used to provide a title for an HTML document. The HeadTitle helper allows you to programmatically create and store the title for later retrieval and output.


The HTML <meta> element is used to provide meta information about your HTML document – typically keywords, document character set, caching pragmas, etc. Meta tags may be either of the ‘http-equiv’ or ‘name’ types, must contain a ‘content’ attribute, and can also have either of the ‘lang’ or ‘scheme’ modifier attributes.


The HTML <link> element is increasingly used for linking a variety of resources for your site: stylesheets, feeds, favicons, trackbacks, and more. The HeadLink helper provides a simple interface for creating and aggregating these elements for later retrieval and output in your layout script.


While most URLs generated by the framework have the base URL prepended automatically, developers will need to prepend the base URL to their own URLs (usually inside an href attribute) in order for paths to resources to be correct.


The HTML <script> element is used to either provide inline client-side scripting elements or link to a remote resource containing client-side scripting code. The HeadScript helper allows you to manage both.


The URL view helper is used to create a string representation of the routes that you define within your application.


The Navigation helper is a proxy helper that relays calls to other navigational helpers. It can be considered an entry point to all navigation-related view tasks. The aforementioned navigational helpers are in the namespace Zend\View\Helper\Navigation, and would thus require the path Zend/View/Helper/Navigation to be added as a helper path to the view. With the proxy helper residing in the Zend\View\Helper namespace, it will always be available, without the need to add any helper paths to the view.


The Menu helper is used for rendering menus from navigation containers. By default, the menu will be rendered using HTML UL and LI tags, but the helper also allows using a partial view script.

So this is what we have done in our layout script:

Line 1: Here we just print out the correct DOCTYPE, remember we declared this in our module config under the ‘view_manager’ key.

Line 6: We are using the ‘HeadTitle’ helper here, first we set the global title, then set our separator which will be use if we append another title (e.g. we could put <?php $this->headTitle('Welcome');?> in our ‘application/index/index.phtml’ script and the title in the web browser would be ‘Zf2 Tutorial – Welcome’), then we have set the ‘autoEscape’ to false so all our titles we pass in are not automatically passed through the escape helper.

Line 8: We have used the ‘HeadMeta’ helper here, we would use this helper to set the ‘metatagsi’ of our page, in my example I have hardcoded the tag but we could make this dynamic a good example are page keywords and description where we would set this via our view script that is called by our controller action. In our next module you will see this in action.

Lines 12-16: We are using the ‘HeadLink’ just to append our stylesheets (or course we could add a favicon here as well), I have used the ‘appendStylesheet’ method of the helper (check the docs for the different ones), if we use the ‘append’ method then we will have to order our stylesheets in the correct order  that being the overriding ones come last. You can see we are using the Twitter Bootstrap here as this is a quick way to prototype our layout also I am using the official CDN of Bootstraps so I don’t have to mess around with downloading the correct files, I have also included the Font Awesome file too.

Line 16: On this line we are importing the site style sheet, you may have notice I have wrapped the location in the ‘BasePath’ helper, the ‘basePath’ will resolve to our ‘public’ folder. We will create the CSS file called ‘styles.css’ shortly.

Lines 19-21: the ‘HeadScript’ helper is like the ‘HeadLink’ but is used for appending our JavaScript files and we use the ‘appendFile’ method to do this. Here again you can see I have chosen to use the CDN urls for JQuery and Twitter Bootstrap, but you could use local files if you wish.

Line 34: In this HTML link we have used the ‘Url’ helper to output the correct url, This helpers first argument is the route name we want, remember in part 2 we set up our ‘home’ route well if you we then do <?=$this->url('home')?> then the outputted code will corraspond to our route setup in this case the result will be, again this is a powerful helper and we will see it in action soon.

Line 37: This line output our menu, we set up our navigation in our ‘module.config.php’ file and this helper will output that. First we are passing a string called ‘Navigation’ and is called a container, containers hold all the pages for a given menu set and will have to tell the ‘ServiceManager’ about it we will do that in a minute. Then ask call for the menu type, which is just ‘menu’ then we set its ‘ul’ class as Twitter Bootstrap requires a class of ‘nav navbar-nav’ so that is what we put.

Line 44: this is how we output our content for the layout, not much else to say about that.

OK with that done lets tell the ‘ServiceManager’ about our navigation so:

and add this to the ‘service_manager’ key:

Here we are adding a ‘factories’ key to the ‘ServiceManager’ with a key called ‘Navigation’ (this is what we put in our navigation helper), and told the ‘ServiceManager’ to use  the ‘Zend\Navigation\Service\DefaultNavigationFactory’ to build our menu, remember on line 20 of ‘module/Application/config/module.config.php’ we put our menu in an array called ‘default’ well this class will look for that and use the values it finds there to build the menu.

so ‘config/application.config.php’ should look like this now:

Now all we have to do is create our ‘styles.css’ file so

and now for the file

and put this in it

And that should be all for our ‘Hello World’ app, we are ready to test it ‘hip, hip, hip hooray’ I hear you cry.

Time to test

As we have not installed a web server to test our app we will use the build in web server that ships with PHP 5.4, we will have to change our directory to the ‘public’ folder of our app

now we type a php-cli command to start the server, if you are using a virtual machine use its ip, but if you are doing this on your local machine then use ‘localhost’ so my ip is ‘’ so i would use php -S ./index.php but if you are using your local machine use php -S localhost:8080 ./index.php this server cannot use port 80 so we are using port 8080.

This server is for testing on development machine only and should not be used for product cases at all.

When you have entered the command you should see something like

Now you can use your web browser to access your zf2 app. You see where the output say ‘Listening on …’ well that url is what is put in your web browser and the you should see



If you only see a blank page then something went wrong, you should see any error messages in the terminal window.

I hope you enjoyed this simple look into Zend Framework 2 and for our next series we shall start adding to our app to make an article module that will create pages that we can edit, add and delete.

Please feel free to ask questions or just comment.

  • Jason

    I am new to zend framework 2, i followed the step in creating the hello world application using zend framework2. however i get a blank page. May i know how can i troubleshoot? Because right now i cant find any error reporting. I am using window 7, with php5.6 and apache 2_4.

    • if using apache errors should be in the error log, or you could put
      ini_set('display_errors', true);
      at the top of your index page and that should show your error.

      A blank page means that you made a typo, there was a parse error or an exception was thrown.

  • Il y’a une erreur dans 404.phtml. Apache renvoie:
    PHP Parse error: syntax error, unexpected end of file in 404.phtml on line 100

    • Shaun Freeman

      Thanks for that. I have updated the code in the examples that causes the parse error.