Decrepation treadmill

1

This is more of a request than a problem, but could the CakePHP core developer please cut down on the number of deprecations they introduce?

Right now I am converting an old CakePHP 1.3 based website to CakePHP 3, and inside the 3.x cookbook quite a few functions are already deprecated; most are only trivial renames like Email->subject() to Email->setSubject(). I’m a bit surprised that this happens even within a major release cycle; secondly, it would be nice if the examples are also immediately updated.

But today I checked out the AuthComponent document, and lo and behold I read:

Deprecated since version 4.0.0: The AuthComponent is deprecated as of 4.0.0 and will be replaced by the authorization and authentication plugins.

and I’m like: “WTF? I just implemented the new authentication mechanism. Does it ever stop?!”

As for a rationale: this website is for a customer; he grudgingly approved the update because of the imminent phasing out of PHP 5.6. So this is costing the customer money, which is a-okay for the PHP reason but I can hardly justify charging him for changes just because the Cake core developers think it’s “better”.

With Cake I’m feeling that I am on a constant “deprecation treadmill”; just when you think you have a stable set you have to go back in and re-do your work. I wonder if others feel the same.

2

Yes it stops when you stop writing and using framework biased code.

I write my own RBAC, I have code that works great in cake, yii2, and laravel.

I used to program in java (servlets, jsp, ejb) for a medium sized trucking and logistics company.

Servlets and jsp does not come with “out of the box” RBAC, or pagination, etc.

So I learned to write paginators, RBAC code, etc a long time ago. My RBAC works no matter the framework.

In my cake helpers I use and like static methods, so I did have to also work on using session in a static method.

See (Solved) Use session in static method (cakephp 4) - #11 by jimgwhit

But I have used laravel since 4.2, am number 14 on their top 50, and have been a major contributor to another framework. So I know and understand inner workings pretty well. Of course not as smart as the cake or laravel team at the inner workings.

Bottom line, don’t be framework biased, learn php (not just cake, but php), because you will find in those vendor folders the “behind the scenes” engine is hard core php and pdo.

Look at the top layer of a framework like shortcuts. The vendor folder to make the “shortcuts” happen is the real heavy programming.

I still use cakephp also for some projects. Right now caught up and just playing around with cakephp 4.

I like the php extensions now for view, I did not like the ctp.

3

Learn PHP? I’ve been programming PHP long before frameworks came out… Frameworks are a double edged-sword: you get a lot of functionality but you also take a performance cut.
Anyway, thanks for your feedback, but it doesn’t really address the issue.

4

To me it is the exact issue, I use Cake, Laravel, and Yii2.

I am not about to use

  • Laravel authentication and authorization in laravel
  • Cakephp authentication and authorization in cake
  • yii2 authentication and authorization in yii2

Not when I have good RBAC that works in any framework. However I did tweak it
in laravel, since laravel has great “out of box” authentication, I wrote the helpers to work with that and the roles I setup.

If you “know” php well, why in the World woud you use a frameworks “shelved” authentication and authorization.

I like the ability to use a frameworks MVC, it’s build there already. But that doesn’t mean you have to use the ORM for example. For complex reports I use normal PDO with proper bindings of course.

All the major frameworks have the PDO instance.

But just my 1.5 cents.

Just be careful, if you get too frame_workmatized (biased), it could paint you in a corner.

5

Right now I am converting an old CakePHP 1.3 based website to CakePHP 3

Last release of Cake 1.3 was in October 2015 and even CakePHP 3.x is nearing end of it’s cycle as we get ready for Cake 4.x. So you are way behind the framework’s release cycle, you can’t really fault CakePHP for that.

most are only trivial renames like Email->subject() to Email->setSubject()

All methods which were combined getter/setter have been split into separate methods. So for e.g. instead of subject() you now have getSubject() and setSubject(). This results in cleaner API and reduces potential usage errors.

I’m a bit surprised that this happens even within a major release cycle; secondly…

