[wp-trac] [WordPress Trac] #29247: Crucial caches are not cleared when deleting site
WordPress Trac
noreply at wordpress.org
Tue Dec 29 18:27:07 UTC 2015
#29247: Crucial caches are not cleared when deleting site
-------------------------------------+-----------------------------
Reporter: rmccue | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Future Release
Component: Cache API | Version:
Severity: normal | Resolution:
Keywords: needs-patch 2nd-opinion | Focuses: multisite
-------------------------------------+-----------------------------
Changes (by johnjamesjacoby):
* keywords: needs-patch => needs-patch 2nd-opinion
Comment:
The `is_blog_installed()` function is a very random shot in the dark at
deciding if a site needs to be repaired, and I wouldn't trust it to be the
reason you couldn't switch between sites.
What if someone wanted to `switch_to_blog()` to run the repair tool on
that site? I don't see very much wrong with someone switching to a site
that's missing some data; I see more wrong with a core API blocking
behavior with only a vague idea of why.
----
Addressing the OP, how deep should cache invalidation go? Posts &
taxonomies? Users that were previously members of that site? Maybe these
are passively cleared when their data objects & meta are deleted, but they
aren't explicitly so.
The way I see it, this function only exists as a wrapper for the various
bespoke site & network cache groups that have been half haphazardly
introduced through the course of multisite's half-life. This function
reads more as a yard of graves that require exhuming than it does a
reliable ledger of what's buried beneath it.
Maybe there is some overlap with the `WP_Site` object (being proposed for
4.5) that can help guide us into cleaning up the cache groups mayhem.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/29247#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list