Problem/Motivation

Follow-up to #3103380: Allow rendering dialogs using the admin theme.

Not all admin components are rendered in a dialog. We should allow specifying which theme is used for rendering these as well. This would help Contextual Links, Quick Edit, and Toolbar.

Proposed resolution

TBD

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

lauriii created an issue. See original summary.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Based on the title, I think this is proposing the following:

$build = [
  '#theme' => 'foo',
  'child' => [
    '#theme' => 'bar',
  ],
];

Is that correct?

lauriii’s picture

lauriii
he/him
Primary language Finnish
Location Finland
commented

Unfortunately #theme is already reserved so we need to use something else. Also, we can't allow choosing any theme because otherwise, we have a dependency from modules which would lead to a circular dependency between modules and themes #474684: Allow themes to declare dependencies on modules.

Maybe something like this would work:

$build = [
  '#theme' => 'foo',
  'child' => [
    '#theme' => 'bar',
    '#admin' => TRUE,
  ],
];
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

I'm confused by #3. You're saying that #theme is already reserved. But then your example still uses it, it just adds #admin. So adding a modifier would be okay? What if some contrib code already uses #admin (or whatever other name we pick)?

IOW: I'm confused by it being reserved on the one hand yet your proposal still using it on the other hand 😅

I think it'd be helpful if you could share your reasoning :)

lauriii’s picture

lauriii
he/him
Primary language Finnish
Location Finland
commented

The reserved render array properties are listed here: https://www.drupal.org/docs/8/api/render-api/render-arrays#properties. #theme is used for connecting the render array to a theme hook / template.

The example could be also:

$build = [
  '#markup' => 'foo',
  'child' => [
    '#type' => 'bar',
    '#admin' => TRUE,
  ],
];
So adding a modifier would be okay? What if some contrib code already uses #admin (or whatever other name we pick)?

This is something that has been documented as internal in our BC policy: https://www.drupal.org/core/d8-bc-policy#render-arrays. However, in practice, we'd probably have to give a warning to users in a form of deprecation.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

This is something that has been documented as internal in our BC policy: https://www.drupal.org/core/d8-bc-policy#render-arrays. However, in practice, we'd probably have to give a warning to users in a form of deprecation.

Custom @RenderElements tend to define their own #properties!

I think https://www.drupal.org/core/d8-bc-policy#render-arrays refers to the contents of render arrays, not to #properties in render arrays. 🤔

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.

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.