A while ago the Symfony project published a “Best Practices” book.
This is a source of excellent suggestions and it’s written by the people who wrote Symfony in the first place, so we decided to stick to it as much as possible, even in those few cases where the benefits where not immediately clear.
But after a few more Symfony projects, there is one best practice that I definitely want to question: the location of the templates.
Continue reading Symfony template locations: questioning the best practice
I had the need to write to a custom log file, but with the additional constraint that the file name was not known until runtime (UUID for a new entity).
On the Symfony Cookbook there is already a recipe about using different log files but it relies on a configuration made before the execution.
After a little experimenting, here’s the simple solution I implemented:
$logger = new Logger('import');
$logger->pushHandler(new StreamHandler($kernelRootDir . '/logs/' . $runtimeGeneratedId.'.import.log', Logger::DEBUG));
An established practice in web applications is to resize user images during uploads: I am suggesting a different approach instead, which relies in creating on-the-fly the requested size thumb.
Continue reading A design patter: don’t resize images during uploads
I recently wrote about the assets:install command, but there’s a more interesting way to handle your assets: Assetic.
Continue reading Symfony assets management: assetic:dump
In your Symfony application there are bound to exist many assets (JS, CSS, and so on) either created by you or provided by third-party bundles.
As part of your deploy procedure, you usually have to use some Symfony console command to actually make the assets available to the frontend of your application.
Let’s start with the most basic solution: the assets:install command.
Continue reading Symfony assets management: assets:install