Hello @ellmanncreative
Thank you for using our plugin.
I am sorry to read about your issue. Indeed, if you can see that notification for more than a few minutes it seems like the database schema upgrade process has somehow crashed / halted / failed.
The upgrade process is triggered with a cron job called wsal_meta_data_migration_440. Can you please install a plugin such as WP Crontrol or Advanced Cron Manager and restart the cron job?
If the upgrade process still fails, in the wp_options table there should be an option entry wsal_meta_data_migration_info_440 that contains the start time, number of processed events, batch size and connection name.
Can you please let us know the values that you have in it? Maybe it is better to send the information over email at support@wpwhitesecurity.com rather than sharing it on this forum.
Looking forward to hearing from you.
Installed WP Crontrol. In “Cron Schedules”, I can see wp_wsal_meta_data_migration_440_cron_interval (set to “every 5 minutes”).
Otherwise, in “Cron Events” there are only two entries that contain ‘wsal’ in any way: wsal_cleanup (hourly) and wsal_delete_logins (daily).
As for the migration info from wp_options:
array(1) {
["local"]=>
array(4) {
["start_time"]=>
int(1646043533)
["processed_events_count"]=>
int(0)
["batch_size"]=>
int(50)
["connection"]=>
string(5) "local"
}
}
@ellmanncreative
In your case it seems that for some reason the migration process was halted, maybe this could be related to the web host problems you had with script terminations.
Anyway, at this stage I’d recommend the following:
1) Backup the activity log tables. This is very important in case you need to recover them.
2) Delete the option wsal_meta_data_migration_info_440 from the options table
3) Change the value of the option wsal_version to 4.3.6 in the options table to trigger the upgrade process again.
Can you please advise if this helps?
@pwenzel and @houseminute your issues might be caused by a completely different problem, so the best thing is to open your own tickets so we can assist you. Can you please send us an email at support@wpwhitesecurity.com so we can ask you for more technical information, so we can better assist you? Looking forward to hearing from you.
Looks like that did it, and the upgrade took only a few seconds (possibly less).
My theory is that the update got triggered when the plugin auto-upgraded to 4.4.0, and then got axed when the erroneous clampdown killed our PHP processes.
As soon as we move hosts, this sort of issue should stop being an issue. Hopefully.
It’s a good thing that the conversion/upgrade process can be restarted.
I am glad to hear that @ellmanncreative
Indeed, the upgrade process should not take very long. Should there be anything else we can assist you with, please do not hesitate to ask.
Also, please do not forget to rate our service and plugin. These ratings really help us.
Thank you and have a great day.
Hi Robert –
Thanks for the offer, but I set the plugin to delete all its data and started over. A fresh installation of the current plugin worked great. I appreciate that this wouldn’t be an ideal approach for many people, but it wasn’t necessary that we retain previous data and, for us, it was an expedient solution. Thanks again 🙂
I am glad you “solved” the issue as well @houseminute
It might not be the ideal solution, but as long as it works for you, you’re another content user 🙂
Please do not forget to rate our service and plugin. These ratings really help us.
Thank you and have a great day.
I have this issue on at least 8 sites. Not really feeling like spending the time as mentioned above to “fix” this. Will it be handled in a near update?
@jakobward considering that the plugin uses the mentioned value as its “signpost” to know whether it went through or not, and considering that it’s potentially possible that the second attempt actually breaks the data table – I doubt it’ll be handled automatically.
At best, I would see a “retry” button somewhere, which would trigger a complete restart of the upgrade procedure. It might caution you to make a full database backup, just in case.
Otherwise, I don’t see any good way out of this – at least not for installations which are already affected.
I haven’t looked at the source code to see how this upgrade works exactly, so I can’t really say anything for sure – but I expect a little bit more of defensive programming wouldn’t hurt here. Though I strongly suspect that WP’s very disjoint nature (specifically – how any scheduled process must fully expect to be interrupted and resumed, perhaps multiple times) isn’t helping matters at all.
Alright, cool. I’ll figure something out. Thanks for the feedback. Great plugin.
@jakobward note that I am not part of this plugin’s dev team.
Your best approach to getting this answered is to open a new thread and ask there – it will bring this to the attention of the developers, and you won’t have other people interfering (unless they crash the party, like you ;P).
Hello everyone,
Even if you have encountered the same issue, please open your own support thread. We won’t be providing support / answering anyone else on this ticket other than the person who opened this thread.
Thank you for your understanding.
