Thanks for having me on, Scott. I enjoy this podcast very much, and I really enjoy getting the chance to talk to you.

Absolutely. CakePHP is definitely not the first thing that comes to mind in the PHP zeitgeist, but it is the first PHP framework that I got to play around with back when I was a baby developer. CakePHP is an MVC framework, not unlike Symfony or Laravel. It focuses on convention over configuration and rapid development and deployment. You might hear me talk a couple of times about the Bake tool, which is a tool that ships with CakePHP that lets you very quickly scaffold controllers, tables, models, and a variety of other classes, and it just makes it really easy to do that. It has a really healthy ecosystem of plugins and a really active developer community, and I've always found it an absolute pleasure to work with. And I've built, I don't even know how many apps off of it, and I continue to recommend it to everyone that I talk to.

Well, in the beginning, CakePHP was very heavily focused around, like I said, rapid development and was one of the first tools or frameworks to offer rapid deployment tools that were out there because at the time you had Joomla, you had WordPress, and No frameworks really offers you the ability to set up your database a certain way using third normal form, for example, where you have your articles table and your leads table, and to be able to jump into a CLI and run bin/cake bake articles, bin/cake bake articles leads, and just get so much code out of that without having to really lift a finger. That's the convention. aspect to it. If you build your database, what is considered to be the best practices way, you can get a lot of code out of that for free. Now, later on, frameworks like Laravel came along and offered many of this kind of functionality, like artisan, I believe, is the similar command. And that is a very similar concept. I haven't used Laravel too much to really compare them directly. But it is the same concept under the hood. Symfony is a bit of a different beast. I tend to think of Symfony as more of a bucket of building blocks, whereas CakePHP is instructions to rapidly build things, templates, if you will. Symfony is a great framework and a lot of CakePHP is built on top of those base Symfony components. But when you're reaching for Symfony to build your app, it means you want to get down to the really nitty-gritty stuff. And really customize the low-level functionality of your platform. Whereas CakePHP is more focused on, well, I kind of know how I want it to work and don't really care about the inner details. I'm going to leave that to the framework maintainers to guide me in the right direction. And it includes tests too, by the way, when you bake a model or a controller, you're going to get tests out of that for free. And as a junior developer, first learning the framework. I couldn't ask for a better setup.

Bake.

Yeah.

That'll, that's been known to happen. Yeah.

I was going to say, uh, yeah, absolutely. Uh, the, the problem space is the problem space. Um, these are all web frameworks, also CLI frameworks a little bit too. I can and have built some pretty cool complex CLI applications in CakePHP, just like you can do with Laravel. In fact, I think there's lots of tools out there that are built on top of the CLI interface that just use PHP's input and output layers. It's by no means limited to just the web, which is one of the things that I think it's, it's really great about it. But you have these core problems that need solved, like the need to authenticate users, the need to authorize users. The need to have read and write only database connections, the need to talk to a caching engine. I could go on and on and on about all the problems that CakePHP solves. What's great about it is that so much of this stuff is baked in and ready to go. And oftentimes you just have to reach out to a built-in component or a community-made plugin. As a plugin developer myself, I've been very pleased and how easy it was to integrate with the Cake ecosystem, as well as the breadth of the ecosystem overall. We have the awesome list and we have plugins.cakephp.org, which lists a ton of available plugins for CakePHP that people can just go out and choose and basically take them off the shelf and slot them in again, because of that convention-based approach.

Absolutely. Plugins are just extensions to the CakePHP core code that are built in a very simple way to extend or add additional behaviors to the core. I'll give you an example. The first plugin I ever made for the CakePHP ecosystem was back when Mailchimp got rid of their transactional email API. And it was very popular at the time because it had a very generous free tier. I wasn't using it for anything production related at the time, maybe some password reset emails, but when they got rid of it overnight and moved to a paid one, I and many other developers were a little bit left in the lurch. So their competitor at the time was SparkPost. So I developed a CakePHP plugin. for SparkPost. And all I had to do was go to the CakePHP docs, find their mailer class, create the SparkPostMailer class, sub in the API keys and config reads where necessary. And all of a sudden, anybody in the world that was using that plugin could easily load the SparkPost component and begin sending transactional email with a totally different API. without actually changing their business logic code, except for changing MailChimp to SparkPost. And I got some recognition from SparkPost for that. The community really loved it. SparkPost isn't around or nearly as popular anymore, but it was a really great introduction to plugin development for CakePHP.

It can, there are so many plugins, Scott, out there that do so many crazy different things. I mean, It is not, to answer your question, it is not limited to just a small set of functionality. I use a plugin at work that scans all of our controllers and builds the swagger.json file that all the API clients read to understand how our API works. There's another plugin that generates, uh, uh, uh, just a plain old PHP file that tells OPCache how to prime itself to load the application even faster. They're the authorization and authentication plugins, which are the official plugins, by the way, are extremely powerful and integrate with the dependency injection system really well. And that's just 2 of the official plugins that are available. There are probably at least a dozen. I don't have the number off the top of my head, but there are a load of really great official plugins in addition to all the awesome plugins that the community has contributed. And again, plugins.cakephp.org has all the info you could want in addition to packages, in addition to GitHub. You can find all the information on utilizing those plugins right there.