Deprecations are an inevitable part of release cycles. The deprecations actually help users keep their code base up to date and making upgrading for next major release easier.

it would be nice if the examples are also immediately updated.

We do our based to try to keep the docs updated as possible but as a small team of volunteers who contribute their time for free something we get behind at times.

and I’m like: “WTF? I just implemented the new authentication mechanism. Does it ever stop?!”

Well the AuthComponent isn’t “new”. It’s existed since Cake 2.x. Even the first release of Cake 3.0 was in March 2015.

As for a rationale: this website is for a customer; he grudgingly approved the update because of the imminent phasing out of PHP 5.6. So this is costing the customer money, which is a-okay for the PHP reason but I can hardly justify charging him for changes just because the Cake core developers think it’s “better”.

This is something we developers have to deal with regularly and there’s no easy solution to that. It’s always difficult to explain and convince customers why staying reasonably up to date with the tech is necessary. If they aren’t willing to pay for upgrades then they will stay with unsupported versions of the language / framework.

With Cake I’m feeling that I am on a constant “deprecation treadmill”; just when you think you have a stable set you have to go back in and re-do your work.

I think the major cause of your grief is unfortunate timing. You are upgrading to 3.x when it’s already near the end of it’s release cycle and that’s the reason you feel there are too many deprecations. You would have been in same situation with any other framework, maybe even worse. We provide much longer support for each major branch then most other frameworks.

1 Like
6

IMO your mindset is wrong, deprecations are friendly info from devs thats saying “we will remove this method in future”, cake uses semantic versioning and your code will still be working up to version 4.0 when they will remove those deprecations

untill then just set https://book.cakephp.org/3.0/en/appendices/3-2-migration-guide.html#disabling-deprecation-warnings if you dont want to see them, then enable it back to update to latest 3.x version and then update

7

Last release of Cake 1.3 was in October 2015 and even CakePHP 3.x is nearing end of it’s cycle as we get ready for Cake 4.x. So you are way behind the framework’s release cycle, you can’t really fault CakePHP for that.

Well, 4.0 is not out. So I am not going to develop production code on that. In fact, I’ll probably wait until 4.1 or 4.1 until the bugs are ironed out.

But this also highlights exactly my problem. 4.0 is around the corner, so once that’s out it’s the same mantra again: upgrade, upgrade, upgrade. Most major software packages / frameworks that I am aware of keep major versions in parallel: PHP: 5 and 7; GCC: 6, 7, 8 and 9; Qt 4 and 5 (though 4 is really shelved); Python 2 and 3; Windows 7, 8 and 10; any major Linux distribution. CakePHP seems to be the only framework where the previous version is immediately declared dead when the new version arrives.

All methods which were combined getter/setter have been split into separate methods. So for e.g. instead of subject() you now have getSubject() and setSubject(). This results in cleaner API and reduces potential usage errors.

I agree it’s more consistent.

Deprecations are an inevitable part of release cycles. The deprecations actually help users keep their code base up to date and making upgrading for next major release easier.

[sarcasm]Yeah, I also have infinite amounts of time and my customers very deep pockets.[/sarcasm]

Well the AuthComponent isn’t “new”. It’s existed since Cake 2.x. Even the first release of Cake 3.0 was in March 2015.

I know it’s behind. Nothing I can do about it.

I think the major cause of your grief is unfortunate timing. You are upgrading to 3.x when it’s already near the end of it’s release cycle and that’s the reason you feel there are too many deprecations.

Again, why is this immediately the end of the release cycle?

You would have been in same situation with any other framework, maybe even worse. We provide much longer support for each major branch then most other frameworks.

As I pointed out above, other packages keep versions in parallel.

Thank you for your answer, but personally I think it’s time for me to re-evaluate frameworks for future projects.

8

You’re reading too much into it. even a 3.* cake version will be good for some time to come.
And updates aren’t always necessary unless a security update.

To add, java has good backwards compatibility, some older j2ee stuff I did years ago, I tested code on latest, and it worked. I do not use it no longer, was just playing and testing.

