[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