Matthew Weier O'Phinney has posted a guide to modules in ZF2 - some helpful hints to get you started writing modules for the Zend Framework 2 to fit into the new architecture.

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.

On PHPBuilder.com Jason Gilmore has posted a first peek at Zend Framework 2, an upcoming reworking of the popular framework with PHP 5.3-centric features.

Version 2.0 seeks to improve upon the current release in a number of ways, focusing on making it easier to get started using the framework, improving performance, and fully embracing the latest PHP language enhancements made available to version 5.3. [...] Although the official release won't be out for several more months, it never hurts to take an early look at what the future holds for a technology used by countless PHP developers around the globe. In this article I'll present a meandering introduction to the key version 2.0 features that I find particularly compelling.

He starts with a brief tutorial on getting the latest version of ZF2 from the git repository and creating basic project. The changes in the framework have fallen into a "rewrite only where it makes sense" mentality and changes have really only been made transparently to the backend or as new features/components like module management and Doctrine 2 integration. He also points out a few resources you can use to keep up to date on the latest from the framework including the changelog, mailing list and the ZF2 blog.

Pavel Shevaev has a quick new post to his blog showing how to get PHP-FPM to execute PHP scripts via a socket request.

We are using APC cache very heavily in our projects and during project deployment the cache must be flushed and warmed up. A common solution to warmup the APC cache is to fetch some special page via HTTP which does the job. The problem with this approach is that it's not reliable enough when PHP is served via several fastcgi back-ends.

To solve the problem, he uses a PHP-FPM module to work with the FastCGI socket and execute any file (as permissions allow, of course). In his case, he uses it to "warm up" his APC cache for the user. A code snippet is provided as an example.

RubySource.com has posted another in their "confessions of a converted PHP developer" series (more here) with a new article comparing namespacing between the two languages.

The moment you start writing code that grows beyond a few classes, you start to realise that you need a way to group files and logic. While this is easy to do, it can become quite difficult to ensure that you have class names that are unique and don't end up accidentally clashing with other classes in your own code, or classes in other people's code that you are using.

He talks about PHP's namespacing, a relatively recent addition, and how pre-5.3 "pseudo-namespacing" was done through class and directory names with autoloading. He compares this to Ruby's module support that provides a sort of built in namespacing support. He includes a multiple namespace Ruby example and shows how to nest modules for even more fine-grained separation.

Most of the time you spend using PECL modules, you'll either be upgrading or installing new ones. Occasionally, though, you might need to move the other direction and roll back to a previous version. This handy tip from Lorna Mitchell shows you the handy single-command method.

Recently I saw some weirdness in an existing application when I upgraded a PECL module that the application depended on. To figure out if that really was the problem, I wanted to downgrade the module to its previous version. There is no opposite command to "upgrade" but you can instruct pecl to install a specific version of a module, using the -f switch to force pecl to overwrite newer modules.

In her case, she needed to downgrade the pecl_oauth package to 1.0.0 from 1.1.0. The trick lies in the "-f" switch for the "pecl install" allowing you to specify the version to install.

In a recent post to his blog Tom Van Herreweghe shares his method for running Zend Framework modules from a phar file, a simple archiving method native to PHP that makes it simpler to group and package related files.

Using Zend Framework as an MVC application is probably the most common usage examples for Zend Framework. When you create such an MVC application, you will probably have heard about modules: reusable components of your application. [...] In my case, I usually just copy and paste the module from one base project into a new project. That's easy. But it would be cooler to package your module as a Phar file, and run that file instead.

He includes the code that can be dropped into your Zend Framework installation - MyLib_Application_Resource_Modules - that handles the bootstrapping of the phar files and executes the Boostrap.php file that it finds inside. He also points to this other article from Cal Evans about working with phar files in the Zend Framework.

Flyn San has a new post to his blog today about a better Doctrine 2 module he's created for use with Kohana framework-based applications.

Since releasing my original Doctrine 2 module for Kohana 3 (found here), I've done a bit of reshuffling of folders and added some additional features from my old Doctrine 1.2 module. Due to the extent of modifications, I decided to put up a new post with some added information on how to use the new module. For the impatient ones out there, here's the download link: Doctrine 2 Module for Kohana 3

He spends the rest of the post explaining the structure of the module, how to get it installed and working and some sample schema files (for Product and Serial tables in yaml) you can import and test with.

On the Query7 blog there's a new tutorial that will step you through making a module for the Kohana3 framework - a replacement for the Kohana_View view layer included with the framework.

We will be building a module that replaces Kohana's own view layer (Kohana_View). It will use the PHP template library Twig. We want our own view layer to be API compatible with Kohana's view layer. This will ensure that other modules work out of the box and that the only code the developer will need to alter in their application are the templates (so that they are Twig compatible). No code in any controller will need to be modified.

They lay out the directory structure (dropping all files in /modules) and show you how to enable the module. He talks a bit about what Twig is and shows the code needed to initialize it and configure some of its basic settings. They define the "capture()" method and include a sample of using Twig in your controller.

Rob Allen has this quick new post to his blog today for those out there developing with the Zend Framework - how to use view helpers inside modules.

I came across a situation last week where I needed to access a view helper that was in the default module's views/helpers directory when I was in another module. This came about because my layout.phtml uses a view helper that is in application/views/helpers.

An error's thrown if you try to use it normally, something about a plugin not being found. The key fix is an easy one, though - add a new Zend_View_Helper path and a helperPath for the module you want to use them in inside the application.ini file.

Robert Basic has a quick new post to his blog today showing how to load custom module plugins in your Zend Framework application.

I was trying to load a Front Controller plugin which resides in app/modules/my_module/controllers/plugins/ and not in the '�usual'� lib/My_App/Plugin/. I want this plugin to be called in every request and I want the plugin file to be under it's '�parent'� module.

To solve the problem he added a path to the Zend_Application_Module_Autoloader as a resource and registered it in the front controller. He includes some code to show how it works - a simple bootstrap with two _init functions, one for the news autoloading and another for plugins.