malimart

The plugin (v4.9.4) caused another issue. When updating WP to 6.9.4 we also needed to update the database from version 60421 to 60717.

When doing wp core update-db –network the plugin flooded the database with SHOW TABLES LIKE queries.

SHOW TABLES LIKE 'wp_2969_ppfuture_actions_args';
# Time: 2026-03-17T14:09:05.026401Z
# User@Host: wordpress_user[wordpress_user] @ localhost [127.0.0.1]  Id:  2355
# Schema: wordpress  Last_errno: 0  Killed: 0
# Query_time: 5.557624  Lock_time: 0.000003  Rows_sent: 1  Rows_examined: 439007  Rows_affected: 0  Bytes_sent: 233
SET timestamp=1773756539;
SHOW TABLES LIKE 'wp_2860_ppfuture_workflow_scheduled_steps';
# Time: 2026-03-17T14:09:05.250572Z
# User@Host: wordpress_user[wordpress_user] @ localhost [127.0.0.1]  Id:  2383
# Schema: wordpress  Last_errno: 0  Killed: 0
# Query_time: 3.982953  Lock_time: 0.000003  Rows_sent: 0  Rows_examined: 439005  Rows_affected: 0  Bytes_sent: 187
SET timestamp=1773756541;
SHOW TABLES LIKE 'wp_2885_ppfuture_workflow_scheduled_steps';
# Time: 2026-03-17T14:09:05.352565Z
# User@Host: wordpress_user[wordpress_user] @ localhost [127.0.0.1]  Id:  2473
# Schema: wordpress  Last_errno: 0  Killed: 0
# Query_time: 4.978682  Lock_time: 0.000002  Rows_sent: 0  Rows_examined: 439005  Rows_affected: 0  Bytes_sent: 163
SET timestamp=1773756540;
SHOW TABLES LIKE 'wp_2998_ppfuture_actions_args';
# Time: 2026-03-17T14:09:05.765314Z
# User@Host: wordpress_user[wordpress_user] @ localhost [127.0.0.1]  Id:  2350
# Schema: wordpress  Last_errno: 0  Killed: 0
# Query_time: 3.729303  Lock_time: 0.000003  Rows_sent: 1  Rows_examined: 439007  Rows_affected: 0  Bytes_sent: 233
SET timestamp=1773756542;

What should have been a routine upgrade caused the whole network to slow down to a crawl. Downgrading the plugin to version 2.7.8 solved the slowdown problem.

I have one more question about the database tables in a multisite setup.

I can see that the plugin now uses two global tables: wp_top_ten_daily and wp_top_ten.

However, on some subsites where the plugin is active, there are also site-specific tables. For example, the blog with ID 5787 has two tables: wp_5787_top_ten and wp_5787_top_ten_daily.

From what I can tell, these site-specific tables are no longer used. I tested deleting them and it had no effect on the statistics for that blog or on the plugin’s functionality, since all the data appears to be stored in the two global tables.

My assumption is that an older version of the plugin used the per-blog tables, and the current version has migrated everything to the global tables.

Can you confirm that it’s safe to remove the wp_XXXX_top_ten and wp_XXXX_top_ten_daily tables for each blog?

Yes, the issue is still present on the latest version of the plugin 2.5.0 and the latest version of the Divi/Extra theme. Here is the error stack from the php-fpm log:

PHP Fatal error:  Uncaught ArgumentCountError: Too few arguments to function ET_Core_PageResource::save_post_cb(), 2 passed in /var/www/wordpress/wp-includes/class-wp-hook.php on line 324 and exactly 3 expected in /var/www/wordpress/wp-content/themes/Extra/core/components/PageResource.php:873
Stack trace:
#0 /var/www/wordpress/wp-includes/class-wp-hook.php(324): ET_Core_PageResource::save_post_cb()
#1 /var/www/wordpress/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters()
#2 /var/www/wordpress/wp-includes/plugin.php(517): WP_Hook->do_action()
#3 /var/www/wordpress/wp-content/plugins/admin-management-xtended/general-functions.php(191): do_action()
#4 /var/www/wordpress/wp-includes/class-wp-hook.php(324): ame_ajax_save_tags()
#5 /var/www/wordpress/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters()
#6 /var/www/wordpress/wp-includes/plugin.php(517): WP_Hook->do_action()
#7 /var/www/wordpress/wp-admin/admin-ajax.php(192): do_action()
#8 {main}
  thrown in /var/www/wordpress/wp-content/themes/Extra/core/components/PageResource.php on line 873

I think the problem is that save_post expects 3 parameters ($post_ID, $post, $update) while the plugin only sends two.

This is from the plugin (general-functions.php(191)):

do_action( 'save_post', $postid, $post );

It should be

do_action( 'save_post', $postid, $post, $update );

I successfully updated Prime Mover to 2.0.4. The plugin works, but the problem with excessive database queries remains.

UPDATE wp_sitemeta SET meta_value = ... WHERE site_id = 1 AND meta_key = 'fs_accounts'

Upon activation the plugin sends thousand of queries per minut. It’s always the same query shown above. It massively degrades performance of the DB server.

I tried uninstalling, reinstalling, upgrading, downgrading nothing worked. I finally solved the issue by manually deleting all Prime Mover options from the database.

Upon uninstallation some plugin files and DB entries are left behind. I uninstalled the plugin

wp-cli plugin uninstall --deactivate prime-mover

then manually deleted the remaining folders

rm -rI wp-content/uploads/prime-mover-export-files
rm -rI wp-content/uploads/prime-mover-lock-files
rm -rI wp-content/uploads/prime-mover-tmp-downloads

and finally the DB entries

DELETE FROM wp_sitemeta WHERE meta_key LIKE '%prime_mover%';
DELETE FROM wp_usermeta WHERE meta_key LIKE '%prime_mover%';

After deleting the DB entries and installing version 2.0.4 the plugin stopped spamming the queries. The problem has finally been solved.

The options prime_mover_in_progress_packages had a lot of entries even though no packages were in progress. Maybe that is what was causing the issue.

I can confirm that the issue was resolved by updating to 1.6.0.

Thanks for the update.

I was able to network activate Prime Mover 2.0.4. The export didn’t work. In the dashboard the progress stayed at 0%. This was in the logs, there was only one export running:

2025-01-29 08:58:56 => Logged common event for blog ID 57873 from Codexonics\PrimeMoverFramework\utilities\PrimeMoverComponentAuxiliary::restoreExcludedOptions method: DB LOCK: Not being able to move setting prime_mover_excluded_settings_db_57873 from user meta to options in prime_mover_shutdown_actions hook using user ID: 91722 because the value is not an array or empty.

Another issue that is unique to version 2.0.4 is that in slowed down our entire network. Response times went from 500ms to 7s as soon as the plugin was activated. The situation normalized once the plugin was deactivated. This was not a problem with 2.0.3.

Now we basically have 3 different issues:

1. Migration only works with versions up to including 1.9.9.
2. All version are flooding the database with queries as soon as the plugin is activated.
3. Version 2.0.4 significantly slows down the site.

I’m manly interested in the second issue related to the database.

I will send a support ticket with logs to the contact you gave above.

Correct. I have the latest version 1.16.0.