search_api_post_update_views_cache_none() replaces all cache types with "search_api_none"

Here is a patch that fixes the typo.

The reason this is bugged is because of order of operations, fixed by the brackets. The cache type can be NULL in a number of situations, such as when the cache type is set in the default display and not overridden in the other displays.

https://www.php.net/manual/en/language.operators.precedence.php

$display['display_options']['cache']['type'] = 'search_api_tag';
$result = ($display['display_options']['cache']['type'] ?? '' === 'none');
print $result; // search_api_tag, which is TRUE in a condition

$display['display_options']['cache']['type'] = 'none';
$result = ($display['display_options']['cache']['type'] ?? '' === 'none');
print $result; // none, which is TRUE in a condition

$display['display_options']['cache']['type'] = NULL;
$result = ($display['display_options']['cache']['type'] ?? '' === 'none');
print $result; // false

This is because "??" is "right associative" and lower priority than "===" which is non-associative. In a condition, php tries to shortcut the decision. If it believes that it has a positive outcome, it will no longer execute the rest of the code. In this case, the parts are divided into $display['display_options']['cache']['type'] and '' === 'none' with "??" between. If the variable doesn't evaluate to NULL, then nothing on the right is checked. If the variable is NULL, then it evaluates '' === 'none' which is always false. All quite confusing.

Anyway, the brackets fixes it. The other option would be to evaluate the null coalescing operation into a variable and then use that in the condition.

+1 for patch #2.

+1, just ran into this.

Considering how many sites (some 40,000) this will be affecting, perhaps an emergency release is warranted? A lack of caching on search views would have brought down our site. Bumping to major.

This is a quite huge regression, setting this to critical, a new release is needed

drunken monkey → made their first commit to this issue’s fork.

Thanks a lot for reporting this issue, and thanks @Taran2L for notifying me via Slack! This is indeed a critical bug which needs to be addressed in a new release ASAP.
Created an MR so this can be tested and will merge and create a new release right away once the tests come back green.

Fixed. Will now create a new release.

Here → is the release.

As noted in the release notes, however, this won’t restore the caching strategy you had set on your views before the update to 1.32. You will need to manually restore the proper caching setting for them, in some way.

What is the default caching strategy on a fresh install for the default search view? (to know what to revert to)

@KlemenDEV I believe it is

      cache:
        type: search_api_tag
        options: {  }

What would that translate to in the UI selection? Thanks for help!

Search API (tag-based)

Thanks! :)

Automatically closed - issue fixed for 2 weeks with no activity.