WordPress.org

Make WordPress Core

Opened 22 months ago

Closed 7 months ago

Last modified 3 months ago

#35773 closed enhancement (duplicate)

_network_meta() functions could use _metadata() API

Reported by: johnjamesjacoby Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Options, Meta APIs Keywords:
Focuses: multisite Cc:

Description

The wp_sitemeta database table matches exactly the format expected by the Metadata API. It could use it out of the box, but a bunch of bespoke surrounding code would need updating:

  • alloptions cache keys would need tests
  • Filter names would need to be carried over or deprecated
  • Network ID fallbacks would need revisiting (sometimes primary ID is guessed)
  • Transients, if we tried integrating them, would need... probably a lot

I'm attaching a basic & obvious first pass at how easy this could be, if it weren't for all the legacy stuff. This is a big-huge task that might not be worth exploring much more, but I figured I'd get some discussion going to start.

Attachments (1)

35773.1.patch (3.3 KB) - added by johnjamesjacoby 22 months ago.
What _network_meta() functions would look like today

Download all attachments as: .zip

Change History (10)

@johnjamesjacoby
22 months ago

What _network_meta() functions would look like today

#1 @sc0ttkclark
22 months ago

+1, especially using the 'site' meta type!

#2 @johnjamesjacoby
22 months ago

The neat thing about codifying this approach, is we can start thinking about "network options" like the metadata that it is instead of by the screens & hard-coded settings with which that data is funneled through.

A few less obvious wins:

  • Ability to register network meta, and use the sanitization & capability checks that come with register_meta()
  • Mirror get_post_custom() and have 1 function get "all meta" similar to the alloptions cache
  • We get metadata API caching for free, which is pretty neat to see in action with network meta

And maybe other caveats:

  • The settings API is not currently used in the Network Admin. Can we use these new functions with a network settings API?
  • So many wrappers. Is this worth added confusion of which to use when and why?
  • This matters more for multi-network than multi-site. Is this better handled in a plugin?
Last edited 22 months ago by johnjamesjacoby (previous) (diff)

#3 @sc0ttkclark
22 months ago

Related to Network Settings API: #15691

Worth also noting that this would work great with the meta support we have in Fields API when it comes to that.

#4 @jeremyfelt
22 months ago

Previously: #25344

I guess one important question is: what do we gain by switching from _network_option() and the filters/etc around that to _network_meta()?

And: would this deprecate _network_option(), _site_option() and their related filters, or would we need to account for those in a back-compat way.

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


17 months ago

#7 @johnjamesjacoby
7 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Closing in favor of recent activity on #25344.

#8 @johnjamesjacoby
7 months ago

  • Keywords 2nd-opinion has-patch removed

#9 @spacedmonkey
3 months ago

Duplicate of #25344.

Note: See TracTickets for help on using tickets.