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

Remaining tasks

User interface changes

API changes

Data model changes

Comments

Fabianx created an issue. See original summary.

fabianx’s picture

Brainstorming:

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)

fabianx’s picture

Thinking 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:

<!-- SECTION 'content.sidebar_first' -->
  <div class="sidebar-first" data-drupal-section-emtpty="content.sidebar_first">
<!-- INNER_SECTION 'content.sidebar_first' -->
  <span>I have content</span>
<!-- INNER_SECTION 'content.sidebar_first' -->
  </div>
<!-- SECTION 'content.sidebar_first' -->
<!-- SECTION 'content.sidebar_first' -->
  <div class="sidebar-first" data-drupal-section-empty="content.sidebar_first">
<!-- INNER_SECTION 'content.sidebar_first' --><!-- INNER_SECTION 'content.sidebar_first' -->
  </div>
<!-- SECTION 'content.sidebar_first' -->

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 <!-- SECTION tags again and just leave the data attributes.

So markup would look for BigPipe after the middleware / response subscriber like:

  <div class="sidebar-first" data-drupal-section-empty="content.sidebar_first">
    <span data-bigpipe-placeholder-id="[hash]"></span>
  </div>

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.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank 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!

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.