Tim Nolte

@jakeyprime OK, I’ll try to get the fix for this rolled out in the coming weeks.

@jakeyprime what IDP are you using? I have not seen the session timeout be a major pain. I have this currently running on around 25 sites for a single client. It’s possible that they issue is worse for some IDPs versus others.

@carlalexander yeah, I’ll for sure do that. I should have thought to do that. I ended up having to just disable the plugin in order to get back into my sites(multisite). I’ve honestly been looking at removing JetPack altogether which is probably what I may end up doing since I’ve cancelled my premium plans.

To follow up with either MySQl 5.7 or MySQL 8.0 with HyperDB active the following is an example of the sort of error when trying to install a site the very first time.

WordPress database error: [Invalid default value for 'user_registered']
CREATE TABLE wp_users ( ID bigint(20) unsigned NOT NULL auto_increment, user_login varchar(60) NOT NULL default '', user_pass varchar(255) NOT NULL default '', user_nicename varchar(50) NOT NULL default '', user_email varchar(100) NOT NULL default '', user_url varchar(100) NOT NULL default '', user_registered datetime NOT NULL default '0000-00-00 00:00:00', user_activation_key varchar(255) NOT NULL default '', user_status int(11) NOT NULL default '0', display_name varchar(250) NOT NULL default '', PRIMARY KEY (ID), KEY user_login_key (user_login), KEY user_nicename (user_nicename), KEY user_email (user_email) ) DEFAULT CHARACTER SET utf8

Without HyperDB active this error doesn’t occur. After reactivating HyperDB then there are issues with creating new posts with the following sort of error:

Fatal error: Uncaught Error: Attempt to assign property "post_content" on null in /var/www/html/web/wp/wp-admin/includes/post.php:808 Stack trace: #0 /var/www/html/web/wp/wp-admin/post-new.php(66): get_default_post_to_edit('page', true) #1 {main} thrown in /var/www/html/web/wp/wp-admin/includes/post.php on line 808

From everything we’ve seen this doesn’t occur with MariaDB versions or AWS Aurora DB versions.

It actually appears that HyperDB is really only compatible with MySQL 5.6.

It is really a shame that this plugin seems to have been abandoned. There appear to be major compatibility issues with more current version of MySQL. With HyperDB active using newer MySQL versions it is not possible to properly run through the initial WordPress install without errors about column default values. If you initialize a site without HyperDB active then you can get past this issue but then you run into errors with being able to create new posts.

It also seems related that with HyperDB active that WordPress is not able to properly detect some aspects of the database specifically I can see in the Health Check that “Database collation” is blank, whereas with HyperDB deactivated this is properly populated. “Database collation” is an aspect that is not consistent and compatible between MySQL & MariaDB versions.

FYI, there is actually an incorrect implementation of session length tied to the token refresh expiration. I have a fix in the works and this should be resolved in the next release. There is a hook that can be used that was implemented to extend the WordPress session length.

auth_cookie_expiration

FYI, a bit late but the fix for this should be setting the following:

WPDB_PATH=${ABSPATH}${WPINC}/class-wpdb.php

That can go in a .env file if your site uses one otherwise it can go in wp-config.php such as:

define( 'WPDB_PATH', ABSPATH . WPINC . '/class-wpdb.php' )

The plugin doesn’t provide anything for IDP registration because there is no standard for that. All IDPs have their own unique registration process, if there is even one. Shortcodes are a WordPress Core functionality that you can just use directly if you need something.

@spiderdab OK, that is what I described in the second part of my first response. If you aren’t using static environment configuration then they are stored in the database like any other standard plugin settings.

@spiderdab there are some redirect URLs stores in some temporary transients, but other than that there shouldn’t be anything stored in the DB anywhere with your domain name. If you are talking about the plugin settings those are stored in the options table or configured via a .env or the wp-config.php.

Hmm, so I must confess that this plugin has taken a backseat to other priorities, and I also don’t do support work for any sites using this plugin anymore. I have not done any work to support Blocks with the plugin.

I’ll have to take a look to see what level of Block support I’ll be able to implement, but I suspect it’s going to take a larger effort to support it than I’m really wanting to put into it.

Updating to the latest 1.121 release fixed the issue with connecting Google Analytics.

So, seeing the latest release notes for Site Kit I’m thinking the issue could be related to having Google Tag Manager already configured.

https://github.com/google/site-kit-wp/issues/7937

I’m going to work on getting the site updated with this version and I’ll report back.

It would generally be expected that the user will be logged out when it can no longer obtain a refresh token. This should be what manages the WordPress session.