This is an installment in an ongoing series of posts on ZF3 development status. In the last three weeks, we've done a lot:

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

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:

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. In the last three weeks, we've done a lot:

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

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:

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

Source

The Zend Framework community is pleased to announce the immediate availability of:

  • Zend Framework 1.12.18

You can download Zend Framework at:

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:

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

Source

ZF2016-11: Potential Insufficient Entropy Vulnerability in ZF1

We discovered several methods used to generate random numbers in ZF1 that potentially used insufficient entropy. These random number generators are used in the following method calls:

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

In each case, the methods were using rand() or mt_rand(), neither of which can generate cryptographically secure values. This could potentially lead to information disclosure should an attacker be able to brute force the random number generation.

Moreover, we discovered a potential security issue in the usage of the openssl_random_pseudo_bytes() function in Zend_Crypt_Math::randBytes, reported in PHP BUG #70014, and the security implications reported in a discussion on the random_compat library.

Action Taken

We replaced the usage of rand() and mt_rand() with the random generators of ZF1 implemented in Zend_Crypt_Math().

Moreover, we removed the usage of openssl_random_pseudo_bytes() functions in Zend_Crypt_Math::randBytes(). This removal is not a BC break for Linux users thanks to the usage of /dev/urandom as an entropy source. For Windows users, this can be a BC break if the Mcrypt extension is not enabled.

The following releases contain the fixes:

  • Zend Framework 1.12.18

Recommendations

If you are using an affected version of PHP, we highly recommend upgrading immediately to Zend Framework 1.12.18.

Acknowledgments

The Zend Framework team thanks the following for identifying the issues and working with us to help protect its users:

  • Brian Engert of Soliant Consulting, who discovered, reported, and proposed a patch for the issue;
  • Enrico Zimuel, who tested the patch and added the patch for the OpenSSL usage removal.

Source

ZF2016-01: Potential Insufficient Entropy Vulnerability in ZF1

We discovered several methods used to generate random numbers in ZF1 that potentially used insufficient entropy. These random number generators are used in the following method calls:

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

In each case, the methods were using rand() or mt_rand(), neither of which can generate cryptographically secure values. This could potentially lead to information disclosure should an attacker be able to brute force the random number generation.

Moreover, we discovered a potential security issue in the usage of the openssl_random_pseudo_bytes() function in Zend_Crypt_Math::randBytes, reported in PHP BUG #70014, and the security implications reported in a discussion on the random_compat library.

Action Taken

We replaced the usage of rand() and mt_rand() with the random generators of ZF1 implemented in Zend_Crypt_Math().

Moreover, we removed the usage of openssl_random_pseudo_bytes() functions in Zend_Crypt_Math::randBytes(). This removal is not a BC break for Linux users thanks to the usage of /dev/urandom as an entropy source. For Windows users, this can be a BC break if the Mcrypt extension is not enabled.

The following releases contain the fixes:

  • Zend Framework 1.12.18

Recommendations

If you are using an affected version of PHP, we highly recommend upgrading immediately to Zend Framework 1.12.18.

Other Information

Acknowledgments

The Zend Framework team thanks the following for identifying the issues and working with us to help protect its users:

  • Brian Engert of Soliant Consulting, who discovered, reported, and proposed a patch for the issue;
  • Enrico Zimuel, who tested the patch and added the patch for the OpenSSL usage removal.

Source

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

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