Well, it is a long and ongoing process. I'll tell you that. What my boss likes to say is it's never truly done. There will always be one more thing to port over, right? But For a production-critical application like what we're talking about, the most important thing is transparency. We have to be able to make this, uh, transition without the end users knowing, because they don't care what version of CakePHP you're on. You also have to understand the urgency of keeping your stuff up to date if you have to undergo a security audit. CakePHP 2 has lots of CVEs and dependencies on packages that have CVEs that really can't be resolved without an immense Herculean effort. So really that is the motivating factor behind getting things upgraded and up to date on the latest version of CakePHP. So to answer your question, how did we start it? I can't get too much into internals, but I could sketch it out. We decided from the jump we wanted to be API first. So we started a brand new CakePHP 5 project using the app template. which allowed us to bootstrap a whole bunch of stuff all at once. And we started out with the basics. We need, we know we need authentication, we know we need authorization, we know we need that swagger.json, just including that community plugin. We know we needed caching. So once we had all of those basics more or less handled, we then had to turn our attention to, okay, how do we actually start porting over the logic? The more research we did, The more we realized that the strangler fig pattern was a great selection for us. And for those who aren't familiar, the strangler fig pattern works by having your old code and your new code essentially run side by side. And you have a switch in between them that you control and you decide based on a variety of factors, whether you want your users to hit the old path or the new path. And it's on you to ensure that the workflow is not disrupted based on Whether they're on the old path, the new path, or a mix of the two. What that allows you to do is to deploy the new code to production over time, slowly integrating, and as things stabilize and stay stable, then you can permanently make that switch to the new code for a specific module, class, or method, and delete that old code from your codebase. It's based off of a plant called the strangler fig. Which surrounds trees and strangles them to death. That tree is your old code and you're strangling it out, out of existence to be replaced by your new beautiful code. So that is a high-level overview of how we got from CakePHP 2 to CakePHP 5. API-first was a big part of it. Tools like static analysis and linting were also a really big part of it. And the strangler pattern, the strangler fig pattern, was chef's kiss, exactly what we needed to maintain that transparency to the end users that is so critical for pulling off a gigantic migration like this without disrupting the end users and without disrupting the business.

You're talking about baby steps. I went ahead and did a long jump, an Olympian long jump. That's okay. So the answer is still very simple. Uh, one of the things that we really prioritize as members of the Cake Core team are really high quality migration guides. So if you're going from Cake 4 to Cake 5, You can find a migration guide on our docs. It's more than just a changelog, although we do have changelogs as well. It tells you exactly what's changing and what's breaking between 4 and 5, and 5 and 5.1, and so on and so forth, so that you can have this reference handy for when you're performing your upgrade. There's no automated upgrade tool. Actually, that's not true. I got to take that back a little bit. We have lately been using Rector more and more to help our users perform automated upgrades. And that's been really, really handy. Not everybody uses Rector, and it can definitely be a very powerful deep cutting tool. So between those 2, I would say a developer has a great series of tools to perform a smaller major version upgrade or minor version upgrade with relatively little difficulty.

A little column A, a little column B. Um, CakePHP is operated by the Cake Software Foundation, which was founded many years ago, and it's maintained by that organization in cooperation with partners like CakeDC. And as well as the broad open source community, including contributions from me working at TicketSauce, and Passbolt is another partner that has employees that make contributions to the framework, and the list goes on and on. It is really a melting pot of developers from all over the world and companies of all types that are maintaining and making contributions to the platform. And it results in such a healthy, variegated framework that is something that really makes CakePHP very special to me because someone might say, oh, well, my company needs this. So let me figure out how to make this a valuable contribution to the framework that benefits the entire community. And you can substitute that for any company you can think of, any business case you could think of. And it'll result in a better framework overall. So the contributions that I've seen everywhere from job queues to Swagger.json docs generators to healthy authentication and authorization plugins and beyond, there's so many contributions from different companies coming into CakePHP from all over the world and a ton of different business use cases.

Well, uh, we're always in need of translations help. We just redid our docs on VeepPress and those are brand spanking new and, uh, not every page is translated to every language. So if you speak a foreign language and would like to help translate the documentation, that would be wonderful. Uh, we are also in the process of getting ready to start thinking about getting ready to prepare to release CakePHP 6. So there are numerous features on the roadmap for CakePHP 6 that if you wanted to go take a look, all of our work is of course open source and public on the CakePHP GitHub. If you see something there that intrigues you, by all means, jump in. That's how I got my start in the CakePHP community was making small docs tweaks. And then I developed a plugin and then I developed a couple of tweaks for problems in the core. And eventually I was invited to join the core team. That could be the pathway that you follow too, out there, random developer, and we welcome you with open arms. We are a very wide group of people from all different backgrounds, and we welcome contributions from absolutely everybody.

Sure thing. So I blog on my website at blog.bryant.ai. I haven't been as active lately as I should be because I'm super busy, but I do Also post on Mastodon at S;Semicolons, S-S-E-M-I-C-O-L-O-N-S. And I do keep that up to date because I really vibe with the homies on Mastodon. I'll be attending Longhorn PHP here in about a month, mid-October, and I'm really excited for that. It's the first time I'm going in person. I've been attending virtually for the past couple of years. I'm friends with the organizers and it's always a really good time and I'm really excited to go out there. And hopefully I'll also be able to attend PHP Tech next year. I went this past June. Scott, I believe you were there too. And there's always a really ton, a ton of great information at these conferences in addition to the hallway tracks, just talking to people and learning more about them. So I want to invite everybody to come to the conference nearest you, or maybe it's not that close to you because I probably will be there because I love conferences and I love talking to people.

Thank you, Scott.