Child pages
  • Changes to compressed css/js file naming
Skip to end of metadata
Go to start of metadata

Imported From:

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:

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 "" becomes "".

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.

Related Tasks

INP-948 - Getting issue details... STATUS


  1. 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 <>

  2. Hi Phil,

    Yes, this is correct.


  3. Here is a task for this:

    1167: Improvements in Compressed CSS/JS File Naming -

    INP-948 - Getting issue details... STATUS


  4. 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.* where
    ts is UNIX timestamp unreadable to a human eye


    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



  5. 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

    INP-948 - Getting issue details... STATUS

    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?


    2011/12/2 Dmitry A. <>

  6. Hi Phil,

    Thanks for your reply Phil!

    I guess, you are missing some things here:

    1.  -
    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

    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?


  7. 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. <>

  8. Then I'll have to live with that :)

  9. 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 <>

  10. Thanks for your Input Phil.

    Task has been updated and reopened for adjustments.


  11. you're welcome :)

    2011/12/6 Dmitry A. <>

  12. 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".

  13. Sure! I am all in.

    Alex, please update the task too then!


  14. good idea, yes :)

    2011/12/6 Dmitry Andrejev <>