- No packaging of assets with block templates.
- No asset positioning in the page for optimization – a block type's asset would just be printed out wherever that block was rendered.
- Requires handholding by developers.
- No way for blocks to mark core assets as required for function.
As Concrete matured, we added better ways for these assets to be included, including
- Auto-inclusion of view.js and view.css in a block's view template
- Auto-inclusion of custom template view.js and view.css for blocks
- Since the above methods couldn't be used with blocks (due to how they rendered), we added BlockController::on_page_view(), to add assets to a page's header or footer whenever that block was used on a page.
Again, there were some good things here:
- Template flexibility
- More elegant bundling of JS and CSS with custom templates.
- Much better asset reuse - automatically include assets only on pages where they're needed.
- Only include named assets once per page.
- Ability to specify required assets.
But things were far from perfect:
- Header bloat.
- No asset minification.
- A proliferation of assets. Add one add-on that requires one asset, add another that requires the same, get two files loaded.
- All based off brittle filenames. You'd have an add-on load jQuery UI. What happens if we change the location of jQuery UI, or we break jQuery UI into multiple files? It becomes hard for us to reorganize included core assets.
- With bootstrap this only got worse. Certain themes include bootstrap, others do not. Certain add-ons require it, others do not. Forcing it to be included for all requests bloats requests by hundreds of KB.
Fixing the Problem: The Asset Sub-System in Concrete 5.7
Introduction and Video
This code was around for awhile before it made its way into 5.7. Here's an early presentation about the Asset sub-system I made to the Concrete core team in August of 2013: