Block Cache false?
Permalink Browser Info Environment
Hi,
I tested your add-on and see in the code that you've disabled the cache for block output ($btCacheBlockOutput), may I ask way? Because it slows down things a LOT ;)
Thanks.
I tested your add-on and see in the code that you've disabled the cache for block output ($btCacheBlockOutput), may I ask way? Because it slows down things a LOT ;)
Thanks.
Type: | Discussion |
---|---|
Status: | Archived |
Hi Parasek,
I noticed you released a new version. I'd like to install it, but it is not available via Composer. (seehttps://composer.concrete5.org/#c5market/simple_gallery).... Do you have experience with Packagist.org? It's relatively easy to set up, and it would make it a lot easier for Composer users to install (and update!) your add-on.
Let me know what you think! ;)
I noticed you released a new version. I'd like to install it, but it is not available via Composer. (seehttps://composer.concrete5.org/#c5market/simple_gallery).... Do you have experience with Packagist.org? It's relatively easy to set up, and it would make it a lot easier for Composer users to install (and update!) your add-on.
Let me know what you think! ;)
Sure, I will try it, when I find some free time.
I also need to move this repo from bitbucket to github anyway.
I also need to move this repo from bitbucket to github anyway.
In the meantime I've downloaded the package via the marketplace. I tried it, but still encounter some issues.
I have full page caching enabled, but when I clear the cache (without the 'Clear thumnails' checked'), and load a page with the gallery, it's super slow.
It kinda looks like the thumbs are regenerated, even though they might already exist. Does this issue sound familiar to you?
I have full page caching enabled, but when I clear the cache (without the 'Clear thumnails' checked'), and load a page with the gallery, it's super slow.
It kinda looks like the thumbs are regenerated, even though they might already exist. Does this issue sound familiar to you?
1. Are you refreshing site with gallery as not-logged-in user?
2. How many images do you have in fileset and how large are they?
3. Check two last checkboxes in /dashboard/system/environment/logging
and go to:
/dashboard/system/optimization/query_log
How many queries do you have after clearing cache/refreshing page with gallery twice (as non-logged in user)?
After second time, when you cleared log (red button), refreshing site should run 0 queries.
Currently addon always generates few queries, because of 'simple-gallery/localization'. I changed it in v1.0.5.
By the way, first refresh after clearing cache will always be slower, because cache will be used next time.
2. How many images do you have in fileset and how large are they?
3. Check two last checkboxes in /dashboard/system/environment/logging
and go to:
/dashboard/system/optimization/query_log
How many queries do you have after clearing cache/refreshing page with gallery twice (as non-logged in user)?
After second time, when you cleared log (red button), refreshing site should run 0 queries.
Currently addon always generates few queries, because of 'simple-gallery/localization'. I changed it in v1.0.5.
By the way, first refresh after clearing cache will always be slower, because cache will be used next time.
I found the problem. It's a bug in C5 8.2.1. I reported it a while back on Github, and it has been fixed already, but it is still in the current release. Seehttps://github.com/concrete5/concrete5/issues/5794...
I updated my composer.json to the development version of concrete5. All works well now:https://a3020.com/add-ons/image-optimizer...
Cache problems.
And long answer
Set $btCacheBlockOutput = true;
In CMS, turn all cache options on and set expiration for 1-minute (for testing purpose).
Open gallery in incognito tab and clear cache. After 1 minute refresh page in incognito mode.
Some css and js files will be missing, because view() function will not be run when cached.
You can move those files to on_start() or registerViewAssets() (those functions will still be run, even with cache on).
But, the root of the problem is that, some settings need to add unique css to page (for example: number of columns). We also need different "$this->uniqueID" for every block on page (obviously).
When you turn "Block Cache" on, unique class in view.php template will not change (e.g. it will always stay as sg-a4202aRandomNumbers). But every minute, "$this->uniqueID" will change to something else. So custom setting will not work that way.
So, I set $btCacheBlockOutput to false.
Solution to that is quite easy, add inline <style> to view.php instead inserting inline code by addHeaderItem(). But it will cause validation errors (cause <style> tag should go to <head>, not <body>), although browsers are ok with that.
In the end, I decided to turn block cache off (although opposite solution is also valid).
-----
After some thinking, I will propably try to target unique css by blockID instead uniqueID. It should work, need to test it now and implement in next version if everything will work as expected.