WordPress.org

Make WordPress Core

Opened 13 months ago

Last modified 4 months ago

#44387 new enhancement

Add support for site meta in `register_meta()`

Reported by: flixos90 Owned by:
Milestone: 5.3 Priority: normal
Severity: normal Version: 5.1
Component: Options, Meta APIs Keywords: 2nd-opinion has-patch
Focuses: multisite Cc:

Description

#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.

Attachments (1)

44387.diff (545 bytes) - added by spacedmonkey 5 months ago.

Download all attachments as: .zip

Change History (11)

This ticket was mentioned in Slack in #core-restapi by flixos90. View the logs.


13 months ago

This ticket was mentioned in Slack in #core-multisite by spacedmonkey. View the logs.


13 months ago

#3 @spacedmonkey
13 months ago

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.

This ticket was mentioned in Slack in #core-multisite by spacedmonkey. View the logs.


13 months ago

This ticket was mentioned in Slack in #core-restapi by spacedmonkey. View the logs.


12 months ago

This ticket was mentioned in Slack in #core-restapi by kadamwhite. View the logs.


11 months ago

#7 @flixos90
10 months ago

  • Milestone changed from 5.0 to 5.1

#8 @flixos90
6 months ago

  • Milestone changed from 5.1 to 5.2

@spacedmonkey
5 months ago

#9 @spacedmonkey
5 months ago

  • Keywords has-patch added
  • Version set to 5.1

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.

#10 @desrosj
4 months ago

  • Milestone changed from 5.2 to 5.3

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.

Note: See TracTickets for help on using tickets.