Move all Requirements calls to templates

[sminnee]

I think that we should remove all the PHP Requirements::javascript and Requirements::css calls that we make in core to <% require javascript %> and <% require css %> calls in templates.

This keeps the front-end concerns bundled together in one place. It also means that if you switch to different templates, you won't be left with legacy javascript/css that you somehow need to disable.

In general, I think that we should recommend the in-template control codes as the preferred standard, and we should update our own code to match.

I've added this task to the admin project; as best I can see it mostly affects admin-related packages: admin, cms, asset-admin, campaign-admin, siteconfig. There are a few edge-case reference in security too.

[chillu]

Looking in LeftAndMain->init(), there's non-trivial logic about requirements includes (e.g.extra_requirements_css). I wouldn't want devs to override an entire template just to add this - in particular since modules use this as their extension points for adding custom CMS styling and JS behaviour. So I don't see how we can do this consistently without creating new, specialised APIs around <% require %>

[sminnee]

OK — so maybe an exception for the parts that are developer extension points, and the i18n javascript?

Related to this, there are a few of these extension points and they're all written differently, so maybe a more standardised way of adding CSS/JS to an existing template would be of benefit? However, that might be a 4.1+ / 5 thing. In the first instance I was envisioning just:

• making use of the APIs that already exist
• advocating for in-template inclusion as our recommended approach (in docs, etc)

It's a hypothetical example, but if our legacy forms HTML & javascript were structured this way, we could have moved the whole shebang to a separate theme package and let people choose whether or not to use it.

A less hypothetical example will likely be the CSS and or JS for bootstrap forms and other frameworks.

[chillu]

I was going to say that the whole Requirements system is becoming less relevant with the uptake of frontend asset bundlers (Webpack etc), but then again: HTTP/2 makes it feasible again to have lots of individual paths for network requests.

I think a standardised way to add CSS/JS to an existing template (as opposed to the controller) would be great. It's a bit more magic, so we'll need to ensure there's good debugging abilities. But overall, it's a view concern, not a controller concern.

[sminnee]

The use-cases of requirements are:

• letting a sub-template flag the requirements that needed to be added in the global header/footer
• mapping package resource references to actual URLs (i.e. the thing I added last week)

Front-end build chains don't replace these.

I agree that Requirements::combine_files() is less relevant and could probably be deprecated.