Uncaught TypeError: setcookie() expects parameter 5 to be string, bool given in...

[kmvan]

​https://github.com/WordPress/WordPress/blob/5e62e6b2034516c0bb366f808673752030d2d2b7/wp-includes/default-constants.php#L303

<?php
        /**
         * @since 2.0.0
         */
        if ( ! defined( 'COOKIE_DOMAIN' ) ) {
                define( 'COOKIE_DOMAIN', false ); // The value maybe '', not boolean
        }

[desrosj]

Hi @kmvan,

Your ticket is not very detailed. It's impossible to look into this further without more information.

Are you running a single site install or a multisite install? Where is the call to setcookie()? Is it in WordPress Core? A plugin? A theme? Please provide more details so that others can reproduce your issue.

[kmvan]

Hello @desrosj,

The function setcookie() args: ​http://php.net/setcookie

setcookie ( string $name [, string $value = "" [, int $expires = 0 [, string $path = "" [, string $domain = "" [, bool $secure = FALSE [, bool $httponly = FALSE ]]]]]] ) : bool

The 5th parameter type is string, but the default constant COOKIE_DOMAIN type is boolean.

<?php

// So when I code below in my theme/plugin:
declare(strict_types = 1);

\setcookie(
    'name',
    'value',
    \time() + \YEAR_IN_SECONDS,
    \COOKIEPATH,
    \COOKIE_DOMAIN // This is not string
//    \is_bool(\COOKIE_DOMAIN) ? \COOKIE_DOMAIN : '' // I need to code on this way XD
);

So I think the default value shall be define( 'COOKIE_DOMAIN', '' );.

Setting the default value of COOKIE_DOMAIN to a null value

Trac ticket: https://core.trac.wordpress.org/ticket/46550

[rajinsharwar]

#58959 was marked as a duplicate.

[rajinsharwar]

Yes, it was causing a Fatal error when the default value of the COOKIE_DOAMIN was used in any external PHP script. So, set the default value of the constant to null instead of false.

cc @cybr @johnbillion

[Cybr]

It causes no warnings nor errors in PHP unless strict typing is declared: ​https://3v4l.org/dEQk2.

However, to reclarify: setcookie() expects a string for $domain. false does nothing for it.

Nothing in WP checks against false, nor would a cookie have a boolean. This change should be fairly inconspicuous and ensures future compatibility, seeing how PHP is strictly typing internal functions.

It caught my eye, and I thought I'd mention it in Slack for an easy fix.

[jrf]

It causes no warnings nor errors in PHP unless strict typing is declared: ​https://3v4l.org/dEQk2.

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.

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

[nicolefurlan]

@kmvan could you add testing instructions to this ticket? Thank you! :)

[kmvan]

@nicolefurlan Sorry, this ticket is from five years ago. I no longer write programs and I don't have a computer. I'm sorry that I can't add unit tests. T_T

[nicolefurlan]

No worries @kmvan! I apologize I didn't notice that this was so long ago!

Can someone else please add testing instructions for this ticket so we can keep it moving along? Thank you!

[oglekler]

For testers:

<?php

 declare( strict_types = 1 ); // Add this to the beginning of the file

 setcookie(
    'name',
    'value',
    time() + YEAR_IN_SECONDS,
    COOKIEPATH,
    COOKIE_DOMAIN
  );

I tried and got the fatal error as described. The patch is solving the problem.

[hellofromTonya]

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?

​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?

[jrf]

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.

Well, my gut feeling says that issues resulting from the BC-break would be very rare and most likely would point to code which needs love anyway.

The typical usages of this constant will likely be:

• Check if it is defined() and define() if not (= no value check).
• Passing it to something like set_cookie() (= no value check).
• Checking whether a cookie is valid for a given domain. This would involve a value check but most likely one where a cookie domain is compared against the constant. A cookie domain of false or '' will both result in a cookie being invalid when compared to an actual cookie domain, so this would not result in a behavioural change.

Having said that, I agree a late beta stage is probably not the best time to validate a gut feeling ;-)

It would be nice if the patch could get updated based on the previously given feedback so it is ready to be committed for 6.5 early.

[hellofromTonya]

Thank you @jrf. Moving this ticket to 6.5 early, which gives it a longer soak time to validate if there are any BC concerns.