This year I want to quickly put a few useful things out there again for you in terms of CakePHP development and ecosystem.
CakePHP 4 preview
Check out CakePHP 4 while it is still not RC (release candidate) and therefore not fully frozen yet in terms of API.
You can still give valuable feedback and input on missing functionality or help to look into open issues/PRs.
Plugin upgrades
Take a look into the ecosystem and plugins which could need some help upgrading now that the
4.x version stabilized. I recommend using cake-4.x/cake4 branch names here until the core is stable enough (RC) to do first pre-releases.
Don’t use 4.x if this is not by chance also the major plugin version it will become – to avoid confusion.
Tip: The awesome wiki contains a list of already started upgrades. Add yours there, as well.
Version map
If you maintain a plugin, it can (without framework-sem-ver) become quite difficult to understand what version of the plugin fits to what version of CakePHP/PHP.
As such I recommend using a version map in your wiki that you can link to from your README file:
| MyPluginName plugin | CakePHP core | PHP min |
| --- | --- | --- |
| 0.x | 3.x | PHP 5.6 |
| 1.x | 4.x | PHP 7.2 |
...
And in your README below the headline:
This branch is for use with **CakePHP 3.7+**.
For details see [version map](https://github.com/.../.../wiki#cakephp-version-map).
See e.g. dereuromark/cakephp-ide-helper/wiki#cakephp-version-map and the corresponding README link.
Shims
Shimming can help to modify CakePHP 3 apps to be closer to CakePHP 4 to make the jump easier (forward compatibility). It can also help when upgrading (to 4.x) to keep BC (backwords compatibility) on some 3.x removals by not having to modify that code (run 3.x code in 4.x) until all is working again and you have time to do further refactoring.
Shim plugin to the rescue:
- You can already slowly prepare to get your 3.x app very close to the behavior of 4.x in terms of changed behavior, like referer local handling, which is also security-relevant by the way.
Forward compatible (FC) shims include:
- Extra deprecations
- Controller
referer()local security fix - BoolType, StringType, DecimalType, JsonType behave like in 4.x
- Table
newEmptyEntity()method available
Once the upgrade is complete, the 4.x version helps especially for large code bases to not have to fix everything at once:
- FormHelper BC for datetime
- Property declarations for several classes, including default sort order for models
And on top of all it helps to provide some valuable fixes or enhancements to core, e.g.:
- Continue to provide Nullable behavior for better data consistency
- Convenience wrappers
Feel free to help out and provide shimming enhancements for both 3.x and 4.x branches.
PHP 7.4 preview
CakePHP master has already been adjusted to work with early drafts of what PHP7.4 might look like.
The most important changes, that you might want to look into early on are:
-
{0}access on strings, which should be rather[0], e.g.if (is_string($tags) && $tags[0] === '<'). I would still rather usestrpos()orsubstr(), though. -
array_key_exists()on objects was apparently never a thing that should have been used. Use here->offsetExists()on the object instead. It makes no sense to me that they remove it rather than fixing it (since it would then be consistent around array vs ArrayObject usage topics), but so be it.
Speed up your Travis builds
You want to have quicker results on your Travis builds for your plugins?
Add this before_install part before your before_script composer install execution:
before_install:
- composer global require hirak/prestissimo
- phpenv config-rm xdebug.ini
before_script:
- composer install --prefer-dist --no-interaction
The xdebug removal should be fine as long as you are using coverage collection with a tool that does not require this (e.g. phpdbg).
Add basic caching on your composer content:
cache:
directories:
- $HOME/.composer/cache
This way both cache and cache-miss runs are super fast now.
Also: I recommend not adding all minor versions from 5.x to 7.x, instead use min/max boundaries and then 1-2 in between together with variations on DB, tooling and coverage or alike.
Check out my IdeHelper travis config.
Use background processing for async tasks
Sure, this is something which these days everyone knows. Deferring some tasks to the background is really important and useful for any (PHP) application.
Almost 6 years ago I blogged about this. It might be time to retrospect a bit.
The dependency less Queue plugin become quite popular in recent years, being so easy to run and deploy on PHP servers.
It also became a bit easier to integrate into PHP applications in terms of feedback and processing status of jobs.
From 31.07.2019 via Mixer plugin/tool CakeDC/mixer
If you haven’t used any queueing yet, check your code and find the spots where you are able to use it. There will always be a few spots you could actually integrate it for a better workflow. You can speed up page load with faster feedback and a message of the job being "started".
You can send mails or access APIs this way allowing it to auto-retry (x times configurable) in case of gateway/API timeout/server issues.
With the latest changes and the fresh new major (v4.0 for CakePHP 3.7+) there are very powerful improvements, however, that also can help for more demanding use cases.
In our case, we had quite some long-running and memory/CPU expensive jobs to run regularly. Now, with 1-2 servers and several workers each you cannot run a "composer update" or alike (that requires > 2GB of memory each run) multiple times in parallel without deadlocking everything.
So we came up with something I call "costs". Each job now can have a value from 1…100 assigned, and each server collectively counts the current points left and workers pull only what is fitting. This basically allows low-cost jobs to be still run in parallel, while the others are somewhat serialized per server. With this, we have no overloading of servers anymore and all jobs finish in a reasonable timeframe.
A bake command now even helps you to generate a Queue task as well as its test case.
Check out the latest version and give some feedback on it.
Tip: The Sandbox examples showcase some basic use cases, well – live for you.