[wp-trac] [WordPress Trac] #57923: Deprecated notice fired by wp_set_object_terms() with PHP 8.1

WordPress Trac noreply at wordpress.org
Wed Mar 15 14:05:24 UTC 2023


#57923: Deprecated notice fired by wp_set_object_terms() with PHP 8.1
-----------------------------------------+---------------------
 Reporter:  Chouby                       |       Owner:  (none)
     Type:  defect (bug)                 |      Status:  new
 Priority:  normal                       |   Milestone:  6.3
Component:  Taxonomy                     |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  php81 2nd-opinion has-patch  |     Focuses:
-----------------------------------------+---------------------
Changes (by SergeyBiryukov):

 * keywords:  php81 needs-patch 2nd-opinion => php81 2nd-opinion has-patch


Comment:

 Given that the "More information" section (at least in this case) is not
 the official DocBlock, but some user-editable notes previously imported
 from Codex which may or may not be up-to-date or fully accurate, I would
 suggest **not** to add `null` as an explicitly supported type, as I don't
 see a strong reason for that, the three existing types should be enough
 for any use case.

 That said, adding the `if ( empty( $terms ) ) { $terms = array(); }` check
 would make the logic more consistent with `wp_set_post_terms()`, while
 also resolving the issue by supporting `null` implicitly.

 So I think I would prefer something like [attachment:"57923.diff"] here:
 * Make `wp_set_object_terms()` and `wp_set_post_terms()` handle `null`
 consistently. Even if it's not technically a supported type, it's a
 reasonable value to account for in this case.
 * Clarify the DocBlock to mention an empty array, rather than an ambiguous
 empty value.

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


More information about the wp-trac mailing list