@mattab opened this issue on December 10th 2013

When Activating or deactivating a plugin, on the new page view, the Javascript and CSS file will be re-processed. Currently it takes up to 20 secondes (ouch)! This is because the JS and CSS files are huge in size: they include all core files, as well as third party plugins files.

Proposed solution: - All JS and CSS from "Core" plugins (see method isPluginBundledWithCore) is stored in the getJs and getCSs as currently - All JS and CSS from "Third Party plugins" are located in a new getJsPlugins and getCssPlugins

This new file is very small (since there are few third party plugins, especially atm). This file is easy and fast to re-process.

Notes: - When a Core plugin is enabled/disabled, delete core css+js files. - When a third party plugin is enabled/disabled, delete new plugin css+js file - Check that enabling/disabling plugins will only re-process the two small css/js files, therefore clicking should be 1-2 seconds at most.

@julienmoumne commented on December 17th 2013

Dividing Less files would remove the ability for third-party plugins to override global Less variables.

Furthermore, most of the time is spent in minifying JavaScript files.

We will only separate JavaScript files.

An additional improvement will be committed :activating/deactivating plugins without JavaScript files will no longer trigger a full merging process.

@anonymous-piwik-user commented on December 17th 2013

In 6624e27e575d6056da7881bc05e9972c50ec1128: fixes #4373, #1640

@mattab commented on December 19th 2013

it's now slick to enable third party plugins & themes... Very impressive change, full test driven, very well done Julien!

@mattab commented on December 19th 2013


Refs #1640 Adding jshrink to LEGALNOTICE + update help text

@mattab commented on December 19th 2013

In 3910272e8c2a2fa5d0ad5dab54365a0215c6eee7: Refs #4373 The getAssets calls the dispatcher with a plugin that cannot be loaded. catching exception when trying to "uninstall" the plugin.

@tsteur commented on January 28th 2014

In ca4779fa8582a7031a149a2c113a322b2c2f2090: refs #4373 fixes the merged assets file was only generate if it did not exist before and fix it also was not regenerated if a plugin was not updated. Therefore include the version number in the cache buster.

@tsteur commented on May 16th 2014

In 8e9f6fc2a5d5d578c07430a9b71ebb8308fce0a2: refs #4373 I had to make this change to force reloading the css in case the compiled css changes without a version change

Following scenario: There is a plugin that generates css/less files dynamically from time to time but the Plugin version does not change as there is no plugin update. Only the less file changes. When the less file changes, the plugin deletes the merged asset file as well.

The current cache buster is based on Piwik version + Plugin versions. That means, when a less file changes but no version the browser will still use the "cached CSS" as the cache buster does not change.

Therefore I have to build a cacheBuster value based on the content of the compiled CSS file to invalidate the cached CSS file in the browser and to force the reloading. As far as I can see this change does not have any huge performance implications as it builds a hash based on the already compiled CSS file and only tries to regenerate the compiled CSS file if it does not exist.

@tsteur commented on May 16th 2014

In 6f325aae4e07f297943ec9d135abd6e14ab99d91: refs #4373 somehow my previous commit did not work. need this method public for my previous change in the view

This issue was closed on May 16th 2014
Powered by GitHub Issue Mirror