Add support for site meta in `register_meta()`

[flixos90]

#38323 adds subtype handling to register_meta(). These efforts include introducing a function get_object_subtype() which returns the object subtype of a given type and ID combination. For the initial merge, this only includes the single site types "post", "term", "comment" and "user". Since [42836], sites in a multisite also support metadata, so they should receive subtype support as well.

Since sites do not actually use subtypes at this point, we basically only need to add a clause which checks whether a site with the given ID exists, and if so, return the type identifier.

The tricky part into which we need to put some thought is the naming: Sites have been historically called "blogs", and WordPress core aims to get rid of the legacy naming in its APIs (and only the database schema remains untouched). For example, there are wrapper functions like get_site_meta(), but they actually call the low-level meta functions like get_metadata( 'blog', ... ) because those are tightly coupled to the DB schema. Since registering site meta would be new, we should consider actually naming the type "site" here, and then only internally handling the "blog" part of it. However, this may introduce unexpected inconsistencies with other areas, so we need to investigate whether this is a wise choice or not.

I'd generally argue the simplest solution would be to introduce register_site_meta() and unregister_site_meta() and otherwise keep the "blog" name (which would be consistent with the way existing site meta wrappers work) - however we decided wrappers should only be introduced for object types that use subtypes, so here with sites, developers would actually need to call register_meta( 'blog', ... ) themselves which would be sub-optimal. Let's discuss.

[spacedmonkey]

So I have looked into this and it is not possible to use the key of site over blog. The reason for this are two fold.

A patch like this could be implemented

                case 'blog':
                case 'site':
                        $site = get_site( $object_id );
                        if ( ! $site ) {
                                break;
                        }

                        $object_subtype = 'site';
                        break;
                case 'site':
                case 'network':
                        $network = get_network( $object_id );
                        if ( ! $network ) {
                                break;
                        }

                        $object_subtype = 'network';
                        break;

This function is get_object_subtype is not a developer focused. It is designed for internal use so passing blog to it is logical, as the naming within core is blog. Core uses the naming blog and all referencecs in the *_site_meta functions. It is impossible to have one meta type for developers and another for core. Also, as you can see, the key of site is already used for networks.

[spacedmonkey]

In 44387.diff I have put up a basic patch for support. I have used blog, as this how core treats site meta. It is important to support site, as that is what network meta is supported under.

[desrosj]

5.2 beta 1 is in less than 2 days. Going to punt this. If a committer has the availability to properly review and commit prior to beta, feel free to move it back.

[johnbillion]

Patch looks sane, but this should have test coverage.

[davidbaumwald]

This ticket still needs unti tests, and with Beta 1 of version 5.3 only a few days away, this is being moved to Future Release. If this ticket can be resolved in time for 5.3, feel free to re-milestone.

Trac ticket: #44387

[spacedmonkey]

I'm adding this ticket to the 7.2 milestone as site meta support is a key prerequisite for landing native site REST API endpoints (/wp/v2/sites).

Without register_meta( 'site', ... ) and proper show_in_rest handling, we can't cleanly expose or manipulate site-level metadata.

Unblocking this is critical to support Core Data Views, AI/MCP server integration, and site provisioning workflows. Full details on the broader architectural context and requirements are outlined in ticket #40365.

[spacedmonkey]

@realloc @sainathpoojary

The current patch is missing register site meta function.

/**
 * Registers a meta key for sites.
 *
 * @since 7.2.0
 *
 * @param string $meta_key The meta key to register.
 * @param array  $args     Data used to describe the meta key when registered. See
 *                         {@see register_meta()} for a list of supported arguments.
 * @return bool True if the meta key was successfully registered, false if not.
 */
function register_site_meta( $meta_key, array $args ) {
        return register_meta( 'blog', $meta_key, $args );
}

/**
 * Unregisters a meta key for sites.
 *
 * @since 7.2.0
 *
 * @param string $meta_key The meta key to unregister.
 * @return bool True on success, false if the meta key was not previously registered.
 */
function unregister_site_meta( $meta_key ) {
        return unregister_meta_key( 'blog', $meta_key );
}

Would it be possible to add this to the current patch?

[sainathpoojary]

Thanks, @spacedmonkey! I've updated the PR to include the register_site_meta() and unregister_site_meta() wrappers as requested, along with the supporting unit tests.

[spacedmonkey]

This ticket looks good to me. I have marked it as commit and assigned it to myself to commit.

[spacedmonkey]

In 63603:

Meta: Support site meta subtype in get_object_subtype().

Add a 'blog' case to get_object_subtype() so register_meta() can resolve
subtypes for site meta, matching the support already in place for posts,
terms, comments, and users.

Introduce register_site_meta() and unregister_site_meta() wrapper
functions for registering and unregistering meta for sites, consistent
with the existing site meta wrapper functions.

Props sainathpoojary, spacedmonkey, flixos90, johnbillion.
Fixes #44387.

Commited in https://core.trac.wordpress.org/changeset/63603