Once I used Nestedset behavior for Doctrine, Symfony in a project, and faced issue with broken indexes. (You can read how Nested Set works here). This happened because low-level MySQL query executed during migration, and because of this Doctrine events responsible for refreshing indexes was not executed. To fix that a Symfony Command was written, which refreshes indexes. This is just example. Better way is to move this code to the service and add one more migration which will refresh indexes. Here is just simple example how this issue can be solved.
Argument of the command is an entity to refresh.
Uploading files in Symfony is conceptually no different from other PHP platforms, but still has its own features due to the presence of additional tools provided by the framework.
First of all, it is worth noting that there are ready-made solutions that solve the task at hand. I strongly recommend familiarizing yourself with them, and only after that, if you decide that they do not suit you, implement your own solution.
In this note we will try to show possible ways to solve the task, using both ready-made solutions (VichUploaderBundle, IphpFileStoreBundle), and using our own implementation (in Symfony controllers and admin classes from the SonataAdminBundle).
When using SonataAdminBundle and SonataBlockBundle, I wanted to remove the default block.
It doesn't provide much benefit, as it simply duplicates the functionality of the side menu on the dashboard.
When installing SonataBlockBundle, if we simply write in the configuration:
sonata_block: default_contexts: [sonata_page_bundle] blocks: 
(in the future we will add our own blocks, but for now we just leave an empty array), we will catch an error.
As a backend, SonataAdminBundle is used. Implemented:
1. Admin panel (WYSIWYG, ckeditor), image/audio uploading, player.
2. Tags, categories, archives, tag cloud
4. RSS-feed (requires modification)
5. "Smart" caching of everything, content is served very fast
To "ease the soul":
Widgets Bundle - a bundle for easy widgets management. (Supports only widgets which require only client-side code for displaying). Includes both client side (for displaying) and admin side (adds admin classes and has a SonataAdminBundle dependency) functionality.
Can be used (for example) for adding counters, banners, advertising network codes (google adsense, etc).
Was created during this blog has been developing.
During developing this blog I invented one more bicycle for Caching Symfony controller. But first of all lets see how did this task arose.
For example, I have a list of categories, archives and tags on a sidebar. It is relatively easy to get last one (one query), but much harder to get list of categories and archives. For getting categories, we need to select trees (categories can be nested) and using subqueries inside queries get number of articles in every category (result is a little bit monster). For getting the archives list, we need iterate over all articles and gather list of years/months. All this actions isn't very sophisticated, but it is better to avoid them.
When developing a medium to large project, there is a problem with localizing numeric/money data. In this note, I will talk about the difficulties of using the Symfony framework, Sonata Admin Bundle, and the client-side. But first, let's discuss the essence of the problem, as it is not very obvious at first glance.
The simplest way to customize the login form in FOSUserBundle is to use the mechanism of bundle inheritance. (Assuming that in the future it will be necessary to modify not only the login form). Let's show an example of such customization using bootstrap.
Fixtures (Eng. fixtures) - a very useful development tool. Essentially, it is just a set of test data used in dev mode. They are typically not used in prod mode (for production, Data Migrations are usually used).
There are several convenient bundles for working with fixtures in Symfony. The first one is the basic DoctrineFixturesBundle, which is dedicated to this article.
When creating a bundle, it is useful to configure it, which will be used as a library (and not only).
Of course, you can put everything in parameters, thus avoiding configuration, but that would not be kosher. =)
Proper practice is to describe the configuration in config.yml, and to extract some necessary parameters into parameters.yml: