Maybe the problem is I’m not *really* awake yet, but I’m afraid I don’t understand @funsail. Could you explain again, but with a real example and also why you think this could help? 🙂
The current setup allows code to be Opt into one file or not at all.
It’s more likely that you will get groups of pages that have common uses for different features.
So rather than having those pages have the one large aggregator file Plus 20 excluded files.
you could have maybe 3 or 4 chunks of files. each page might use two or three of these Chunks.
Some pages may only use one chunk.
so say you would have one file that contains all the base code for the whole site
then you might have a couple of pages that use a table and a flip box. Instead of just excluding those files and leaving them, you would actually aggregate them into a separate file.
every single feature tends to have more than a couple CSS and JS files. I need to exclude them means you still end up with 20 or 30 files
ok, think I understand more or less, but afraid this would become _very_ complex, both code-wise and from a configuration point of view.
what seems to be the best way forward to me, would be to use the (currently API-only, not GUI) whitelist feature for the base code (which is used on (almost) the entire site and let the rest be minified but not aggregated (available in AO 2.4 beta already).
given the fact that most site are on HTTP/2 (or should be) and thus the HTTP-connection is used for multiplexing all requests, this seems the best approach really 🙂
Exactly. It is hard for you to work out what is common.
That’s why you have 2 fields and we deal with it.
For you it’s like running the plugin once, then with the leftovers running it again with the 2nd field.
