TypeError: Drupal\Core\Utility\ThemeRegistry::getGlobalPreprocess(): Return value must be of type array

Prevent a NULL return value in the function Drupal\Core\Utility\ThemeRegistry->getGlobalPreprocess() that always has to return an array.
If the Gin-theme (based on Claro) is used as admin theme, the above error occurs in Drupal 11.3.
The following patch solves the problem.

Thanks for the issue and a patch, maybe you can create a GitLab MR? https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr...

What is the root cause?

It seems that some preprocess functions of the Gin theme are not registered at all, because the get('global preprocess') function returns NULL. See also the work in progress in the linked issue.

Can you share a list of modules you have installed?

Here's my composer file.

Do you have the contextual module disabled?

The interesting thing is that getGlobalPreprocess only gets module hook_preprocess implementations.

I think it's a simple quick fix to do what you proposed, but it's interesting we're hitting that situation.

Looking again there is something else going on, we set the default to an empty array where it gets set, is there more to the error you are receiving?

I can push it up to see if any tests fail with this addition, but I'd like to see where it's coming from.

@Berdir suggested a hook_theme_registry_alter might do this, can you review your site to see if there are any of those?

I have two hook_theme_registry_alter functions in my code, both are just overriding the path of some templates, which are newly defined in my modules.
Function in ting module (already converted to OO code):

/**
 * Implements hook_theme_registry_alter().
 */
#[LegacyHook]
function ting_theme_registry_alter(&$theme_registry): void {
  \Drupal::service(TingWebformHooks::class)->alterThemeRegistry($theme_registry);
}

Function in TingWebformHooks class:

  #[Hook('theme_registry_alter')]
  public function alterThemeRegistry(&$themeRegistry): void {
    $path = $this->pathResolver->getPath('module', 'ting');
    $themeRegistry['webform_submission_form']['path'] = $path . '/templates';
    $themeRegistry['webform_section']['path'] = $path . '/templates';
    $themeRegistry['webform_confirmation']['path'] = $path . '/templates';
  }

But my guess is, that the gin theme has been heavily refactored in October. And there was also work in the area of turning preprocess hooks into OO code (see Issue https://www.drupal.org/project/gin/issues/3553537). Coincidence?

Thank you, that looks fine at first glance. Yes the Gin refactor is likely a coincidence since global preprocess is module only.

Remark:
Because the ThemeRegistry::get() function can return NULL, my change in the ThemeRegistry::getGlobalPreprocess() function is mandatory, because an array as return value is requested.

Yes that's why I added the MR, honestly we should do the same for getPreprocessInvokes.

I think this qualifies for the fix without tests policy.

I just wanted to understand better how we get into this situation to see if there is a deeper issue.

Agree with getPreprocessInvokes fix. Thanks for the merge request.

Thanks for reporting, possible to get concrete steps added to the summary to reproduce.

Also may need test coverage for this.

Let's make this easier to find.

Should the default to array be done in ::resolveCacheMiss()? It would mean everything else could guarantee it gets an array back, but it might be too much.

I got confirmation from @catch in slack that this is eligible for being fixed without tests https://www.drupal.org/about/core/policies/core-change-policies/core-gat...

Still needs an issue summary update with more detail and a followup to figure out how this is happening. Leaving need work for that.

This was only reported for getGlobalPreprocess(), not the other one. Seems extremely unlikely that the invokes is completely empty?

Per #12, I suspect this, especially doing it to the invokes method would hide a major issue and make all OOP preproccess hooks non-functional and therefore lots of really weird errors.

Hello a change between 11.2.10 and 11.3.0 introduced the error. Here a diff output:

179c179
<   public function getPreprocessInvokes() {
---
>   public function getPreprocessInvokes(): array {
180a181,193
>   }
> 
>   /**
>    * Gets global preprocess callbacks.
>    *
>    * @return array
>    *   An array of preprocess callbacks that should be called for every theme
>    *   hook.
>    *
>    * @internal
>    */
>   public function getGlobalPreprocess(): array {
>     return $this->get('global preprocess');

Solved temporarly by rmoving the : array

Somehow I missed 21, I don't know how we would do it in resolveCacheMiss how do we know the expected type?

I don't have a super strong opinion about 23, but I trust @berdir's instincts.

I will remove the extra one in invoke I added and create the investigation follow up.

Once tests are done I think this will be ready.

Created: #3568066: Investigate how global preprocess map can be null

This needs to be recreated on the new main branch it was created on 11.3.x

Edit: unfortunately it looks like we need to manually update the fork. Once that is done we need to add ?? []

To the getGlobalPreprocess method in ThemeRegistry

Ok that was fun(tm)

I think it's OK to get it in like this without test coverage, steps to reproduce are not entirely clear, but this stops the bleeding. The whole theme registry structure and build process is due for a refactor once all the BC layers are gone.

Committed/pushed to main, 11.x and 11.3.x, thanks!