Resolved Bug


This bug has been marked as resolved.

Out of date Config values returned

Permalink 3 0 Browser Info Environment
I have been using the config table to track information from one execution of a job to the next (I am trying to preserve some info between job executions, so that a job knows how many times it has been executed). The class that does this is all static, which may be something to do with the problem as I have done similar in the past, but not with a wholly static class. The following is a summary of logging written and read values. In the log, the user shows as Guest.

Run 1:
set a config value to A
read it back = A
Run 2:
set a config value to B
read it back = A

hours later
Run XXX:
set a config value to X
read it back = A

Clearing the cache does not seem to have any effect.
Deleting files in /files/cache appears to clear it, but then it starts again.


Status: Resolved
JohntheFish
JohntheFish replied on at Permalink Reply
JohntheFish
Replacing the config method with sql to read directly from the config table fixes the problem, so confirming that setting a config value is written through to the database (verified with phpMyAdmin), but getting it is returning an out of date cache value.

// Original code, returns out of date cached value
$val_1 = $pkg->config($key);
//
// New code, returns the correct value from config table
$db = Loader::db();      
$val_2 = $db->getOne('SELECT cfValue FROM config WHERE cfKey = ? AND pkgID = ?', array($key, $pkg->getPackageID()));
minh replied on at Permalink Reply
I've got the same problem with the caching. It seems to be not working when I deploy the source code from my local machine to the live server.
xanido replied on at Permalink Reply
xanido
Confirmed. Caching these config items isn't in itself a bad idea, but the fact that clearing the cache through the interface does not remove these cached values is a bug.
Remo replied on at Permalink Reply
Remo
I've had the same problem a few times and also had a look at the code and from what I saw, the code seemed to clear the cache just fine.

Unfortunately I never had enough time to dig deeper.
Remo replied on at Permalink Reply
Remo
Remo replied on at Permalink Reply
Remo
I just removed my directory /files/cache on a site I had the same problem and saw that I had several cache files here the Config variables were stored.

It seems like the unique key for the file name isn't properly determined.
JohntheFish replied on at Permalink Reply
JohntheFish
Hi Remo

I am looking for a hack fix for this that I can insert in code and apply unilaterally across multiple c5 versions. Do you know what the cache key should reliably be (guessing this will be a php fragment), so I can add my own code to unilaterally clear that cache key?

John
Remo replied on at Permalink Reply
Remo
Haven't had a closer look but the file names used by the file backend in the Zend Framework seem to be difficult to predict.

I ended up removing "Cache::enableCache();" but that of course means patching the core!

However, on a site where the cache is disabled, you'll only see very few files in /cache. Why not simply remove all of them?
JohntheFish replied on at Permalink Reply
JohntheFish
My purpose is a simple addon that sets a specific config value that the rest of the site uses.

I want it to be able to set that value reliably, without placing other constraints on sites that install it. So was hoping there would be an easy way to, when I set the config value, also forcibly remove the cache entry, hence allowing everything else to proceed as normal.

Clearing the entire cache may be a little heavy handed.
Remo replied on at Permalink Reply
Remo
I agree, but from what I saw, we have several files where the cache values are stored. This is probably also the cause of the issue. If we knew how those filenames are generated, we could fix the issue as well. Although, it's not necessary because the code has changed in 5.7

No sure if there's a nice way to remove those files. Maybe just use the SQL query you've posted above?
JohntheFish replied on at Permalink Reply
JohntheFish
Where it is my addon that needs to get the accurate value, I am already using the query (eg in Backup Voodoo). But where I am setting values that are used by the core or other addons, I have no control over how they read the config values. Hence my desire for a means of forcing it.
JohntheFish replied on at Permalink Reply
JohntheFish
I have just uploaded the addon concerned:
http://www.concrete5.org/marketplace/addons/mm-jobs/...
Remo replied on at Permalink Reply
Remo
Sorry for spamming this but I thought I'd check if there were any changes and found something.

If you check the 5.7 branch, you'll see that there's no caching functionality in the ConfigStore class:

https://github.com/concrete5/concrete5/blob/5.7-performance/web/conc...

I guess we wouldn't have this problem if this change was in the current stable version.
andrew replied on at Permalink Reply
andrew
This is resolved in 5.6.1

concrete5 Environment Information

WAMP, 5.6.0.2

Browser User-Agent String

Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11