Isolated Block Rendering

This is essential for having any kind of core support for ESI/SSI/CSI, which is likely to be the only way we're able to make up for some of the performance regressions introduced during 8.x. I've talked to Mark Sonnabaum about this and we agreed this is critical to have, and I've spoken to both Dries and Angie today to confirm whether they'd be OK with making it a release blocker. So.. bumping this to a critical task so we don't release without it.

This is where things get tricky because we'll need to figure out how to pass css/js specific to the block upstream, as well as whatever html represents the block.

While I do not understand the "whatever html represents the block' fully -- isn't that just the http reply body?? -- i can answer CSS/JS: HTTP reply X- headers.

Marking postponed on #1535868: Convert all blocks into plugins given the dependency declaration in the issue summary.

Return a response object of that block. This is where things get tricky because we'll need to figure out how to pass css/js specific to the block upstream, as well as whatever html represents the block.

This is the key problem with sub-requests (SSI / ESI) right now (even on Drupal 7). I don't know if there is a reasonable way to conciliate sub-page request rendering and proper CSS/JS aggregation and dependency-handling. On most projects, we ended-up loading upfront all possibly necessary CSS/JS assets.

CSS/JS aggregation in sub-requests. One idea is that the sub-request (the block plugin) would register configuration or a callback for what CSS/JS files it would like to include on the full page. This only works if ESI is not used for external things (use an ESI tag on different independent sites).

Example is I want to include the user login block. That would register form.js to be included on the page when that sub-request is set to be loaded on the full page.

Another example is I want to include a comment block. But for certain users I would also like to include misery.js. This would use a callback as I don't know if misery.js should be included until I look at some context; user object in this case.

Any other ideas on how to make CSS/JS aggregation in sub-requests work? Registering is the best I could come up with.

@Damien, I've discussed that issue in some depth with msonnabaum and others at Munich and BADCamp. It's doable, but hard. Needs properly writing up somewhere.

To make it work we first need to do #1839338: [meta] Remove drupal_set_*() drupal_add_*() in favour of #attached/response for out-of-band stuff.

BAP got committed, so un-postponing this.

Actually, is this the same as #1830854: [meta] The ESI pipeline battle plan?

Postponing this on #1605290: Enable entity render caching with cache tag support and #1839338: [meta] Remove drupal_set_*() drupal_add_*() in favour of #attached/response for out-of-band stuff since it's not possible until those two are done.

the issues this was postponed on look done. restoring back to active critical.

It should probably use an issue summary update

This would be good if we can do it, but most of the pre-requisites like enabling render caching/removing drupal_add/set_*() have their own criticals, so downgrading to major.

Only now discovered this one.

I've essentially been working on this for a long time, by working on bringing render caching of blocks. Making blocks render cacheable involves solving many of the same problems as this, most of which boil down to: be explicit about dependencies. (We can only render cache blocks if we know which contexts it depends upon/is varied by: language, user role, active menu trail….)

Inject context into the block generating function & give 3rd party code the option to inject other things as well. That way you can easily replay the conditions in which that block was originally requested. I use this method for css/js aggregate generation inside of advagg and seems to work quite well.

Duplicate of #2469431: BigPipe for auth users: first send+render the cheap parts of the page, then the expensive parts at this point.