silverstripe-framework: Cookies cannot expire in less than 1 day.

Note: I initially send an email to the silverstripe-dev group here but I feel it may make more sense to go ahead and submit this as an issue since, to me, this is not correct functionality (but now depended-on).

There should be a finer degree of resolution for setting a cookie expiration in SilverStripe. Since the Cookie::set() method already has parameters that exactly match that of PHP’s native setcookie() function (link), I think it should also accept the same type of input (i.e. enhance this to accept unix timestamp instead). I could not find any immediate explanation at all in the documentation as to why this diverged from the unix timestamp and instead chose days. As such, I find this extremely confusing.

EDIT: Corrected to indicate this should be a unix timestamp, not just “number of days from now”. Another part of why this is a little confusing.

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 28 (28 by maintainers)

Most upvoted comments

Sure, ok. Fine with me. 😄

Yeah, my vote goes to shifting back to the same arg type as setcookie() and deprecating the current semantics.

I just was’t sure what number to place in the Deprecation::notice() call.

IMO, yeah, has to be a breaking change if you’re changing the intention of any argument in an interface.

It occurs to me that some users will have registered different Cookie_Backend services. That means changing the internal use of the Cookie::set() API to supply $expiry as a timestamp will be a breaking change for those users.

Is this an affects/v4 issue? Or does this need to be re-labelled to change/major affects/v5?