faulty caching when renderTV in plugin

Saving the resource does clear the entire cache correctly.
I do neither CacheMaster nor any plugin on OnBeforeDocFormSave.
I already set the TV's with @INHERIT default values, now I tried the oposite.
Both with no effect, caching stays faulty.
I backchecked this in the german forum, at least one more can prove this result on a further installation.

OK, now I'm completely confused (I often am).

Reading back through this thread, it seems to me that you've said or implied:

With the RevoSSL plugin disabled, everything works normally
The RevoSSL plugin has nothing to do with the problem.
The Resource in the cache contains incorrect TV values
Saving the Resource with the new TV value clears the Resource cache.

These can't all be true and I still don't know exactly what you mean by "faulty caching."

Also, this thread is marked as "Answered" which may be why you're not getting more help.

I still have no idea how I would go about reproducing your problem. The code in your bug report just gets a TV value (which works fine for me). You need to be clearer about all of the exact steps necessary to reproduce the problem and where to look to see it.

BTW, are we sure this isn't an issue with the browser cache?

Thanks Bob for your patience.
The fact is, the plugin itself work as expected, the output of the TV Value is correct.
But after using $resource->getTVValue() or $tv->renderOutput() in the plugin, the resource cache does not build as expected afterwards. There is no error thrown, no logfile entry, but bad performance, for complex pages a big disadvantage.
To take all confusion out of this, let's start from begin.

• Add a plugin in your installation described in the bugtracker with a TV of your choice. Now set it to inactive first.
  clear the cache.
• Call a page in your browser, set the [^t^] and [^s^] tags in your template to get the perfomance data on screen, watch the built cache and its structure with a ftp client. Repeat the call, now coming from the cache.
• Now set the test plugin active (cache will be cleared).
• Repeat your page call, watch the performance tags. Watch the newly built cache with your ftp client. Do the second call (expected coming from the cache). Compare your performance data with the former call with inactive plugin.

Expected result: 1st call is coming from database, 2nd call is coming form cache (obviously faster).

Effective result: 1st call is coming from database. 2 call is coming from , the response time is about the same as the 1st call. Looking at the cache with my ftp client the cache structure looks odd. Either no id.cache.php present or 1.cache.php in every cache partition.
I hope, that I described it this issue clear enough this time.

OK, I get it (finally). Sorry for being so dense.

Saving the Resource when setting the TV should delete the cache file for that resource (and all other resources unless you're using CacheMaster).

The getObject() call in the plugin, if it's called right after that, has to get the Resource from the DB but it should definitely create a new cache file for that resource (assuming that you don't include the cacheFlag=false argument). Are you saying that's not happening?

Quote from: BobRay

... it should definitely create a new cache file for that resource. Are you saying that's not happening?

It's probabely not done correctly. As you compare the cache file(s) built between activated and deactivated plugin, the cache build is different.
I don't know about the structure of the cache, but it seems that the cache built with activated plugin cannot be retrieved successfully from the cache and therefore is reloaded from db (trying to set the cache and so on and on..).

You should be able to see the normal cache file by clearing the cache manually, making sure the cache file has been deleted, then visiting the page in the front end.

You could compare that cache file to the one created when your plugin runs.

After loading resource id 2:

This is the cache with plugin deactivated:

seems correct.

This is the cache with plugin activated:

2.cache.php is missing.

With the plugin activated, 2.cache.php never shows up?

That looks wrong, but I don't understand the cache well enough to say any more.

OK, using the code from your bug report, I've confirmed the problem and updated the bug report.

I looked at the code, but couldn't see any reason why this would happen.

I tried a couple more workarounds, but couldn't find anything that worked. Hopefully, it will be fixed soon, though for obvious reasons, a bug that just slows down a site tends to have a lower priority than ones that break it.

Sorry I couldn't be more help.

Thanks for taking the time, Bob.