nrueckmann / smarty-php

Automatically exported from code.google.com/p/smarty-php
0 stars 0 forks source link

nocache blocks lost when using CACHING_LIFETIME_SAVED #133

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Steps to reproduce:
1. Use CACHING_LIFETIME_SAVED and a KeyValueStore cache implementation 
2. Run a template with caching enabled that makes use of nocache blocks
3. Delete the compiled template from disk
4. Wait for the cache entry to exceed its cache_lifetime
5. Run the template again
6. Examine the cache entry

Expected: The cache entry still contains the code for the nocache block, as it 
did after step 2.
Actual: The cache entry has been overwritten in step 5 with the generated 
output for everything, including the nocache block.

Affects smarty 3.1.13.

Explanation:
When working with CACHE_LIFETIME_SAVED we have to call the cache resource's 
process() method before we can find out if the cache entry is actually valid, 
as we need to read the cache_lifetime out of the template properties. As far as 
decodeProperties() is concerned, the data is valid, so the content_ unifunc 
from the cache entry gets defined.

The cached entry is now found to be invalid by the cache resource constructor, 
since it has exceeded cache_lifetime.
We then find that we don't have a compiled template on disk, so we need to 
compile it again. Thanks to our call to decodeProperties() on the cached entry 
we already have a unifunc name defined in our template properties, and 
createTemplateCodeFrame() re-uses this old unifunc name.

We then include our fresh new compiled version of the template, but due to the 
unifunc name having been reused our content_ function has already been defined 
(when the cached entry was eval()ed) and is not redeclared.

We end up calling the content_ function from the old invalid cached version 
instead! We also think that we're using a newly generated compiled file, so put 
the output into the cache. This is already a bit bad. Worse, the cached 
versions of templates do not include the comments that allow nocache to 
function, so the new value that gets put into the cache has the full generated 
output in it.

Proposed fix:

Make Smarty_Internal_Template::decodeProperties() return false if we're 
decoding a cache entry, using CACHE_LIFETIME_SAVED, and the entry has exceeded 
it's cache_lifetime. With this returning false the content_ function from the 
invalid cache entry will not be defined, and so our re-use of the old unifunc 
name in the newly compiled file will work.

I've attached a patch.

Original issue reported on code.google.com by j...@moo.com on 26 Feb 2013 at 5:40

Attachments:

GoogleCodeExporter commented 8 years ago
Thanks for your input.

The fix is now in the SVN trunk and will later be included in 3.1.14.

Your fix needed a small modification as it had a side effect with 
$smarty->caching = true;

Original comment by Uwe.Tews@googlemail.com on 28 Feb 2013 at 7:27