Next to the already available DoctrineCacheAdapter this PR adds a PSR-6 compatible adapter, which without any BC break allows to easily implement one of the pools available at:

http://php-cache.readthedocs.io/

In my opinion, and I think @Nyholm agrees with that too, it would be better to completely follow PSR-6 and get rid of all adapters, but that would be a huge BC break. I'd propose to release 1.3.0 after merging.

Referencing the ... extension by its name (defined by getName()) is deprecated since 1.26 and will be removed in Twig 2.0. Use the Fully Qualified Extension Class Name instead

The "Asm89\Twig\CacheExtension\Extension" extension is not enabled.

I just did a composer update and spent a lot of time on figuring out why the application is not working. Then next day in the morning I just got an idea and it worked. Here is the patch.

The problem occurs when I'm using the emanueleminotto/twig-cache-bundle, it has a class that extends this one, and then probably the child class is registered as service.

When working with designers it would be convenient if you could omit the versioning portion of the cache key, so you can use {% cache 'user' %} instead of {% cache 'user/v5' %}.

The problem is, that if you have a complex structure of templates, where a tree of other templates is included inside the cache tag, then you have to version the key every time you change one of the included templates. Sometimes someone forgets to do this and this leads to unexpected results.

Rails handles this by automatically including the hash of the contents and by all templates which are included as partials inside the cache tag. That's called "cache digests" and I found a post which also describes this problem: http://blog.remarkablelabs.com/2012/12/russian-doll-caching-cache-digests-rails-4-countdown-to-2013

What do you think of this @asm89?

We'd like to have a namespace with our keys, the GenerationalCacheStrategy and LifetimeCacheStrategy already use some sort of prefix (e.g. __GCS__ and __LCS__). I'm aware that we easily can add it to the key in Twig itself, but that seems wrong.

What about refactoring these "prefixes" to the interface and making it an optional constructor argument?

interface CacheStrategyInterface
{
    private $keyPrefix;

    // ...
}

class LifetimeCacheStrategy implements CacheStrategyInterface
{
    private $keyPrefix = '__LCS__';

    // ...

    public function __construct(CacheProviderInterface $cache, $keyPrefix = null)
    {
        // ...
        if (!is_null($prefix)) {
            $this->keyPrefix = $keyPrefix;
        }
        // ...
    }
}

Our use-case is quite easy, we want to include the Symfony environment in our cache key. Basically I'd like to eventually have the prefix as a configuration parameter in the TwigCacheBundle.

I'm rendering big list of categories using ul+li. Selected category should use span instead of a. Using standard way (cache key depends on active category id) we store N keys, N - categories count.

This is inefficient:

1. cache size growth
2. cache miss rate big
3. hard to invalidate cache. If we have something like products count near the category then we should invalidate all of the N keys when adding new product to one category. So cache miss rate will increase

I'm proposing add some syntax for second pass for cached entry. Example:

