[wp-trac] [WordPress Trac] #27199: When site_name is missing from sitemeta table, it cannot be updated by Network > Settings screen

[WordPress Trac]

#27199: When site_name is missing from sitemeta table, it cannot be updated by
Network > Settings screen
--------------------------------+------------------------
 Reporter:  JPry                |       Owner:
     Type:  defect (bug)        |      Status:  new
 Priority:  normal              |   Milestone:  3.9
Component:  Options, Meta APIs  |     Version:  trunk
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:  multisite
--------------------------------+------------------------
Changes (by jeremyfelt):

 * milestone:  Awaiting Review => 3.9


Comment:

 Hey @jPry, thanks for the report and the patch!

 I've run into this before once because I deleted that meta key, definitely
 weird behavior.

 I think the approach of [attachment:27199.patch] makes sense. It should be
 extremely rare that this fallback will ever be needed and if we are not
 able to find a value in the initial boot process, then caching an assumed
 one only covers the issue.

 That said, this could affect other uses of `get_site_option( 'site-name'
 )` as `false` will be returned until the meta key is restored. There are
 only a couple places in core that use this.

 I wonder if we can replace all uses of `get_site_option( 'site_name' )`
 with `get_current_site_name()` instead, as that would use the fallback
 properly.

 Related #16676, which reduced the setting of site name cache by a bit in
 [18604].

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