• ~130 pull requests merged, and ~100 issues closed.
• Over 30 component releases.
• Completion of the component documentation migration.
• Tagging of zend-mvc 3.0.
• Completion of the new skeleton application and related installers.

Documentation

Since the last update, we managed to complete the migration of documentation to components, as well as publish documentation for all components!

You can view a list of all documented components via GitHub Pages:

• https://zendframework.github.io/

Each component contains a link in the topnav to scroll in the component list, allowing you to navigate to other components.

Please help us thank Frank Brückner for the enormous amount of assistance he provided driving this milestone to completion!

zend-mvc 3.0 stability

After copious testing with the skeleton application (more on that below), and prepping components such as zend-test to work with it, we decided that zend-mvc was ready to tag with a 3.0 stable version!

For those not following previous updates, the main goals of the zend-mvc v3 effort were:

• De-couple from other components. Many components were listed as development requirements and suggestions due to the fact that zend-mvc contained zend-servicemanager integrations for them. We have moved those integrations into the components themselves.
• Reduce dependencies to exactly what's needed for a basic zend-mvc application:
  • EventManager
  • HTTP
  • ModuleManager
  • Router
  • ServiceManager
  • Standard Library
  • View
• Split optional integrations into their own packages. These included:
  • Console integration (now provided via zend-mvc-console)
  • i18n integration (now provided via zend-mvc-i18n)
  • Several plugins had requirements on additional libraries, including:
    • PRG (uses zend-session)
    • FilePRG (uses zend-form and zend-session)
    • FlashMessenger (uses zend-session)
    • Identity (uses zend-authentication)

During the process, we were able to remove around 75% of the code, making the component much smaller, more maintainable, and more focused.

Once zend-mvc was tagged 3.0, we quickly followed up with a zend-test 3.0 release, and stable releases of zend-mvc-console, zend-mvc-i18n, and the various zend-mvc-plugin packages.

Skeleton application

We'd begun refactoring the skeleton application previously, and were able to complete the work in the past couple weeks. The new skeleton:

• Migrates to PSR-4 directory layout for the shipped Application module.
• Relies on Composer for all autoloading, including the Application module.
• Removes all translations. These were of dubious use, and were quite difficult to maintain.
• Depends only on zend-mvc, zend-component-installer (which automates injecting components and modules into application configuration during installation), and zend-skeleton-installer (more on this below).
• We removed almost 8000 lines of code, adding only 800!

zend-skeleton-installer is a new Composer plugin that prompts the user during installation to:

• Decide if they want a minimal install, or want to add optional packages.
• Prompts for a number of common optional packages, including caching, logging, console integration, i18n, etc.
• When installation is complete, it removes itself from the project!

Matthew plans to blog on the code behind zend-skeleton-installer in the near future.

You can test out the new skeleton using the following:

$ composer create-project "zendframework/skeleton-application:dev-develop" zend-project

The above will use the new develop branch, and create a project in the directory zend-project.

Finally, we added both an updated Vagrantfile and Docker support to the skeleton, allowing you to start developing in a consistent, de-coupled environment immediately.

For Vagrant, after you've installed, execute:

$ vagrant up

For Docker, you will need to use docker-compose; once you have that available, execute:

$ docker-compose up -d --build

With each, we bind your host port 8080 to the container's port 80, allowing you to visit it at http://localhost:8080/

We're excited about the new skeleton, and look forward to getting your feedback on it!

Final milestones

We have a few last milestones before we're ready to announce the completion of the Zend Framework 3 initiatives.

First, because PHP 5.5 support ends at the end of June, we will be releasing a new minor version of all components setting the minimum supported PHP version to 5.6. (Many already have such versions in place.)

Second, now that the skeleton application is ready, we will be migrating our tutorials to a new repository, converting them to Markdown and MkDocs, and updating them to follow the new skeleton and component changes.

Finally, we will be deciding what the zendframework/zendframework package will look like for a version 3 tag. In large part, it becomes unnecessary, as we can ship even the skeleton with a minimal set of components; however, for those who want "everything at once", keeping it around as a metapackage may have value. We'll be announcing the plans for it soon.

Until next time

If you want to help:

• Test the new skeleton (see the directions above) and provide feedback.
• Search for help wanted or EasyFix issues (most of the latter are documentation).

Many thanks to all the contributors who have provided feedback, patches, reviews, or releases since the last update!

Per the GitHub documentation on renames, existing links will be automatically redirected, and will persist as long as we do not create a new repository with the name "zf2". Redirects occur for:

• issues
• wikis
• stars
• followers
• git operations

Update your remotes

While git operations pushing and pulling from the original repository URLs will continue to work, GitHub recommends you update your git remotes to point to the new location. You can do this with the following in the CLI:

