Fix wp site empty O(n) scaling: replace per-item cache ops with wp_cache_flush()

[Copilot]

wp site empty scaled linearly with object count due to per-item cache deletions before each table truncation. empty_comments() also issued an unbounded SELECT comment_ID query, risking memory exhaustion on large sites.

Changes

• empty_comments() — removed unbounded get_col() fetch and per-item wp_cache_delete() loop; now truncates directly
• empty_posts() — removed QueryIterator loop over all post IDs for cache eviction; now truncates directly
• empty_taxonomies() — uses get_taxonomies() (registered taxonomies, no DB read) instead of scanning the term_taxonomy table; consolidates all delete_option("{$taxonomy}_children") calls into a single DELETE FROM {$wpdb->options} WHERE option_name IN (...) query
• empty_links() — removed QueryIterator loop with wp_delete_object_term_relationships() / clean_object_term_cache() per link; now truncates directly
• empty_() — calls wp_cache_flush() once after all truncations, replacing all the per-item evictions with a single O(1) cache flush
• Removed now-unused QueryIterator import
• Updated docblock: cache is flushed automatically; notes Multisite caveat (flush affects all sites)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>wp site empty doesn't scale</issue_title>
<issue_description>## Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

The time that the wp site empty command takes to run increases approximately linearly to the number of posts, comments, terms, and taxonomies on the site, because of all the querying and cache clearance that happens. This means it scales very poorly.

In addition, the query to fetch comments for deletion is unbounded, which means memory exhaustion could be experience on a site with a very large number of comments.

Describe how other contributors can replicate this bug

1. Find yourself a site that contains a large number of posts, for example 100,000 or more.
2. Run time wp site empty --yes and then go and put the kettle on.

Describe what you would expect as the correct outcome

The time that wp site empty takes to run shouldn't be dictated by the number of objects in the database.

Provide a possible solution

Ideally the cache clearance would happen on a per-group basis to avoid the need to delete every cache entry for every object, but I understand that this is typically not possible.

It may be possible to simply call wp_cache_flush() after truncating all the tables to flush the entire cache, although this will have side effects on a Multisite installation.
</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes wp site empty doesn't scale #263

---

💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.

[Copilot]

Pull request overview

Optimizes wp site empty to avoid O(n) behavior on large sites by removing per-object cache operations and unbounded ID fetches, relying instead on direct table truncation and a single cache flush.

Changes:

• Remove per-comment and per-post ID iteration/cache deletions; truncate content tables directly.
• Simplify link deletion to a direct links table truncation.
• Add a single wp_cache_flush() at the end and update the command docblock accordingly.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.