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.
- - discounted in #24 - we have code that depends on this being an array.
- - 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