$ git remote set-url origin https://github.com/zendframework/zendframework.git

Note the following:

• Replace origin with the name of the remote you use locally; upstream is also commonly used. Run git remote -v to see what you're actually using.
• Valid remote URLs now include:
  • https://github.com/zendframework/zendframework.git
  • git://github.com/zendframework/zendframework.git
  • git@github.com:zendframework/zendframework.git

Composer

Because Packagist points to GitHub, it will seamlessly redirect. Additionally, all sha1s for all commit remain identical. As such, there should be no impact to end-users for the change for existing installs.

We have updated Packagist to point to the new URL as well, so that as users update, their composer.lock files will start pointing to the new URL.

Another way of putting it: changes to the main repository are happening incrementally, and version 3 will just be a new major version update within the existing repository.

However, such evolutionary change poses a slight logistical problem: the repository is currently named "zf2".

As such, we've decided to rename the repository to remove the version identifier. It will become simply "zendframework".

This naming is already reflected in our Composer package, which is named "zendframework/zendframework". Additionally, GitHub will provide long-lived redirects for all links to the repository, including those to issues, comments, pull requests, etc.; those redirects also work at the git level for each of HTTPS, SSH, and git protocol access. Because no sha1s change, this means that Composer installs will not suffer any issues, either.

We've also verified with GitHub that references of the form zendframework/zf2#... within commits, comments, etc. will continue to work, and redirect to the new location.

With all our concerns satifisied, we'll be making the change on 3 May 2016, and will post to the blog with details on how to update your git remotes to point to the renamed repository at that time.

• ~160 pull requests merged, and ~110 issues closed.
• Over 60 component releases.
• Completion of the zend-mvc version 3 refactors.
• All components are now forwards-compatible with existing v3 releases, including those that depend on zend-stdlib.
• Progress on the documentation initiatives, including 11 new components documented.
• Announcement of issue closures.

MVC Refactor

In the previous update, we provided a roadmap for the zend-mvc v3 refactor; at the time, we'd just begun the initiative, but still had the bulk of the work remaining.

As of last week, however, we have completed all tasks related to the refactor! These include:

• a component installer Composer plugin, which will automatically inject installed components into application configuration as modules. (It is also forwards-compatible with upcoming Expressive releases!)
• console functionality as a separate component (zend-mvc-console).
• separation of controller plugins with additional dependencies into their own packages, including:
  • PostRedirectGet
  • FilePostRedirectGet
  • FlashMessenger
  • Identity
• separation of i18n integration into a separate component (zend-mvc-i18n).
• separation of the code for wiring zend-di into zend-servicemanager into a dedicated component (zend-servicemanager-di).
• removal of all factories and integrations with components that fall outside the core dependencies.

This latter required that we move the various factories, service integrations, and event listener wiring code into the components themselves. This affected eight components, though we ended up addressing another five components that were already defining factories for zend-servicemanager as well:

• zend-filter
• zend-form
• zend-hydrator
• zend-inputfilter
• zend-log
• zend-navigation
• zend-serializer
• zend-validator
• zend-cache
• zend-db
• zend-mail
• zend-paginator
• zend-session

For each of these, we created two new classes in their defined namespaces, ConfigProvider and Module. The first is an invokable class returning configuration, which might include service configuration, plugin configuration, etc. Module is a class specific to the Zend Framework ecosystem, and returns configuration, but, in several cases, also wired other code into the zend-mvc workflow. All of the above components received new minor releases once these were in place, and zend-mvc was updated to remove dependencies on them.

The core dependencies in zend-mvc are now:

• zend-eventmanager
• zend-http
• zend-modulemanager
• zend-router
• zend-servicemanager
• zend-stdlib
• zend-view

Once we were done, the lines of code had dropped to approximately 25% of the size in the version 2 releases!

Skeleton application

With the zend-mvc refactor complete, we decided to work on the skeleton application.

Feedback we've had includes:

• While having i18n support is interesting in terms of seeing how it's done, it's mostly worthless in the skeleton application. The provided translations are only valid for the home page shipped with the skeleton, which is replaced essentially 100% of the time with custom content. Additionally, it poses maintenance overhead with regards to reviewing and accepting new translations. Finally, with the split of zend-mvc-i18n, keeping it in meant adding additional dependencies which might never be used.
• Related, we've had a lot of folks indicate that they'd like an option for a minimal skeleton. Many developers don't want the i18n, console, forms, cache, logging, and other facilities, or want to pick and choose which ones they configure.
• As PSR-0 is deprecated, our skeleton should reflect PSR-4 for the default Application module.
• Related, we want to encourage using composer for all autoloading.

To get the ball rolling, I created a pull request proposing a streamlined skeleton. This has already generated a fair bit of discussion, and we have a number of new ideas we're going to investigate, including setting up Expressive-like installation questions to allow bringing in common features during the first install.

