ZF1: community-maintained official fork

Contributors
21

Have a look on zend-expressive!

1 Like
22

I was about to use it for my last project but i had a doubt about the learning curve of this middleware.

23

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:

  1. A list of classes/issues that cannot reasonably be fixed so they can be avoided or worked around.
  2. 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.

1 Like
24

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)

25

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!

1 Like
26

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.

2 Likes
27

Ad::

  1. Agree
  2. 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,
  3. As long as you dont own the repo, technically yes; but Zend has no power to stop people from taking over their repo.
  4. Its BSD license so you can do whatever
  5. True,
  6. Nice name,
  7. why?
  8. Not necesarily.
28

Is RogueWave really selling Zend Server with PHP 7 and ZF1 support or is this just vaporware?

I am now waiting for a price quotation since january after talking to a solution consulting manager of RogueWave.

29

Yes; weā€™ve had PHP 7 support in Zend Server for quite some time; in terms of solution consultants, I have very little communication with them, so cannot answer to their responsiveness. Iā€™ll prod them, however.

30

Regarding my questions about a temporary community ZF1 fork to provide some PHP 7.1 compatibility:

I appreciate the feedback, though my post was, as I mentioned before, related to figuring out options for moving forward with a less-than-ideal situation.

Unsurprisingly, the admonishments about running old software did not rewrite history for my clientā€™s project, nor did they help in any other way, particularly when I was already in agreement about those pitfalls.

ZF2/3/Expressive upgrades are underway, but in the meantime we do have needs for PHP 7.1 in certain areas and we will likely need to bridge the gap enough to make some ZF1 classes usable on a temporary basis. So I appreciate those who contributed to the original issue on Github.

31

See my comment above: stay on PHP 7.0!

32

Please take a look at https://github.com/zf1s - a ā€œcomposeableā€ zf1 with some fixes added. All components are available on packagist.org with zf1s/ namespace and we are still keeping php 7.2+ compatibility.

33

Where are the unit tests? How should this be checked?

This brings us back to my main argument:

34

As much as Iā€™d like to see ZF1 still maintained, I donā€™t think zf1s is a good idea. A quick glance tell me that this line will generate a count(): Parameter must be an array or an object that implements Countable error on PHP 7.2. If you had unit tests it would probably have come up, and been fixed, very easily. Not having unit tests at all really is show stopper nowadays.

Also the project git log was lost, which makes it near impossible to understand why things are the way they are, or who did what.

I wouldnā€™t recommend using it.

35

What do you mean the log was lost? Itā€™s present on githubā€¦

Or do you mean the fact that it only goes back to somewhere between 1.7 and 1.8? (For those curious why I mention that: when we migrated to git from SVN, we had to do it from a revision in that timeframe due to a reorganization of the SVN tree that made it impossible for git-svn to traverse further back.) Personally, I think decisions before that are mostly moot; the architecture changed dramatically with version 1.10 (when we added the Zend_Application class and the pseudo-module system). I also know we werenā€™t terribly great about having good commit messages in the early years. :wink:

36

I was referring to zf1s (notice the ā€œsā€), the fork of zf1. The repo I checked in that fork all have only a few commits.

Sorry for the confusion.

37

If anyone else is looking for maintained forks of zf1 due to legacy apps, here are two that Iā€™ve found so far:

I agree with the original subject. Itā€™s great to have this option for some older apps that one cannot easily upgrade to zf2, zf3 or another framework.