In a post to his site Matthieu Napoli shares some recommendations about how to organize the code in your application using a "domain modules" approach. This is an organization method that relates the code based on functionality it relates to rather than the type of object it is.

We recently discussed 2 topics seemingly unrelated with my colleagues at Wizaplace: how to organize code [and] how to organize teams.

Regarding “how to organize teams”, we were discussing Spotify’s Feature teams. In a “classic” organization, teams are usually formed by grouping people based on their job title. [...] But in a “feature team” organization, teams are organized… by features. [...] The pros of this kind of organization are numerous and I do not intend to go over them here. But what does this have to do with code organization?

He starts with the "classic" code structure - organized by each item's type (ex: Entity, Service, etc). He then suggests reorganizing it move by what it does in the application, namely which module it belongs in best. He briefly touches on dependencies, "agile design" and the differences between a normal "product" and a "product" in e-commerce. He then applies these ideas and shares a domain organized directory structure, trying to reduce the overall complexity of the structure and the overall cohesion of the codebase.

The SitePoint PHP blog has a new post from Kirk Madera sharing some of the things he's learned about creating modules in Zend Expressive. His goal is to make it as easy as possible and enable "rapid development" in your application. This is the second part of a series on rapid development with Zend Expressive from Kirk (part one is here).

I have learned a few tricks when writing Zend Expressive modules that I want to share with you.

Please follow the previous post first to set up a proper working environment. I explained how to install and configure Zend Expressive with Doctrine, Gulp, and an abstract reflection factory – it’ll take a total of 10 minutes.

In this tutorial, we’ll build a simple read-only blog module (a page listing blog posts from a database) in minutes, demonstrating the kind of rapid development one is capable of with Zend Expressive.

He then shows how to use the command line tooling to create the module and how it is registered with Composer. He then shows the creation of the "blog" entity and database tables followed by the routing changes. Next he fleshes out the actions that will respond to the requests on each route and the templates that will be served as a part of the response.

On the Master Zend Framework site Matthew Setter has written up a tutorial showing you how to create a Zend Expressive module to help organize your application and keep related files all in one place.

I've been reflecting recently on the things that I commonly have to do when I begin building Zend Expressive applications. Of the list that I created, I found that one of the most common — and uninteresting — of them is setting up the rendering of static page content. [...] To solve this, I've usually manually created modules to handle the rendering of static page content. These module's usually had little more than a PageAction class that returned an HtmlResponse object, whose body was a rendered template file.

[...] If you're in a similar position to where I was and want to collate the logic into a reusable module, then follow along with me in this tutorial I'm going to step you through how to create a module which you can reuse across any Zend Expressive project.