{# original - required N cache records #}
{% cache 'sidebar-categories'~activeCatregory.id ttl %}
    {% set categories = categoriesHelper.loadCategories() %}
    <ul>
        {% for catrgory in categories %}
            <li>
                {% if category.id == activeCatregory.id %}
                    <span>{{ catrgory.title }} ({{ category.productsCount }})</span>
                {% else %}
                    <a href="{{ category.url }}">{{ category.title }} ({{ category.productsCount }})</a>
                {% endif %}
            </li>
        {% endfor %}
    </ul>
{% endcache %}

{# with second pass syntax, only 1 cache record #}
{% cache 'sidebar-categories' ttl {'activeCatergoryId': activeCatergory.id} %} {# pass activeCatregoryId to the cached rendered template #}
    {% set categories = categoriesHelper.loadCategories() %}
    <ul>
        {% for catrgory in categories %}
            <li>
                {% cache_expression('if ('~category.id~' == $activeCatregoryId:') %}
                    <span>{{ catrgory.title }} ({{ category.productsCount }})</span>
                {% cache_expression('else:') %}
                    <a href="{{ category.url }}">{{ category.title }} ({{ category.productsCount }})</a>
                {% cache_expression('endif;') %}
            </li>
        {% endfor %}
    </ul>
{% endcache %}

// will compiled to smth like
<ul>
    <li>
        <?php if (1 == $activeCategoryId): ?>
            <span>category 1 (59)</span>
        <?php else: ?>
            <a href="#ololo">category 1 (59)</a>
        <?php endif; ?>
    </li>
    <li>
        <?php if (2 == $activeCategoryId): ?>
            <span>category 2 (80)</span>
        <?php else: ?>
            <a href="#trololo">category 2 (80)</a>
        <?php endif; ?>
    </li>
</ul>

Syntax sux, but I hope you understand the goal.

The Twig_NodeInterface interface is deprecated in Twig 1.x and will be removed in Twig 2. Changing Twig_NodeInterface to Twig_Node should make the extension ready to support both Twig 1 and Twig 2 for now.

In php I'm defining time=time(); This is my twig code:

{% cache 'v1' 10000 %}
    Hello! {{ time }}
{% endcache %}

Every time I hit refresh I have new timestamp. Doesn't it suppose to be fixed for 10 seconds?

In Development Mode it could be very annoying sometimes to have to clear the cache files at all when changing some twig and the previous cached version is rendered instead of the modified one.

With this new Strategy one can overwrite the twig_cache-settings in config_dev.yml to avoid any caching: e.g.

services.yml:

    twig.strategy.blackhole:
        class: Asm89\Twig\CacheExtension\CacheStrategy\BlackholeCacheStrategy

config_dev.yml

twig_cache:
    strategy: twig.strategy.blackhole

When running in dev mode with debug off, this works as I'd expect:

{% cache 'v1/blog' ~ pageNumber 900 %}
    {{ render(controller('AppBundle:Default:_blog', {'pageToken': pageToken, 'pageNumber': pageNumber})) }}
{% endcache %}

If an exception gets thrown inside that controller then it bubbles up as 500 and nothing gets cached.

However, when I switch to prod mode with debug off I seem to just get a blank 200 page back if an underyling exception occurs. Then it seems to stay cached.

These are the objects I'm using:

app.cache_backend:
    class: Doctrine\Common\Cache\ApcCache

app.cache_provider:
    class: Asm89\Twig\CacheExtension\CacheProvider\DoctrineCacheAdapter
    arguments: ['@app.cache_backend']

app.lifetime_cache_strategy:
    class: Asm89\Twig\CacheExtension\CacheStrategy\LifetimeCacheStrategy
    arguments: ['@app.cache_provider']

app.cache_extension:
    class: Asm89\Twig\CacheExtension\Extension
    arguments: ['@app.lifetime_cache_strategy']
    tags:
        - { name: twig.extension }

I have a website that has a lot of festivals and concerts (events). I want to cache the whole output of the page to speed things up. But when a festival is in the past (expired) I don't want to serve it from cache but just fresh from the database. Those pages aren't visited very often so there is no need to cache it.

Would it be possible to add an extra flag to the {% cache %} block to allow the toggle?

For example:

{% cache 'events' { key: 'event_' ~ event.id } event.shouldCache %}
  output
{% endcache %}

Hi,

When, I want to download twig-cache-extension from packagist (repo TwigPHP), I have this error :

Cette erreur survient avec la version 3.x de Twig, car elle n'est pas supporté

Please can you add support for twig 3.x

have a nice day !

asm89/twig-cache-extension suggests installing psr/cache-implementation (To make use of PSR-6 cache implementation via PsrCacheAdapter.)

$ composer require psr/cache-implementation

[InvalidArgumentException] Could not find a matching version of package psr/cache-implementation. Check the package spelling, your version constraint and t hat the package is available in a stability which matches your minimum-stability (stable).

Hi,

we want to cache templates that use lazily fetched data. Something like this:

class ViewModel
{
    public function getItem(): Item
    {
        $this->repository->findItem();
    }
}

{% cache 'v1/show_item' viewModel %}
        {{ viewModel.item.title }}
{$ endcache %}

Of course, most of the time our logic is more complicated than that. There is more template stuff to cache and more data stuff to cache. By using VM inside cached part of template, we have a lazily loaded entity (or entities, or other data), which seems cool enough to use this extension.

The problem is: how do we invalidate the cache when values in Item change?

We could use GenerationalCacheStrategy, but that would mean we cannot have Item (and other stuff) lazily–loaded.

So we want to invalidate cache „manually” (but still in code ;)) when necessary. For example, there is code that changes title in some Item – then we'd like to call something like this: invalidateCache('show_item_'.$item->getId()).

But what if there are more parameters to take care of? Like current user status, etc?

Should we try cache tags? What's the best way to implement them here?

Any other ideas?

As always,

There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton

I see PR's open here without replies and there's actually even a bundle that still uses this repo. On the other hand twigphp/twig-cache-extension seems quiet.

@asm89 maybe deprecate this repo and point out to twigphp/twig-cache-extension if that's what should happen in the end?

hi, its somehow possible something like this?

{% cache 'product' product %}
    {{ product.id }}
    {% cache 'category' category %}
        {{ category.id }}
    {% endcache %}
{% endcache %}

when i change category (i have own key generator, watching classname+id+updatedat, this is ok), i want change/regenerate only category block inside - but its not working for me, its possible to do this or i must regenerate top parent - product in this case? thanks