This issue is dependent upon: #1535868: Convert all blocks into plugins

Blocks need the ability to be rendered in complete isolation through a menu item dedicated to rendering blocks from subrequests. The technical details on this are a little fuzzy still, but the basics are:

  1. A menu item which is likely ['block/%block']. This %block would be the full CMI address of a given block instance and block_load() (which already exists) would return a block plugin instance that is fully configured. This should be relatively trivial to write as all the code except the menu item already exists and should work this way.
  2. 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.
  3. Get a subrequest actually parsing blocks into a parent request object. (this will likely require some effort with regard to fleshing out some caching options per block, but even a hard coded working example would be beneficial at this point)

Eclipse

Comments

catch’s picture

Priority:Normal» Critical

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.

chx’s picture

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.

Gábor Hojtsy’s picture

Status:Active» Postponed

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

Damien Tournoud’s picture

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.

mikeytown2’s picture

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.

catch’s picture

@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.

webchick’s picture

Status:Postponed» Active

BAP got committed, so un-postponing this.

webchick’s picture

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

catch’s picture

Priority:Critical» Normal
Status:Active» Postponed
YesCT’s picture

Priority:Normal» Critical
Issue summary:View changes
Status:Postponed» Active
Issue tags:+Needs issue summary update

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

It should probably use an issue summary update

catch’s picture

Priority:Critical» Major

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.

Wim Leers’s picture

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….)

EclipseGc’s picture

+1000000 to what Wim is saying.

mikeytown2’s picture

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.