On my main page I found this new widget with Site Changes. What’s the purpose and isn’t this a performance drain, as it looks like it’s loading 1M+ records for my 300+ sites. When I click on that number I get to the InsightsManage page where I can search and filter, but there it “only” shows 10,555 records (for this month).
This seems to have replaced the Non MainWP Changes widget. Is that correct? Where can I find that, because it much more interesting to see what a client installed/removed instead of that I synced the data for all sites.
yeah, the Non-MainWP Changes widget got updated so it shows both changes from Dashboard and Non-MainWP Changes. In the Source column you can see where is the change made from.
In the bottom of the widget, it shows the total number of changes that are logged, but the widget does not load ALL that data.
Table data is loaded page-by-page via AJAX loading, so it should not hit the resources heavily.
ON the other hand, I do see that users might like to see only Non-MainWP changes or only from Dashboad changes, so we can add an option for that
2 Likes
I’d really love that, because now I need to find a needle in a haystack, when I don’t even know there even is a needle.
And the same query is run on the single site pages, so it’s showing the data for all sites there instead of only those for that specific site.
1 Like
In version 5.4.0.1 the default is Non MainWP Changes, but it only shows changes from today, while there are a few more from the last days. Please remove the day filter.
On the overview page the records don’t fit in the column anymore and I can’t mark them as OK (ignore…)
1 Like
I’ve reproduced this on my end. The widget is only displaying the logs from the current day. We will have this changed in an upcoming release.
We’ll also bring back the Ignore/Dismiss button.
1 Like
When clicking the All changes button it goes to /wp-admin/admin.php?page=InsightsManage and has issues to load the data. It’s showing a loading icon for a while and ends with a DataTables warning:
How can I cleanup all the dashboard changes and just keep the Non-MainWP changes? Maybe this is not an issue with just a few sites, but with 300+ it clearly is.
You would have to filter the changes down to Dashboard as a source, and then select large enough date range to encompass them, then select them all in the table and then click Dismiss Selected Changes.
You may face similar issues even then if there is a large number of changes.
So you would either need to select shorter date ranges and do so multiple times.
Or perhaps, delete them directly from the DB using a SQL query.
Can you tell me more about the database structure? I see 3 tables that appear to be involved:
wp_mainwp_wp_actions: 9878 records, 2.5 MB
wp_mainwp_wp_logs: ~83960 records, 54.2 MB
wp_mainwp_wp_logs_meta: ~114316 records, 13.5 MB
1 Like
wp_mainwp_wp_logs: Site Changes logs (Dashboard and Non-MainWP changes)
wp_mainwp_wp_logs_meta: Sites Changes logs
wp_mainwp_wp_actions: Old data for Non-MainWP changes logs
Non-MainWP Changes stored into the tables wp_mainwp_wp_logs & wp_mainwp_wp_logs_meta with: connector= ‘non-mainwp-changes’
Dashboard Changes stored into the tables wp_mainwp_wp_logs & wp_mainwp_wp_logs_meta with: connector != ‘non-mainwp-changes’ AND connector != ‘pro-reports’
Will the wp_mainwp_wp_actions table be removed with a future update or do I have to do that myself? I guess it’s not used anymore.
Can we do something about the large number of records in the other tables based on the usage? I’m only interested in the non-MainWP changes and I guess it would benefit performance if the other records were not stored (for 300+ sites).
Are records in these tables purged after a certain number of days or are they kept forever?
1 Like
I cannot comment on the exact plans but It will likely be removed in a future update. It is safe to remove it manually if you want.
We have a filter for that will disable Dashboard changes logging while keeping Non-MainWP Changes logging enabled:
add_filter( 'mainwp_module_log_check_connector_is_excluded', 'mycustom_mainwp_module_log_check_connector_is_excluded', 10, 3 );
function mycustom_mainwp_module_log_check_connector_is_excluded( $is_excluded, $connector_name, $excluded_connectors ){
if( 'non-mainwp-changes' !== $connector_name ){
return true;
}
return $is_excluded;
}
At this time, they are kept forever. The team has added a hook to enable some dev features in the Settings for deleting the logs. It looks like in the image below.
I can send you this dev version of MainWP Dashboard via a DM if you wish.
I’ve removed the table now.
Do I understand correctly that these functions make that I don’t need the snippet? Or is that an “all or nothing” setting? In that case I’ll add the snippet.
I’m happy to test the dev version. You can send it to me via Discord or DM.
If you want to use those options in the dev version of the Dashboard then you don’t necessarily need to use filter.
I am sending you the Dashboard with those options.
1 Like
Hi Bojan,
With the dev version my database is growing very fast. The meta table has grown from 114K records to 4.59M records
I’ve run a query to count the meta_key records and these are the keys with more that 5K records.
| meta_key | count |
|---|---|
| user_meta | 1035727 |
| site_name | 1030136 |
| siteurl | 1030136 |
| item | 961457 |
| name | 161195 |
| version | 160521 |
| extra_info | 158413 |
| user_meta_json | 92941 |
1 Like
The team doesn’t think that the dev version of the Dashboard I sent you should have impacted the number of logs being generated.
From what I understand, the log growth has been fine in the latest stable v5.4.0.5 release?
If you wish, I can send you via a DM a new dev Dashboard version that adds some monitoring for Sites Changes DB to the Custom Event Monitor page.
Of course the tables are growing a bit, but not so extreme as earlier this week. So they might not think that the dev version caused it, but what then? I didn’t do anything special that caused that much logging.
I’m happy to test a newer dev version, as long as I get some more info about what it does, so I know what I’m testing. Let’s do that via DM.
1 Like
Thanks for testing the latest dev version @josklever.
To update the rest of the community - the extreme DB growth was happening only with a dev version of the Dashboard that had some dev options exposed and that likely contributed to the growth.
The issue was not present in a subsequent dev version.
Regardless of that issue with the dev version, the development team will take a comprehensive look into optimizing the Site Changes functionality to minimize the expected/normal DB growth for users with large number of sites.
At this time, we don’t have an exact ETA on those optimization changes.
1 Like
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.