nystudio107/craft-cookies

A simple plugin for setting and getting cookies from within Craft CMS templates.

craft-cookies's Issues

getCookie works with this plugin but not cannot get a cookie with native craft code - what is the difference?

Hey Andrew.
This is more of a question and trying to get an understanding. So I have a cookie that set with Javascript https://github.com/js-cookie/js-cookie when a button is clicked. When I started out I tried to use native Craft cookies to get the cookie value as per your article here https://nystudio107.com/blog/cutting-the-cord-removing-plugins#plugin-2-cookies. However, it seems that the cookie is not returned using the native get method. So after someone recommended on Discord they used your plugin to get the JS cookie I tried it and it works! Great 🎉

However, I wondered what the plugin is doing differently to the native approach that allows the get method to work?
For clarity I have added some code below.

<button
        @click="showNotice = false; Cookies.set('{{ cookie.name }}', '{{ cookie.content }}', { expires: {{ cookie.expires }} })"
        class="js-bannerNotice hover:bg-white hover:text-red-600 focus:outline-none"
      >
        {{ svg('@icon/bx-line/bx-x.svg')|attr({ class:" w-10 h-10 flex-shrink-0 fill-current
      " }) }}
        <span class="sr-only">Close</span>
</button>

Using the plugin I can check the cookie exists like this:

{% if not getCookie(cookie.name) %}
Banner notice here
{% endif %}

However, using the native approach this does not return anything:

{% set requestCookies = craft.app.request.cookies %}
{% set cookieName = requestCookies.get(cookie.name) %}
{{ dump(cookieName) }}

No plugin exists with handle "cookies"

We've been using this plugin for about a week and everything has been fine. An hour ago we are now unable to install the plugin via command line or through the craft plugin store.

Problem:
Unable to install the plugin

Error message from the command line:
Nothing to install or update

Error message from Craft's plugin store:
Response: {"error":"No plugin exists with the handle \"cookies\"."}

Request:
Would like to be able to install the plugin again

Other Notes
We installed the plugin March 1, 2019. This was after the date that you updated the package name in this issue ticket

Cookies are always forced to 'secure'

Looks like when some changes were made 2 months ago to handle php7's setcookie parameter changes, secure was set to true and can't be changed.

https://github.com/nystudio107/craft-cookies/blob/v1/src/services/CookiesService.php#L62

Can this be fixed to be configurable?

Permission Sets

It would be great if we could add 'permission sets' on the fly, which may aid with GDPR legislation with the opt-in and privacy by design aspects of it.

For example, if the user has said that tracking cookies are okay, it would be great if we could go.

{% if craft.cookies.permission('tracking') %}
   {!-- Facebook pixel code here --}
{% endif %}

Settings page blank

Describe the bug

The settings panel of the plugin is blank.

(This is more of an aside, but might be related) This is after I attempted to install the plugin via the Craft Store onto a site running on Craft Nitro 2 under WSL2. When I did so, it claimed the plugin was installed, but a problem happened that prevented it from being enabled. Craft then asked me if I wanted to uninstall it or continue as-is. I then successfully installed and enabled the plugin via the command line ($ nitro composer require nystudio107/craft-cookies and then $ nitro craft plugin/install cookies).

To reproduce

Steps to reproduce the behaviour:

1. Go to the control panel
2. Click on Settings
3. Click on the Cookies plugin down below to jump right to the plugin's settings panel
4. Settings panel is blank.

Expected behaviour

I expected the settings panel would have a raison d'être, but alas...

Screenshots

Versions

• Plugin version: 1.1.14
• Craft version: 3.6.11.2

question about the readme examples' logic

The README provides examples like

{% do getCookie('marvin') %}
{# Get the cookie using 'getCookie' function #}

{% do craft.cookies.get('marvin') %}
{# Get the cookie using 'get' variable #}

{% if getCookie('marvin') %}
    {% set myCookie = getCookie('marvin') %}
    {{ myCookie }}
{% endif %}

Since (in my tests — I haven't dug into the plugin source) getCookie() and craft.cookies.get() return null if the requested cookie doesn't exist, it seems like that could be simplified to

{# these two do the same thing #}

{% set myCookie = getCookie('marvin') %}
{{ myCookie }}

{% set myCookie = craft.cookies.get('marvin') %}
{{ myCookie }}

I'd be happy to submit a readme PR, but wanted to first understand whether I'm missing some plugin-specific need to shield the set with the if and do?

It seems that the craft-cookies plugin isn't able to set a cookie in Craft CMS v.3.5.17.1

Describe the bug

I've recently upgraded Craft CMS 2 to the latest Craft CMS version and the craft-cookies plugin won't set a cookie.
I used your plugin in v.2 and it worked great.

In template I've tried all 3 non-secure methods to set a cookie and for the note, cookies are enabled in my browser.

To reproduce

Steps to reproduce the behaviour:

1. Followed the upgrade instructions
2. Installed the plugin from the Plugin store
3. Noticed the problem

Versions

• Plugin version: 1.1.12
• Craft version: 3.5.17.1

Update

Firefox browser logs this warning massage

Cookie “name” has been rejected because a non-HTTPS cookie can’t be set as “secure”.

which tells that setting a cookie in non-secure method like e.g.

{% do craft.cookies.set('name', 'value') %}

sets the cookie as secure.

Setting a cookie using a secure method like e.g.

{% do craft.cookies.setSecure('name', 'value') %}

works.

Something is not right because in the same environment (same PHP server config, same web server config, same browser config) worked all well under Craft CMS 2.

Set cookie on form submit

Question

Is there a way to set a cookie on form submit, either through native submit or ajax?

Field Uids - changed

Question

I locally added this plugin and after installation, it changed the fieldUids to many volumes and other types.
I was wondering if there would be consequences for pushing this to my production environment.
Everything seems to work fine, just wondering and trying to prevent making a mess.

$sameSite must be of type boolean

Hi,

I've ran into an issue using the v4 version of this plugin (for craft 4).

Here:

craft-cookies/src/twigextensions/CookiesTwigExtension.php

Lines 65 to 74 in bc5aea1

	public function setCookie(
	string $name = "",
	string $value = "",
	int $expire = 0,
	string $path = "/",
	string $domain = "",
	bool $secure = false,
	bool $httpOnly = false,
	bool $sameSite = false
	): void

The $sameSite param is required to be a boolean.

But here:

craft-cookies/src/twigextensions/CookiesTwigExtension.php

Line 55 in bc5aea1

new TwigFunction('setCookie', fn(string $name = "", string $value = "", int $expire = 0, string $path = "/", string $domain = "", bool $secure = false, bool $httpOnly = false, ?string $sameSite = null) => $this->setCookie($name, $value, $expire, $path, $domain, $secure, $httpOnly, $sameSite)),

and here:

craft-cookies/src/twigextensions/CookiesTwigExtension.php

Line 42 in bc5aea1

new TwigFilter('setCookie', fn(string $name = "", string $value = "", int $expire = 0, string $path = "/", string $domain = "", bool $secure = false, bool $httpOnly = false, ?string $sameSite = null) => $this->setCookie($name, $value, $expire, $path, $domain, $secure, $httpOnly, $sameSite)),

$sameSite has a default value of null which gives the following error when setting a cookie without explicitly passing the $sameSite param:

CookiesTwigExtension::setCookie(): Argument #8 ($sameSite) must be of type bool, null given

Default to Craft's defaultCookieDomain setting for domain

If defaultCookieDomain is set in Craft's config settings, can (or should) that be the default craft-cookies uses, if DOMAIN is left blank?

Update from 1.1.7 to 1.1.8 breaks.

Hi!

First of all, thank you for this great plugin 😄 .

I am opening an issue because latest update from 1.1.7 to 1.1.8 is breaking when trying to get a secure cookie, and you may be able to help me find the solution faster.

The breaking change is caused by commit a545eb7d782dbe532f04c81404b47b2f3751b64b in CookieService, line 139 and below.
Previously, that function does:
$cookie = Craft::$app->request->cookies->get($name);
Before the change, it checked if $cookie wasn't empty but after the change it directly tries to access $cookie->value.

This happens when I do getSecureCookie('cookie_name') in a view, to check for the cookie value that was set by another app in another subdomain of the same domain.

Shouldn't it check if $cookie is empty first?
Thanks!

unserialize() expects parameter 2 to be array, boolean given for PHP version >= 7.1.0

getSecureCookie function returns empty value on PHP 7.1.0

Issue is found in "CookiesService" on line 161
$result = @unserialize(base64_decode($data), false);

Please change it to
$result = @unserialize(base64_decode($data), ['allowed_classes' => false]);

From PHP 7.1.0 onwards unserialize function requires strict options naming.
http://php.net/manual/en/function.unserialize.php#121813

I have not tested with PHP 7.0

I would also suggest to remove '@' so debugging of errors would be easier :)

Removing cookies throws an error

When removing a cookie, Craft throws the following error

When checking if you have to remove the cookie, there's the following code:

if ($name == "") {
    Craft::$app->request->cookies->remove($name);
}

Shouldn't this be if ($value == "")?

But if I change that the following error is thrown:

If I change the whole statement to this:

if ($value == "") {
    Craft::$app->request->cookies->readOnly = false;
    Craft::$app->request->cookies->remove($name);
    Craft::$app->request->cookies->readOnly = true;
}

It works, but that seems a bit convulted somehow?

Documentation: same example added twice in a row

Describe the bug

The Retrieving Secure cookies example is listed twice.

To reproduce

see retrieving-secure-cookies

Sorry, Andrew, it's not a bug, but I can't change the label. :)