Remove deprecation notice from get_the_excerpt

[jamesglendenning]

The deprecation notice for is_bool inside get_the_excerpt has long been redundant, it's been well over a decade since this function took a bool value of $fakeit & the deprecation notice is now just making noise, as it will still pass this value through to get_post regardless of it it's a bool value or not.

The line for this notice is: ​https://github.com/WordPress/wordpress-develop/blob/5.9/src/wp-includes/post-template.php#L408

There was previously a Trac ticket that looked at removing the notice, but it looks like it never made it into core: #27246.

[jrf]

Thanks for opening this ticket and your suggestion.

the deprecation notice is now just making noise

The deprecation notice only makes "noise" when a boolean is passed to the function, which indicates a dev-error. I'd say keep the deprecation notice and fix the dev error instead.

[jamesglendenning]

Replying to jrf:

Thanks for opening this ticket and your suggestion.

the deprecation notice is now just making noise

The deprecation notice only makes "noise" when a boolean is passed to the function, which indicates a dev-error. I'd say keep the deprecation notice and fix the dev error instead.

On further investigation as to why this was being triggered, it looks like we may have passed true/false to the function via a data sync. Interestingly though, the following will still return the post excerpt of the post you're on.

<?php
get_the_excerpt(false)
get_the_excerpt(true)

On one hand it's telling you off & with the other it's handing you the output. This assumption based logic may have led the developer to believe the function was working as intended, if they had muted deprecation warnings on their local machine.

Could the check be improved by checking for all types & returning empty if an unexpected input is parsed?

<?php
if ( null !== $post && is_bool( $post ) && ! ($post instanceof WP_Post) ) {
   _deprecated_argument( __FUNCTION__, '2.3.0' );
   return '';
}

[jrf]

@jamesglendenning While I understand where you are coming from, changing the behaviour of the function would be a backward-compatibility break, so no, that would not be considered as a viable patch.