Hi, I'm not sure if this is simply the way Core Library works or a bug, but it's confusing nevertheless.

When all caching and aggregation is turned off in /admin/config/development/performance and Core Library is enabled and set to anything but Disabled (in my case it was set to Anonymous only), the JavaScript includes from the $scripts output in html.tpl.php can't be cleared with Clear all caches on the performance page.

I noticed this while developing a new site and trying out different modules as well as adding scripts with drupal_add_js(). All the script references ever added to <head> stayed indefinitely, even after removing modules and drupal_add_js() lines.

Cheers

Comments

pounard’s picture

Assigned: Unassigned » pounard

The whole goal is to merge all javascripts/CSS files even if used only once in order to build a larger but redundant file for each, this in order to avoid having conditionnal/different aggregated files on every pages, and ensure once a client hit the site, he won't have to download a different file on each page.

There is actually a way to remove the outdated scripts, go to admin/config/development/library and submit the form with the "Reset learnt files" button. This is because, even on production sites, you may sometime need to clear all caches, and I didn't want the library configuration to be reset while clicking it.

The real bug here is that I should actually reset this variable when disabling modules, and the above described behavior should be documented on the performance page!

Tell me if it sounds a good explaination to you, if the "reset learnt files" button doesn't work, or if you find out that the bug is more than that.

account-deletion-needed’s picture

Thanks for the reply, makes sense.

I was just under the impression, that Core Library would not affect CSS and JavaScript includes when aggregation is disabled on the performance page (regardless of Core Library settings). Wouldn't it make sense to let it automatically Reset learnt files when disabling aggregation?

pounard’s picture

It's supposed not to, let me check this and come back to the issue. If it does mess up while disabled, this is a real bug!

pounard’s picture

It works as expected, when you disable the module, scripts went back to normal behavior. Except that, if you use aggressive page cache, you should wipe out the cache. I'll notice this in a hook_help() on the admin page.

pounard’s picture

Status: Active » Fixed

Add did it. New release coming.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.