While the previous article opens up many refactoring strategies, it is still important to work out the details. This time, I will cover sharing application settings (including PHP options which ZF1 apps tend to set in the runtime) and sharing error handling.
35 posts in category
In the previous part, we got Zend Expressive working on top of legacy Zend Framework 1 application. This was only the first step towards deeper integration. In this post, I will show how to bring these apps closer by introducing shared Service Container. It will open up new strategies of refactoring.
Just as presented in the previous article, wrapping legacy application in a PSR-7 compatible middleware seems to be the best option for gradual modernisation process. In this post I will show how to do it, starting from Zend Framework 1 skeleton application.
Back in its days, Zend Framework 1 used to be one of the most popular PHP frameworks around. Even now, 8 years later, there are numerous working applications built on top of it. Because ZF1 has reached it's EOL and is not supported anymore, companies and development teams are considering upgrading it to something more modern. While the default choice is often to migrate ZF1 application to Zend Framework 2 (or 3), there's a good alternative - Zend Expressive. Expressive is much smaller, better suiting modern, API-centric applications. It promotes separating business logic from the legacy code, and I would argue that it is easier to master than ZF3.
This is what we did in my company, with good success. With relatively small effort, in 2-3 years we've been able to reduce our legacy code base to only 18% of total 300k lines of code (meaning that only 18% is now dependent on old ZF1).
Because from time to time I'm getting questions about the migration, I'd to blog about it. In this post, I will give a basic introduction, and later on, I'll show concrete code examples.
Writing factories for
zend-servicemanager can be a tedious, repetitive task. Most of factories
I write follow the same pattern: pull some dependencies from the container, instantiate new
object and return it. How can you avoid the repetition?
As you may know, folks from ZF2/Apigility projects keep bringing interesting utility modules, enriching ZF2 ecosystem. Today I discovered small framework/helper for writing console applications: ZF-Console. And, to my surprise, it was based on my own pull request from last year! I was really proud to see that I brought something useful to the community.
There's an important question often rising when working on Zend Framework 2 module:
should I test service factories? After all, they are usually trivial, they create some object
and inject it with dependencies from
ServiceManager. Having one test per factory seems to be an
Better to go one step back, and ask yourself a question: what exactly do you want to test?
I'm happy to present a ZF2 module that handles composing and sending e-mail messages.
Why another module? There are a few of them already available on ZF modules website. However, when I was looking for solution to use in my application, I quickly realized that most of them are either outdated, or they miss features I needed. That's why I decided to write my own.
My intention was to create something powerful, but still simple to use. You an customize e-mail headers, add layout, automatically generate plaintext version of HTML e-mail, and so on. But you can also start composing and sending e-emails from your controllers with just a few lines of code.
Zend\View is pretty advanced rendering engine, with multiple useful features.
It is working nicely within ZF2's MVC stack, where it is automatically configured for you. But how to use it
without full MVC?
This can be useful in some situations: when building Your Own Microframework™, when creating an application
based on ZF2 components, or (in my case) when working on module that is supposed to render something outside MVC flow.
All of this projects can benefit from nested templates, multiple rendering engines, or pluggable architecture of
So, how to do that?
This post covers basic tasks that you may want to do within controller: forwarding to different actions, redirecting, and displaying 404 page. Once again, I will show how this tasks can be achieved in both ZF1 and ZF2.