Last checked and updated on 10 Jun 2026
What Is New in CakePHP 3.9
CakePHP 3.9 is an incremental update focusing on maintenance, security, and preparing for the future. It introduces several deprecations to pave the way for CakePHP 4.0 while also adding some quality-of-life improvements and fixes.
| Group | Key Changes |
|---|---|
| Deprecations | Methods and properties deprecated for removal in 4.0, including several in View, Database, and Routing layers. |
| Improvements | Enhanced Cache::clear() method, better constraint naming in migrations, and updates for PHP 7.3 compatibility. |
| Bug Fixes | Fixes for issues in ORM, Database Schema, and HTTP client. |
| Security | Updated dependencies, including the CakePHP core to use newer, more secure versions of reliant components. |
What deprecations should I be aware of?
This release marks many features for removal in 4.0. The View class sees several deprecations, like View::loadHelper() and the $layoutPath and $templatePath properties. In routing, the RouteBuilder::extensions() method is deprecated in favor of RouteBuilder::setExtensions().
Database-related deprecations include the Type::build() method and the TableSchema::column() method. These changes standardize naming conventions and streamline the API. In practice, you'll see deprecation notices in your logs if your app uses these.
Are there any useful improvements for caching?
Yes, the Cache::clear() method now returns a boolean indicating success or failure. This is a small but practical change. Previously it returned void, so you couldn't programmatically verify if the cache clear operation worked.
// Now you can check the result
$success = Cache::clear('my_config');
if ($success) {
// Proceed
}What changed for database migrations?
Constraint name generation in migrations has been improved for consistency. When using addForeignKey() or addConstraint(), the generated names will be more predictable. This matters because it helps with database portability and makes debugging schema issues easier.
The TableSchema::column() method is deprecated. You should use getColumn() and setColumn() instead. This separates read and write operations clearly.
Were there fixes for the ORM or HTTP client?
Several bugs were squashed. A notable fix corrects an issue where the ORM could incorrectly hydrate associated data under specific conditions. Another fix addresses a problem with the HTTP client not correctly handling certain redirect scenarios.
These are the kinds of fixes that resolve edge-case bugs you might encounter in production. They improve stability without changing the public API you already use.
FAQ
Is CakePHP 3.9 a major feature release?
No, it's not. Think of 3.9 as a bridge version. Its primary role is to introduce deprecation warnings for code that will be removed in 4.0, giving you a clear upgrade path. It includes minor improvements and bug fixes, but no major new features.
Should I upgrade to 3.9 immediately?
Yes, if you're on the 3.x branch. It's a recommended maintenance release. The upgrade process is straightforward for most applications. Running your tests after upgrading will quickly show if any deprecation notices are triggered by your code.
What's the most common deprecation I'll see?
You'll likely encounter deprecations related to the View class if you override view properties or use loadHelper() in your controllers. Also, check usage of RouteBuilder::extensions() in your config/routes.php file.
Does 3.9 require a newer version of PHP?
It maintains the same PHP requirements as CakePHP 3.8.x. It's fully compatible with PHP 7.2 and 7.3. This release includes tweaks to ensure compatibility with newer versions of PHP within that range, but doesn't raise the minimum version.
How does this affect my preparation for CakePHP 4.0?
This is the perfect testing ground. Update to 3.9, fix all deprecation notices, and ensure your application runs cleanly. Once it does, your code will be largely compatible with 4.0, making the final upgrade significantly smoother.