[#3493] - Misleading cache time settings
- Closed
- 24 Apr 2014
- Medium
- Build: 3.3-dev
- # 3493
- Diff
- shur:3.3-dev
- Foreign ID 33641
- Success The Travis CI build passed Details
User tests: Successful: Unsuccessful:
Suppose I need to configure cache time for a module.
I find this option in the Advanced Module Settings > Cache Time: 900
But it’s not clear 900 of what? hours, minutes???
- Why time unit is not specified in description? My customers repeatedly ask this question.
- One can suppose that the unit is a minute, since cache time in Global Configuration is set in minutes. But it turns out to be wrong, cache time in module cache settings must be set in seconds.
- Is it that important to set module cache time up to a second?
- If you need to set a long cache time e.g. 5 days, it’s pretty complicated to fill in this field. You’ll definitely need a calculator to accomplish the task (5 * 24 * 60 * 60 = 432000 sec), which is very inconvenient.
Currently, we have these descriptions:
Global Configuration > Cache Settings > Cache Time
“The maximum length of time in minutes for a cache file to be stored before it is refreshed.”
Module Manager > Any Module > Advanced Module Settings > Cache Time
“The time before the module is recached” <- time unit is not specified
To avoid confusion and simplify cache setting process we need:
- always describe what time unit is used for cache settings
- keep to the same time unit everywhere in cache settings. I think it’s better to use minutes.
I understand why you want to do this. But if you want to do this you're going to need to implement it in a b/c way. For example currently anyone who has it set to 900 seconds is going to have it as 900 minutes! which is quite a change :P
I agree with George that this is not backward compatible. This needs a bit more thinking so modules don't suddenly have 60 times the cache duration as previously. I don't think it will be easy as it also has to work for 3rd party extensions.
The one thing you could do to reduce confusion is to specify in the tooltip that the time is in seconds.
We cant do this - it will break all existing sites cache settings
I'm going to close this PR for the reasons stated.
Feel free to create a new PR when you have an idea how to do this in a BC way. It certainly would be a good move.
| Description | <p><a href="https://github.com/joomla/joomla-cms/issues/3487" class="issue-link" title="Misleading cache time settings">#3487</a><br><a href="https://github.com/joomla/joomla-cms/issues/3487" class="issue-link" title="Misleading cache time settings">#3487</a></p> | ⇒ | <p><a href="https://github.com/joomla/joomla-cms/issues/3487" class="issue-link" title="Misleading cache time settings">#3487</a></p> |
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-04-24 14:01:47 |
| Labels |
Added:
?
?
|
||
Agree that current solution cannot be applied as it is. I thought Joomla guru could suggest a solution for BC.
My assumption was that when updating from previous Joomla version to v.3.3 SQL request would search in database #__modules column params and replace current cache_time value with cache_time value divided by 60.
This could help the problem with all the installed modules, both core and third party modules. But it wouldn't impact the default settings in xlm files of newly installed third party modules.
The one thing you could do to reduce confusion is to specify in the tooltip that the time is in seconds.
Yes, the minimum that must be done.
The easiest path without breaking anything would probably be to create a new parameter which holds the time in minutes and deprecate the existing one. The cache could then see if the new parameter is available and use this one if present.
Of course you would either have to adjust the current values during an update like you suggested, or you do some funny things with the new parameter (using a custom field) where it would look for the old stored value and update it.
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33641&start=0