[meta] Remove drupal_set_*() drupal_add_*() in favour of #attached/response for out-of-band stuff

I followed up on #1830588-3: [META] remove drupal_set_title() and drupal_get_title() — it seems the same pattern is being proposed for some other things that share some aspects with the page title (e.g., breadcrumbs), and I don't think the proposed pattern will work out, so it might make sense to hash it out for the page title first.

A DX detail for getting rid of drupal_add_js is how we handle JS settings, using #attached is a pretty sucky DX compared to drupal_add_js().

First step of this was to change all drupal_add_js to drupal_add_library. The only part I couldn't change was a piece of code line 247 of the color.module.

And I guess I can close #1762204: Introduce Assetic compatibility layer for core's internal handling of assets and say it's B&L that'll fix it, right?

Updated issue summary.

Blocks and Layout.

Closing since both functions will (hopefully) go away with the new way of processing the #attach suff?

Blocks and Layouts ... Perhaps this is a slight DX regression but it is in the interest of caching that actually works. This isn't really optional.

what, this can't be the issue? :)

unless someone recommends that i split it out, i plan to roll them in with the controller patch (#1812720: Implement the new panels-ish controller [it's a good purple]). that's code i'm literally writing that code right now, since we're down to ONE failure on blocks-as-plugins :)

This is an important issue, but I don't believe it's a critical task (see http://drupal.org/node/45111 and http://drupal.org/node/1181250). Specifically, although we should fix this throughout core, if contrib modules are failing to use #attached it's already a bug against that module, not really core's fault directly. Also, none of the issues that this is a blocker for are marked critical - at least not as of a few minutes ago, anyway :)

If you disagree and feel this must still be marked critical, please provide a very specific justification and keep in mind that every critical issue significantly prevents other features that people are working hard on from getting into Drupal core, due to the issue queue threshold policy (until/unless #1810428: [Policy, no patch] Adjust major and critical task thresholds during code thaw is addressed, at any rate). Note that I am not singling out this issue for particular attention but rather (slowly) trying to go through the issue queue and do this in many places so that other features still have a chance to get into Drupal core soon without the thresholds getting in the way. I am trying my best to be impartial, and of course, just because an issue isn't marked "critical" certainly doesn't mean it's unimportant to work on. You can follow my progress via the tag I've just added to this issue :)

finally got my giant honking followup posted: #1871596: Create a PartialResponse class to encapsulate html-level data [Moving to sandbox]

Sorry for the noise; I'm told that slashes in tags can break the autocomplete on drupal.org.

I added a comment in #1762204-40: Introduce Assetic compatibility layer for core's internal handling of assets for why I think this issue is separate from that one, needs to happen regardless, and can be worked on in parallel. Adding the caching tag to try to keep everything that's needed for ESI discoverable.

Updated issue summary.

Tagging.

Opened #1998102: Remove the global JS futzing in ViewsFormBase::getForm() for that tricky bit.

So I picked off some of the low-hanging fruit in #2003524: Remove drupal_add_css from() help.module — use #attached, #2003564: Remove drupal_add_css() from block.module — use #attached, and #2003574: Remove drupal_add_css() from openid.module — use #attached.

The remaining drupal_add_css/drupal_add_js issues are split between:

• Theme functions/preprocessors
• Tests
• Form-alters
• Complex systems (e.g. using drupal_add_css() to get a list of the current css files, then doing some processing on that list

In other words, things that don't necessarily lend themselves to easily swapping to an #attached property on a render array.

Adding breadcrumbs issue

#15: Thanks, reviewed & RTBC'd all three of them.

Four calls to drupal_add_css in theme.maintenance.inc: issue and patch here: #2008270: Remove drupal_add_css() from template_preprocess_maintenance_page() — use #attached

Updated issue summary.

Added list of issues to remove drupal_add_css and drupal_add_js.

Updated summary and added patch for colour module: #2010636: Remove drupal_add_css() and drupal_add_js() from color.module — use #attached

Added #2010636: Remove drupal_add_css() and drupal_add_js() from color.module — use #attached

Updated summary and added patch for book module: #2012526: Remove drupal_add_css() from book.module — use #attached

Added #2012526: Remove drupal_add_css() from book.module — use #attached

The right way to do drupal_set_message() is to use flash messages on the Symfony session, on the request object. Which of course is still blocked by Simpletest: #1858196: [meta] Leverage Symfony Session components

I've discussed this with several people, including Crell, sdboyer, and Dries, and all agree on this being a critical issue, because of the huge performance impact that enabling block and other partial page element caches in core by default would have.

Specifically, although we should fix this throughout core, if contrib modules are failing to use #attached it's already a bug against that module, not really core's fault directly.

Right. This issue is primarily about fixing the usages in core. Though once we do that, removing the functions themselves, to force contrib to also do things correctly, is pretty easy.

Rerolled

• #2010636: Remove drupal_add_css() and drupal_add_js() from color.module — use #attached
• #1969916: Remove drupal_add_js/css from seven.theme

However, there are still many other remaining calls to drupal_add_(css|js)(). We need issues/patches for those as well.

Removing OpenID issue.

Added related issue

I had a list, somewhere. I'll update it and add the issues.
(Most are in tests, iirc.)

#26: yep, typhonius is working on those already! :) I expect he'll file a new issue along with a patch.

Moved to cache system per #2050763-16: Refine "base system" component (notes on refactoring of "base system" category here: https://docs.google.com/a/acquia.com/spreadsheet/ccc?key=0AusehVccVSq2dF...).

This will be an API change, but my understanding is this is implicitly approved because it makes render caching work.

Re-adding tags for #29. Tag Monster!

Added in related issue for bartik.theme

https://docs.google.com/a/acquia.com/document/d/1sgxD0l2OM91EqTekXryhdaX... has notes from Portland; looks like it somehow never got linked here.

We still need issues for drupal_set_breadcrumb() and drupal_set_message(). Adding the latter to the summary.

Updated issue summary.

Filed #2073817: [META] Remove drupal_set_message() for that discussion.

Updated issue summary.

Updated issue summary.

Split off #2073819: [META] Remove direct calls to drupal_add_css() and #2073823: [META] Remove drupal_add_js() calls to make it easier to get novice contributors working on those tasks.

#1743590: Isolated Block Rendering was postponed on this. since this is done, opening that one.