[wp-trac] [WordPress Trac] #35404: Incorrect @var docs for WP_Network property types

[WordPress Trac]

#35404: Incorrect @var docs for WP_Network property types
--------------------------------+-----------------------------
 Reporter:  jdgrimes            |      Owner:
     Type:  defect (bug)        |     Status:  new
 Priority:  normal              |  Milestone:  Awaiting Review
Component:  Networks and Sites  |    Version:  4.4
 Severity:  normal              |   Keywords:
  Focuses:  docs, multisite     |
--------------------------------+-----------------------------
 Several of the properties in the `WP_Network` class are documented as
 `@var int` when they are actually strings.

 The `$cookie_domain` is obviously not an integer, since even its default
 value is a string:
 {{{#!php
 public $cookie_domain = '';
 }}}

 The `$id` and `$blog_id` properties are also documented as `int` although
 both of them are usually populated directly from the database values, and
 therefore will usually be integers represented as strings. To further
 complicate things, the `$blog_id` property is declared with a default
 value that is an integer:

 {{{#!php
 public $blog_id = 0;
 }}}


 Related to this is #33929.

 The quandary is whether we should change the docs from `int` to `string`
 to maintain back-compat, or whether we should cast the values to integers
 to meet the docs and dev expectations (I discovered this because I was
 doing a strict comparison while expecting the network `id` to be an
 integer).

 The `WP_Network` class was just introduced in 4.4.0, so at first glance it
 might seem like we don't need to worry about backward compatibility for
 code that is built expecting these values to be strings despite their
 docs. However, the `$current_site` global has been around for quite some
 time, so we should be careful to maintain back-compat with the types devs
 are expecting for its properties. I'm assuming that prior to [34097] the
 values of `$current_site->id` and `$current_site->blog_id` were both
 strings. Of course, it is possible that people have been overriding the
 `$current_site` global with their own implementations, which might be
 offering these values as integers instead.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/35404>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform