3.9.0 update didn’t create new tables

I tried editing the Updater class to this to manually trigger the update script but that didn’t work so rolling back the plugin now:

public function __construct( $skip_admin_check = true ) {

Hi, thanks for the report.

Can you try reading this migration article to see if that helps or not?
https://github.com/boonebgorges/buddypress-group-email-subscription/wiki/Migrating-to-3.9.0

The latter part of that article explains that there should be an option on the admin settings page to start the migration process. If you are familiar with WP-CLI, there are also commands you can use to create the DB tables. This info is also available in the article linked above.

• This reply was modified 5 years, 8 months ago by r-a-y.

I have this problem too. Looking at the migration doc mentioned by @r-a-y, there is nothing in the admin screen about migration status. I don’t use WP-CLI, so what can I do?

Thanks

Same as @petervandoorn I’m not seeing a “Migration Status” section on the settings panel and nothing runs when we update it. I’ve tried on multiple client sites and all have the same results of no migration running. We don’t use WP-CLI either.

We do have WP Rocket running which decreases the heartbeat rate as well as Wordfence running and we use real cron jobs. Not sure if any of those would play a part here.

Hi @petervandoorn and @contemplate – Thanks for your patience as we sort through this.

I just had a closer look, and the 3.9 release had at least one issue that might have prevented the database routine from running properly. It’s been fixed in 3.9.1, just released.

I also loosened the restrictions on the “Migration Status” section of the “BP Group Email Options” Dashboard panel, so that you should be able to see it. Please verify this. You should see the failed creation steps there; click the “manual” migration link to re-run things, and please let me know how things go.

Thanks again for the patience. These migrations are a bear.

Thanks @boonebgorges this got me a little further but I’m stuck on the migrate subscriptions step:
https://www.dropbox.com/s/ov2pc8wdchibi3v/Screen%20Shot%202019-03-21%20at%2012.58.24%20PM.png?dl=0

I see 13165 records have been created in the database but it hasn’t progressed past this in some time now:
https://www.dropbox.com/s/syuyjx3bq914jqw/Screen%20Shot%202019-03-21%20at%2012.58.13%20PM.png?dl=0

I fear I can’t revert back now… help?

Hi @boonebgorges. Didn’t work for me I’m afraid. In the settings screen I see red Xs against all 3 steps. I clicked on the manual run button and no difference. Checking my debug.log I see no errors for creating tables, but loads of errors all saying WordPress database error Table 'brighto9_db2.wp_bpges_subscriptions' doesn't exist for query SELECT * FROM wp_bpges_subscriptions WHERE group_id = 3 ORDER BY id ASC made by require('wp-blog-header.php')

Hey @petervandoorn I had to press the manual link a few times before it would create the tables. But then got stuck on step 2

@contemplate It could be that the migration died partway through, either because one of the self-pings failed, or because one of the batches timed out. Can you check (a) your PHP error logs to see if there are related fatal errors (like “memory limit exceeded”), and (b) your access logs for requests to admin-ajax.php? In the latter case, you should see a chain of them every couple seconds around the time of migration, and it may end up in a failure.

As a sanity check, you might run a couple queries to see how much of the migration has actually run. Compare: SELECT COUNT(*) FROM wp_bp_groups_groupmeta WHERE meta_key = 'ass_subscribed_users' (number of groups with subscribers in the legacy setup) with SELECT COUNT(DISTINCT group_id) FROM wp_bpges_subscriptions (number of groups with subscribers in the new setup). It might be that the migration actually finished, but wasn’t marked as finished for some reason.

In any case, you do not want to revert. The functionality in the plugin is perfectly fine, it’s just the migration that is finicky. That being said, no old data is deleted by the migration process – it’s all still there.

@petervandoorn Did you try triggering the manual update link several times, as suggested by @contemplate ?

Hi @boonebgorges. So, I had downgraded to the previous version so my users still had their email notifications. When I re up-dated the migration hadn’t run according to the settings page. I clicked on the manually trigger migrations link and the 1st one, Create database tables, got a green tick. Clicking the link again and the other 2 then completed. I think checked one of the groups and the members are all showing the correct preferences. So, that’s a result! No errors in the log either. Thanks

Hi @petervandoorn – Thank you so much for following up! To confirm that the migration did indeed run properly, you may want to trigger a few test notifications – post an activity update in a test group and make sure that subscription settings are obeyed, etc. Otherwise, it sounds like things worked, which is a relief ??

ok @boonebgorges I did the sanity check.
First query produce a count of 101
Second quesry produced a count of 70

Shouldn’t the first query produce a smaller count?

Also the qeuried items table appears to be full with 3592 records
and the subscriptions table is now at 13177
it still shows I’m stuck on step 2

I’m not seeing any PHP errors related to this after the tables were created

Hi Guys,
I just wanted to chime in and say that I also experienced the same issues on one of my sites and after triggering the manual migration a few times, the problem was solved.
Thank you!

Tried updating as well, after a few attempts tables have been created. Migrate subscriptions & Migrate queued items hvaen’t run and tried running manually multiple times.

Any other way to fix this or do I need to keep trying the manual link?

Thanks

Hi all – Again, thanks for your continued patience.

I’ve just pushed up some more improvements to the 3.9.x branch of this plugin on GitHub. These improvements are focused around the manual migration process.

The main improvement is that the CLI tools are no longer asynchronous, which means that they’re pretty much 100% reliable. If you have access to wp-cli, this is the preferred method to clean up:

1. wp bpges install-database (if your tables are not yet installed)
2. wp bpges migrate-legacy-subscriptions
3. wp bpges migrate-legacy-digest-queue (this must be run after the subscriptions)

If you don’t have access to wp-cli, I’ve written a small script that can be put into a mu-plugin, which will attempt to process all of your migrations in one single pageload. It’s likely that it’ll time out on very large installations – this was the point of the asynchronous migrator – but you should be able to refresh until it finishes. Here’s the script: https://gist.github.com/boonebgorges/14c0d1042e85d263d48f3eaf7ca25b6d Use: put into an mu-plugins file, and then visit /wp-admin/?bpges-force-migrate=subscriptions (for subscriptions) or /wp-admin/?bpges-force-migrate=queued_items (for digests – do after subscriptions).

Note that you will need to update to the latest 3.9.x branch from GitHub for any of this to work. Download https://github.com/boonebgorges/buddypress-group-email-subscription/archive/3.9.x.zip, rename the unzipped file to buddypress-group-email-subscription and replace your existing plugin with it.

It’d be great to get confirmation from one or two folks that these migration improvements (especially the CLI tools) are good, before I push 3.9.2 to the repo.