PHP Native Sessions table is missing a primary key

Hi @david-barczak

That notice is informing you about an issue that we identified in an earlier version of the Native PHP Sessions that would have caused your database to perform more slowly. The notice itself is benign but giving you instructions on how to resolve the issue via Terminus commands that we’ve added to the plugin. The plugin still works the same way as it did before and the notice can be dismissed, but it’s advised to run the steps that are instructed to add indexes to the database tables for your PHP sessions.

If your codebase doesn’t use or need to use PHP sessions at all, then you don’t need to keep the plugin and deactivating it (and deleting it) is enough. The tables will still exist, but since they wouldn’t be accessed for anything, they won’t cause any performance degradation.

hi Chris – for those more comfortable with SQL workbench or PHPMyadmin etc – please can you provide the sql here to create the index as that’s often the easiest way to do so.

e.g. CREATE INDEX index_name ON table_name (column_name(length));

That would be really handy ta.

PS: thank you for maintaining this plugin – it really makes session management behind a load balancer sooooo much easier – in fact – with the popularity of load balancers and the dominance of WordPress I’m kinda amazed they’ve never added this functionality to the core WordPress product.

@heavencore There’s a number of things the CLI command does (mostly to ensure that it’s executed safely) which you can see, if you’re curious, here: https://github.com/pantheon-systems/wp-native-php-sessions/pull/265/files#diff-281dc1f283dc76e853f26d96bf01ee54a0cd34e7b4e1fb550e28e6adf198e531R264-R438

The specific SQL query you’re looking for is here: ALTER TABLE {your_table, e.g wp_pantheon_sessions} ADD COLUMN id BIGINT AUTO_INCREMENT PRIMARY KEY FIRST. Obviously all the normal precautions apply if you’re going to be manipulating the database directly (make a backup, test first, etc etc etc). The CLI command makes a copy of the wp_pantheon_sessions table, makes its changes there and then, when it’s validated that everything works as expected, there’s a finalize command that replaces the existing wp_pantheon_sessions with the new copy with indexes.

We just pushed an update that, if you dismiss the notice, the notice is dismissed for that user. We will be working for our next release to integrate into the WordPress Health Check page to move this information into the Health Checks so they still exist if you’ve dismissed the notice. This way, if the issue is not of concern to you (because you aren’t experiencing any issues with the unindexed database table) you can dismiss the notice and forget about it (or deal with it at a later date).

I’m going to mark as resolved but happy to work through any specific issues if you encounter problems running the update.

When will this be fixed not every one has WP-CLI on their host, or phpmyadmin access, will there be a version that fixes this message by the plugin itself?

@sadesades

An update to the WP-CLI script to allow it to apply to all sites in a multisite is being worked on right now with the intent of pushing it out in the next couple days. Part of that update will include a fix for the notice on WordPress multisites not dismissing properly.

However, it should be noted that the notice and WP-CLI function that was added in 1.4.0 is for your information only and is telling you about a problem identified in your database. While the notice can be dismissed, it doesn’t “fix” the problem — the problem can only be fixed by running the WP-CLI command. We’ve updated the language of the notice to add a bit more detail so it’s clearer that it’s informational and not necessarily indicative of a problem (unless you have a large, high traffic site). In the future, we plan to also add integration to the WordPress Health Check page so when you dismiss the notice, you can still get that information in the Health Check as being something that should be addressed.

We do not have immediate plans to build a GUI for the actual fix, but unless you have a multisite, dismissing the notice will store a value to your user meta and prevent it from being displayed for you (which, again, is not a fix, the fix is the WP-CLI command).