Transferring Zend Framework to Laminas: A Retrospective

The reorganization of the Zend portfolio was announced in the year 2018, in the month of October, which also included the Zend Framework. Most people became concerned regarding the future of the Zend Framework. After six months, Rouge Wave made an announcement about their plans to transfer the project to the Zend Development which is also known as the Linux Foundation.

Around February 2019, a few months before the announcement was made, a project was under development to make a tool that helped to transfer the project depositories to their new destinations. Initially, it was thought that altering the namespaces would do the work. But the underlying goal was to offer packages that provided complete compatibility by the replacement of the legacy components with the components of the legacy Zend Framework.

Either Rewrite Just The Tags or The Complete History?

With over 150 transferrable components, the majority of them carrying eight years of history and over a thousand commitments, and the Expressive components had a lesser period of history with some hundred commitments.

The primary plan was decided to rewrite the complete history with the “git filter-branch command”. The instruction applied arbitrary actions on each repository history revision. But, the development in the scope and functionality of the transfer tool reduced the operation pace. One component required several hours to jot down.

Therefore, a new approach to rewrite the tags was put to use. New signatures came to form with filter branches which further led to the development of new commit identifiers. The focus shifted to the specific tags that converted to installable releases. This procedure eases the identification of the complete history of the individual commits.

The procedure was developed with the scrutiny of the individual tags, followed by the rewriting of the operations. The original tag was replaced with the new tag, which contained the fresh new code.

In the year 2019, the New Year’s Eve 2019 witnessed the launch of the Laminas Project. The launch assured the complete functionality of the components in the Zend Framework. But the new features and fresh releases would likely assist in the Zend to Laminas Development Services. The Laminas Project comes with promising objectives with potential application migratory properties irrespective of an Apigility application, the old Zend Framework 2.0 version, or the Expressive Application.

Assignment Division

The Apigility project was a unique concept that was under development at a separate institution. However, The MVC, general components, and Expressive fell under the same organization. It was decided that Expressive was supposed to carry its own unique identification like that of Apigility. The names of the organizations were supposed to comply with their latest counterparts – Mezzio and the Laminas API Tools.

The present Laminas Project is represented by these GitHub firms –

1. Mezzio – which represents the (previously Expressive) components and the Mezzio middleware runtime.

2. The MVC and components representer – Laminas.

3. The Laminas API Tools components – laminas-API-tools, previously called Apigility.

Such assignment divisions made it simpler to obtain the codes that were particularly related to the individual subprojects.

Read More: The Promise Of Laminas Project: How It Transforms Your Good Old Zend Development?

Unity

The new project kept consistent namespaces for each of its components. Some of the earlier namespaces in use under the Zend Framework collections include –

• Zend.
• Expressive
• ZendXml
• ZendOAuth
• ZendService/ {service component namespace}
• ZF
• ZF/ Apigility

These divisions complicated the condition even for the maintainers. Thereby, the standardization ended to a pair of top-level namespaces which were –

1. Laminas and

2. Mezzio.

The subnamespace Laminas API Tools constructs on the Laminas MVC; thereby, every individual subproject component ended up with the namespace Laminas/ApiTools. The Laminas components also incorporated the service components – ZendService/Twitter and ZendOAuth.

Package Abandonment and Deprecation

Some of the packages were abandoned like –

• The official AWS PHP SDK or ZendService/Amazon.
• ZendService/Google/Gcm
• ZendService/Apple/Apns.

The lack of adequate resources had to make them prepared for abandonment from the corresponding APIs. The Laminas Project would incorporate these APIs with the help of additional labor (which would force them to extend beyond the providence of the official libraries from SDK).

A few other minor packages were depreciated, which remained unused by the other components like

• zfcampus/zf-deploy: the instruction was highly limited and needed a better perspective.
• zfcampus/zf-console: users were being directed to use CLI tooling libraries like symphony/console.

Providing Functionality and Connecting Components

Each of the migrated components needs to make use of the laminas-zendframework-bridge component. A compatibility layer was necessary, which ensured the parallel functionality of third-party components that functioned with Laminas Components and the Zend Framework. The objective was to ensure the prevention of BC break inside third-party libraries during the transference process to Laminas. But, the procedure brought forth certain hurdles –

The lack of a Zend Framework class caused trouble loading the proper Laminas class. The inclusion of an autoloader in the system made an alias for the legacy class with the class_alias and altered the fly namespace. Similar class subsequent requests used the Laminas replacement. But typehit-reference classes could not trigger autoloading into action.

The second challenge was to make sure that the legacy class type hints functioned with the Laminas replacements. The coding components should function during the installation of the Laminas component on the replacement of the ZF component. An additional autoloader was developed, which would make a legacy class class_alias similar to the autoloaded Laminas class.

Excess difficulties arose with the presence of integration classes that carried the word “Zend” in the name, like the LaminasRouter. The use of class maps with the aforementioned autoloaders brought out the proper solution to resolve those issues.

Customized Functions

Different shipment libraries carry defined namespace functions. The lack of class_alias in those functions created an issue in this case. The earlier functions were to remain in the legacy namespace, with it being delegated to its counterpart in the new namespace.

The duplicate tooling function was brought in to solve the issue. The function duplicates the individual function files with the .legacy.php suffix. The legacy namespace is put to use in that file with proxy modifications to the file. The addition of such legacy function files into the autoloader helped to make use of the new versions with the legacy versions.

For instance,

Rewritten create_uploaded_file.php

Legacy create_uploaded_file.legacy.php file

An up-to-date composer.json.

Consonants That Are Customized

Like namespaced functions, there was a problem with namespaced functions. But their solutions were similar.

Refer to the constants.legacy.php and constants.php, which are available in the mezzio/mezzio packaging. Also, refer to the transfer tool code with the structure as given here – Namespaced Constant Fixture.