I have followed the steps provided. I successfully tested 1-3 steps. But not able to understand 4th and 5th step clearly. I am sure this is me who don’t understand as I don’t much familiar with joomla framework so far.

Thank you. ?

Look, I know this is tricky as all can be to properly test, but there are major logic and workflow fixes introduced here that are somewhat needed to break some existing bad practices. Some tests here would be appreciated...

Is this going anywhere or can I close for lack of interest?

from my part i find all your PR interresting but because of gsoc project lack of time ATM.

Out of sync yet again and apparently too complex for the user base. I'm done.

This has only been open 4 months, even some simpler PRs have been open since Aug 18, 2014 ;-)

After the discussion yesterday I'm keeping my PRs limited to things that a user can click in the backend after installing a patch with patch tester since apparently requesting testing on highly technical matters such as this is asking for too much.

please don't close your PR michael, i think most of them are important.

i don't have always time to test all of them, but i try to test them when possible.

I will try this one last time. Key points here:

• The database handler has a hardcoded dependency to the record being inserted by the application, this is now fixed
• The database metadata cleanup operation is differed to the end of the request cycle and error trapped to prevent the user from getting the error page simply because this operation failed
• Session starting is deferred to a point after the application is stored to the factory; if the session fails to start for whatever reason this should put the user in an error page instead of the "Application Instantiation Error" stuff showing
• One must explicitly call $session->start() to correctly start the session right now; similar to other parts of the API that lazy load, the session can now do the same
• The session start event is reliant on global state (namely having a JSession object stored to the factory); this is resolved by passing the event dependency through the dispatcher
• Because of our metadata tracking mechanisms, right now the loadSession() method is also performing session garbage collection when the database handler is in use; this is a waste of cycles as the underlying PHP API has mechanisms to perform garbage collection AND handles expired sessions just fine without us beating it to the punch

These are all deep rooted architectural issues that need to be addressed and the only way to do so is testing through these technically heavy patches.

• applied patch
• in frontend deleted all cookies to start a new session
• refreshed the page. Result: 500 error

Same error in the admin

Fixed. That last merge didn't go well at all.

I have tested this item ✅ successfully on 42fe67a

1) Download the branch from https://github.com/mbabker/joomla-cms/archive/refactor-session-metadata-coupling.zip
2) Install Joomla; sessions in the installation application should continue to function correctly

OK

3) Use Joomla normally; sessions should continue to function correctly

OK

4) With the database session handler enabled, JApplicationCms::checkSession() should only be executed when the session is new. As this is only ensuring the extra metadata is present in the database, it is not required for every page load. All requests after the session is started will have the record in the database updated by the session handler only (or any place making an explicit query to the #__session database table). As well, the new JApplicationCms::cleanupSessionMetadata() method should never be called.

OK. Added $this->enqueueMessage('checkSession called', 'notice'); in JApplicationCms::checkSession() to confirm.

5) With any other session handler enabled, JApplicationCms::checkSession() should only be called if the session is new or the time is an even numbered second. The new JApplicationCms::cleanupSessionMetadata() method should be called when the onAfterRender event is triggered and the delete query should only run when the time is an even numbered second.

Didn't test don't have other session handler to test.

Should be able to use the filesystem (PHP, None, whatever it's called in the UI these days).

ok of course! ? will check that

I have tested this item ✅ successfully on 42fe67a

PHP, Database
No memcache

Works with PHP as session handler too, with this handler the notice added appears somewhat random as supposed (should only be called [...] or the time is an even numbered second).

Hmm, @mbabker

Could this be the reason why I get a PHP Warning?

See #12108

Reverting this PR solves the issue

This should not have been merged into 3.6.3 it was not a bug fix and should have waited for 3.7

Wouldn't have mattered what branch it went into. Still would've hit the same bugs because some condition's not going to be tested through normally and it's going to result in someone getting something broken. So, I'm not pushing it anymore. We'll just stick with the broken global state and default structures we have now.