can't you insert the debug breake point inside of the js file?

you mean edit file in file system? you can, but why would you if browsers have extended functionality for this? shouldn't​ we support worldwide used development tools and tech?

Ping @dgt41

This is an interesting point, since I believe the versioning was added to allow a full refresh of JS when enabling debug since many users forget to clear then cache we make sure they get a new file.

I suppose we could add an option to the debug plugin that adds the version to JS file or not?

Thoughts @dgt41 ?

Isnt the problem that with the case of tinymce we only ship minified javascript gin

no, both files​ are shipped.
It's what Tony described above.
but I believe there is a way to make this work - version should be set based on modified timestamp.

By that do you mean the time stamp that the debug mode was enabled? I still think there is a usage case for it loading a new file every time when debug mode is enabled.

On 31 May 2017, 18:47 +0100, Alexandr Kosarev notifications@github.com, wrote:

no, both files​ are shipped.
It's what Tony described above.
but I believe there is a way to make this work - version should be set based on modified timestamp.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

no, timestamp from filesystem, file modified time

I think that's really the way to handle versioning and cache.

Ah ok, yep that to me would be a good idea but only when debug mode is enabled.

On 31 May 2017, 18:54 +0100, Alexandr Kosarev notifications@github.com, wrote:

I think that's really the way to handle versioning and cache.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

sorry i thought you were referring to the js from tinymce not the joomla js

Tony, do you think that checking file modified date with filesystem will cause performance impact?

It will have an effect given it's an extra process but your debugging so expect it a bit slower anyhow. Should be worth a test nontheless.

On 31 May 2017, 19:02 +0100, Alexandr Kosarev notifications@github.com, wrote:

Tony, do you think that checking file modified date with filesystem will cause performance impact?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

i'm not in favour of I/O file system calls to check file timestamps ... there are IMO already too much to check browser versions?? among other things

a lot of I/O fs calls can be a performance problem in servers using the open_basedir php ini config option - normally shared servers - since for security reasons when you enable this option php does not cache filesystem paths - reference: https://bugs.php.net/bug.php?id=52312

also the HTTP server and browser should already be doing that using HTTP protocol Headers (ex: "Last-modified", "ETag", etc)

but you can also disable appending the media version to scripts/stylesheets when in debug mode (using JDEBUG const)

if anyone is interested the code that adds the media version is in:

• Gets media version https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/document/renderer/html/head.php#L70
• Adds media version in stylesheets https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/document/renderer/html/head.php#L144
• Adds media version in scripts https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/document/renderer/html/head.php#L255

+10

Agreed, I just checked JFile out, I sheepishly assumed it had a an info attribute containing basic info like JImage.

Anyhow, then my solution still stands. Not many people are debugging JS IMHO within the browser. So for the ones who are they know how to clear a cache.

We just need to allow adding and removing of the unique version numbering, within the debug plugin I think should suffice.

On 31 May 2017, 20:30 +0100, Brian Teeman notifications@github.com, wrote:

+10
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

@andrepereiradasilva

i'm not in favour of I/O file system calls to check file timestamps ...
a lot of I/O fs calls can be a performance problem in servers using the open_basedir php ini config option - normally shared servers - since for security reasons when you enable this option php does not cache filesystem paths - reference: https://bugs.php.net/bug.php?id=52312

I had same thoughts, so in my extension in order to avoid it
i use a timestamp from a single file to version all files,

It is a file that is modified on every extension upgrade ...

This way i avoids making a few dozens of time stamp checks , 1 per file,
and instead always doing only 1

This requires to hard refresh pages during developing time (or an option to generate new version),

but it is safe for refreshing caching of JS / CSS file for users upgrading my extension, and also works with setting breakpoint in the browser

But that's pointless in this usage case, because my argument is fine with a config option. Since we could use the modified time from when the config was saved for instance and debug was enabled.

But I don't think that's necessary and we are just overly complicating things.

On 31 May 2017, 20:41 +0100, Georgios Papadakis notifications@github.com, wrote:

@andrepereiradasilva

i'm not in favour of I/O file system calls to check file timestamps ...
a lot of I/O fs calls can be a performance problem in servers using the open_basedir php ini config option - normally shared servers - since for security reasons when you enable this option php does not cache filesystem paths - reference: https://bugs.php.net/bug.php?id=52312
I had same thoughts, so in my extension in order to avoid it
i use a timestamp from a single file to version all files,
It is a file that is modified on every extension upgrade ...
This way i avoids making a few dozens of time stamp checks , 1 per file,
and instead always doing only 1
This requires to hard refresh pages during developing time (or an option to generate new version),
but it is safe for refreshing caching of JS / CSS file for users upgrading my extension, and also works with setting breakpoint in the browser
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

But that's pointless in this usage case, because my argument is fine with a config option.

Not pointless since my suggestion works, if there are alternatives, it does not mean that something is pointless

Since we could use the modified time from when the config was saved for instance and debug was enabled.

This will not work in all cases

This will not work in all cases

i meant if you upgrade and configuration was saved / set before upgrading (unless it also changed on upgrade too), plus that solution would a little more work to implement, and some argueably unneeded checks will always be running on save of global configuration

but i would not be against it, whatever

@ggppdk

I had same thoughts, so in my extension in order to avoid it
i use a timestamp from a single file to version all files,

just additional info: the joomla media version does not do any timestamp or fs I/O at all.
Is changed, for instance, on joomla update, or whenever JFactory::getApplication()->flushAssets(); (otr the code of this method) is called
see

• https://github.com/joomla/joomla-cms/search?q=flushAssets
• https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/application/web.php#L967-L971
• https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/version/version.php#L244-L325

and also could be changed by any 3º party extension.

example on joomla patch tester: https://github.com/joomla-extensions/patchtester/pull/178/files (in this case change the joomla media version whenever you apply a patch to avoid js/css browser cache issues)

Tony, If I understand you correctly, than checking config file timestamp is not a solution as it leads to caching files from time of enabling debug. And this extra effort for same result as just strip version away.
And if file checks are bad for performance than "no version" is the best solution here.

@andrepereiradasilva

you are right, just since it is updated by Joomla upgrade it is not suitable for extensions

but then as you say...

and also could be changed by any 3º party extension, ... example on joomla patch tester:

i did not consider doing this !
... probably it is not a bad choice to do for my extension too

Just invalidating client caching of many site JS / CSS files, not related to my extension does not sound necessary

Now about this topic, a simple solution is to update the versioning URL hash number more often

• not only on Joomla upgrade (done already)
• but also on global configuration saving regardless if debug setting is ON,
  this will not only solve this issue, but also help speeding up working with debug on,
  just if you modify JS files you will need to do hard refresh every time

maybe onAfterDispatch debug system plugin

if ((boolean) joomla global debug === true && (boolean) new param "refresh media version" === true)
then
JFactory::getApplication()->flushAssets();
end if

:)

Global configuration saving does not the event 'onExtensionBeforeSave'
public function onExtensionBeforeSave($context, $table, $isNew)

Maybe better add triggering of the above (with an appropriate "context") ?
it will be useful in other cases too

I lost track of it... so you propose to update version when debug is on? and the issue here that it's happening and preventing browser from setting breakpoint...

we could also disable the media version if debug is enabled, but imo it should be enabled so in debug mode we always use a new file.

ok, so agree with @tonypartridge is IMO a good solution for this particular case

We just need to allow adding and removing of the unique version numbering, within the debug plugin I think should suffice.

see #16406

closed as having PR #16406

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/16381