[META] Remove direct calls to drupal_add_css()

New: #2095311: Remove drupal_add_css() from update.module.

New: #2095329: Remove drupal_add_css() from batch system & #2095335: Remove drupal_add_css() and drupal_add_js() from the ajax system.

Updated issue summary.

New: #2096577: Remove drupal_add_css() from views.module, #2096591: Remove drupal_add_css() from the theme system and #2096593: Remove drupal_add_css() from system.module.

Now all remaining drupal_add_css() calls that add assets are removed, only those that use it to retrieve all added CSS (from its static variable) remain.

Updated issue summary.

We're down to the following in runtime code:

Two calls with no arguments in drupal_get_css() and template_preprocess_maintenance_page().

A dynamic call in drupal_render_collect_attached().

A few remaining calls in tests.

I think we should do the following to get this meta issue closed:

1. Add a leading underscore to the function to make it private and update the docs to make it clear no code should call it. That will at least break existing usage to force people to use #attached.

2. If there's not an issue already open, create a follow-up to refactor drupal_render_collect_attached() to use a service internally for stashing the assets and possibly the refactor of drupal_render() to make the assets available to the caller as discussed at DrupalCon Prague. That can be major, but it'd not be an API change so could go into 8.x at any point (at least theoretically).

catch: I'm not clear how the planned changes to drupal_render() are not an API change? It changes the return value(s), doesn't it?

@Crell, not necessarily. We could have a second $attached argument to drupal_render() by reference which would maintain bc.

While we technically could, that means the return type of the function changes based on the input in incompatible ways. That's a gross code smell. (Gross both in the "big" sense and the "fugly" sense.)

But let's just go ahead and do it ASAP so its BC-ness isn't an issue in the first place. :-)

I think you mis-read 16, I said 'by reference', so no change in the return value.

re: #16:

Add a leading underscore to the function to make it private and update the docs to make it clear no code should call it. That will at least break existing usage to force people to use #attached.

+1

If there's not an issue already open, create a follow-up to refactor drupal_render_collect_attached() to use a service internally for stashing the assets and possibly the refactor of drupal_render() to make the assets available to the caller as discussed at DrupalCon Prague. That can be major, but it'd not be an API change so could go into 8.x at any point (at least theoretically).

i already have a dumb way of doing this in #1762204: Introduce Assetic compatibility layer for core's internal handling of assets, and it works; though it's oriented towards the new collection structures, if we want a simple step then it'd be a good thing to work from in coming up with an array-based equivalent.

that said, my dirty solution is not at all up to the standards of what we discussed in Prague. i implemented it as a stopgap, with the hopes that other folks who had those ideas would do them and i could re-adapt them. my solution relies on global storage in drupal_static(), which is not what we ultimately were going for - iirc, at least part of the goal was to make the asset information only accessible to things that have direct (non-hook/horizontal) access to the page array.

Opened #2168113: Add leading underscore and other discouragement to drupal_add_css() and drupal_add_js() for the quick docs/leading underscore change since drupal_add_js() needs identical changes now.

Opened #2168111: Allow drupal_render() to pass up #attached to parents - sdboyer would be good if you could paste your comment over there too.

Marking this one fixed.