The blacklist of JS files should be abstracted so that other compression engines can easily make use of the same configuration. Additionally the blacklist requires an interface which is not in this first patch

Comments

arthurf’s picture

StatusFileSize
new2.53 KB

Here's another patch that has configuration options.

mfer’s picture

Should this just be a form field or should there be another way to declare it? Maybe a hook?

mfer’s picture

Before we do this we have an issue we need to deal with. It's why I created #1502802: Contrib minified JS. There is a potential legal issue here. JavaScript on drupal.org or released openly where the source and license are available are easy. Custom JavaScript for a site is a different legal story. The JavaScript shipped with Drupal is GPVv2. When custom code uses that (e.g., Drupal.t(), Drupal.theme(), behaviors) it is extending GPLv2 software and is itself now GPLv2 software. Then that code is shipped to the browser. If only the minified code is shipped it can be considered obfuscating the original source.

So, we need to handle this issue. This is why I started with just Drupal core. This is controlled and I know. When we get into deal with the sites folder I didn't want to set anyone up for GPL violations (even if no one will likely press them on it). For files in the sites folder we should be able to put a comment at the top of the file with the full path to the original source and be ok. This is more difficult in development where the base path may be different than production.

Thoughts? Ideas?

Note: I am not a lawyer and this is not legal advice.

arthurf’s picture

There is an interface for it on the patch in http://drupal.org/node/1525424 I should have split it out- sorry :(

arthurf’s picture

In terms of the legal issue- Why don't we insert a link at the top of the minified file back to the source file? This would be fairly simple to do. That should cover the GPL issue I'd imagine?

mfer’s picture

When you run the command to generate the minified files how do you know the production base path and domain reliably?

arthurf’s picture

Yeah- we don't have any $_SERVER info that we can pull from. There is $base_url in settings.php or we could just require --base_url=http://mysite.com/ as part of the drush argument.

KeyboardCowboy’s picture

Title: Abstract blacklist to enable usage by other compression solutions » Add UI to Configure Blacklist Paths
Category: Task » Feature request
Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new5.09 KB

Rerolled the patch for the current dev version and to use drupal_patch_path() so wildcards can be used in blacklist paths. Added a default value to blacklist *.min.js and js files already in speedy in case that directory is allowed.