CakePHP

When and where to determine the ID of an entity

It always amazes me when I randomly come across an article or a blog post precisely on the subject that I’m mulling over in my head – all without searching specifically for the solution or even researching the problem domain. It’s almost like the universe knows what I’m thinking and sends help my way.

“When and where to determine the ID of an entity” is an example of exactly that. Lately, I’ve been working with events in CakePHP a lot. And for one particular scenario, I was considering the beforeSave() event in the model layer, which would trigger some functionality that modifies data in other models. So, having a reference of the current ID would be useful for debugging and logging purposes. But since the current entity hasn’t been saved it, the ID is not there. And that’s where I started thinking about this whole thing and considering where is the right place to generate the ID.

One thing that kind of bothered me on top of the theoretical discussion, was the practical implementation, especially in different frameworks. If I remember correctly, the earlier version of CakePHP framwork, used the presence or absense of the ID in the entity to differentiate between insert and update operations. It might still be true now, but at least there is a way to work around it, as CakePHP now has isNew() method to check if the entity needs to be inserted or updated.

ORM: Active Record vs. Data Mapper

Everybody building a web application with a modern framework, is already probably using an ORM (Object-Relational Mapping). Most frameworks include one out of the box. But digging deeper into the subject, ORMs do vary from each other, and some cases, very significantly.

Most variations are coming from two main approaches: Active Record and Data Mapper. I’ve heard the terms for a long time, but today decided to look into the meaning and the actual difference.

The two approaches seem very similar. The difference is described in a multitude of articles online. I particularly liked this one. In essence, Active Record is a better choice for simpler, CRUD-based applications. Data Mapper, on the other hand, is better for domain-specific applications, as it provides another level of abstraction between the domain objects and the persistence layer.

Most of my work these days is done with CakePHP framework, which I now thought uses the Active Record pattern. But it turns out that CakePHP ORM so powerful, because it’s more than just one of those:

The CakePHP ORM borrows ideas and concepts from both ActiveRecord and Datamapper patterns. It aims to create a hybrid implementation that combines aspects of both patterns to create a fast, simple to use ORM.

It looks like I need to do some learning and dig deeper into the subject. Pointers are welcome.

CakePHP 3.6.0 release

My all time favorite PHP framework – CakePHP has recently announced the availability of the long awaited version 3.6.0. What’s so special about this particular version? – those of you not very familiar with CakePHP might ask. And I’ll tell you.

CakePHP is a well established framework, with long history – going strong for 13 years now (initial release was in April of 2005). In web development, 13 years is a very long time. Old tools fade away. New versions of the language and popular libraries come into play. And it’s the job of the framework to change and adjust smoothly, providing the developer with the best and greatest, without breaking applications. That’s not an easy task – ask anybody who had to maintain any codebase for longer than a couple of years.

I started using CakePHP back in 2007-2008 or so. It was version 1.x and it was great. At the time. Then, a few years later, version 2.x was released, and as a major releases often do, it broke backward compatibility. The most painful change at the time was still easy to fix – it was the change in the naming convention for folders, files, and classes. CakePHP 2.x switched from their own naming convention to the PSR-2 Coding Style.

About 4 years ago, CakePHP 3.x was released, and this time it was the major of the major releases. CakePHP framework got a lot better (and I do mean A LOT), but the price was an impossible migration. One of the big changes in that version was the complete rewrite of the model layer and the ORM, which meant moving the CakePHP application from version 2.x to 3.x meant an almost complete rewrite (as most applications have most of the code in the model layer anyway).

That was a huge pain and community reacted. Everybody wanted to use the cool new features of CakePHP 3, but nobody could afford to rewrite almost all of the application for this version of the framework. (By the way, this situation is not unique to CakePHP – pretty much all other frameworks, both in PHP and other languages, either faced it or will face it in the future – that’s just how things are done).

When the CakePHP 4 roadmap was announced, one of the first things that CakePHP core developers team addressed was the upgrade path. From the start they said that there must be a better way to handle major upgrades of the framework, and that they will find it. And they did!

This time around, there was some ground work laid out. Instead of just dropping another major release into developers’ laps and all the upgrade pain that comes with it, CakePHP developers absorbed a lot of it on their end, and softened the transition. How did they do it?

Well, that’s where we get to the exciting CakePHP 3.6.0 release! You see, the plan was do provide the gradual transition and give developers warnings and time to adjust their applications. From the early stages of the CakePHP 3.x, a lot of functionality was commented as deprecated. Any developer building with CakePHP framework could easily find what’s gonna go in the next major release. But developers are always busy and never have the time for looking up things. So what CakePHP 3.6.0 does is quite elegant. It introduces deprecated warnings for all the functionality that will be removed in CakePHP 4. This means that once you upgrade to CakePHP 3.6.0 your logs will get a lot noisier, telling you exactly what needs fixing. If you don’t have the time right now, or want to ignore these warnings for now, you can simply disable them by adjusting the error reporting configuration, and all works as before. But if you want to get ready for the next major version of CakePHP, then you have precise information of what needs to be fixed in your application. Fixing one issue at a time, when you have the time, is great!

In fact, at work, we loved this approach so much that we started using it for our own projects as well. Switching between different projects across several developers, and working on some old projects, etc., makes things difficult to remember. With deprecated warnings, things are a lot simpler.

So, ladies and gentlemen, if you were looking for a framework to try, give CakePHP 3.6.0 a go. You’ll easily upgrade to CakePHP 4 when it becomes available. And if you were already using CakePHP 3, upgrade to CakePHP 3.6.0 and check your logs for deprecated warnings.

And, of course, stay tuned for CakePHP 4!

rector – reconstruct legacy PHP codebase to modern standards

rector looks like an excellent tool for those days when you need to rewrite large chunks of legacy code for the modern coding standards and best practices. Of course, there are IDEs that can help a lot with refactoring, but they are usually complex and slow. Regular expressions have always been a poor man’s choice for replacing old code with new code. But life can be easier and better. rector helps you find and replace things like namespaces, class names, method names and property names; change type hints and values of parameters; replace magic methods with their real implementations, and much more.

I’m sure I’ll be trying it out Real Soon Now ™, with the upcoming release of CakePHP 3.6.

CakePHP with NightwatchJS on Travis CI

My colleague Andrey Vystavkin has been setting up a testing environment for our CakePHP projects recently. We had one before, of course, using PHPUnit. But this time we wanted to add Google Chrome headless browser with some form of JavaScript test suite, so that we could cover functional tests and a bit of front-end. Andrey described the configuration of NightwatchJS on TravisCI in this blog post. If you are more of a “show me the code on GitHub” person, have a look at this Pull Request (still work in progress) on our project-template-cakephp project.

Once we are happy with the TravisCI configuration, we’ll be bringing this setup to our BitBucket Pipelines environment as well.

The setup is also based around CakePHP framework, but it’s easy enough to adopt it to any other framework, PHP or not.