@mbabker should this be applied to a Project?

confirmed

@mbabker any ideas?

Additionally, testing the latest Joomla 4 Alpha 4 i noticed that by default every session is started having the 'client_id' set to NULL until a user login to the frontend or backend application.
Basically a 'client_id' is no more assigned until a user perform the login to either the frontend or backend.

So now that 3.8.6 is merged up, between the changes created with the MetadataManager class' introduction and the architecture changes in 4.0 in general, the metadata manager is never actually triggered on a fresh session's creation (only the hook in the user plugin to refresh this data is fired).

Here's what needs to happen:

• #19594 is finished and merged, this puts the architecture in a better state to set up event subscribers for the session events fired before plugins are even available
• The MetadataManager class converted to a service to be used throughout the app stack as needed
• The MetadataManager class refactored to account for 4.0 architecture changes
  • The database session handler actually inserts records now, in contrast to 3.x and earlier where the handler relied on the part of the API which logged the session metadata to do the insert, so createRecordIfNonExisting() can't really work as is
  • The MetadataManager should be made aware of the new config which disables the metadata tracking altogether
• The MetadataManager triggered by a SessionEvents::START event listener (TODO - check if there's a code path in the CMS where sessions are restarted, inherently triggering SessionEvents::RESTART, and ensure that is hooked too)
  • This needs to be prioritized after the current WebApplication::afterSessionStart() method which also serves as a listener for the start event to ensure that the internal session registry and user object are set

Also to consider is if we're now willing to accept the metadata being stored to a separate table or if we're going to continue mixing the session table with both core session data and the extra metadata.

Also to consider is if we're now willing to accept the metadata being stored to a separate table or if we're going to continue mixing the session table with both core session data and the extra metadata.

Why wouldn't we?

Why wouldn't we?

We're a stubborn crew that's set in our ways?

@joeforjoomla is this still an issue?

@joeforjoomla is this still an issue?

No longer an issue. Closed.