[#19577] - [4.0] Add a CLI command to run PHP session gc
- Fixed in Code Base
- 6 Feb 2018
- Medium
- Build: 4.0-dev
- # 19577
- Diff
- mbabker:4.0-session-gc-cli
User tests: Successful: Unsuccessful:
Summary of Changes
This is in essence the same thing as #19548 but converted for 4.0 with the changes in the CLI runner and the session API in place.
This also defines a core service for lazy loading console commands so that command classes with dependencies don't have to arbitrarily be loaded at all times.
Testing Instructions
With the patch applied, run php cli/joomla.php session:gc to trigger the command. If running PHP 7.0 or the operation fails, you'll get an error message; otherwise you'll get a success message. Note the PHP 7.0 error condition is because the Framework's default implementation of SessionInterface::gc() relies on PHP's session_gc() function, which is not available before PHP 7.1, and the function does not have a userland polyfill at this time.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries |
wilsonge
- | Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-02-06 12:15:21 |
| Closed_By | ⇒ | wilsonge | |
| Labels |
Added:
?
|
||
It relies on whatever PHP's session_gc() function is doing. Which, I honestly don't know the internals of.
But, if it is triggering our handler's gc() method, that won't be enough in the case of the database handler because we have code that defers garbage collection until the session is closed for that request. Considering that a session has to be started to run garbage collection, theoretically the close operation is being run at the end of the process too.
Either way this should not be fixed with special handling for the database handler.
Actually, it does nothing. For some reasons (I haven't looked at the code in deep yet), the store property of session is an instance of Joomla\Session\Storage\RuntimeStorage, and this storage does nothing on gc method https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/vendor/joomla/session/src/Storage/RuntimeStorage.php#L111
So as of right now, this command is useless
It's because of how the session service is built in https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Service/Provider/Session.php
So as of right now, this command is useless
That's a little harsh, the command works just fine but the SessionInterface injected into it and its internals don't work well for what the aim is
That's a little harsh
Sorry, I just wanted to mention it doesn't work. Of course, the logic of the command is fine, it just doesn't work as expected and we need to find a way to solve it.
We need to do a refactor on how the session service provider is built. At a minimum we probably need a session.web and session.cli service using the different storage mechanisms that way we can forcibly grab the one that's needed when not using the default. It also means having some logic outside the service provider to alias the session key (and the classes/interface) to the correct service based on environment.
Look like this doesn't work as expected. I tried to test with Database Handler and running the command doesn't delete data stored in #__session table