Changes to compressed css/js file naming

[Alexander Obuhovich]

Since In-Portal 5.1.0 new feature was introduced. This feature allows to merge all js/css files on the page into one file and then compress it. This allows to significantly enhance website loading time.

There is one problem though: old versions of compressed files are never deleted.

Currently filename is generated by following scheme:
<d¦c>_<filenames_crc>_<timestamp>.<css¦js>

This way new file is created every time developer forces a recompression procedure by pressing "refresh" button in themes list in admin console.

I'm proposing to move timestamp part away from filename part into that file's url parameters. We actually could just use file modification time from file system instead of keeping it in 2 places, like now.

For example url "http://www.website.tld/system/cache/c_1253243_544433445.css" becomes "http://www.website.tld/system/cache/c_1253243.css?ts=544433445".

This way we always use the same file and just change it's url, so web browser would read it from server and not from it's cache.

[Phil -- wbtc.fr --]

Does timestamp actual position is the only reason why we have (so) many outdated files in cache?

I'm experiencing exactly what you describes: dozens of css and js files, while there should be only 2 of each (cached and actual version), right?

2011/9/11 Alexander Obuhovich <aik....@gmail.com>

[Dmitry A.]

Hi Phil,

Yes, this is correct.

DA

[Dmitry A.]

Here is a task for this:

1167: Improvements in Compressed CSS/JS File Naming - http://tracker.in-portal.org/view.php?id=1167

DA

[Dmitry A.]

Hi Phil,

I have a question for you!

We are working on this improvement and came across idea of formatting the Timestamp in the end of the file in 2 ways:

1. http://www.website.tld/system/cache/c_1253243.css?ts=544433445 where ts is UNIX timestamp unreadable to a human eye

or

2. http://www.website.tld/system/cache/c_1253243.css?ts=20111202-122312 where ts is Timestamp in human readable format.

Please note that both ts have the same date value when this Compressed file has been auto-generated (on Themes Refresh button) - it's just a different representation of this date - computer format or human format.

Let us know which one you find more appropriate for your day to day operations.

Cheers!

DA

[Phil -- wbtc.fr --]

Hi Dmitry,

thank you for questioning me directly as end-user, I'm happy to bring my daily experience as usual.

From my whole experience, the only time I go into system/cache directory is when I need to delete individual files, and the only reason I needed to delete these files is because I was missing this task, and I had many projects where I had approx. 50 CSS and 50 js files under cache, while of course only 1 was effectively in use.

Also, human-readable timestamp is creating very long filename, which doesn't seem to me very good when listing files.

Then because I never go inside cache for reading, and because I very rarely check these files, I vote for solution #1.

I take this opportunity to ask a (maybe dumb) question: if compressed files have a timestamp, and non-compressed ones don't have (future release of CSS and js), then now we should only have 1 set of each-non-compresed files, and 1 set of compressed files, according to the number of compression tags used in html_head, right?

p

2011/12/2 Dmitry A. <dand...@gmail.com>

[Dmitry A.]

Hi Phil,

Thanks for your reply Phil!

I guess, you are missing some things here:

1. http://www.website.tld/system/cache/c_1253243.css?ts=20111202-122312  - the ts=20111202-122312  part is not the part file name - it's a variable which is added so the files (in the templates) are NOT loaded from Cache after you ran Refresh Themes. The file name will be "c_1253243.css" and will not change unless you add/remove CSS files from list of the ones you caching here.

2. The both Compressed (used on LIVE mode) and Decompressed (used in DBG mode) has VERY similar format - the only difference is whether it has "c_" (stands for compressed) or "d_" (decompressed) prefix - the rest is the same in regards to the filename.

I have a feeling that you might misunderstood those 2 things that I have tried to compare in my previous post. My idea about having the Human readable ts=20111202-122312 part instead of ts=544433445 (nor are part of the filenames) is that if you open your browser and look at the CSS you can actually understand whether it's new or old version (yesterdays) since you have NOT pressed Refreshed Themes. Again, I am not trying to convince you or anything, rather to make sure you fully understand the comparison.

We are kind of doing a small voting whether it should or should not be done (human readable part). I can leave with both, but what's your opinion Phil?

DA

[Phil -- wbtc.fr --]

thank you for this detailed reply, I've misread your message, and thus replied an inconsistent opinion.

Then if it's an additional parameter, I vote for sure for human-readable version !

2011/12/4 Dmitry A. <dand...@gmail.com>

[Alexander Obuhovich]

Then I'll have to live with that :)

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Phil -- wbtc.fr --]

I guess Dmitry is also for human-readable :)

The cool thing in unix timestamp is to easily check with version is newer by looking at last numbers, while date need to be read. But when we are working on dev and live versions, it's cool to know that you are using the CSS made yesterday.

2011/12/4 Alexander Obuhovich <aik....@gmail.com>

[Dmitry A.]

Thanks for your Input Phil.

Task has been updated and reopened for adjustments.

DA

[Phil -- wbtc.fr --]

you're welcome :)

2011/12/6 Dmitry A. <dand...@gmail.com>

[Alexander Obuhovich]

Maybe it's better to use more familiar MySQL style timestamp in format "YYYY-MM-DD_HH:MM:SS", e.g. "2011-11-12_14:56:44".

[Dmitry Andrejev]

Sure! I am all in.

Alex, please update the task too then!

DA

--

Best regards,

Dmitry A.

[Phil -- wbtc.fr --]

good idea, yes :)

2011/12/6 Dmitry Andrejev <dand...@gmail.com>