[wp-trac] [WordPress Trac] #28290: Changing _site_option functions for _network_option functions

[WordPress Trac]

#28290: Changing _site_option functions for _network_option functions
--------------------------------+------------------------
 Reporter:  jmlapam             |       Owner:
     Type:  enhancement         |      Status:  reopened
 Priority:  normal              |   Milestone:  4.4
Component:  Networks and Sites  |     Version:  4.0
 Severity:  normal              |  Resolution:
 Keywords:  needs-patch         |     Focuses:  multisite
--------------------------------+------------------------

Comment (by jeremyfelt):

 Thanks for the thoughts @spacedmonkey. I went down the `*_network_meta()`
 route almost 2 years to the day in #25344. :)

 There's too much different between what happens for site options now and
 what happens in standard meta handling. As you've mentioned, we would
 inherit a new way of dealing with the data, which would be a big change,
 and we would need to continue accounting for the current filters and
 logic. Let's stick with `_network_option()`.

 Parameter order could probably go as such:

 {{{
 get_network_option( $option, $network_id = false, $default = false,
 $use_cache = true )
 add_network_option( $option, $value, $network_id = false )
 update_network_option( $option, $value, $network_id = false )
 delete_network_option( $option, $network_id = false )
 }}}

 `get_site_option()` can use `get_current_site()`, as can
 `get_network_option()` by default. I agree that we should be able to
 deprecate `get_site_option()`, maybe even in 4.5.

 Any unit tests along the way would be excellent. The tests for
 `*_site_option()` should continue passing and from a brief glance, it
 looks like there's plenty we can do to improve those.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/28290#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform