Redirects during cron

If you mean that it gets triggered by the search indexing, you need to ensure that the content type being used has a customized display for the "Full content" display mode. In other words, don't use the Redirect display widget if all you're using is the Default display mode as it'll completely bork things up :)

That said, perhaps a little more explanation in the README.txt file, and possibly a comment in the widget form, would help?

This needs documentation.

I've done as requested in #1 but still getting redirected.
As you said it is because of SearchAPI indexing process.
There is alternation method which enables you to index whole node so it seems that it just loads full node view.
After turning it off redirection stopped.
I wonder if anything can be done here.

I've just started using SearchAPI too, so I'll see what I can work out.

I've added a new issue for verifying the SearchAPI compatibility: #1609248: Ensure compatibility with SearchAPI

This adds some checks at the start of field_redirection_field_formatter_view() that will make execution bail when ran via Drush, via the cron.php file or when in maintenance mode.

Added a check for the admin/reports/status/run-cron page, fixed the check for maintenance mode.

Committed.

FYI #1979300: Display a warning when editing unsuitable view modes should help people avoid configuring Field Redirection for the wrong view modes.

Leaving this as postponed as I'm not sure how much work can or should be done to work around the problem.

This sadly still seems to breaks cron runs on search index in certain cases. This happens if a page is indexed which uses field_redirection for a link field. It doesn't limit to view mode "Default" like described above as for example you might use the redirection on other view_modes too which are displayed / indexed.

In our case it's view mode "Full" of a taxonomy term, I'm not yet sure why it's being indexed by search API, but it kills cron via redirect.

I'll further investigate this and try to find out why none of the conditions that were added in the commit work. Does someone know if core exposes information if the current call is a cron run? Perhaps it would make sense if core would set a parameter at the beginning of a cron run for such cases?
On the other hand it's not really a cron problem, but more a "This is a search crawl" problem and cron is just running it? Any ideas?

Switching this to 8.x as it seems it doesn't work in all cases... Didn't yet figure out why none of the if's work here...

But I think I have a safer idea, at least for Search API:
This module could provide a search api preprocessor to "Exclude all entities with field redirection". If checked, all entities with an active redirect are skipped.

Just like checking the "Skip" checkbox at https://www.drupal.org/project/search_api_exclude_entity.

Wanted to leave that idea, but let's first see why redirects still happen on cron run with search_api indexing and break cron.

Haha, I found the reason! :)

    if (mb_strpos($current_path, '/cron') === 0) {
      return TRUE;
    }

doesn't work for multilang projects! ;)

$current_path is /de/cron there...

Solution: use

$current_url->getInternalPath();

instead of

$current_url->toString();

Didn't check if Drupal 7 has the same problem.

MR !2 is the right one!

One more point I'd like to suggest: When using Search API you can start indexing via UI as batch job, e.g. on admin/config/search/search-api/index/content_index

The $current_url is then starting with /batch so I'd suggest to handle it just like /cron and add that condition?

@DamienMcKenna could you have a look at MR2 and #20 please? :)

Committed. Let's do any additional changes in separate issues.

Thanks, Damien! :) Looking forward to the next stable release with this fix.

@DamienMcKenna, this didn't make it into a stable release yet. Is one planned? (BTW note that there's a test failure in dev)