The really bad thing of ZF1 is that it still is a rock-solid framework: I have many legacy apps in production, all with 100% code-coverage that happily run without bugs nor (known) security holes; all of them must keep running due to legal constraints but none of them have the money for an upgrade.
Fork the latest release - or something similar, like getting in charge for the purpose
Clearly state the purpose of the fork:
Keep ZF1 running without blocking errors on newest PHP versions
Drop support for previous/old/unsupported PHP versions when above point can’t be satisfied
If above points are satisfied, accept trivial-and-tested bug fixes
Reject any API changes, extensions, new features, optimizations etc
Discourage, like now, any usage of the fork beside updating PHP version for legacy apps
Issues for the goal:
Old PR with [no signed CLA] tag: have no idea how to handle this
Zend_Version executes an external call to http://framework.zend.com/api/zf-version: I would like to deprecate this class as I do not want to alter anything outside the fork, like the zend.com website
The naming “official fork” suggests a wrong impression, it should not be used.
I think the name “Zend” can not be used and should not be used.
There is no way to port the open PR’s to another repository. All open PR’s are send to the official ZF1 repository and no one is allowed to port this code. You can ask every contributor to send a new PR to your fork.
You can fork the project as long as you honour the current license terms.
You can create a community around your fork.
My suggestion for naming: “zf1-legacy”
My suggestion for the fork: do not add new features, only fixes bugs and problems.
And don’t forget: you’re still riding a dead horse!
Another and my most important suggestion: Don’t do this!
Create no fork and invest no work or energy in a dead project. And if there is no money for upgrades, why would you update or add new features to the underlying framework?!
Use PHP 5.6 and ZF 1.12.20 and everything stays as it was!
(Please keep in mind: I’m not a lawyer or jurist and it’s only my own view and my opinion!)
I have no experience in licenses management, I fear to make mistakes. I do not want to use the Zend name, but the licence must stay still and same, so the name would be different, but the files containted and the licence would refer to Zend. Would this be correct?
I’m ok with this
Nice name
I totally agree, but:
I fear security issues like CVE-2016-5771 and CVE-2016-5773.
Upgrading the environment is easy and cheap, I do not want unmaintained infrastructures nor systems nor softwares in my production.
Upgrading the framework is tricky and costly, that’s what tests are for: we spent a lot of effort to ensure happy&sad&bad paths are all covered, so we can safely face the environment upgrade.
Keeping the old framework up to date to the newest PHP versions is cheap (at least now), so the overall cost of committing my time into it plus upgrading the environment ensures my client the best compromise between money and issue-prevention.
RogueWave has provided ZF1 patches to customers with service license agreements since the EOL date. All of these have involved fixing issues arising due to running the framework on newer versions of PHP than it was originally tested against. Many of these have proved non-trivial to update, taking many hours of developer time. It’s nowhere near cheap… which is why we only do it for paying customers with SLAs in place.
My point is: do not underestimate the amount of time, energy, and money it will take to keep ZF1 running under newer PHP versions. It’s not as trivial as you might think.
Please do not get me wrong, I understand your situation! I also support some ZF1 applications.
But the update of the framework is not trivial; I have the same experience. Some examples from my work on ZF1 und many applications which based on ZF1: (the list is not complete!)
Zend_Date is a big fat monster with ugly bugs; should removed
Zend_Locale is outdated and gives wrong results; no update without rewrite
Zend_Currency is outdated because it based on Zend_Locale
Zend_Captcha only supports version 1 of ReCaptcha
Zend_Form doesn’t support HTML5 and mixes different layers
Zend_Validate_CreditCard, Zend_Validate_Hostname and Zend_Validate_PostCode are outdated
Zend_Dojo and ZendX_JQuery are completely outdated
Zend_Pdf is incomplete
results from Zend_Markup are wrong
Zend_Registry is a mess
Zend_View is inflexible
Zend_Application is not helpful
the module system not existent
many service and cloud components / classes uses an old API version of the related service
dependency injection where are you?
absolutely no PSR support
version 7.1 and 7.2 of PHP were never tested; 7.0 with allowed failures
PHPUnit with version 3.7 is used
The last point is a KO criteria for further maintenance of the framework!
I advise and strongly recommend a migration for your applications! A migration in several steps:
decoupling the layer with controller from the rest of the application; can be done without changes on the framework or without other external components
replace Zend_Date, Zend_Locale etc. with e.g. PHP’s DateTime and so on
replace Zend_Validate
replace Zend_Db
…
I call this a “soft migration”. Yes, this takes some time – sometimes years! But you will not be riding a dead horse in the future.
Positive side-effect: you create a solid and robust application structure for all upcoming frameworks or framework versions.
If you can change absolutely nothing, then use PHP 5.6 and ZF 1.12.20. Everything else is the same as paying for the Windows XP support.
The main repo only contains headers referencing the single components:
check https://github.com/zendframework for current activity (which is a
damn lot)
@eldt Zend Framework is far from dead. We shipped more than 100 million packages from March until December alone.
Version 1 has reached its end of life, however, which is what this particular topic is about.
ZF2 and later (ZF3 was announced over 18 months ago), which is the repository you referenced, is quite alive. However, it’s no longer being developed in a monolithic repository, but rather as individual components, which you can put together into a full-stack MVC framework (via zend-mvc and the ZendSkeletonApplication), a middleware framework (Expressive), or as a custom runtime (by including only what you want/need).
ZF1 is one of my best PHP Framework and i really like how can we extend it as much as we like and its not a black box like Symfony … I keep choosing it for my projects and i really want we continue to maintain it even if its not official.
Its a bit exagerated i guess … I like Zend 1 because the aspect of tool box, then if you are a good programmer you can manage all the other aspect of security, etc.
Its just recentry that the others framework are more modular by extracting the components seperatly.
Also its just the fact that i am too dependent to the framework and i am just configuring it with anotation and yaml files that i can’t stand and its my point of view !!!
Also have in mind that a framework have to be just implementation of the desgn patterns and with ZF1 you can still implement whatever design pattern your WAY !!! what is not with the new framework because you are using the design patterns implemented their way.
I guess its a long debate but here are my arguments why i still use ZF1
Wrong fact! There are no annotations or YAML configuration in ZF. And with version 1 you have a hard dependency to framework. Loose coupling come with version 2.
The opposite is the case, ZF1 uses some bad practices and has poor limitations.
I got it … just is the fact that i always get what i needed with ZF1 and i really gone far in modules and plugins that helps me every day in my work.
I should give ZF2 a try then. But the Yaml and Anotation i am talking about Symfony that till now i still don’t manage to accept it.
Yes, this takes some time – sometimes years! But you will not be riding a dead horse in the future.
You really should not do this. It’s like “I’m still using Windows 98 for my new Computers”.