[#30444] - Wrong version on css and js files in template... results in cache headache
- Closed
- 17 Aug 2021
- Medium
- Build: master
- # 30444
Steps to reproduce the issue
View source on a clean J3 / J4 installation and you will see scripts and stylesheets in the head.
All css and js files are extended with a string of numbers and letters.
They are meant for cache invalidation... and it should work if they would change when the file is changed.
They don't change when the file is changed.
for example in J3
<link href="/templates/protostar/css/template.css?dacd9129dca0f2ae311fd26072498696" rel="stylesheet" />
This css file is set in templates/protostar/index.php line 41
// Add Stylesheets
JHtml::_('stylesheet', 'template.css', array('version' => 'auto', 'relative' => true));
The version = auto causes the extension of the filename
version = joomla-rocks will cause the following output
<link href="/templates/protostar/css/template.css?joomla-rocks" rel="stylesheet" />
The link elements are set in https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Document/Renderer/Html/HeadRenderer.php
The so-called $mediaversion comes from https://github.com/joomla/cassiopeia/blob/628f6fef933f46909131c389e4a4f064c01fd6ca/libraries/src/Version.php#L245
It is an md5 hash of the long Joomla version together with the secret from configuration.php plus date.
The mediaversion will be set when not present or when the Joomla version changes or when in DEBUG mode.
In J4 the link element is set via https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Document/Renderer/Html/StylesRenderer.php
And uses the same $mediaversion from libraries/src/Version.php
It would be nice if this can be rewritten to something that looks at the filemtime of the loaded asset.
class TemplateHelper
{
/**
* Load CSS
*/
static public function loadCss()
{
HTMLHelper::_('stylesheet', 'style.css', ['version' => self::getFileMTime(JPATH_THEMES . '/' . self::template(). '/css/style.css'), 'relative' => true]);
}
static public function getFileMTime($file)
{
if (!file_exists($file) || filesize($file) == 0)
{
return null;
}
return filemtime($file);
}
}
should the function getMediaVersion.php from libraries/src/version.php be rewritten?
Expected result
I am expecting that when I change a css / js file the version will change as well.
Actual result
When changing a css / js file in the template the version does not change... this causes me headache when certain css changes are not to be seen. :-)
System information (as much as possible)
Additional comments
joomla-cms-bot
- | Labels |
Added:
?
|
||
@hans2103 the whole concept that Joomla is using for versioning the assets is TOTALLY WRONG.
Assets should only change their version ONLY if the contents of the file has changed. Right now (J3 or J4) Joomla INVALIDATES ALL THE STATIC ASSETS per new release. At least a stupid strategy (if anyone can even call this a strategy).
But to be fair here, J3 doesn't have the means for anything better, so invalidating all the assets per any update was the only possible solution.
J4 is in far better place, assets get compiled before packaging therefore it's as simple as injecting a "version": "some-unique-sting" in all the relative JSON files (used by the new asset manager).
To cut it short I have demonstrated how this can be done eg:
- update the build tools to hash the contents of the source file: https://github.com/dgrammatiko/sloth/blob/b2f9317a14f741717d79290543e23b397b9ffa4c/cli/tools/processJs.js#L38-L46
- use the hash in the relevant json files eg: https://github.com/dgrammatiko/sloth/blob/b2f9317a14f741717d79290543e23b397b9ffa4c/sloth/joomla.asset.json#L3-L21
My 2c
that is zero help for when the user edits the css in the template manager
that is zero help for when the user edits the css in the template manager
Actually it just needs a little more effort on the model of com_templates so whenever an asset is changes also the relevant json version is updated. Definitely doable, also the whole concept of the new asset manager is that: Joomla should be doing as less I/O (file reads) processing as possible, thus the json file that acts as storage for all the possible needed attributes.
when you've built that you can say the current method is wrong
when you've built that you can say the current method is wrong
I did and I posted the relevant links. I don't need the com_templates functionality so that wasn't on my list...
I wanted to have a look at the javascript with the browser debug tools - spent all day trying to figure out what was wrong. So in debug mode the version string is changed on every page load, whether or not any css or js file has changed. That means any js file of interest is removed from the debugger along with its breakpoints. So you have to set the break points again and you cant debug initialisation sequences. In the end I found this bug report and just went to libraries/src/Version.php and removed JDEBU || from line 256.
My problem is that, in media/templates/atum/js/template.js, I don't know enough to understand what this means:
(function (Joomla, doc) {
...
})(window.Joomla, document);
The ... in between I can follow. Can anyone point me to an explanation?
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/30444.
@hans2103 the whole concept that Joomla is using for versioning the assets is TOTALLY WRONG.
Assets should only change their version ONLY if the contents of the file has changed. Right now (J3 or J4) Joomla INVALIDATES ALL THE STATIC ASSETS per new release. At least a stupid strategy (if anyone can even call this a strategy).
But to be fair here, J3 doesn't have the means for anything better, so invalidating all the assets per any update was the only possible solution.
J4 is in far better place, assets get compiled before packaging therefore it's as simple as injecting a"version": "some-unique-sting"in all the relative JSON files (used by the new asset manager).To cut it short I have demonstrated how this can be done eg:
- update the build tools to hash the contents of the source file: https://github.com/dgrammatiko/sloth/blob/b2f9317a14f741717d79290543e23b397b9ffa4c/cli/tools/processJs.js#L38-L46
- use the hash in the relevant json files eg: https://github.com/dgrammatiko/sloth/blob/b2f9317a14f741717d79290543e23b397b9ffa4c/sloth/joomla.asset.json#L3-L21
My 2c
@dgrammatiko I like the concept. Is this already implemented in J4? If not... are you willing to create a PR for that?
@dgrammatiko I like the concept. Is this already implemented in J4? If not... are you willing to create a PR for that?
Most cases should be handled correctly since #32485. The couple cases that are still based on the old mediaversion string are $wa->registerAndUseScript and $wa->registerAndUseStyle because these are creating the tags dynamically. Converting those to $wa->useScript and $wa->useStyle should be a simple task: introduce a file joomla.assets.json and link the js,css there.
In the end I found this bug report and just went to libraries/src/Version.php and removed JDEBU || from line 256.
@ceford so this shouldn't be a problem for the majority of the assets (read my answer above). For those assets that still use the mediaversion string you can edit the js and add a single line: debugger; which will cause the browser's debugger to stop at that line
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-08-17 07:28:44 |
| Closed_By | ⇒ | hans2103 | |
| Labels |
Added:
No Code Attached Yet
Removed: ? |
||
The string is joomla version based. When debug is enabled there are additional options. You would need to go back to the original PR and discussions to see the logic behind this choice