Search API indexes view modes in administration theme

Got the same issue here. I've tried to fix it by copying the template files from display suite to the default theme and then to the admin theme. Nothing worked i still get the output like in the screenshoot.

Thanks for reporting this problem! I hadn't thought about this, but it could of course really be a problem.
However, sadly I'm not sure how we can solve this. I'm no expert at all on the theming layer, but it looks to me like changing the active theme just for one function call is not something that Drupal really supports. You can change the theme for the current page in hook_init(), but then you're stuck with it for that page requests. It could probably be done, but only in a very low-level and hack-ish way which would make me afraid to break more things than we fix.

So, unless someone more experienced with the theming layer comes up with a solution, I'm not sure how I could help you.

Any new status there?

I opened an issue in the display suite que. Maybe there come some input over this channel.

Found the main issue for this problem.

Support for search api

This is actually not only DS related but a general problem when e.g loading additional data in preprocess or anywhere else in the theme layer. Another problem is that the data get's corrupted because the indexing context decides which version get's indexed:

- cron indexes using the -> frontend theme
- if you choose to index immediately -> admin theme
- indexing using the admin page -> admin theme

This makes more or less sense but does anyone know why cron indexes in the frontend theme? That could give us a hint to eventually fix this. Also changing the issue title etc

Here's a workaround for the batch-problem:

function mymodule_batch_alter(&$batch) {
  if ($batch['sets'][0]['file'] == 'sites/all/modules/contrib/search_api/search_api.module') {
    $batch['theme'] = ''<your-frontend-theme>';
  }
}

Thanks @stmh. This pronlem was driving me crazy, Search API view modes only pulls the node.tpl.php from Drupal Core. I couldnt get it to work even when placing a node*.tpl.php in the admin theme, so I dont think #5 is quite right.

#6 worked for me, at least it is a workaround and lets me have custom template html view modes without needing to hit the DB.

Thanks stmh. I ran into this issue as well.

If items are being indexed by manually calling cron, hook_batch_alter will not be called and the admin theme will be used while rendering.

To set the correct theme on manual cron updates you can implement hook_custom_theme to force a specific theme to be used on that specific uri

function mymodule_custom_theme() {
  if (request_uri() == '/admin/reports/status/run-cron') {
    return '<your-frontend-theme>';
  }
}

This patch changes the active theme to the default theme and initialises it so that it indexes the default themes html output.

Thanks a lot for posting this!

