[wp-trac] [WordPress Trac] #41333: Implement `wp_initialize_site()` and `wp_uninitialize_site()`
WordPress Trac
noreply at wordpress.org
Tue Sep 4 17:11:48 UTC 2018
#41333: Implement `wp_initialize_site()` and `wp_uninitialize_site()`
-------------------------------------------------+-------------------------
Reporter: flixos90 | Owner: flixos90
Type: enhancement | Status: assigned
Priority: normal | Milestone: 5.0
Component: Networks and Sites | Version:
Severity: normal | Resolution:
Keywords: ms-roadmap has-patch needs-unit- | Focuses: multisite
tests needs-testing dev-feedback |
-------------------------------------------------+-------------------------
Comment (by jeremyfelt):
This is looking really good, @flixos90 - thank you!
> I'd like to discuss whether we should introduce pre-filters for
inserting, updating and deleting sites. Those would allow both short-
circuiting, but also allow to perform actions before anything is changed.
Furthermore, I deprecated delete_blog referring to wp_delete_site as
replacement, however a pre_wp_delete_site filter would be a more accurate
one.
I changed my mind a bit on pre-filters during today's Slack conversation.
I think as long as we can define the ways that people can be flexible with
the site creation process, then we're good. It does sound like a short-
circuit filter for site deletion is a good idea. Site insertion can
already be overridden.
> Another thing I'm asking myself is whether the wp_insert_site hook or
wp_initialize_site hook should be run first.
We just chatted through this in Slack and it seems that we're all on the
same page with `wp_insert_site` being fired first.
And one additional note from a review of the patch:
* It seems like the addition of the `$options` parameter to
`populate_options()` might deserve a ticket of its own.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/41333#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list