[wp-trac] [WordPress Trac] #46550: Uncaught TypeError: setcookie() expects parameter 5 to be string, bool given in...

[WordPress Trac]

#46550: Uncaught TypeError: setcookie() expects parameter 5 to be string, bool
given in...
-------------------------------------------------+-------------------------
 Reporter:  kmvan                                |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  6.4
Component:  Networks and Sites                   |     Version:  5.2
 Severity:  minor                                |  Resolution:
 Keywords:  has-patch has-testing-info changes-  |     Focuses:  coding-
  requested                                      |  standards
-------------------------------------------------+-------------------------
Changes (by hellofromTonya):

 * keywords:  has-patch needs-testing has-testing-info => has-patch has-
     testing-info changes-requested
 * focuses:  coding-standards, php-compatibility => coding-standards


Comment:

 >Agreed and using strict_types = 1 in the context of WP is generally not
 the greatest idea as WP is as loosy as possible, so this would easily
 cause a mountain of errors.

 I agree with @jrf.

 Updating the keywords:
 * Removing `needs-testing` as there is a testing report.
 * Adding `changes-requested` as there are documentation requested changes.

 I wonder:
 * Why was `false` the default value?
 I didn't find the why, but it was introduced in [2725] back 18 years ago
 in WP 2.0.

 * Are there any BC concerns of changing a Core constant's value?
 [https://wpdirectory.net/search/01HCB8AAC8XK625WPK1HXHJFMC A search of
 plugin usages] did not reveal instances of specifically checking for a
 `false` value.

 >Having said that, the proposed fix looks like a good improvement, though
 for reasons of synchronicity with PHP core, not for compatibility reasons.

 I agree with @jrf that this is not `php-compatibility` issue as the issue
 only happens when strict_types is turned on, which is not recommended.
 Having the fix could fall into "synchronicity with PHP core" as @jrf
 suggests.

 That said, I do wonder if there are any BC concerns. Discovering instances
 in the wild that do check for `false` might be better served during the
 alpha phase, rather in the latest stage of beta cycle. Thoughts?

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