Looks quite good. However, why do you only switch the theme if the current one is the admin theme? Shouldn't it always switch if it's not the default theme, to make this as consistent as possible? (Though I guess there won't be a difference for 95% of sites.)
Also, why do you only reset the static cache of drupal_alter() and not those of module_implements()? And are these really the only static caches (that could realistically be accessed/changed in the code between the theme switches) influenced by the theme?

In any case, it would be great if a few people could test this on their sites and report back whether it works as expected for them, and not cause any issues with their setup. As said, I'm pretty sceptic about this not breaking a site somewhere.
Maybe we should make this behavior optional, so people have an easy way out if it messes things up for them?

Patch #9 is not working for me. Tried different ways to change the theme but still not working.
The code in patch #9 is based on drupal_theme_initialize(). However, the $GLOBALS['theme'] should be unset for drupal_theme_initialize() to do anything, which unfortunately does not work either.

Workaround in #6 is the one which is working for me, with a minor modification.

function mymodule_batch_alter(&$batch) {
  $path = drupal_get_path('module', 'search_api');
  if ($batch['sets'][0]['file'] == "$path/search_api.module") {
    $batch['theme'] = variable_get('theme_default', 'seven');
  }
}

@ckng thank you a lot.
#12 works great when indexing with batch API.

Indexing using cron use default_theme, so nothing to change.

I suggest to edit theme changing logic, because sometimes seven theme not enabled

Interdiff #12

- $batch['theme'] = variable_get('theme_default', 'seven');
+ $batch['theme'] = variable_get('theme_default', $batch['theme']);

Result

function mymodule_batch_alter(&$batch) {
  $path = drupal_get_path('module', 'search_api');
  if ($batch['sets'][0]['file'] == $path . '/search_api.module') {
    $batch['theme'] = variable_get('theme_default', $batch['theme']);
  }
}

Patch #9 works for me when the INDEX is forced to update from Search API index form by triggering "re-index all items".

However, I cannot figure out why it doesn't work when forcing to re-index a single node.

E.g., when an admin manually creates a new node or updates existing one (and Admin theme is SEVEN), the node is indexed with neither SEVEN nor DEFAULT theme => it triggers node rendering with NODE module template file /modules/node/node.tpl.php.

I have also tried to force re-index of specific node with RULES action from Search API "Index entity" - still the same result.. Any idea how to fix this ?

The only approach thats worked so far in 7.x for us is a combination of #6 and #8.

/**
 * Implements hook_batch_alter().
 * @param $batch
 */
function mymodule_batch_alter(&$batch) {
  if (isset($batch['sets'][0]['file']) && $batch['sets'][0]['file'] == 'sites/all/modules/contrib/search_api/search_api.module') {
    $batch['theme'] = variable_get('theme_default', 'seven');
  }
}

/**
 * Implements hook_custom_theme().
 * Ensure that running cron uses the right theme for Search API indexing.
 */
function mymodule_custom_theme() {
  if (request_uri() == '/admin/config/system/cron') {
    return variable_get('theme_default', 'seven');
  }
}

Thanks Kevin, I'll try it out.

#9 works fine for me!

However, I'm resubmitting the patch with a proper name, according to the patch naming conventions (https://www.drupal.org/patch/submit), which includes the module name, because it's very hard to update modules and reapply patches if the module name is not included.

I've just created a similar patch for the Search API View Modes module: #3008417: Switch theme to render items
I'm still testing but it seems to work reliable. I hope I find time and can port the approach to the Search API rendering as well.

For me, #18 no longer worked because it seems that there has been another static container introduced which does some caching of the selected theme, so my theme was not switched. I've added a patch which simply extends #18 by the deletion of said variable, and now it works just fine.

I guess patch #20 will work for most sites. But I have the pleasure of working with a multiple entity index, which has a few bugs, one of them is that the viewed entity is not compatible. There is a patch that fixes this, but it has overlap with the patch for this issue.
https://www.drupal.org/project/search_api/issues/2570117

Just in case someone else runs in to the same problem, I made a patch that can be done after applying the patch to fix the callback for the multiple entity index. It is based on version 1.26 and not the latest develop commit.

I did make a small change. It didn't make much sense to me to check for the admin theme, so I changed it to check if the default theme isn't the active theme.

I refactored #20 to basically use the mailsystem module's mailsystem_theme_swap_theme() code.

The switching back and forth code has been moved to a dedicated method.

The switch to the default theme is now done from whatever theme is used (which not necessarily is the admin theme).

Also in this case I don't think it's necessary to call _drupal_theme_initialize() to add CSS and JS files as we don't need them for rendering and we'll switch back to the previous theme anyways.

D8 had the same issues:
#2732881: 'Rendered item' processor renders in the admin theme if indexing is done either on node edit or from the Search API UI
#2869103: Admin theme is used for indexation when saving a node

Thanks, looks great!
Just some minor adaptions in my attached revision.

However, as we have almost no test coverage for D7, it would be really important that several people test this before we can commit it. This looks like it could potentially break sites. (Even though I see it’s been in use in mailsystem for several years now – but pretty surely in a different context.)

Anyone interested in testing this and helping to get it over the finish line?

Come one, this issue has 20 followers and no-one is prepared to spend a few minutes in testing this?

@drunken monkey
Thank you for your patch. I would love to test this feature.
Unfortunately, the way you implemented it does not permit me to access it:
You tied it to SearchApiAlterAddViewedEntity, which makes perfectly sense as it's the subject of this issue.
But in my case, I would need this feature decoupled so that I can switch theme from my custom indexing function (not using SearchApiAlterAddViewedEntity).
It would be great if this switch/unswitch logic could be put somewhere else it could be called from any indexing function (in addition to SearchApiAlterAddViewedEntity).

Sure, why not. Thanks for the suggestion!

@ anrikun: Is it now RTBC for you?

Or does anyone else have feedback?

I'm so sorry for not answering yet. I will review your patch next week. Please send me a reminder if necessary.

I works! Thank you @drunken monkey!

Good to hear, thanks for testing and reporting back.
Ideally, we’d have more testers, but as this issue is very old now, I’m just merging this and hoping it won’t break anything. Will wait a few weeks before creating a new release with it, just in case.
In any case, thanks again, everyone!

Thank you for for that, sorry for not responding (we have not been on 7.x for some time now) but you all are doing great work.