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)
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 theCookie::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 tochange/major
affects/v5
?