Hey guys,
I’m currently doing some cleanup work on a child site and noticed that there are two fairly large entries in the database related to MainWP.
wp_mainwp_child_changes_logs
Rows: 28,351
Size: 10.1 MiB
wp_mainwp_child_changes_meta
Rows: ~158,046
Size: 36.6 MiB
Where do these come from?
Is it a feature from these settings?
I only use the following four addons:
Hey @marowi
Welcome to the MainWP community.
Those tables are used for Network Activity (Site Changes) logs on the child site, which are then shown on the Dashboard > Sites > Network Activity.
It’s normal for it to grow, because it keeps a rolling history; by default MainWP keeps about 30 days and then cleans older records.
If needed, you can reduce retention (child site side) with this filter:
add_filter(‘mainwp_child_actions_saved_number_of_days’, function ($days)
{
return 14;
});
Filter can be applied manually on the Child site, or centrally from the Dashboard using our Code Snippets add-on.
Hi @bojan
thanks for your help!
I hadn’t even noticed the Network Activity tab yet. It’s kind of nice, but I don’t think I need it. Is there any way to turn it off completely?
Not at this time.
Currently, when you disable Network Logging on the Dashboard, it disables it only on the Dashboard side.
We are looking into tying this toggle to the logging on the child site side as well. So in the future, the user who don’t want to have any logging on the child site, would just toggle this off.
That would be great. Thanks! 
Hi @bojan, sorry to hijack this thread, but I’m seeing the same pattern across all of my sites: after upgrading to the latest MainWP Child version (6.0.0) on February 25th, the wp_mainwp_child_changes_logs and wp_mainwp_child_changes_meta tables have started to grow exponentially across all of my sites. On some of my more active WooCommerce sites, the wp_mainwp_child_changes_meta table has now got over 16.000.000 records (!), totalling 2.6GB in size, and we’ve not even reached the 30-day truncation moment. This definitely wasn’t happening before the 6.0 version.
We’ve added more logging data points in v6.0, which explains the increased growth.
Right now, the Network Activity logging cannot be completely disabled on the Child Sites. However, the retention period can be shortened as explained earlier in this thread.
I am currently testing a shorter retention period of 14 days on a website.
Using the recommended code snippet:
add_filter('mainwp_child_actions_saved_number_of_days', function ($days) {
return 14;
} );
It’s still growing right now. Even though I have a server-side cron job that runs every 5 minutes. I’ll keep an eye on it for a while longer.
Hi @marowi ,
Please check `/wp-admin/admin.php?page=SettingsInsights` and disable all the log items you’re not interested in. Especially the Cron logs at the bottom of the list can generate a lot of rows.
Just to clarify.
Does what’s selected in the Dashboard under Network Activity Settings affect what gets logged on the child sites? Or is everything always logged on the child sites, and the settings are just there to show or hide certain things in the Dashboard?
If I can use this to control what gets logged on the child sites, then I’ll go ahead and remove a few non-essential things.
I’m not sure about that, but at least it will help to stop growing the MainWP Dashboard’s database.
You’ll have to check what’s in the database on the child site to see if that needs cleaning. I’m managing 330+ sites and haven’t had serious issues yet with databases on child sites that became a problem. But once in a while I’ve optimized those mainwp tables to free up some space. My issue was mainly on the dashboard’s database.
Ah okay.
I was actually more concerned about child sites. With WooCommerce sites, things can really pile up quickly. But I just tested it by disabling “Viewed a post” in the Network Activity Settings and then no more events were logged for that on the child site. So I’ll go through these settings and remove some of them I don’t need.
Good to know!
When I see large tables, I often make queries that count the records per type or something, so I can see what the main cause is and if that can be optimized.
I’ve been testing the snippet above for a few days now, and it works.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.