Years back that’s what drew enterprise to java.

Also I have a custom framework that is about 6 years old. But I keep my main copy tweaked and updated, even works great on php 7.3 now.

Remember, you can always use a framework for the mvc shell only, yet do custom coding as needed.

To add some Modern Frameworks do change real often where as PHP seems more stable.

Even laravel is every six months but usually updates aren’t too drastic.

It seems just the way things go nowadays super fast change as compared to 10 to 15 years ago, much slower back then.

It would be nice if even PHP would do a 7 to 10 year cycle instead of three. Or at least much longer backwards compatibility like 7 to 10 years.

Then the Frameworks could increase their cycle.

But much of the fault are the users, they demand and want the latest thing now instead of patiently waiting.

9

I feel your pain, having migrated two pretty large projects from 1.3 to 3.x. One of them is stuck at 3.3 for now because of the client, and I’ll need to fight this battle with them soon to move to the middleware architecture to cleanly solve some things they want done.

But the authentication and authorization middleware, which replace the Auth component, have been out for about 2 years now. If you did your homework when you started the upgrade, you should have seen all the notices about things being removed in 4.0, and taken them into account. From what I’ve read, 4.0 is basically just the latest version but with all deprecations removed, and most of those were introduced for PSR compatibility no later than 3.6, which was released over a year ago now. So unless this upgrade is over a year in the making, you should have been working without using deprecated functions and classes in Cake 3.6 or higher, and it would be a pretty trivial migration to 4.x when you decide to go there. But nobody is forcing you to go to 4.x on any particular schedule. If you need the Auth component, then keep using whatever 3.x version you’re working to at the moment, and worry about 4.x later.

10

4.0 is around the corner, so once that’s out it’s the same mantra again: upgrade, upgrade, upgrade.
[sarcasm]Yeah, I also have infinite amounts of time and my customers very deep pockets.[/sarcasm]

No one’s forcing you to upgrade. If older versions work for you then keeping using them. You can even just silence the errors and keep using deprecated methods in 3.x and update them only if / when you decide to upgrade to 4.x.

CakePHP seems to be the only framework where the previous version is immediately declared dead when the new version arrives.
Again, why is this immediately the end of the release cycle?

Perhaps my previous comment wasn’t clear but end of release cycle of a major version surely doesn’t mean we declare it as dead. 2.x kept getting new minor and then bugfix releases in parallel years after 3.0 was released. 2.0.0 was released on Oct 17, 2011 and 2.10.18 was released on May 13, 2019.

After 4.0 is released 3.x will also continue to get bugfix and security releases.

Thank you for your answer, but personally I think it’s time for me to re-evaluate frameworks for future projects.

It’s your prerogative but the issues you are have raised regarding deprecation and release cycle of CakePHP are I’ll found. You will have to deal with deprecations and upgrading to new major releases with any framework. In fact we provide one one of the best support duration for major versions as I showed with release dates for 2.x. Laravel for example does backwards incompatible release every 6 months (they don’t follow semver) and even their LTS version gets bugfixs only for 2 years.

2 Likes
11

Well having to maintain about 20 independent CakePHP3 applications - I can say for sure upgrading a project get a lot easier when you have done it a dozen times already. :smiley:

12

No one’s forcing you to upgrade. If older versions work for you then keeping using them.

Well, in this case our hand was forced due to the PHP 5 end-of-line. But that’s are.

Perhaps my previous comment wasn’t clear but end of release cycle of a major version surely doesn’t mean we declare it as dead.

Okay, that’s good to know.

After 4.0 is released 3.x will also continue to get bugfix and security releases.

Fair enough.

You will have to deal with deprecations and upgrading to new major releases with any framework.

That, I don’t contest. It just seems that CakePHP goes a lot faster in that respect. Anyway, I’ll keep plodding on the upgrade… It is also a good time to remove dead code, fix mistakes from the past and make it a bit more maintainable by using re-usable Elements and such. Not all is lost!