Pretty name, huh?
This plugin allows to configure dynamic Symfony templates cache invalidation on Doctrine objects persistence operations. In other words, you can quite easily define which cached templates will be deleted when your models will be updated.
This can be useful when you need performance using Symfony, Doctrine and Template Caching.
No, seriously, we're all grown-ups here. Just don't forget to enable the plugin in your ProjectConfiguration.class.php
and clear your cache.
Create a doctrine_cache_invalider.yml
file in the config
folder of your project (or the one of any plugin, if you work with plugins), and define template cache uris for each Doctrine model you want:
Article:
uris:
MyContent/index?sf_culture=*: frontend
MyContent/article?sf_culture=*&slug=%slug%: frontend
Comment:
uris:
MyContent/article?sf_culture=*&slug=%article_slug%: frontend
Note that the Article
and Comment
Doctrine models should be defined in your schema.yml
file.
As you can see, you define template cache uris by their internal Symfony one, plus you define the application name where the cache is used, eg. frontend
. This is especially useful if you work with a backend
application (eg. using forms provided by the admin-generator) and want your frontend
templates cache files to be invalidated when records are created, deleted or updated.
You can also define several applications where the cache uris are used, for example if you share some templates accross applications:
Article:
uris:
MyContent/index?sf_culture=*: [frontend, otherapp]
MyContent/article?sf_culture=*&slug=%slug%: [frontend, otherapp]
Comment:
uris:
MyContent/article?sf_culture=*&slug=%Article.slug%: frontend
Also note the %field_name%
-like and %RelatedModel.field_name%
-like parameters, they're just placeholders and will be replaced by the record and related object field value of the model instance which is being created or updated.
I18n is also managed, so if your models implement the Doctrine I18n Behavior, supplementary template cache uris will be invalidated to handle all available translations for the field.
Also, the configuration allows to inherits rules from ones already configured for a given model using the extends
keyword, eg.:
Article:
uris:
"MyContent/index?sf_culture=*": [frontend, otherapp]
"MyContent/article?sf_culture=*&slug=%slug%": [frontend, otherapp]
FrontageArticle:
# will inherits all uris defined for Article
extends: Article
uris:
"MyOtherModule/homepage?sf_culture=*": frontend
The plugin ships with a special cache uri which is *
; this cache uri is a shortcut to tell the plugin to remove all cache related to a given application:
Article:
uris:
"*": frontend
Here all the cached templates for the frontend
application will be cleared.
You can disable cache invalidation for an application, like frontend
for example, in its related app.yml
file:
# apps/frontend/config/app.yml
all:
akDoctrineTemplateCacheInvaliderPlugin:
enabled_listener: false
If you want to see sample use, check out the bundled fixture project provided in the functional tests of the plugin.
This plugin is licensed under the terms of the MIT license.
This plugin is developped by Nicolas Perriault.
So, why the hell is this plugin prefixed with ak
? Because it's a plugin I've developed and am currently using in my company, Akei...