BUG: Behaviour of Related Posts widget and block are not consistent

[burhandodhy]

Describe the bug
The Related Posts widget doesn't show anything when the page is not is_single. However, the block does show the related posts. This is happening because we have a sanity check for the widget that checks if the page is not single then returns. https://github.com/10up/ElasticPress/blob/develop/includes/classes/Feature/RelatedPosts/Widget.php#L42

Steps to Reproduce

1. Add Related Posts Widget and Block in footer.
2. Go to front page.
3. Widget doesn't render anything

[JakePT]

As discussed we probably don't want these to be consistent, since the block has uses outside of is_single(), so instead we can use a check for in_the_loop() || is_singular() so that at least we know that there is a relevant post to get related posts for. The legacy widget will remain unchanged because we don't want it to suddenly appear in places users did not expect it to.

@felipeelia I think that's where we ended up, right?

[chaselivingston]

@JakePT let me know this isn't quite done. #2825 is a fix for a related issue but not this exact one.

[JakePT]

I went to make this change but ran into an issue. in_the_loop() does not return true inside the Query Loop block, so checking in_the_loop() would stop the block from appearing when used inside the query loop block.

Alternatively I though I might be able to check the block for the postId context that's used inside the editor, since I could use that to determine if we were inside the query loop block, but that value does not seem to be available in PHP (it's in the class, but as a protected property).

Frankly I think there's an issue with Core here that might need to be resolved before we can reliably change the behaviour here.

[JakePT]

There's an open issue regarding in_the_loop() in the Gutenberg repo: WordPress/gutenberg#32896 I've added a comment to hopefully revive it.

[felipeelia]

Closing this one as there is nothing we can do.