Authorizer seems to be slowing us down

Those will be any database migrations that need to be run when installing a new version of Authorizer, so it should be a one-time-only thing. If you have a multisite with a lot of subsites (each subsite has its own options table), that probably explains the long run time.

Please verify that you aren’t encountering any database timeouts; if that happens, the version number in the database doesn’t get incremented, and Authorizer continues to try to apply the database migrations.

We have it on our roadmap to batch process future migrations to better support folks with large multisites, so hopefully this will get better in the future!

Hi Paul,

Thanks. We haven’t moved to the current version of Authorizer, so no db migrations have been necessary since the last update. As far as I know, we haven’t experienced any database timeouts.

I’ll try updating to 3.7.1 next week to see if that fixes the problem.

Mark

Sounds good. You can verify by checking the auth_version option in wp_options and verify it’s at the latest, 20230222. If it’s there, no migrations in class-updates.php should be run.

$ wp option get auth_version
20230222

https://github.com/uhm-coe/authorizer/blob/master/src/authorizer/class-updates.php#L511-L535

Thanks! It’s on 20230222.

Hi Paul,

I just updated our test site to 3.7.1 and tested with “wp option get auth_version”. It’s still showing 20230222—shouldn’t this have changed to 2024[something]?

Mark

That should be up to date; it only changes if there’s a new database migration to run. The last migration we added was Feb 22 last year: https://github.com/uhm-coe/authorizer/commit/43fe01dfde333cfd52e456cd89db37cf7fe5137d#diff-9f9789bfbac0b352be06472af8c1b07093c5777ef1a5d8b57b3157125f22dc2eR514