JSON Refactor

We also did some refactoring of the zend-json component. Several users have complained that it includes too much: the JSON-RPC functionality is not generally useful for those who only want JSON de/serialization, and the XML2JSON implementation is only needed by a subset of users.

As such, we split it into three:

• zend-json contains the JSON de/serialization logic only, starting with its v3 release.
• zend-json-server contains the JSON-RPC server implementation.
• zend-xml2json contains the XML2JSON implementation.

We'd like to thank Ali Bahman for his assistance with these changes!

Forwards compatibility

This week, we discovered half-a-dozen components that declare a dependency on zend-stdlib, but which had not been updated to allow usage with zend-stdlib's v3 releases. As such, we quickly updated each to do so, releasing new maintenance releases when ready. These include:

• zend-code
• zend-expressive-skeleton
• zend-ldap
• zend-mime
• zend-soap
• zend-xmlrpc

Documentation

With the MVC initiatives complete, we have begun working on the documentation in earnest again.

The first thing we did was recognize that while it's nice to be publishing the documentation, we really need mechanisms for navigating to other components. As such, we created a topnav button that, when clicked, fetches a list of components with documentation, and slides the list in from the top of the page.

We've also been either documenting components as we create them (see the MVC plugins and JSON changes, above), or publishing documentation as we create new releases on components we update. Since the last update, we've published documentation for the following components:

• zend-json
• zend-json-server
• zend-mime
• zend-mvc-plugin-fileprg
• zend-mvc-plugin-flashmessenger
• zend-mvc-plugin-identity
• zend-mvc-plugin-prg
• zend-servicemanager-di
• zend-soap
• zend-xml2json
• zend-xmlrpc

Many thanks to Frank Brückner for the copious documentation updates he's provided!

There's plenty left to do, however (32 components left at the time of writing). We've created a list of components and tasks to perform if you are interested in helping!

Issue closures

Last week, Gary Hockin posted to the ZF blog about a plan to perform housekeeping of issues posted against the main zendframework repository. The basic summary is: issues against the main ZF repository have been tagged as "To Be Closed", and will be closed in early May unless you comment on an issue and tag user @GeeH before 3rd May 2016.

Pull request and issue activity

Since the last update, we've merged around 160 pull requests, and resolved around 110 issues. (links require a GitHub account).

Notable releases

As noted at the beginning of this post, we've done over 60 component releases since the last update (approximately four weeks ago). Notable amongst them:

• Zend Framework 1.12.18
• zend-json 3.0.0, which removes the JSON-RPC and XML2JSON functionality (as those are now in separate components)
• zend-inputfilter 2.6.1, which fixes a long-standing issue with localization of NotEmpty validation messages generated for required inputs.
• zend-math 2.7.0 provides a security hardening patch for Zend\Math\Rand, forcing usage of PHP 7's random_bytes() and random_int() when available, and requiring ircmaxell/RandomLib for earlier PHP versions.
• zend-session 2.7.0 updates the component to use ext/mongodb + the MongoDB PHP client library instead of ext/mongo, and adds session identifier validation by default.
• zend-db 2.7.1 updates the Pgsql adapter to accept the charset option; fixes Zend\Db\Sql\Insert to properly manage arrays of column names when generating SQL INSERT statements; fixes an issue with how row counts were reported in Oci8 result sets; and updates the IbmDb2 adapter to allow # characters in identifiers.
• zend-cache 2.7.0 offers a ton of new features, including a new APCu adapter, upgraded support for XCache and Redis, and numerous bugfixes.
• zend-stdlib 2.7.7 and zend-stdlib 3.0.1 fix declaration of Zend\Json\Json::GLOB_BRACE when on systems based on non-gcc versions of glob.

Until next time

If you want to help:

• Help complete the documentation migration!
• Test the new skeleton and provide feedback.
• Review issues to be closed
• Search for help wanted or EasyFix issues (most of the latter are documentation).

Many thanks to all the contributors who have provided feedback, patches, reviews, or releases since the last update!

• Zend Framework 1.12.18

You can download Zend Framework at:

• http://framework.zend.com/downloads/latest#ZF1

Security Fixes

Zend Framework 1.12.18 includes a fix for security advisory ZF2016-01, a potential insufficient entropy vulnerability in a number of methods exposed in Zend Framework 1, including:

• Zend_Ldap_Attribute::createPassword
• Zend_Form_Element_Hash::_generateHash
• Zend_Gdata_HttpClient::filterHttpRequest
• Zend_Filter_Encrypt_Mcrypt::_srand
• Zend_OpenId::randomBytes

Moreover, the fix mitigates a flaw in openssl_random_pseudo_bytes(), ensuring sufficient entropy will be used for any random number generated.

