Updating taxonomy with many posts results in timeout

[SuzukiEdo]

Description:

When a taxonomy with 100 more posts is updated, it can timeout the PHP's max execution time.

To Reproduce:
Steps to reproduce the behavior:

1. Create a text category
2. Add posts to it using something like wp dummy content. 100+ preferably.
3. Update something in the category. Better if it's a term meta value.
4. See error

Expected behavior
When a term is updated, all posts with that term are as well. For us is around 130, but on bigger sites that handle dozens of thousands of posts in different categories, this can/will time out. The plugin can handle this in a more gracefully way.

Desktop (please complete the following information):

• OS: MacOS
• Browser: Chrome
• Version: 129

Additional context
Our production servers are set to timeout at 30s. Increasing it might fix the problem in the short term, but is not a real solution to the issue.

[tw2113]

I feel like someone else opened a similar issue recently, but I cannot find where.

The change in question came with version 2.6.0

Added: Support for updating posts when an associated term has been updated.

https://github.com/WebDevStudios/wp-search-with-algolia/blame/main/includes/watchers/class-algolia-term-changes-watcher.php#L73-L105

Closest idea I can think of to help, without reverting the entire feature, would be a filter that can be used to return early, or perhaps have the arguments for the code spot filterable so that it's not fetching all the posts.

[tw2113]

One potential solution based on my previous comments

2.8.3...feature/430-term-post-early-return

[tw2113]

Extra approach notes:

Instead of automatically fetching all posts, cap the posts_per_page fetched at a filterable amount. Perhaps 50 or less.

If the total posts for the term exceed that set cap, add an admin notice about performing a bulk-reindex to get all items updated with the changed taxonomy term updates.

[SuzukiEdo]

@tw2113 I really like that approach 👍

[tw2113]

Not PR'd towards a release branch yet, but #519