Last modified: 2014-08-27 13:45:47 UTC
It is helpful for debugging, when near to the cache key of a minified CSS/JS the timestamp of the minifikation is printed (like information by parser cache <!--Saved in parser cache with key ? and timestamp ? generated by ?-->. Thanks.
* The timestamp of when a module was last modified is available as real data in the startup module. * For HTTP requests this timestamp is passed in the query string. * For HTTP responses the known timestamp is in the 304/Last-Modified header. Adding it to the content as well would increase the payload O*N for each section for each module in a bundled ResourceLoader request. Not sure if that's worth the payload. What do you need it for exactly? Can you use one of the above 3 pieces of information instead?
(In reply to comment #1) > * The timestamp of when a module was last modified is available as real data > in the startup module. In practical that must not the same timestamp, when it was saved in the cache > * For HTTP requests this timestamp is passed in the query string. > * For HTTP responses the known timestamp is in the 304/Last-Modified header. Not all people have FireBug to see header information. When looking at the html source of a page or download the script itself/through the debugger, it is easy there to look at. When this gets expensive, than it is bad and need some refactoring or so. But feel free to close as WONTFIX
(In reply to comment #2) > (In reply to comment #1) > > * The timestamp of when a module was last modified is available as real data > > in the startup module. > > In practical that must not the same timestamp, when it was saved in the cache > > > * For HTTP requests this timestamp is passed in the query string. > > * For HTTP responses the known timestamp is in the 304/Last-Modified header. > > Not all people have FireBug to see header information. When looking at the > html > source of a page or download the script itself/through the debugger, it is > easy > there to look at. > > When this gets expensive, than it is bad and need some refactoring or so. But > feel free to close as WONTFIX The first point (data in the startup module) is accessible from the console (mw.loader.getVersion). It is also accessible in more places I haven't mentioned above (such as the HTML source of the active DOM state, the timestamps are in the URLs, in the <script> tags). Sure someone who looks at the raw source will not see these, but I think this data isn't relevant for that audience. I see no point in putting timestamps in the html output there for each module. Feel free to re-open with a use case, but afaik the data is easily available to any developer in many different places.
