Symfony2: disable Twig cache

Question

I'm trying to disable twig cache in prod mode, or to force it to recompile my views.

I'm using KnapLaps SnappyBundle to generate some PDFs (the same problem appears with DomPDF), and I have dynamic content to render.

When in dev mode, I can modify some text, or even some css properties, the changes are effective immediately.

But in prod mode, I need to cache:clear, or to rm -rf app/cache/prod/twig/* to see the changes.

I tried the following options in my config.yml for Twig section (not at the same time)

cache: "/dev/null"
cache: false
auto-reload: ~

I also try some stuff with header when generating and redering my pdf:

$html = $this->renderView("xxxxPdfBundle:Pdf:test.html.twig", array("foo" => $bar));
return new Response(
    $this->get('knp_snappy.pdf')->getOutputFromHtml($html),
    200,
    array(
        'Cache-Control'         => 'no-cache, must-revalidate, post-check=0, pre-check=0',
        'Content-Type'          => 'application/pdf',
        'Content-Disposition'   => 'attachment; filename='.$file
    )
);

I can't figure out how to force twig to recompile or not use the app/cache, because obviously the pdf content will be dynamic when in production.

Info update from the comments:

I perceived that even the dynamic template variables were not updated, so the same PDF got generated over and over again in production, but not in development.

After clearing all caches again, that issue is fixed: PDFs are now generated with dynamic content as designed.

Still, a question remains: what if, when my website is in production, I decide to change the CSS styling inside a pdf template ? CSS is not template variable, and I can't force people to empty their cache :/

Answer 1

The correct way to disable Twig's caching mechanism is to set the cache environment parameter to false instead of a cache directory:

# config_dev.yml
# ...
twig:
    cache: false

References:

Twig Environment Options

TwigBundle Configuration

Answer 2

The question of client-side caching has some answers.

First, HTTP employs some headers that describe to the client how to do the caching. The worst of them is to declare that the received resource should be considered cacheable for the next time X without revalidating for updates. The less intrusive version is to add a header with a signature of the delivered version or a last-modified timestamp, and the client should revalidate every time whether or not the resource is still up to date, before using it.

The first kind of caching can only be updated by deleting the client cache in the browser. The second could probably be circumvented by force-loading the page again (Ctrl-F5 or so), but this really is as hidden as the menu allowing to clear the cache.

To play it safe, the usual approach would be to add a tag, revision number, incremented counter or whatever is available, to the query string of the URL used for that resource.

1. http://example.com/generated/summary.pdf?v=1234
2. http://example.com/generated/summary.pdf?v=1235

The first URL is from deployment run 1234, the second is from 1235 - this number changes the URL enough to trigger a new request instead of getting the old version from the cache.

I don't know if there is something available in your system to act like this. You could also always add an ever changing value like the current timestamp to avoid caching at all, if you cannot disable the HTTP caching headers.