Deprecate ThemeHandlerInterface::getBaseThemes and remove usages from core

I think the whole concept of getBaseThemes() on both the ThemeHandler and the ThemeExtensionList is not needed. The function signature of having to provide a list of themes to search for sub themes is very odd because both of these things have lists of themes ?!!?

I think this probably needed before we had \Drupal\Core\Theme\ActiveTheme::getBaseThemes() but it appears obsolete now.

+++ b/core/lib/Drupal/Core/Extension/ThemeExtensionList.php
@@ -194,8 +194,14 @@ protected function fillInSubThemeData(array &$themes, array $sub_themes) {
   public function getBaseThemes(array $themes, $theme) {
+    @trigger_error("\Drupal\Core\Extension\ThemeHandlerInterface::getBaseThemes() is deprecated in Drupal 8.7.0 and will be removed before Drupal 9.0.0. There is no direct replacement. See https://www.drupal.org/node/2709919.", E_USER_DEPRECATED);

+++ b/core/lib/Drupal/Core/Extension/ThemeHandler.php
@@ -165,6 +165,7 @@ public function rebuildThemeData() {
   public function getBaseThemes(array $themes, $theme) {
+    @trigger_error("\Drupal\Core\Extension\ThemeHandlerInterface::getBaseThemes() is deprecated in Drupal 8.7.0 and will be removed before Drupal 9.0.0. There is no direct replacement. See https://www.drupal.org/node/2709919.", E_USER_DEPRECATED);

error in "list" message - copy/paste from handler

Looks there's no need at all in gathering base themes

Nice catch.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

For good practice we should still use the standard issue summary template.

Still is tagged for change record updates from a few years back.

Updated the CR too

So I think this needs it's own change record.

The current one is published and said it was introduced in 8.7 which isn't the case for this. So methods have been deprecated in 8.7 and no 10.3 I'm just worried that would be confusing.

Will post in slack also.

Yes, this should have it's own change record. Any changes to the original change record should be moved to the new one so that the dates and version/branch of each change record is correct.

Updated remaining tasks in IS

Additional CR looks fine, made some tweaks to make it clear when it was deprecated and removed.

is deprecated in drupal:10.3.0 and is removed from drupal:12.0.0

What is the reason for keeping this until Drupal 12? We are OK to deprecate in 10.3.0 for removal in 11.0.0, except where we think things might be widely used or difficult to remove, but this one looks straightforward.

Believe there is a slack discussion around this. But moving to NW as the MR is unmergable.

Resolved conflicts / rebased

Edit: removal stays in D12

Fixed https://wiki.php.net/rfc/make-reflection-setaccessible-no-op

Applied a simple :void to the test, but deprecation seems correct.

Committed and pushed 1e80a22b06 to 11.x and 5e778473f4 to 10.3.x. Thanks!

Also published the change record.

Third time lucky, issue credits got swallowed up by d.o somehow.

We are also using this function in our custom module. But after deprecation there are no replacements suggested here.
So Is there any alternate workaround to achieve this?

Before looking for workarounds please consider if you really need this method as it very internal to ThemeExtensionList::doGetBaseThemes() which you can decorate/access in a hacky way

But custom code is not expected to use this method

Thanks for reply andy.
Yes for our use case it might be needed as we are creating some predefined block based to the base theme condition in hook_theme_installed() hook.

Hmm, my theme is heavily using the getBaseThemes and I would like to avoid a major refactor. So you're saying it's possible to decorate ThemeExtensionList::doGetBaseThemes() in order to do what getBaseThemes does?

I'm seeing doGetBaseThemes in core/lib/Drupal/Core/Extension/ThemeExtensionList.php

and there's a test for it in core/tests/Drupal/Tests/Core/Extension/ThemeExtensionListTest.php

Makes me wonder what the rationale for this change is/was?

***EDIT***
I was hoping to use the russian Drupal code grepper to find usages elsewhere but it's currently offline. Other search tools available for contrib are a bit clunky and slow.
***END EDIT***