He starts by briefly describing a "module" in the context of a Zend Expressive application and how they relate (or don't) to the modules in Zend Framework v2. He then starts in on the module creation, showing how to set up the environment, change the Composer configuration to autoload correctly and describes what the end result should look like. From there the tutorial starts on the code required for the classes covering the basics of the class, exception handling, configuration and the creation of a factory to make a module instance.

The Master Zend Framework site has posted a new tutorial covering an aspect of the Zend Expressive project that doesn't seem to get enough coverage: the tooling included with the skeleton application.

For the longest time, Zend Framework hasn't had the strongest command-line tooling and scaffolding support. In stark contrast, other frameworks — especially Laravel, and its excellent Artisan command — have had far stronger tooling support and as a result have been far easier to build projects with. However, that's all changed!

Since the release of Zend Expressive Skeleton 2.0.2, Zend Expressive's command-line tooling support has been rapidly developing. It's provided through a package called, aptly, Zend Expressive Tooling.

The post briefly describes what features the tooling brings and then gets right into the installation process (via Composer). The tutorial then walks you through the commands it provides to create middleware, modules and handle migration to latest versions of the framework. The module and middleware topics are then covered more in-depth, showing code and commands required.

The Zend Framework blog has a new post from project lead Matthew Weier O'Phinney showing how you can use plugin managers in Expressive and how it can be used to integrate other components.

With the release of Expressive 2, one of the key stories was the ability to require ZF components within Expressive, and have their dependencies auto-wired into your application courtesy of the component installer.

However, we recently had a user in our Slack channel (need an invite?) indicating they were having issues with usage of custom validators, filters, and input filters. After a <a href=https://discourse.zendframework.com/t/validatormanager-not-calling-custom-validator-factory/109">more thorough writeup on our forums, I realized we'd missed something important when making these integrations, and set out to solve it.

The article then starts with the problem that they're trying to solve, mostly around configuration handling. The solution involved some work done on various packages (like zend-log, zend-filter and zend-form) to make the configuration loading a bit more automated (and with fallback handling).

On the Liip blog there's a post from Jon Minder talking about the new Drupal 8 migration API/module and includes a guide to get you started using it in your Drupal application.

We at Liip AG believe, that the migration API is the best and most efficient way to import data into Drupal. [...] The Migrate 8 module in core is only an API. There is no user interface. This makes it difficult for new developer to start with Migrate 8.

I suggest you, to install the [several] extension modules right away before you start developing if you want to realize the full potential of migrate.

The post starts with a list of reasons they see to use the migration module over other methods including the fact that it's sponsored and supported by Acquia. He provides a list of modules to install before getting started with Migrate and links to a GitHub repository if you'd like a "quickstart" environment to follow his examples. He then compares the previous version (from Drupal 7) of the migration handling with the newer Drupal 8 functionality, most notably the change over to YAML configuration rather than PHP code. He helps you understand the structure of these files and gives an example. He shows how to run the migration, gives a more advanced JSON source example and mentions the included process plugin.

Michelangelo van Dam has a post to his site, now that PHP 7 is released, showing you how to get it installed on OSX (Yosemite) for your local development.

Yesterday was the release of PHP7.0.0 and I wanted to have it on my mac as fast as possible. Since I'm still using Mac OS X Yosemite I will post here the steps to upgrade my platform, it might be useful for you too.

He starts with the requirements needed for the installation including XCode to be able to compile the PHP from scratch and the latest download of PHP 7 from php.net. He then talks about the benefits of compiling your own installation and shares a script that he uses to compile the PHP version he wants (based on a command line option). Once this is run the typical make and make install are executed and, if all goes well, your output for a /opt/php7/bin/php -v will look the same as his.

The NetTuts.com site has posted a tutorial (the third and last in their series) showing how to override controller handling in Magento. In the previous posts they showed how to override functionality related to the models and blocks (frontend layout elements).

In Magento, the controller is responsible for handling incoming requests, and it's a backbone of the Magento routing implementation. [...] As I said in the previous tutorial, it's never recommended to change core files directly, as it makes upgrading Magento really difficult. To avoid this, we should follow the standard way of making desired changes to core files: we should either use event observers or override core files with our custom module files. We'll discuss the overriding feature today.

You'll need to be familiar with custom module creation to be able to follow along (see here if not) but other than that they provide everything you'll need. They start by creating the files and folders needed for the custom module including:

• Module XML definition (Envato_All.xml)
• Module XML configuration
• the Envato_Catalog_ProductController controller file (PHP)

The controller extends the pre-existing Product controller but the configuration definitions tell it ti use the "Envato" version instead.

Lorna Mitchell has posted a quick guide to compiling PECL extensions to her site today. This is for those users on unix-based systems that might need to manually compile with some custom options (or may be working on your own extension and may just need to test it).

There are lots of reasons why you might like to compile your own PHP extensions. [...] I haven't seen a really approachable guide anywhere, we tend to speak of extensions in hushed tones, and actually it isn't particularly tricky so here is my quick how-to guide.

The process is relatively simple for those familiar with the command line and the steps involved in compiling software. There's some special PHP-only steps you'll have to take before compiling the code to make sure it's ready to be a PHP extension. Then it's up to the usual configure+make_make install to ensure the .so file is correctly generated.

The Master Zend Framework site has a new tutorial today showing you how to use the ZFTool diagnostics to make sure your modules are working correctly. The ZFTool is a stand-alone tool that can help with common tasks like working with application configuration and creating module and project skeletons.

Do you want to be sure that when you create Zend Framework 2 modules, that they’ll work in whatever environment they’re used in? At the very least, do you want a simple way for users to check, as well as something that’s self-documenting? If so, you’re in the right place. Last year, I gave a basic introduction to ZFTool, which is a command line tool to manage applications written in Zend Framework 2. [...] In addition to [the included diagnostic checks] we can write our own diagnostic checks, using the Success, Failure and Warning classes. So in today’s tutorial, I’m going to show how to add diagnostics support to a module.

He's broken the rest of the tutorial up into four other parts, each with the code or commands you'll need:

• Add Diagnostics Support
• The Diagnostics Function
• Running Module Diagnostics
• When Checks Fail

You can find out more about the ZFTool and its usage in with diagnostics in the official manual