Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 291454

Introduce new Theme extension object and properly deprecate REGIONS_VISIBLE and REGIONS_ALL

$
0
0

Problem/Motivation

#2807785: Move global constants from *.module files into interfaces deprecated a bunch of constants but it did not actually replace their usage. We should do this. This issue handles REGIONS_VISIBLE, and REGIONS_ALL. This is a bug because we've deprecated something but we've not completed the task and, more importantly, the old constants are in the System module and used by it but the new constants are in the Block module. That does not work.

Regions are properties of themes not blocks. They are declared in a theme's .info.yml file in the regions key and hidden via the regions_hidden key.

Proposed resolution

Current solution

Add a new Theme class that extends Extension and replaces the extension object in theme lists.

See API changes for a full scope of all the changes.

Other possible solutions

  • Add a new ThemeRegion service.
  • Add an object just to handle the theme extension's info array - discounted in #24 - we have code that depends on this being an array.
  • Add ThemeHandler::listAllRegions($name), ThemeHandler::listVisibleRegions($name) and ThemeHandler::getDefaultRegion($name) - discounted in #13

Remaining tasks

User interface changes

None

API changes

The main changes are:

  • system_region_list() use \Drupal::service('theme_handler')->getTheme()->listAllRegions() or \Drupal::service('theme_handler')->getTheme()->listVisibleRegions() instead.
  • system_default_region() use \Drupal::service('theme_handler')->getTheme()->getDefaultRegion() instead.
  • REGIONS_ALL, REGIONS_VISIBLE, \Drupal\block\BlockRepositoryInterface::REGIONS_ALL and \Drupal\block\BlockRepositoryInterface::REGIONS_VISIBLE are deprecated and should not be used.

As a result several objects that had helper methods to the global functions also have API deprecations:

  • \Drupal\block\BlockListBuilder::systemRegionList() use $this->themeHandler->getTheme()->listAllRegions() or $this->themeHandler->getTheme()->listVisibleRegions() instead.
  • \Drupal\block\Controller\BlockController::getVisibleRegionNames() use $this->themeHandler->getTheme()->listVisibleRegions() instead.
  • \Drupal\block_place\Plugin\DisplayVariant\PlaceBlockPageVariant::getVisibleRegionNames() use $this->themeHandler->getTheme()->listVisibleRegions() instead.

Several methods on the ThemeHandler return an array of Theme objects instead of Extension objects. As Theme extends from Extension this is allowed. These methods are:

  • \Drupal\Core\Extension\ThemeHandlerInterface::listInfo()
  • \Drupal\Core\Extension\ThemeHandlerInterface::rebuildThemeData()

\Drupal\Core\Extension\ThemeHandlerInterface::getTheme() now returns a Theme object.

The one "breaking" change is \Drupal\Core\Extension\ThemeHandlerInterface::addTheme() which now only accepts a Theme object. This change is worth it because this is an incredibly low level method that only exists so that maintenance pages and install pages can use themes before anything is installed. The hard break would help any custom or contrib code in the very unlikely event that they are using it.

New \Drupal\Core\Extension\Theme that extends \Drupal\Core\Extension\Extension and we can build up the abilities of over time so eventually we can replace everything with methods. No more $theme->info['foo'] and we can remove the public properties and turn them into value objects.

Data model changes

None


Viewing all articles
Browse latest Browse all 291454

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>