Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Imagine the following situation:
- You have prepared a deployment for your current project which is using MinifyJS module.
- In your deployment there are new JS files included but also some JS files changed
- After the deployment you need to minify the new files which is already possible through the UI
- You also need to re-minify the updated JS files - if you don't do that users will load the outdated versions of these files
Current situation:
- You need to know the changed files and chose the re-minify option from the UI
- It is not possible to only re-minify these files via drush - I'm currently working in a multisite project with 55 sites. I would need to do that 55 times...
- The UI does not identify changed files - even the filedate and size of the original file do not change
Additional issue:
- In the UI there is an option to only re-minify new files - this option is missing via drush
Expected behavior:
- During a scan the updated files are identified and flagged
- You see a special indicator in the UI that there are modified source files
- Via drush minifyjs there is an option to only re-minify updated files
- Since updated files are only discovered during scan the drush command should also have an option to automatically rescan before minifying starts
- Additional: re-minifying of new files (skip existing) should also be possible
| Comment | File | Size | Author |
|---|
Comments
Comment #2
sfuchsbe commentedComment #3
sfuchsbe commentedComment #4
slydevil commentedI think this is a great idea! I don't like storing the modified state of the file in the table though. I think it's an operation that can be handled on the fly. I will investigate this a little bit today.
Comment #5
sfuchsbe commentedI was also thinking about an option to do it on thy fly but I decided to store this information in the database because of the UI. I think it is a good information for the user to see which files have been modified and to give the opportunity to only re-minify some files by cherry picking them manually. If you wouldn't store this information in the DB the script would need to compare all files in the list each time you call minifyjs_load_all_files() to render the UI (and for all other use-cases). And I always prefer DB operations compared to I/O operations especially when the data we need to compare with is in the DB as well.
Looking forward for your investigation results.
Comment #6
slydevil commentedRemoved the comment...
Comment #7
slydevil commentedThere is no need to create a new field in the database since the last modified date of the original and the minified version are stored already. This data be used to flag which minified files are out of date and can be used to determine which files need to be re-minified (either via drush or through the UI).
Comment #8
sfuchsbe commentedIn my opinion you can not relay only on these two dates. Usually this would work but not if you also take deployments into consideration.
Let me give you an example:
- Your project is in version 1 on your production server and was deployed on January, 1st 2018
- Inside there is a JS file with file date December, 1st 2017
- After deployment you minify the JS files => so all minified files will have the filedate January, 1st 2018
- The next update to version 2 is done on February, 1st 2018
- In this version there is a newer version of the JS mentioned above with filedate December, 31st 2017
- Without comparing the two different filedates of the original file you won't detect this change because the changed filedate is still older then the minified date
I don't think that this is special use case. I think this might happen a lot of times.
In the end it is your module and your decision. I can just share my experience.
Comment #10
slydevil commentedHere is what I've done:
1. During the scan, any files that are currently minified have their size and modified time checked against the current values of the original file. If they are different, the scan will remove the minified file.
2. Added a drush command to minify only files that are not currently minified.
So with drush, after a deployment, you would run
I really wanted to avoid updating the schema and this change accomplishes that.
Comment #11
slydevil commented