Eric Mann

This should be a support question, not a review.

Keep in mind that WP Session Manager is an extension that does nothing aside from provide support for $_SESSION in WordPress. Unless you’re developing a plugin or a theme that uses that, it won’t actually do anything for your site. Said another way: this isn’t something you should just activate on a site.

As for the error you hit – I can’t even begin to diagnose this without more information. The plugin, upon activation, attempts to create a new database table for storing session data. It doesn’t modify other tables or other data, so I’d want to know more about what you’re seeing with your “completely corrupted SQL database.”

Further – if you’re already using plugins (or a theme) that independently embed session management, there’s high potential for conflicts in the code. But that would be present in sessions breaking, not in database failure. Something else is going on here, but no one will be able to fix it without more information from either you or your host.

You can download v3.0.4 from the “Advanced” listing on the plugin page => https://www.ads-software.com/plugins/wp-session-manager/advanced/ It’s not as advanced as the current 4.x release, but will work with older PHP.

After looking at the code for the Authorizer plugin, I can tell you that it’s not compatible with WP Session Manager or anything that uses it. Authorizer attempts to use sessions for user state management while negotiating login, and the independent invocation of <tt>session_start()</tt> will conflict with WP Session Manager.

Said another way, only _one_ codebase can register the session handler for the system. The first to do so, wins.

Both WP Session Manager and Authorizer attempt to integrate deeply with PHP’s session system and are colliding with each other here. Unfortunately, I can’t think of a quick workaround to resolve the issue.

The session plugin doesn’t do any sort of redirect on its own, so I’m confused as to how you were able to identify WP Session Manager as the culprit here. Not saying it’s not, but I don’t see how it could be.

As this is literally a problem I’ve never seen before anywhere else, I can’t even attempt to reproduce without further information.

– How did you track things down to the inclusion of WP Session Manager?
– What other plugins are installed?

Where and how is this code wired on for these pages exactly?

As this has a temporary workaround (see link above) and a pending permanent/total fix, I’m going to mark this as “resolved” here and direct any further viewers to the link above.

@asantos23 This conversation was already resolved as it was fixed in a different release. <i>Next time</i> please open a separate thread so everyone can see it. That being said, let me explain a few of these …

* random_compat

This is a library that provides true random number support for older versions of PHP. On modern versions (i.e. 7+) it’s unnecessary as the random number generators are native. It’s included here as a dependency of the defuse/php-encryption library.

This is a polyfill, meaning it’s built in such a way that it’s not even used if you’re on the right version of PHP – it’s only actually loaded if you’re on old PHP and lack native support.

Note also that WordPress ships this library as part of core as well, so your site is already running it ??

* defuse/php-encryption

This library is used to encrypt sessions at rest and provides a wrapper around common encryption functionality in PHP. If you’re not encryption sessions – though you should be – it won’t do anything.

* Deprecation warnings

These won’t break your site. They’re a consequence of the plugin supporting older versions of PHP and necessarily including libraries that provide backwards-compatibility support. I will eventually be removing them when I bump the minimum version to 7.2 … but that’s a ways out.

* Deprecation errors

These errors – the removal of the mcrypt extension as of PHP 7.2 – are known. They’re why the random-compat library is included at all. Older versions of PHP that lacked a true random number generator used mcrypt to generate random values. Modern PHP uses a native interface and the library doesn’t even try to load the extension.

In summary: static code sniffing is giving you some false positive errors here.

Plugins are loaded in order based on their name. So wp-session-manager will get loaded after aardvark-fancy-plugin because of where they fall in the alphabet. Plugins should leverage the plugins_loaded hook to ensure they’re only triggering business logic once everything’s been pulled into the environment.

Some plugin (or even the theme) is calling session_start() outside of this hook and running too early.

Yes, this error message is new.

WP Session Manager attempts to replace the session handler used by PHP when it stores data. If the session has already been started, then PHP doesn’t allow the plugin to replace the session handler at all. With older versions of PHP, this just failed silently. As of PHP 7.2 it’s become a formal warning and is often exposed directly on the site when encountered.

See https://www.ads-software.com/support/topic/php-7-2-warning-5/ for the original report that led to the fix.

Said another way: If your site is showing this error, then it means WP Session Manager was never really working on your site to begin with because another system would set up the session first.

Regardless of whether or not you’ve actually populated the session, merely calling session_start() before WP Session Manager loads will block the PHP from loading or using the custom session handler.

How do I track down what other plugin is using it?

Do a scan of the plugins (and your theme!) on your site and look for session_start(). Whichever code is calling that is likely doing so outside of the plugins_loaded hook and is beating WP Session Manager to the punch.

• This reply was modified 5 years, 10 months ago by Eric Mann. Reason: Fix formatting
• This reply was modified 5 years, 10 months ago by Eric Mann. Reason: Fix HTML formatting that was broken before :-(

I’ve resolved this in v4.1.0 by hooking in and setting up a cron job for you.

You are likely correct. The call would be something like:

`
$handler = new \EAMann\WPSession\DatabaseHandler();
$handler->clean();
`

That being said, doing this directly is entirely untested at the moment. I’ll queue up an issue on GitHub to add a cron cleanup for the DB handler directly to WordPress in the next release.

• This reply was modified 5 years, 10 months ago by Eric Mann.

My first recommendation: upgrade to PHP 7.1 (at least). PHP 7.0 was end of life last month. So was 5.6. Neither are receiving security updates any longer.

If you can’t upgrade on your own, contact your hosting provider. They can help.

That’s not quite the way PHP itself works. A session is unique to a user, but you can decide whether or not the session contains any data based on the validation result.

This is definitely something we should fix => I’m opening a bug report on the GitHub project for tracking.

Unfortunately, your proposed solution to check whether or not $_SESSION is set first will … break things. We need to set the session save handler before using the session at all in order for it to save to the right place. If your site is setting up a session before we’ve set the save handler, you won’t end up using the plugin’s custom storage in the first place.

In any case, marking this as “resolved” for now because it’s more than likely your theme (or another plugin) that’s setting the session up early. That being said, I’ll queue things up to see if we can be more defensive around setting things up moving forward.

The plugin leverages scalar return type hints to ensure everything works with the correct types. The error you’re seeing is the error that PHP 5.6 or lower would throw when encountering the following code:

function function_name(): int {}

The extra int in there is the return type, which is valid as of PHP 7.0 => https://php.net/manual/en/functions.returning-values.php#functions.returning-values.type-declaration

Can you confirm the version of PHP you’re using?