Other changes

In addition to the security patch, the release includes fourteen other patches, primarily around documentation. You can view a full list at:

• Zend Framework 1.12.18 Changelog

Many thanks to our contributors, and particularly the maintainers who coordinated this version: Frank Brückner, Rob Allen, and Enrico Zimuel.

I want to make you aware of some upcoming changes to the issues that are currently logged in GitHub. We currently have 426 open issues that are logged against the (now) meta zf2 repository. The vast majority of these are now in the wrong place, as we've split our once monolithic single repository into the many single component repositories. These issues should be moved from the zf2 repository to the correct component that the issue relates to.

In preparation for this, we've been doing a little housekeeping and have already closed a few minor issues that have been open since before we even used GitHub for issue tracking. Matthew, Enrico and I also had a long discussion at Midwest PHP on the best way to handle these issues, and we came up with a plan of attack that hopefully will allow us to close off a bunch of historical issues that are no longer relevant, and then move issues that need to be moved to the correct place.

You may have noticed that over the last few weeks, a number of issues have been tagged with the new label of "To Be Closed". These are issues that have been open for a number of years and still haven't been fixed. Its probable that a number of these issues should not be closed as they are still relevant all this time later (after all, just because an issue has been open for many years does not mean that it will never be addressed). However, at some point these issues need to be triaged so that issues that are old and not relevant can be closed, and this is the convenient time.

So, in early may, all the issues that are tagged with "To Be Closed" will be closed. If you feel an issue needs to remain open for any reason, then please comment on the issue with a mention of my username (GeeH). I will then remove the "To Be Closed" tag. Next, no sooner than the 3rd May 2016, we will run a script that will automatically close every tagged issue, commenting on it to advise the original author to re-open an issue on the correct repository if they feel that issue is still valid.

Once this has been done, we will be left with around 100-150 issues by my estimation. Most of these have already been labelled with the correct repository to move them to (thanks to the sterling work of the community). The next step will be to run a script that opens a new issue with the same body text on the correct repository, adding a link to the original issue on the central zf2 repo. A comment will be added referencing the new issue on the original, and the original will be closed.

Hopefully, once this process is complete, we will be left with a few issues that are either in the right place (after all, some issues will relate to the meta package on the zf2 repository), or can be moved by hand.

TLDR

