Disk space used by cache growing too large about autoptimize HOT 5 CLOSED

Well, filename is autoptimize_.js (see classes/autoptimizeScripts.php), so that means there have to be (minor) differences between those files. This is typically caused by plugins inserting small pieces of page- (or request-)specific inline code. As inline code is aggregated by default, this has as a consequence that a huge amount of files are being created.

There are 2 solutions for this problem:

1. finding the the offending JS-code and exclude that from being aggregated (see FAQ)
2. disabling aggregation of inline JS as a whole, which can be done using the API as seen in autoptimize_helper.php_example

For AO 2.0 I will most probably make "aggregate inline JS" (and CSS) an option in the settings-page (which will be off by default, to avoid people running into this particular issue).

Concerning autoptimize_cache_nogzip is the option used to store the setting if autoptimize JS/ CSS is to be delivered statically (true) or dynamically (false), this logic is in classes/autoptimizeCache.php.

Hope this clarifies :-)

frank

from autoptimize.

thanks @futtta, and sorry for the noise.

i'll try to find out why my compare of the files shows them as identical, but obviously the live code is not. It's got to be something simple

from autoptimize.

For AO 2.0 I will most probably make "aggregate inline JS" (and CSS) an option in the
settings-page (which will be off by default, to avoid people running into this particular issue).

@futtta I have tweaked some of the plugins I use to put a well known class attribute on scripts that I don't wan't moved out of the code. Most of these tend to be the CDATA only scripts that get created as a result of wp_localize_script.

If you are thinking about providing some additional options around what to localize, perhaps a "don't localize CDATA only scripts " option would be useful. These scripts don't seem to impact page speed scores, not sure about if the browsers are tagging these as blocking or not?

from autoptimize.

hiya @JeffPyeBrook;

Generally speaking CDATA-blocks are actually leftovers from the XHTML-days to identify parts of the XML-tree that was to be excluded from XML-parsing. As such any inline JS could be blocking or non-blocking, depending on what the JS is doing. Just setting some variables would be non-blocking, but doing some heavy lifting (and e.g. connecting to 3rd parties) would clearly be blocking, no matter if the JS was enclosed in CDATA-markers or not.

Now specifically for WP-scripts; it indeed seems that WP core inserts CDATA-markers when doing wp_localize_script (as per print_extra_script() in wp-includes/class.wp-scripts.php, which mentions CDATA is not needed, so it might get dropped anyhow).

Conclusion: I'm not sure it's a good idea to to rely on that in AO-core But one could simply add "CDATA" to AO's JS exclusion-list if one wanted to, no?

from autoptimize.

@futtta Yes, I also experimented with adding the CDATA to the exclusion list and everything that you would expect to was skipped, but ended up adding the class attribute to the plugins to get better control. It was necessary because I wanted to ensure some scripts with CDATA were parsed prior to other javascript. Specifically, AdWords and Google Analytics scripts.

from autoptimize.