There's really no such thing as "module-specific" anything in ZF2, so what we're really talking about is the topmost namespace of the controller being dispatched. So in the case of MyModuleControllerSomeController, the topmost namespace would be MyModle. In most cases, this will be the name of a given module.

He gives a quick piece of sample code showing a "Module" class that attaches an event on the dispatch of its request. Inside this event, he grabs the controller (target) and updates the layout via a call to the "layout" method. This is all handled in the "init" method of the module, so it should "just work" when the module is used.

With the recently released PHP 5.4, the Suhosin patch and extension were removed from many Linux distribution packages (i.e., Debian et al.) and until three weeks ago, there was no possibility to compile and run the Suhosin extension under PHP 5.4. This little howto shall serve as installation instruction for Debian Wheezy users - your mileage may vary. I blogged about this here.

They start with the apt-get commands to install the latest PHP5 for your distribution (yum commands are similar, of course) and includes the location to download the latest Suhosin version from Stefan Esser's github account. Unpack it, compile and "phpize" it and if all goes well, you should have a shared module built and ready for use.

With the new modular infrastructure in Zend Framework 2, one of the most common questions will indoubitably be how to share a database connection across modules. Here's a quick explanation of how to share your database connection across multiple modules in a way that can even allow you to use a single connection between ZendDb, Doctrine2, and possibly even other database libraries / ORMs.

He includes the code in the post to configure this application-wide database resource, a "masterdb_pdo" that uses a MySQL backend. This configuration is used to set up the connection in a dependency injection container for later (globalish) use. He also mentions something similar about sharing Doctrine connections with the ZendDb components (using the same DI container approach).

Why write something of my own? Well, of course, there's the fact that I'm a developer, and have control issues. Then there's also the fact that a blog is both a simple enough domain to allow easily experimenting with new technology and paradigms, while simultaneously providing a complex enough domain to expose non-trivial issues.

He realized that he wanted a platform that was not only something he wanted to maintain but that also allowed him to write how he wanted to write - no more in-browser editing, just working with text files and generated page output. He shares some of the thoughts behind the different parts of the blog software - the domain model, his PhlyBlog module and the updated code he used to override some of the functionality in this default module. He also describes his new blogging process which includes git branching, creating a PHP "post" file, regernerate the blog via a command-line tool and merge and deploy.

In a few rare cases this is not what people like, for that PHP introduced "persistent connections" of different kinds. Testing those is a bit annoying as you have to configure a webserver and ensure to hit the same instance over the course of a test and then use a load generator, probably one which can detect a failure. Additionally by having a webserver in the game there is more code being executed, which might mean an additional source for trouble while debugging. An alternative might be using FastCGI, while that adds it's own issues for such a test. To solve this for myself I, some time ago, wrote a PHP SAPI module called pconn and pushed it to github.

The extension provides a way to emulate requests by executing a script multiple times automatically, making it easier to test things that require checking against multiple things simultaneously. While the built-in webserver (PHP 5.4) can be used to test some of these things too, Johannes' extension can also be compiled to help with testing of threading in applications as well.

Unfortunately the Symfony documentation does not provide any details on how to configure Assetic to use LESS. There is a blog post by Dustin Dobervich that gives some pointers, but after following the instructions, Assetic issued the following error: Cannot find module 'less'. We searched around without much success. After several tries, we nailed the configuration.

It's an easy two-step process: first you be sure you have "npm" (the package manager) installed on your system, then you modify your Symfony app.yml file to point to the Node modules path.

Following on from the discussion on modules, we can hook into the event system to do module specific bootstrapping. By this, I mean, if you have some code that you want to run only if the action to be called is within this module, you can hook into the Application's dispatch event to achieve this.

He starts with an example of a basic module (Simple/Module.php) and shows how to define an "onBootstrap" method that calls the "onDispatch" method (when hooked to the event manager) to do some module-specific bootstrap operations. The RouteMatch feature is used to ensure that you're in the right controller/namespace combo to use the module.

A Zend Framework 2 application is made up of a number of modules which each contain the controllers, models, views and other support code required to implement a specific part of the application.

He covers a few different topics:

• where modules can be located
• the directory organization inside them
• setting up a module of your own (a "bare bones" example)
• how to use the init() method to set configure your module when it's loaded

A site has also been started (official) to share other user-created modules with the rest of the Zend Framework community - modules.zendframework.com.

Let's say that you install the ZF-Common's User module. By default, it sets up its routes under the /user path segment. [...] This config section will create the routes /user and through the magic of child_routes, also create /user/login and other required routes. If you don't want /user and would prefer /member, then it's easy enough to change. Just add a new config file to the project's config/autoload folder.

Code for the configuration files is included with the update to the "ZendMvcRouterRouteStack" to change the ZF-Common User module's setup to point to "/member" instead of "/user" when routed. You can find out more about the module system in ZF2 in the latest version of the manual.

During ZendCon this year, we released 2.0.0beta1 of Zend Framework. The key story in the release is the creation of a new MVC layer, and to sweeten the story, the addition of a modular application architecture. "Modular? What's that mean?" For ZF2, "modular" means that your application is built of one or more "modules". In a lexicon agreed upon during our IRC meetings, a module is a collection of code and other files that solves a specific atomic problem of the application or website.

He starts with a definition of a module as a reusable, self-contained object that can contain the code for one functional piece of the application (like a "forum" module or "blog" module). He gets more technical with a code-level module example structure and example code for setting up a "blog" module with autoloading and a little ACL. He includes the code you'll need to tell the module manager about the module and a few helpful tips/tricks he's found along the way.