Admin theme is used for indexation when saving a node

However there must be a reason why they exist ?

The reason is as discussed in #2732881: 'Rendered item' processor renders in the admin theme if indexing is done either on node edit or from the Search API UI: the "Rendered item" property should always use the same theme, not a different one based on where the indexing operation originated. So this code should definitely be there, but it might of course be buggy or have unintended side effects.

I have to admit, I'm not very familiar with the theme system, especially in Drupal 8, so I'm not sure what could be going wrong there. The error message sounds like there might actually be an issue with your custom template? What does the template contain, could you post/attach that?
Also, what's the theme setup on your site? I guess Seven as admin theme and CUSTOM_THEMENAME as your default theme? Are there any parent themes in use, could that maybe lead to the issue?

@drunken-monkey Hello. I am currently running in the same issue using 8.x-1.3.

My use case:

• In my custom theme I am preprocessing a node-type and I also provide a custom twig template for it
  
  Ex. node--custom-node.html twig and hook_preprocess_node__custom_node() in my custom theme.
• I created a DB index that uses "Rendered HTML content" and I am using the Default view-mode for rendering
• When I try to index I get twig errors for the custom variables that I add in my preprocess hook
• After investigating with Xdebug and twig_xdebug I found out that the indexing is using the twig template from my custom theme, but not running the preprocess hook from my custom theme, instead it was using the "seven" admin theme
• I tried the "patch" provided by @hoebekewim and that actually does not crash my indexing anymore.

I hope this is useful.

Thanks for chiming in here. Good to know other people have the same problem. Seems there's really something not quite right with that code. Or, as I'd guess, something missing – namely, the clearing of some static cache(s) that still make some of the theme code refer to the "old" theme, not the one we explicitly set.
It's unfortunate that this leads to the indexing completely failing in such cases, and it's clear that removing the theme-switching code would resolve that problem. However, as explained above, this is definitely not the right solution, because it creates a different problem for everyone else using the processor (and you, too).

As said above, though, I don't know enough about the theme system to know how this should really be fixed. I'd need some theme layer expert to tell me that.
If no other solution presents itself, I guess we could make that code optional, maybe with a hidden setting. But it's really a workaround, not a solution.

As said above, though, I don't know enough about the theme system to know how this should really be fixed. I'd need some theme layer expert to tell me that.
If no other solution presents itself, I guess we could make that code optional, maybe with a hidden setting. But it's really a workaround, not a solution.

I don't really know the solution either, but making that code optional sounds like a bad workaround. Is there a possibility to surface this to any of the core theme maintainers?

The problem we have seems related to this. The theme gets switched correctly, but the preprocess functions of the active theme are not called during the indexing. That's the current state, but I will do some more debugging.

I have the same problem. Did somebody find a solution or at least a better workaround? The patch in #2 may lead to render the content using the admin-theme, what at least in my case is not desired.

It seems that this issue brought me on the right way: #3049414: {{ directory }} in Twig template resolves the directory of the child theme rather than that of the parent theme.

It seems that Search API \Drupal\search_api\Plugin\search_api\processor\RenderedItem::addFieldValues() is using the right theme but, there is a function _template_preprocess_default_variables() in core/includes/theme.inc which seems to be called before that. There the directory variable get set incorrectly to the admin-theme path ($variables['directory'] = \Drupal::theme()->getActiveTheme()->getPath();) and static cached at first call (at least in my case).

Resetting the statically cached default variables fixes the issue for me.

Patch for MR: https://git.drupalcode.org/project/search_api/-/merge_requests/19.patch

Thanks a lot for debugging, would be awesome to finally resolve this!
Unfortunately, automated testing of issue forks doesn’t work in this project for some reason (cf. #3190024: Problem with test dependencies when testing issue forks), so we’ll need to work with patches.

Attaching a minor revision, where the only real change is removing one of the two $this->getThemeManager()->setActiveTheme($default_theme); lines – I assume you meant to move it into the if, not have it twice?
Otherwise, this looks really good, so if you don’t object to my changes, I’d think this is RTBC.

Thanks a lot again, great job!

Committed. Thanks a lot again!

Attaching a minor revision, where the only real change is removing one of the two $this->getThemeManager()->setActiveTheme($default_theme); lines – I assume you meant to move it into the if, not have it twice?

Yes it makes total sense, I don't know why I missed this. Thanks for fixing.