Deprecate direct access to the $_SESSION super global by flagging all keys which are not registered as session bags in SessionManager.
After the deprecation period, remove support for the $_SESSION super global from SessionManager.
Determine storage keys of all registered bags in SessionManager::save(). Generate one deprecation for any key which is contained in $_SESSION but isn't present in the list of session bag storage keys.
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes, plain diff MR !11803
Comments
Comment #3
znerol commentedNeeds tests for the new deprecation. Also needs a CR for sure.
Comment #4
znerol commentedAdded a legacy test and a CR.
Comment #5
smustgrave commentedLooks good!
Left some comments on the MR.
Comment #6
smustgrave commentedComment #8
andypostApplied clean-up and D12, IMO looks RTBC and is not disruptive since D8
Comment #9
smustgrave commentedFeedback appears to be addressed.
Comment #10
znerol commentedIn both
SessionTestControllerandLegacySessionController, the method documentation often declared a completely wrong return type:Since this MR touches a couple of those methods, I fixed them all.
I agree that deprecating direct access to the
$_SESSIONis not disruptive. However, the next step will be to remove support for custom session keys completely. I.e.,SessionManagerwould stop considering custom keys in$_SESSIONwhen deciding whether to start/save a session automatically.If contrib and custom code continue to access custom keys, this might or might not work depending on other circumstances (i.e., whether or not some unrelated part of the system is using the session as well). But problems will be hard to diagnose because custom keys are silently ignored when the deprecation and support for custom keys are dropped.
That was the reason I think a longer deprecation period could be worthwhile in this case.
Comment #11
smustgrave commentedLet’s see what comes from the decision on the policy if some stuff will be pushed to 13
Comment #12
catchThat's for 11.3, not 11.2
Comment #13
smustgrave commentedNot sure I see the difference if we are still talking about waiting till 13
Comment #14
znerol commentedRight, then there is no need to delay the deprecation, I guess.
Comment #15
catchSee #3518671: [policy, no patch] Defer disruptive 11.3 deprecations for removal until 13.0, the Drupal 13 deprecations would start when the 11.3.x branch is open, which is not yet.
Comment #16
andypostI find it good to go and let's discus disruption in #3518527: Deprecate custom keys in $_SESSION
Comment #17
andypostI mean #3283288: Implement Symfony SessionListener
Comment #20
alexpottDiscussed with @catch we agreed that this can go in the 11.2.x alpha period.
Committed and pushed 5301cfd2371 to 11.x and 94ccff04de2 to 11.2.x. Thanks!
Comment #21
alexpott