Always use proper version check method
Be aware of version checks that are using the inferior and even wrong </> comparison.
This can lead to wrong conditions with higher minor versions.
I had this in my code from the early 2.x days:
if ((float)Configure::version() < 2.4) {
...
}
With the upcoming 2.10 release this will now suddenly start to return true. Luckily my 2.next tests already revealed that and I was able to fix it up properly:
if (version_compare(Configure::version(), '2.4') < 0) {
...
}
This will now work in all minors of 2.x.
The same is true for 3.x, of course, even though we are "only" at 3.3.6 at this point in time yet.
Order your flash messages semantically
You can use the Flash plugin to enhance your flash messages a bit.
It works out of the box with your current setup, but adds a few useful things on top:
- Prevent size and output issues when running into a redirect loop boiling up messages in the session (>> 50) by limiting the stack to 10 by default.
- Use ordered output (error first, then warning, success and lastly info). Errors should be visible first in case multiple types are to be displayed.
Switch away from basic log files
I would switch away from basic log files to database – even if it is just a simple SQLite one like DebugKit uses.
This way you can more easily navigate and filter through them.
Check out the DatabaseLog plugin which can do exactly that in just a few minutes of configuration.
For not just personal fun apps it is advised to look into a bit more sophisticated approaches, like using Monolog and services like NewRelic to write to. But for smaller projects it can be enough to have a small admin backend to filter through the logs, especially error and warning types.
Keep your controller code lean
That specifically includes all those verbose allow statements to make certain pages public:
use Cake\Event\Event;
...
/**
* @return void
*/
public function beforeFilter(Event $event) {
parent::beforeFilter($event);
$this->Auth->allow('index');
}
See TinyAuth which since recently allows to more cleanly declare this with a single INI file in your src/config folder.
The complete code above goes away for every controller 🙂
As long as not needed (custom dynamically made decisions based on session or alike) this kind of noise should be kept out of the controllers.
This makes it also possible to modify the public access to actions without the need to be a developer. The next step could be to make the input for TinyAuth database-driven and alike.