Properly re-fill the `$meta` param of deprecated `wpmu_new_blog` action

[david.binda]

The updates in r43548 changed the way how $meta value passed to wpmu_new_blog is being populated.

It introduces the $site_data_whitelist array (see https://core.trac.wordpress.org/browser/trunk/src/wp-includes/ms-functions.php?rev=43548#L1288 ) which contains keys of properties which are now being passed to wp_insert_site, where those are being processed, and removes those keys from the $meta array.

The list of keys was previously used for identifying what properties are being saved as site options, but those were still passed to wpmu_new_blog action in terms of $meta param. (see https://core.trac.wordpress.org/browser/trunk/src/wp-includes/ms-functions.php?rev=42976#L1309 )

That said, after the 5.1.0, the $meta in wpmu_new_blog no longer contain any of following properies:

<?php
$site_data_whitelist = array( 'public', 'archived', 'mature', 'spam', 'deleted', 'lang_id' );

Further, in r43654 the WPLANG, previously default meta in wpmu_create_blog was moved elsewhere, and is also not available among $meta in wpmu_new_blog action.

While the wpmu_create_blog is no longer the recommend way of creating new blogs, and wpmu_new_blog action have been deprecated, there still are some integrations out there, which may rely on the previous version of the $meta array.

I'm attaching a patch for properly re-filling the values and a unit test demonstrating the issue. The patch is introducing more values to the $meta, since the current implementation really wants to re-populate the $meta variable in case there are some callbacks hooked to wpmu_new_blog action, so it's easier to pass more data (with default values), than adjusting the wp_insert_site function the way it only passes the same limited set of properties.

[jeremyfelt]

Thanks, @davidbinda - this makes sense at first glance. I'm going to move to the 5.1.1 milestone.

[pbiron]

@davidbinda: I've just been testing your patch. Is your intention to exactly duplicate the behavior of WP <=5.0.3? If so, it does not do that. I don't think it does anything wrong, but is results in $meta containing more info than would be provided in 5.0.3.

For example, when adding a new site via /wp-admin/network/site-new.php, the value of $meta passed to functions hooked to wpmu_new_blog is:

in 5.0.3

<?php
$meta = array(
        'public' => 1,
        'WP_LANG' => get_network_option( $network_id, 'WPLANG' ),
)

in 5.1, without your patch

<?php
$meta = array(
        'WPLANG' => get_network_option( $network_id, 'WPLANG' ),
)

• so, yes, without the patch the value of public is not passed

in 5.1, with your patch

<?php
$meta = array(
        'public' => 1, 
        'archived' => 0,
        'mature' => 0,
        'spam' => 0,
        'deleted' => 0,
        'lang_id' => 0,
        'WPLANG' => get_network_option( $network_id, 'WPLANG' ),
)

• the values of archived, mature, spam, deleted and lang_id where not passed in 5.0.3

So, again, I'm not suggesting that your patch is wrong, just that it results in slightly different behavior (for the default case of creating a site in the WP admin module) than 5.0.3.

[david.binda]

Thanks for testing the patch!

So, again, I'm not suggesting that your patch is wrong, just that it results in slightly different behavior (for the default case of creating a site in the WP admin module) than 5.0.3.

Yup, I wanted to introduce just minimal changes to the existing code, and was accepting the slightly different behaviour as a good enough.

But, I've re-visited the code and the patch in order to achieve the same behaviour, and turns out the necessary changes are not that huge and do no make the code less readable. Please, see the updated patch.

Thanks again!

[pbiron]

@davidbinda: the revised patches looks good!

When adding a site interactively, I get the same array passed to my function hooked to wpmy_new_blog as I do in 5.0.3. When I "manually" call wpmu_create_blog() with additional $meta, that additional $meta also gets passed the same as it does in 5.0.3.

Something is screwy with my local setup and I can't run unit tests right now, so I can't test the unit test in your patch. However, visually inspecting it, in test_wpmu_new_blog_action_backward_compatible(), shouldn't

<?php
remove_action( 'populate_options', array( $this, 'wpmu_new_blog_callback' ), 10 );

be

<?php
remove_action( 'wpmu_new_blog', array( $this, 'wpmu_new_blog_callback' ), 10 );

[david.binda]

Thanks for the code review and the feedback!

You're right, a wrong action name was used in the remove_action call. However, inspecting the WP_UnitTestCase_Base::__restore_hooks showed that there is no need to remove action/filter set in one test, as the method "Restores the hook-related globals to their state at setUp() so that future tests aren't affected by hooks set during this last test."

I've adjusted the patch accordingly (removing the remove_action call altogether).

[pbiron]

@davidbinda thanx for the revised patch. Looks good to me!

[jeremyfelt]

This looks good, thanks @davidbinda and @pbiron!

Clarification for my own future sake:

The $meta that was passed to wpmu_create_blog() prior to 5.1.0 was "promoted" (for lack of a better word) to top level keys in $data when passed to wp_insert_site() in 5.1.0+.

The 5.1.0 back-compat handling for the wpmu_new_blog hook accounted for $meta, but only for data passed to the new options key (yet to be documented, see #45061).

[jeremyfelt]

In 44805:

Multisite: Ensure wpmu_new_blog hook receives expected data in $meta.

Restores public, archived, mature, spam, deleted, lang_id, and WPLANG to the $meta data passed to wpmu_new_blog. This hook was deprecated in 5.1.0, but code using it still relies on this data.

Props david.binda, pbiron.
Fixes #46351.

[jeremyfelt]

In 44806:

Multisite: Fix code formatting errors from r44805

See #46351.

[jeremyfelt]

In 44807:

Multisite: Ensure wpmu_new_blog hook receives expected data in $meta.

Restores public, archived, mature, spam, deleted, lang_id, and WPLANG to the $meta data passed to wpmu_new_blog. This hook was deprecated in 5.1.0, but code using it still relies on this data.

Props davidbinda, pbiron.
Merges [44805] and [44806] to the 5.1 branch.
Fixes #46351.