Make WordPress Core

Opened 6 years ago

Last modified 4 years ago

#44387 new enhancement

Add support for site meta in `register_meta()`

Reported by: flixos90's profile flixos90 Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 5.1
Component: Options, Meta APIs Keywords: 2nd-opinion has-patch needs-unit-tests
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 years ago.

Download all attachments as: .zip

Change History (15)

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


6 years ago

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


6 years ago

#3 @spacedmonkey
6 years 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.


6 years ago

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


6 years ago

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


6 years ago

#7 @flixos90
5 years ago

  • Milestone changed from 5.0 to 5.1

#8 @flixos90
5 years ago

  • Milestone changed from 5.1 to 5.2

@spacedmonkey
5 years ago

#9 @spacedmonkey
5 years 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
5 years 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.

This ticket was mentioned in Slack in #core by david.baumwald. View the logs.


5 years ago

#12 @johnbillion
5 years ago

  • Keywords needs-unit-tests added

Patch looks sane, but this should have test coverage.

This ticket was mentioned in Slack in #core by david.baumwald. View the logs.


5 years ago

#14 @davidbaumwald
4 years ago

  • Milestone changed from 5.3 to Future Release

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.

Note: See TracTickets for help on using tickets.