Problem/Motivation
In #953034: Themes improperly check renderable arrays when determining visibility the second case is that a region does contain empty blocks, but also placeholders after rendering. (e.g. the messages block or the user login block (max-age=0))
Further there is 2 possible cases, when placeholders will be replaced to determine empty-ness:
1. Able to do during rendering, because the placeholders have not been replaced to ESI or BigPipe tags or whatever. => Non-JS solution in a FinishResponseSubscriber. => Ensure we can do this without having to parse the DOM after placeholders have been replaced.
2. Need to do this client side with Javascript (e.g. BigPipe with JS is enabled), but ajax would need the same.
Open question:
- What to do for simple streaming that replaces placeholders last, but needs to be consistent in itself? => possibly make the whole region a new non-lazybuilt placeholder including the other placeholders?
Proposed resolution
- Discuss
Comments
Comment #2
fabianx commentedBrainstorming:
So overall it seems even with the new section tag, the biggest problem is that a non-JS solution can only work in isolation of ESI.
And unlike in core where a late middleware could check empty-ness, ESI would need to rely on purely Javascript, which the biggest advantage of it is, that it does not need that.
However usually it is only a section that we worry about and I wondered if not the best thing would be if that if we detect placeholders in a section that should be conditionally shown based on empty-ness, is to placeholder the whole section instead.
That would be less ideal than just placeholdering the relevant block, but it would allow the simple visibility rule to work perfectly.
Also it would mean that the rendering would just work perfectly, because recursive placeholders are always directly replaced.
In theory even a list of lazy builders would still be effectively cacheable in dynamic page cache as it all could still be rendered independently and also cached independently.
The effect of BigPipe and ESI of course would be less, but those concerned with that could ensure with visibility conditions that the section never contains placeholders and hence this is never a problem.
Especially for BigPipe though placeholdering the whole section might create layout problems ... :/ (as it has the opposite problem)
Comment #3
fabianx commentedThinking of this some more:
- ESI in Varnish can only work with a fixed layout. That is nothing new and nothing we need to solve here. A JS enhancement to hide the section once the page is loaded is nice though.
- BigPipe really wants a fixed layout, too.
--
Outside of those two late placeholdering technologies themers want their section to be shown or not shown. This needs to happen after dynamic page cache OR an internal ESI like cache, so preferably in a middleware using very little CPU.
A markup that would allow that is:
So by searching for
<!-- INNER_SECTION '$var' -->from attached drupalSettings we could easily check if the section is empty or not and also remove all the<!-- SECTIONtags again and just leave the data attributes.So markup would look for BigPipe after the middleware / response subscriber like:
And attachBehaviors() could every time check for data-section-empty elements in the parents (or whole document for context=document).
So that would work as well and hide the section as soon as possible (also for ESI users with JS enabled).
If users truly need empty markup, they would need to use with a CSS styled width of "0" or a non-visible UTF-8 character - though that is more easily possible to achieve, but a slight BC break.
Comment #17
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!