[wp-trac] [WordPress Trac] #40364: Improve site creation in multisite
WordPress Trac
noreply at wordpress.org
Tue Oct 3 20:41:01 UTC 2017
#40364: Improve site creation in multisite
-------------------------------------------------+-------------------------
Reporter: jeremyfelt | Owner: flixos90
Type: enhancement | Status: assigned
Priority: normal | Milestone: Future
Component: Networks and Sites | Release
Severity: normal | Version:
Keywords: ms-roadmap has-patch has-unit-tests | Resolution:
early | Focuses: multisite
-------------------------------------------------+-------------------------
Comment (by flixos90):
[attachment:40364.6.diff] applies cleanly against the latest changes in
trunk and makes the following adjustments:
* Use `wp_update_site()` internally in `update_blog_status()`.
* Use the existing `update_blog_public` action hook in
`wp_maybe_transition_site_statuses_on_update()`.
* Update version numbers to use `5.0.0`.
Something we need to carefully examine is how the hooks when changing one
of the site status fields are fired. In trunk, the hooks fire only if the
value has changed when calling `update_blog_details()`, but they fire
''always'' when calling `update_blog_status()`, which I think doesn't make
sense. Furthermore the `update_blog_public` hook ''only'' fires in
`update_blog_status()` at all.
I think we should make this more consistent, which the above patch is a
first take at. The hooks are now fired as part of
`wp_maybe_transition_site_statuses_on_update()`, and they are only fired
if their value has changed. While this may theoretically be a breaking
change for very unusual setups (I don't know who would wanna do something
when a status field is updated, but not actually changed), I think we
should be good here - but it's something to discuss further of course.
Note that for example I needed to adjust a few tests for these, since
those would expect the hooks to run in `update_blog_status()` even when
the value wasn't changed.
Note that in the current patch there are two tests that fail to pass,
however I haven't been able to figure out the reason yet.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/40364#comment:29>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list