You need to comment on an issue mentioning GeeH BEFORE the 3rd May 2016 to ensure it remains open after that date (if it's currently tagged "To Be Closed").

• ~160 pull requests merged, and ~125 issues closed.
• ~60 component releases.
• Completion of the zend-servicemanager/zend-eventmanager migrations.
• Completion of the component/module installer.
• Progress on the zend-mvc version 3 changes, including separation of routing and console tooling to separate packages.
• Publication of documentation for 5 components to GitHub Pages.

Compatibility Migrations

During the first week of March, we completed the forwards compatibility migrations of components. As a reminder, we were working on updating components that depend on any of:

• zend-eventmanager
• zend-servicemanager
• zend-stdlib

to be forwards compatible with the version 3 releases of each. In particular, the first two have version 2 releases that allow developers to make their code forwards compatible with the version 3 releases, and we were doing precisely that with the various Zend Framework components. As of 2 March 2016, we completed this task — a major milestone in the ZF3 initiative!

The following component releases were made since the last blog update and mark the current stable versions that are forwards compatible with the v3 releases:

• zend-authentication 2.5.3
• zend-barcode 2.6.0
• zend-captcha 2.5.4
• zend-db 2.7.0
• zend-eventmanager 3.0.1 (which updates the component to use zend-stdlib v3)
• zend-file 2.6.1
• zend-form 2.7.0
• zend-hydrator 1.1.0
• zend-hydrator 2.1.0
• zend-inputfilter 2.6.0
• zend-log 2.7.1
• zend-mail 2.6.1
• zend-modulemanager 2.7.1
• zend-mvc 2.7.3
• zend-navigation 2.6.1
• zend-paginator 2.6.0
• zend-progressbar 2.5.2
• zend-session 2.6.2
• zend-test 2.6.1
• zend-uri 2.5.2
• zend-validator 2.6.0
• zend-view 2.6.5

In addition to the migration changes, we made a number of other updates to zend-mvc, including:

• addition of a new MiddlewareListener, allowing routing to PSR-7 middleware in the MVC layer.
• modifications to the EventManagerAwareInterface initializers; since shared managers are injected in EventManager instances via the constructor in zend-eventmanager v3, the initializers needed changes in order to work with both v2 and v3.
• AbstractController::getServiceLocator() now raises an E_USER_DEPRECATED notice. zend-servicemanager v3 removes the ServiceLocatorAwareInterface, and zend-mvc will remove the implementations with version 3. Users should start updating their controllers to accept dependencies via constructor injection.

The above are messaged in more detail in the zend-mvc migration guide.

Component / Module Installer

One goal for zend-mvc is to reduce the number of dependencies. Much of the functionality within zend-mvc is not directly related to execution of the MVC, but rather integrating components. Typically this is done by either providing and wiring factories for components, or providing and/or wiring event listeners for components.

We already have functionality that allows doing these tasks via the zend-modulemanager component, which means we can expose components as application modules. However, this creates an installation issue: just like modules, you would need to:

1. Install the package containing the module.
2. Enable the module in your application.

To automate the second task, we developed zend-component-installer back in December. As part of the current milestones, we completed that component, by making the following changes:

• It now acts as a composer plugin. You install it as a development dependency, and it will then inspect any package you install to see if it can handle installation tasks. This vastly simplifies the previous iteration, which required downloading a self-updating PHAR to install the composer scripts within an application.
• It now prompts you to ask which file to inject the detected component or module into, allowing you to choose from:
  • config/application.config.php (vanilla zend-mvc application)
  • config/modules.config.php (Apigility application)
  • config/development.config.php (application using zend-development-mode)
  • config/config.php (for Expressive users using the expressive-config-manager)
  • or "do not inject".
• It now prompts you to ask if you want to use the selection made on additional packages being installed.

We've become quite excited about the possibilities Composer plugins and installer scripts offer, and plan to leverage them as much as possible!

zend-mvc v3 progress

Several weeks ago, we created a detailed plan for the zend-mvc v3 refactor. The work is primarily around reducing the number of dependencies zend-mvc requires; the above work on the component installer directly enables these changes, but much more needs to be done.

Since we posted that, we've also started work on the various milestones it details. In particular, we've done the following:

• Created the zend-router component, to provide all routing capabilities. This reduces the amount of code in zend-mvc tremendously, and also makes it easier to re-use routing in other projects (e.g., zend-expressive-zendrouter). We also removed console routing from the component, letting it focus on HTTP routing only (more on this).
• Created the zend-mvc-console component, to provide integration between zend-console, zend-mvc, zend-router, and zend-view. Essentially, all console-related functionality from zend-mvc, zend-router, and zend-view were pushed into this component.
• Created zend-mvc-plugin-prg, which makes a standalone component out of the prg() controller plugin. This is the first of several component plugins being developed.

As part of this effort, we are documenting migration steps needed by end-users, to ensure that developers will be able to update their applications once version 3 is tagged.

Documentation

The documentation effort was put on the back-burner during these past few weeks so that we can focus on the development efforts. Regardless, we managed to publish 5 components to GitHub Pages:

• zend-barcode
• zend-mvc
• zend-mvc-console
• zend-mvc-plugin-prg
• zend-router

Additionally, a number of contributors, and notably Frank Brückner, have been providing patches to resolve issues created following the automated documentation migration.

Diactoros, Stratigility, and Expressive

A fair number of issues and feature patches have been reported on the Diactoros (PSR-7), Stratigility (PSR-7 middleware foundation), and Expressive projects, and we had a short sprint to resolve these.

• The latest version of Diactoros is 1.3.5, and it incorporates around 20 bugfixes and documentation fixes; among others, if fixes detection of HTTP/2 requests in the ServerRequestFactory.
• The latest version of Stratigiliy, 1.2.0, makes the behavior of its internal Response class less error-prone following calls to end(). Additionally, it:
  • ensures that exception details are not emitted in production mode, and makes production mode the default.
  • adds a FinalHandler::setOriginalResponse() method, to allow injection after instantiation.
  • adds support for catching Throwable errors in PHP 7 applications within the dispatcher.
  • provides a more meaningful InvalidMiddlewareException that is raised by MiddlewarePipe::pipe() for non-callable middleware.
• zend-expressive-skeleton provides a number of fixes:
  • It updates the Pimple container script to cache factory instances for re-use.
  • It updates the composer.json to allow installing zend-servicemanager v3, whoops v2, and ProxyManager v2.
  • It fixes an issue in the installer whereby specified constraints were not being passed to Composer prior to dependency resolution, resulting in stale dependencies.
  • It removes error/exception display from the shipped default error templates, to make them secure by default.
• zend-expressive-zendviewrenderer 1.1.0 updates the component to be forward-compatible with the zend-servicemanager and zend-eventmanager v3 releases.
• zend-expressive-zendrouter 1.1.0 updates the component to depend on zend-router instead of zend-mvc.

Pull request and issue activity

Since the last update, we've merged around 160 pull requests, and resolved around 125 issues. (links require a GitHub account).

Unlike previous posts, we are not detailing every component release this time; the sheer number of them (around 60!) would result in a very long read!

Until next time

If you want to help:

• Help complete the documentation migration!
• You can help with the MVC milestone; the linked page provides plenty of detail on how you can assist.
• Search for help wanted or EasyFix issues (most of the latter are documentation).

Many thanks to all the contributors who have provided feedback, patches, reviews, or releases since the last update!

The highlights:

• ~60 pull requests merged, and ~100 issues closed.
• Another v3 release: zend-stdlib!
• 16 components updated to zend-servicemanager/zend-eventmanager/zend-stdlib v3 changes, and tagged with stable releases.
• 25 component releases.
• Publication of documentation for 13 components to GitHub Pages.

New 3.0 versions

We released another component with version 3.0 stability, zend-stdlib. This release got the major version bump for a number of reasons:

• Per version 2.7.0, the hydrator sub-component was deprecated (it has been moved into its own component, zend-hydrator). With the new major version, we were able to remove it.
• A number of features existed as polyfills to provide forwards-compatibility support from PHP 5.3 or PHP 5.4 to later PHP versions. Since we now support only PHP 5.5+, we could remove these.

Unless a component depends specifically on the hydrators, it's essentially already forwards-compatible with the new version 3! As such, we'll be gradually updating components that depend on zend-stdlib to depend on ^2.7 || ^3.0.

Compatibility Migrations

The past two weeks have been heavily focused on preparing components to be forwards compatible with the version 3 releases of zend-stdlib, zend-eventmanager, and zend-servicemanager. We had several breakthroughs that are enabling these migrations.

First, we can test the different versions via additional Travis-CI jobs. As an example, consider these PHP 5.5 entries from the zend-cache test matrix:

matrix:
  include:
    - php: 5.5
      env:
        - EXECUTE_CS_CHECK=true
        - PECL_INSTALL_APCU='apcu-4.0.8'
    - php: 5.5
      env:
        - SERVICE_MANAGER_VERSION="^2.7.5"
        - EVENT_MANAGER_VERSION="^2.6.2"
        - PECL_INSTALL_APCU='apcu-4.0.8'

Note that in the second entry, we specify specific v2 versions of zend-eventmanager and zend-servicemanager to use.

Later, in our before_install section, we do the following:

before_install:
  - if [[ $SERVICE_MANAGER_VERSION != '' ]]; then composer require --no-update "zendframework/zend-servicemanager:$SERVICE_MANAGER_VERSION" ; fi
  - if [[ $SERVICE_MANAGER_VERSION == '' ]]; then composer require --no-update "zendframework/zend-servicemanager:^3.0.3" ; fi
  - if [[ $SERVICE_MANAGER_VERSION == '' ]]; then composer remove --dev --no-update zendframework/zend-session ; fi
  - if [[ $EVENT_MANAGER_VERSION != '' ]]; then composer require --no-update "zendframework/zend-eventmanager:$EVENT_MANAGER_VERSION" ; fi
  - if [[ $EVENT_MANAGER_VERSION == '' ]]; then composer require --no-update "zendframework/zend-eventmanager:^3.0" ; fi

Essentially, we have two builds. One against the v2 components, and one against the v3 components; the items above force one or the other for the particular build. This allows us to verify that the code works against both versions, and that any later changes require that both versions continue to work.

What about that line to remove dependencies, though?

The tricky part of migration has been unravelling dependencies. If a dependency of a component being migrated also depends on one of the updated components, we have to wait until the dependency is migrated. Or do we?

In many cases, these dependencies are marked as suggestions, and as development dependencies only; they are not hard requirements of the component. Realizing this, we discovered the following workflow:

• We can remove dependencies when testing against v3 components if:
  • the dependency is not yet migrated
  • the dependency is optional (only listed in require-dev and/or suggest)
• We can update the tests to skip tests that depend on those particular components if classes or interfaces from that component are missing.

This means that we're testing specifically that the current component is forwards-compatible with the new versions. Later, once those dependencies are updated, we can re-enable those tests.

Finally, a contributor wrote a trait that we can compose in plugin manager tests to verify that a plugin manager implementation is both v2 and v3 compatible. By adding these to components, we're able to verify with much more confidence that the code works on both versions.

With these findings and tools in place, we were able to complete migration of 16 components these past two weeks, tagging each with new stable versions! These include:

• zend-math 2.6.0 (technically, this one removes the dependency on zend-servicemanager, as it was an internal detail, and not necessary)
• zend-serializer 2.6.0 / zend-serializer 2.6.1
• zend-tag 2.6.0 / zend-tag 2.6.1
• zend-permissions-acl 2.6.0
• zend-crypt 2.6.0 (this one replaces zend-servicemanager with container-interop)
• zend-filter 2.6.0
• zend-http 2.5.4
• zend-server 2.6.1
• zend-json 2.6.1
• zend-config 2.6.0
• zend-text 2.6.0
• zend-console 2.6.0
• zend-log 2.7.0
• zend-i18n 2.6.0
• zend-feed 2.7.0
• zend-cache 2.6.0 / zend-cache 2.6.1

We've made every effort to ensure that these releases continue to work with existing version 2 functionality; however, occasionally, errors occur. If you notice such errors, please report them as soon as you can, with as many details as you can, so we can correct them. Additionally, please be aware that developers are fellow human beings, and be respectful in your communication. Nobody is intentionally trying to break your applications, and contributors desire a smooth migration for you as well.

At this point, we're about half-done with the migrations, and of the remaining half, around half have patches under review. If you want to assist, please review the migrations page to see which patches are need review, and where you might be able to help.

Documentation

As noted in our last update, Gary Hockin performed an automated migration of our documentation from our reStructuredText sources to per-component Markdown a few weeks ago, and opened issues against each component to guide review of the documentation before publication. We also mentioned a plan to host documentation via GitHub Pages.

As part of the migration process, we decided to review and ready documentation for publication for any component getting a new minor release. This has resulted in new documentation for the following 13 components!

• zend-servicemanager
• zend-stdlib
• zend-hydrator
• zend-tag
• zend-permissions-acl
• zend-filter
• zend-config
• zend-text
• zend-console
• zend-log
• zend-i18n
• zend-feed
• zend-cache

We're very excited about the new documentation, particularly as it's mobile-friendly, and has in-site search!

Pull request and issue activity

Since the last update, we've merged around 60 pull requests, closing over 100 issues. (links require a GitHub account). Activity has been particularly high on documentation issues.

Component Releases

The following is a list of component releases since the last update, minus those noted in the migration section already. While not all releases are related to ZF3 specifically, this list is intended to detail activity within the organization.

• zend-expressive-twigrenderer 1.1.1 updates the TwigExtension to implement Twig_Extension_GlobalsInterface, to ensure it is forwards-compatible with Twig v2.
• zend-servicemanager 2.7.5 fixes the behavior of the InvokableFactory for situations when options are passed via a plugin manager, and provides tests for validating plugin managers are ready for both v2 and v3.
• zend-servicemanager 3.0.3 provides a number of fixes:
  • cyclical alias detection and reporting.
  • skips alias resolution if no aliases are present.
  • adds tests to verify plugin managers are v3-ready.
  • publishes documentation to GitHub Pages.
• ZendXml 1.0.2 updates the PHP dependency to ^5.3.3 || ^7.0, allowing it to work with any ZF component, in any supported PHP version. It also expands the test matrix to include PHP 7.
• zend-i18n 2.6.0, while previously noted, also contained the following changes:
  • adds support for NumberFormatter text attributes when using the NumberFormat view helper.
  • provides updated postal code verifications for Mauritius and Serbia.
  • allows multiple invocations of the DateTime validator with different sets of input.
  • provides null checks on provided message strings.

Until next time

If you want to help:

• Help complete the documentation migration!
• Also, as noted above, you can assist with refactoring components to support v2 + v3 of zend-servicemanager.
• Search for help wanted or EasyFix issues (most of the latter are documentation).

Many thanks to all the contributors who have provided feedback, patches, reviews, or releases these past two weeks!

The highlights:

• > 70 pull requests merged
• 2 components updated to zend-servicemanager/zend-eventmanager v3 changes
• 23 releases of components, including Expressive 1.0, and new maintenance releases of Apigility and the ZF2 package.
• Kickstarting of the documentation migration

Expressive 1.0!

Following two final release candidates, and after three months in release candidate status, we've finally tagged Expressive 1.0 stable! Among other things, we've created a dedicated documentation site, which will update automatically as features are merged to the project.

We feel Expressive is the true cornerstone of the ZF3 initiative, and we look forward to seeing the middleware-based projects people develop using it!

ZF2 and Apigility

We noted that the zendframework/zendframework package, which since 2.5.0 has been a metapackage aggregating the various independent components, was using ~2.5.0 for component constraints. This is problematic, as many components have 2.6 and even 2.7 versions, and some of those contain security fixes. To fix this, we released version 2.5.3, which modifies the component constraints to ^2.5, allowing them to get the latest 2.X series of any given component.

We also released version 1.3.2 of Apigility, to bring in some changes merged many months ago to fix things like DB Autodiscovery, as well as to pick up the 2.5.3 version of ZF2.

Documentation

Gary Hockin generously donated some time and wrote scripts to automate translation of individual component documentation from the ZF2 reStructured Text sources to markdown, and submitted pull requests across all components, which we have now merged. These are incomplete; some syntax cannot be translated correctly, imports within files could not be automated, etc.

If you want to assist, we've labeled all documentation tasks (link requires github login); feel free to jump in on the effort!

We're also working on a plan to host the documentation via GitHub Pages, to allow constant, up-to-date documentation, based on the work we did for the Expressive documentation. Most of the tooling for this is now created, and we will be able to start pushing it out to components once their documentation is ready to publish.

Pull request activity

Since the last update, we've merged over 70 pull requests (link requires a GitHub account). Activity has been particularly high on Expressive and documentation issues.

Component Releases

The following is a list of component releasessince the last update, minus a number of Expressive releases leading to the stable release. While not all releases are related to ZF3 specifically, this list is intended to detail activity within the organization.

• zend-view 2.5.3 adds support for the itemprop HTML attribute in the headLink() view helper, and updates PhpRenderer::render() to no longer lazy-instantiate a FilterChain if none is already present.
• zend-servicemanager 2.7.4 fixed an issue with resolving aliases of aliases due to canonicalization changes in previous versions.
• zend-servicemanager 3.0.1 removes the dependency on zend-stdlib by inlining the ArrayUtils::merge() routine into the Config class.
• zend-expressive-twigrenderer 1.1.0 adds several new features:
  • url and absolute_url template functions for generating URL paths and absolute URIs.
  • New "globals" configuration for specifying variables to make available in all templates.
• zend-servicemanager 3.0.2 fixes an issue whereby the creation context was not being passed correctly to abstract factories from plugin managers, and provides a performance boost for alias resolution.
• zend-code 3.0.1 moves the phpcs dependency to the require-dev section, and ensures that the method name is required when adding a method to the class generator.
• zend-apigility-admin 1.4.1 fixes an issue in the RpcServiceModel to ensure that a correct pattern is generated when fetching a service by name.
• zend-apigility-admin-ui 1.2.2 fixes a number of issues discovered, including:
  • DB Autodiscovery was failing due to inability to properly select the DB adapter name.
  • Custom authentication adapters are now displayed.
  • The regex for validating custom content-types was fixed to ensure it only allows valid MIME type specifications.
  • Fixes validation for REST and RPC service names, raising a warning on invalid input.

ZF3 Refactors

Our refactoring effort has slowed due to our focus on getting Expressive stabilized, though we're starting to get a number of community contributions to aid the effort.

If you wish to assist, please read the ZF3 ServiceManager refactoring guide; be sure to edit the wiki to indicate when you're working on a component, as well as to indicate the relevant pull request.

Until next time

If you want to help:

• As noted above, help complete the documentation migration!
• Also, as noted above, you can assist with refactoring components to support v2 + v3 of zend-servicemanager.

Many thanks to all the contributors who have provided feedback, patches, reviews, or releases these past two weeks!

You can install it using Composer, via the create-project command:

$ composer create-project zendframework/zend-expressive-skeleton expressive

If you were using a release candidate, you can update your existing applications using:

$ composer require "zendframework/zend-expressive:^1.0"

What's new in the stable version?

Nothing!

Well, not "nothing". Since last week, we merged a few documentation fixes, but, more importantly, finalized our documentation. This included a few changes:

• Some re-organization, to better categorize the documentation hierarchy.
• Switching from bookdown to MkDocs as our build engine of choice. We'd already been using MkDocs to publish on ReadTheDocs, so this wasn't a huge change. The choice was made based on stability, maturity, and ecosystem; MkDocs has been around for quite some time, and enabled us to accomplish a number of ideas quite quickly.
• Automated publishing to GitHub Pages, via Travis-CI. Any time we push to our master branch, the documentation will be updated.

We're quite proud of the results, and hope that the new documentation serves our users well.

What's to look forward to?

Shipping a stable version means that you can depend on the API going forward. As such, we're messaging that it's production ready; start building and shipping your applications on it today!

For the next feature version, we already have a few things scheduled:

• Removal of the deprecated pre_routing/post_routing configuration support, as messaged in the migration documentation.
• Providing modular functionality by default (with opt-out). This will likely include also providing a solution similar to the component installer to aid with auto-registering installed packages.

Kudos

We wish to thank everyone who contributed to the Expressive project! (That previous sentence is a link for every one of our 11 Expressive repositories!)

Additionally, we thank everyone who has provided us feedback — whether in the form of questions, bug reports, or suggestions — these past few months; without the critical feedback, the project would not be where it is today.

A few folks stand out:

• Enrico Zimuel, who started it all!
• Geert Eltink, who did the hard work of making the installer work!
• Hari K T, who nudged us to split the repository into discrete, single-purpose projects!
• Michael Moussa, who suggested the idea that middleware specifications could be pipelines themselves — and then implemented the solution!

Write your next project Expressively!

Write your PSR-7 middleware today! Consult the documentation to get started!