Hello Zend Frameworkians.

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").

Source

This is an installment in an ongoing series of posts on ZF3 development status. It's been more than a month since the last update, and we've been quite busy with:

  • ~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:

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:

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:

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

Source

This is an installment in an ongoing series of posts on ZF3 development status. It's been more than a month since the last update, and we've been quite busy with:

  • ~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:

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:

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:

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

Source

This is an installment in an ongoing series of bi-weekly posts on ZF3 development status.

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, [https://zendframework.github.io/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. 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. 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:

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.

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!

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:

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

Source

This is an installment in an ongoing series of bi-weekly posts on ZF3 development status.

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:

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!

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:

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

Source

This is an installment in an ongoing series of bi-weekly posts on ZF3 development status.

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:

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

Source

The Zend Framework community is pleased to announce the immediate availability of Expressive 1.0.0 STABLE!

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:

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!

Source

This is an installment in an ongoing series of bi-weekly posts on ZF3 development status.

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:

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

Source

The Zend Framework community is pleased to announce the immediate availability of Expressive 1.0.0 STABLE!

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:

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!

Source

The Zend Framework community is pleased to announce the immediate availability of Expressive 1.0.0rc7 and the Expressive Skeleton and Installer 1.0.0rc8!

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

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

You can update your existing applications using:

$ composer update

This release candidate contains bug fixes for dispatching error middleware pipelines. Additionally, we've released a new version of our Twig integration, and detail those changes below.

Changes in zend-expressive RC7

RC6 updated the configuration for the middleware pipeline to make it a single pipeline. We recommended that developers make use of our middleware grouping feature, however, which allows you to specify not just a single, named middleware service, but an array of named middleware services. This feature is great for grouping middleware based on when it should execute, and makes ordering related middleware simpler.

Per our suggested, default configuration:

use Zend\Expressive\Container\ApplicationFactory;
use Zend\Expressive\Helper;

return [
    'dependencies' => [
        'factories' => [
            Helper\ServerUrlMiddleware::class => Helper\ServerUrlMiddlewareFactory::class,
            Helper\UrlHelperMiddleware::class => Helper\UrlHelperMiddlewareFactory::class,
        ],
    ],
    // This can be used to seed pre- and/or post-routing middleware
    'middleware_pipeline' => [
        // An array of middleware to register. Each item is of the following
        // specification:
        //
        // [
        //  Required:
        //     'middleware' => 'Name or array of names of middleware services and/or callables',
        //  Optional:
        //     'path'     => '/path/to/match', // string; literal path prefix to match
        //                                     // middleware will not execute
        //                                     // if path does not match!
        //     'error'    => true, // boolean; true for error middleware
        //     'priority' => 1, // int; higher values == register early;
        //                      // lower/negative == register last;
        //                      // default is 1, if none is provided.
        // ],
        //
        // While the ApplicationFactory ignores the keys associated with
        // specifications, they can be used to allow merging related values
        // defined in multiple configuration files/locations. This file defines
        // some conventional keys for middleware to execute early, routing
        // middleware, and error middleware.
        'always' => [
            'middleware' => [
                // Add more middleware here that you want to execute on
                // every request:
                // - bootstrapping
                // - pre-conditions
                // - modifications to outgoing responses
                Helper\ServerUrlMiddleware::class,
            ],
            'priority' => 10000,
        ],

        'routing' => [
            'middleware' => [
                ApplicationFactory::ROUTING_MIDDLEWARE,
                Helper\UrlHelperMiddleware::class,
                // Add more middleware here that needs to introspect the routing
                // results; this might include:
                // - route-based authentication
                // - route-based validation
                // - etc.
                ApplicationFactory::DISPATCH_MIDDLEWARE,
            ],
            'priority' => 1,
        ],

        'error' => [
            'middleware' => [
                // Add error middleware here.
            ],
            'priority' => -10000,
            'error' => true,
        ],
    ],
];

Unfortunately, for error middleware, this was not working correctly.

Internally, when we encounter an array of middleware, we create a Zend\Stratigility\MiddlewarePipe instance, and pipe each middleware service to it in order. The problem is that MiddlewarePipe does not implement the error middleware signature — which meant that error middleware pipelines were completely skipped!

To make this work, we introduced a proxy class, Zend\Expressive\ErrorMiddlewarePipe, which wraps a MiddlewarePipe, and exposes the error middleware signature. This is now used internally whenever an error middleware pipeline needs to be created.

Changes in zend-expressive-skeleton RC8

When we created the new default middleware pipeline configuration for RC6/RC7, we forgot one important detail: the error middleware group was missing its error key, meaning it wasn't attempting to create error middleware at all! We've fixed this in RC8.

If you upgraded to RC6/RC7 earlier this week, make sure you add that error key, as detailed in the above example.

Twig integration updates

Today we released version 1.0.1 of our Twig integration. This includes a few new features:

  • It adds a dependency on zend-expressive-helpers and, if the UrlHelper and ServerUrlHelper services are registered, makes new url and absolute_url template functions available.
  • It adds a new "globals" configuration sub-section for registering variables to pass to all templates.

You can read more in the Twig integration documentation.

Many thanks to Geert Eltink for these new features!

Future

Code is stabilizing, and we're seeing fewer issues hitting our issue tracker. We hope that in a week or two we can release a stable version.

If you are testing Expressive — whether for the first time, or updating an existing application — please help us prepare it for general availability!

Source