[wp-trac] [WordPress Trac] #62035: SITE_ID_CURRENT_SITE broken in 6.3 or later

[WordPress Trac]

#62035: SITE_ID_CURRENT_SITE broken in 6.3 or later
--------------------------------+-----------------------------
 Reporter:  scottculverhouse    |       Owner:  SergeyBiryukov
     Type:  defect (bug)        |      Status:  accepted
 Priority:  normal              |   Milestone:  6.7
Component:  Networks and Sites  |     Version:  6.3
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:  multisite
--------------------------------+-----------------------------
Changes (by SergeyBiryukov):

 * keywords:  reporter-feedback => has-patch
 * owner:  (none) => SergeyBiryukov
 * status:  new => accepted
 * milestone:  Awaiting Review => 6.7


Comment:

 Replying to [comment:5 SergeyBiryukov]:
 > I saw the ticket, but I can't figure out how to reproduce this yet.
 `$this->id` should only ever be an `int`

 Hmm, I was able to reproduce it with [attachment:"class-wp-
 network.php.diff"].

 When a new `WP_Network` instance is created, it sets the initial
 properties as retrieved from the database:
 {{{
 WP_Network::get_instance() {
     ...
     $_network = $wpdb->get_row( $wpdb->prepare( "SELECT * FROM
 {$wpdb->site} WHERE id = %d LIMIT 1", $network_id ) );
     ...
     return new WP_Network( $_network );
 }

 WP_Network::__construct( $network ) {
     ...
     foreach ( get_object_vars( $network ) as $key => $value ) {
         $this->$key = $value;
     }
     ...
 }
 }}}

 This is where `$this->id` is set to a string, so it appears that [37870] /
 #37050 didn't quite work as expected: despite being documented as an
 `int`, `$this->id` is still a string in practice.

 [attachment:"62035.diff"] fixes the issue in my testing, but this could
 use some unit tests.

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