Sessions are empty?

[lougreenwood]

Hi, I'm (attempting) to use the plugin to allow WP in a distributed environment.

Some info about our setup:

• WP 4.9.4 & Themosis framework 1.3.2 (Themosis allows working with WP using MVC design patterns. Themosis modifies/augments the WP bootstrap process - https://framework.themosis.com).
• Completely custom UI, uses no WP hooks etc.
• PHP 7.2.2
• WP/Redis caching

I'm seeing that the "Sessions" page in WP Admin is empty. Also when deployed on our load balanced/distributed WP staging servers I see weirdness where every couple of page loads the site shows the user the login page - presumably because Pantheons DB sessions aren't being used and one WP node is getting some unknown session from another WP node which the user previously visited?

Any ideas on what the problem might be or how I could attempt to debug this?

Cheers

[lougreenwood]

[danielbachhuber]

Hi @lougreenwood,

Thanks for the report. WordPress doesn't use PHP sessions to manage login state, so WP Native PHP Sessions isn't applicable for that use case. WP Native PHP Sessions is meant for the scenario where your codebase is dependent on $_SESSION and similar.

It's hard to say what your problem might be without being able to debug further. We offer full support for projects hosted on Pantheon, and limited support otherwise. One thing I'd recommend verifying is making sure WP Native PHP Sessions is loaded as a mu-plugin, so it runs before other plugins.

[lougreenwood]

Yeah, I hadn’t realised that I needed to do session_start() myself. I’ve successfully gotten it working for a simple custom login form, but I hoped that it would at least hook into WP’s native login function and set the session that way.

Seems my attempts were compounded by a custom Ajax login form, so session wasn’t getting set (because Ajax) anyway.

I’ll keep working at it - thanks for the reply :)

[lougreenwood]

@danielbachhuber Fixed. I needed to set the correct loading order as an mu-plugin. Seems to be working properly now.

One final question. Would you consider updating the 'type' attribute in composer to an mu-plugin?

"type" : "wordpress-muplugin",

This would allow a clean install using Composer directly into the mu-plugins folder...?

[danielbachhuber]

Hm, I don't think it's worth changing existing use of the plugin as a Composer package. Easiest to keep things as-is and then use a stub file as a loader.

[lougreenwood]

Stub file works, thanks. :)

Although, if I can provide a suggestion: if the mu-plugin approach is often suggested - (which to me seems like it should be how the plugin is installed anyways, since the use case for needing PHP sessions pretty firmly falls into a 'must use' use case for a site and the plugin already tries to load itself before all other plugins) - it might be worth considering switching to installing as an mu-plugin in composer at the next major version.

Using the stub file leaves the plugin listed in the normal plugin list of WP-Admin, and if that shows 'deactivated' (even though the mu-plugin is active, but I presume it's best to not activate both the mu & standard plugin?), that could cause issues in the future when a dev forgets - or a new dev isn't aware - that it's also loaded as an mu-plugin.

Anyways, thanks for the great tool, much appreciated! 👍