$wp_query->max_num_pages return value as float

[ironghost63]

As a page number, Integer would make more sense than Float.

This is not a big problem but kinda annoying when you do strict comparison on this value. since no one will define a page number as float.

[birgire]

@ironghost63 Welcome to WordPress Trac and thank you for the report.

But there is more!

The example:

$q = new WP_Query( ['posts_per_page' => 2 ] ); var_dump( $q->post_count ); var_dump( $q->found_posts ); var_dump( $q->max_num_pages ); 

displays:

int(2) string(1) "2" double(1) 

So these counting properties of WP_Query have three different types!

Within the WP_Query class, the inline docs says it's an integer:

/** * The amount of pages. * * @since 2.1.0 * @var int */ public $max_num_pages = 0; 

The calculated value comes from:

$this->max_num_pages = ceil( $this->found_posts / $q['posts_per_page'] ); 

but from the ​PHP docs:

The return value of ceil() is still of type float as the value range of float is usually bigger than that of integer.

The inline docs for found_posts also says:

/** * The amount of found posts for the current query. * * If limit clause was not used, equals $post_count. * * @since 2.1.0 * @var int */ public $found_posts = 0; 

but the data query

$this->found_posts = $wpdb->get_var(...); 

returns a string.

So it looks like either we need to adjust the inline docs or adjust the return types.

[SergeyBiryukov]

#55137 was marked as a duplicate.

[johnbillion]

I noticed this while working on #47280. All the tests use assertEquals instead of assertSame for this reason. The property is indeed documented as an int but is a float.

[SergeyBiryukov]

Also noticed this in comment:19:ticket:38266.

Replying to birgire:

So it looks like either we need to adjust the inline docs or adjust the return types.

I think it makes sense to do the latter here, to adjust the return types to match the documented types.

[audrasjb]

The same goes for other related queries:

• WP_Network_Query
• WP_Comment_Query
• WP_Site_Query
• …