hook_theme_registry_alter should provide a second parameter containing the name of the theme that we are currently building the registry for. In many cases this is not required but I just recently ran across one where it indeed is. I am aware of the fact, that in 99.99% of the cases this is identical to the global $theme_key but since the functions that invoke hook_theme_registry_alter are also called with the theme name as a parameter it is not unlikely that this code might be called with a different theme name than the currently active theme (for example by a contrib module).

@see: http://api.drupal.org/api/drupal/includes--theme.inc/function/_theme_bui...

Comments

dvessel’s picture

Version: 7.x-dev » 8.x-dev

I think you're confused about how the alter hooks interact with modules and themes.

If you want to target a specific theme then try using the global $theme (not $theme_key since that can change in various conditions). The $theme global will always be specific to the theme that rendered the current page.

But I do see how it can be useful to have that parameter for easy access. Bumping to 8 since it's an api change.

lauriii’s picture

Version: 8.0.x-dev » 8.1.x-dev
Issue summary: View changes
Status: Active » Postponed (maintainer needs more info)

This is a feature that could be added in a minor version of Drupal 8. However I still don't understand, what is the use case for altering theme registry for specific theme only from a module? I don't think such thing should be possible since modules cannot depend on theme. If you use hook_theme_registry_alter inside theme it will be run only for the theme where the alter is in.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.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.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

joelpittet’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

In Drupal 8 we can get the current active theme with
\Drupal::theme()->getActiveTheme()->getName()

Closing to triage the issue queue, reopen if you feel this still needs to be addressed. If so please address questions from #2

donquixote’s picture

Status: Closed (works as designed) » Active
Related issues: +#2142181: Make $theme available to hook_theme_registry_alter().

However I still don't understand, what is the use case for altering theme registry for specific theme only from a module?

The idea is not to target a specific theme name from the module, but to do alterations depending on information found in or for the theme being processed.

Examples:

  • crumbs_theme_registry_alter(): Crumbs allows to have distinct breadcrumb display settings per theme. When altering the theme registry, it loads the setting for the theme in question, and does alterations depending on this setting.
  • atomium theme: We are currently trying to move the logic from the theme into a module. It would allow all themes to have specialized theme functions with __ suffix, similar to templates. Or something like that. For this, we alter the theme registry depending on information found in the theme.
  • mailsystem_theme_theme_registry_alter() only does its alterations for the theme that is used for emails. It is probably fragile and hacky, but the use case is valid, I guess.

None of these hooks hardcode a specific theme name.

In addition, themes can use this hook to alter their own theme registry. In this case it would be ok to hardcode the theme name.

I am switching to "Active" again.

donquixote’s picture

My previous comment was about Drupal 7.

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

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Branches prior to 8.8.x are not supported, and Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should 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: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

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

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should 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.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should 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: 9.5.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. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.