archon810

Looks like 1.73.6 addresses this. https://plugins.trac.www.ads-software.com/changeset?sfp_email=&sfph_mail=&reponame=&new=3064836%40memberful-wp&old=3054645%40memberful-wp&sfp_email=&sfph_mail=

1.73.6
* Fix PHP deprecation warnings.

Fired up a Github ticket as well in case you’re not checking the forums https://github.com/zedzedzed/table-of-contents-plus/issues/157.

This made some pages on the site crash. Had to revert.

Upon further review, it looks like this is caused by something we’re doing on our end (i.e. disabling certain Jetpack functions) due to Jetpack causing major performance issues on the frontend in the past. We’ll take a look at resolving this internally.

Thank you, randomly noticed that whole TOC missing, and this was the fix. I’d classify it as a bug in the update, which the author should probably fix.

• This reply was modified 1 year, 7 months ago by archon810.

Nice, thank you! I’m happy to hear there were no security issues here.

Looking at the wp_options table, wsal_pruning-date is the only WSAL (or any other plugin) option that keeps updating many times a second like that, so the bug is oddly specific and related to just this option (it’s also an option I changed today, though it wasn’t the only one I changed – I also changed the pagination option).

Edit: I’ve changed the option back to “Keep all data” but it’s still stuck as “6 months” in wp_options and getting continuously deleted/re-added. The UI is correctly showing “Keep all data” selected though. I’m further confused.

• This reply was modified 2 years, 4 months ago by archon810.
• This reply was modified 2 years, 4 months ago by archon810.

In the meantime, I followed the steps above, deleted the wsal_meta_data_migration_info_440 option, changed the wsal_version option to 4.3.4, and reloaded the page. No notice thus far.

However, monitoring the SQL log, I see a lot of these fly by over and over. Why is WSAL deleting and creating this option over and over and over? Seems like a bug.
DELETE FROM wp_options WHERE option_name = 'wsal_pruning-date'

I’m refreshing every second and the ID keeps changing, meaning this option indeed gets deleted and recreated many times a second.
SELECT * FROM wp_options WHERE option_name = 'wsal_pruning-date'

In fact, I recall at some point this killing our db today because a high db load caused this constant deletion and recreation to spiral out of control and all processes to hang.

To give more context, if I refresh every 2 seconds or so, the ID goes up by 100, meaning the plugin absolutely thrashes our db. An urgent fix is needed.

• This reply was modified 2 years, 4 months ago by archon810.

Found another thread with more users running into the same issue: https://www.ads-software.com/support/topic/permanent-alert/.

Is there maybe a log of the conversion events or anything helpful to figure out what’s going on under the hood anywhere?

Finally, you keep mentioning an upgrade to 4.3.6 was required, but https://wpactivitylog.com/support/kb/plugin-changelog/ doesn’t mention this, or “4.3.6” at all.

Having the same issue after updating from 4.3.4 to 4.4.1.1 @robert681.

This upgrade actually created a number of issues with the db load. After seeing the message not going away and thinking it may be the size of the metadata table, I tried to trim the db to the last 6 months (previously, it was set to store all). This ended up essentially taking down replication because this absolutely massive query 45MB in size with millions of IDs was running and never finishing:
DELETE FROM wp_wsal_metadata WHERE occurrence_id IN (1,2,3,4,5...)

Eventually, after seeing it stuck for 15 minutes, I had to kill it, which took another 15 minutes to cancel, and took a look at the data. I found 110 million rows in wp_wsal_metadata. In my opinion, the cleanup script should batch the deletions, otherwise you risk taking out replication (because it’s single-threaded and slaves will lag by the amount of time it takes to execute this query), plus the load on the db server spikes quite badly due to all the table writes.

I ended up sorting out the table manually by batching the deletions 1-10 million rows at a time, though I recommend a lower number, like maybe 10-100k per query.

But anyway, back to this issue. Is it possible to tell if something is really stuck with whatever upgrade/conversion it’s trying to do or it’s progressing, but very slowly? Is there a query I could run to see the queue? Or did upgrading from 4.3.4 without first going to 4.3.6 break something permanently? What’s the proper fix?

Thanks.

Interesting, alright. I assume you’ve already done this, but the answer I got from the WP team is to email [email protected]. https://twitter.com/Ipstenu/status/1539368794820186112

Wow, that’s pretty crazy. They just pulled the plugin with no notification to you, the author? You sure it’s not in some spam folder? Who do you even reach out for something like that?

Thanks for the fix in the latest version of the plugin.

To add some details, the url random people are pinging that’s causing this notice is https://www.OURSITE.com/?memberful_endpoint=auth.

Upgrading to 9.6 didn’t seem to help.