Have a look on zend-expressive!
I was about to use it for my last project but i had a doubt about the learning curve of this middleware.
To get back to the original point of the discussion: I see a value to having a repository that follows the goals stated by @Slamdunk. I also agree with @froschdesign in theory in that it may end up being difficult to maintain in the long run.
However, the reality is that there are ZF1 applications that are still running and still moving forward on this old code. They do need to be migrated. But as @froschdesign said, a soft migration is best, and that can take months or years. In the meantime, some portion of the code in this applications will be dependent on ZF1, while newer portions may well need to take advantage of PHP 7.1, 7.2 or possibly later. We may also not want these applications marooned on an old version of PHP that is past EOL and no longer receives security updates.
Therefore, we might as well have a community fork that makes it possible to share these patches. The alternative will be each of us creating our own fork, and each of us writing all of the patches.
I would also be for the inclusion of:
- A list of classes/issues that cannot reasonably be fixed so they can be avoided or worked around.
- Code that streamlines migration. That’s possibly a separate repo though.
As long as the fork clearly states that it isn’t for new projects, I don’t see the harm.
This is no theory! I was one of the maintainer of ZF1 after ZF2 was released. And so I can say with certainty that you need a complete rewrite of some components. And don’t forgot PHPUnit with version 3.7, which is outdated for a long time. (The support for PHPUnit 5 ends next friday on 2 Feb 2018!)
Why do still work on this application on the same code base? Every new feature or every work on this old applications must be also a part of a migration.
You working already with old software which is no longer supported and which get no security updates. Why is PHP now a problem?
You can use ZF1 with 7.0, because it was tested with this version and PHP 7.0 is supported until 3 Dec 2018. With PHP 7.1 there should not be much more errors or warnings and PHP 7.1 is supported until 1 Dec 2019.
After that you can use a Linux distributions which has LTS + PHP 7.0 or 7.1 for many more years.
I see no need to support PHP 7.2 or creating a fork. You can use a current supported PHP version and ZF1 – for the next years!
But keep in mind: ZF1 is a risk and also PHPUnit. So that’s not a recommendation from me!
(For supported Versions of PHPUnit see: https://phpunit.de)
If you can understand actions in ZF1, middleware will be easy to understand and write. In many ways, it’s even easier, as you can write it without worrying about learning things like pre/post dispatch hooks, etc. Each middleware does one thing, and either delegates to the next handler (
$response = $handler->handle($request);), or returns a response on its own.
Definitely give it a try!
Yes, they do. And those migration plans should have started 18 months ago, when we announced the EOL. Applications that are still running on ZF1 have been running on borrowed time since that point. Maintaining a fork may prolong it, but comes with a ton of headaches:
- Who is responsible for security patches?
- Who is responsible for providing support for new versions of PHP? How do you test those, considering ZF1 supports PHP 5.2 and up, but PHPUnit versions often have PHP minimums that are far greater than that? (You wouldn’t believe the trouble we have currently with testing ZF components that still support PHP 5.6!)
- What happens when a component needs a complete rewrite to work under a newer PHP version? Will you rewrite it, recommend the ZF2+ equivalent and/or a different library?
- When will the EOL be for the fork? Because, frankly, I’m pretty sure nobody will want to maintain this indefinitely based on answering the above questions.
My point is: maintaining such a fork is going to be as much work as migrating, if not more. Put your effort where it will have greatest impact.
- Zend name can be used as its name of open source script and company is only named after it; so yes - it can be used,
- As long as you dont own the repo, technically yes; but Zend has no power to stop people from taking over their repo.
- Its BSD license so you can do whatever
- Nice name,
- Not necesarily.