Actually, if I deactivate and re-activate the plugin, the log then imports the old data and starts logging new events. So it looks like deleting the old tables isn’t required, but the updated process is not triggering the import of old data and allowing new tracking to work.
Still leaves old tables intact after importing and since the previous version wasn’t pruning old data, they could have grown to significant size for some.
Hi Endymion00,
Thank you for showing interest in our plugin.
It seems that we had some issues with the upgrade script, i.e. it wasn’t creating the tables upon upgrade. But as you said, upon deactivating and reactivating the plugin then the upgrade works (because the new tables get created etc).
Upon upgrading the plugin imports the old alerts from the old tables to the new tables and this time I can confirm that the auto pruning is working.
Since the alerts are imported, it is save to delete the 2 tables used by old plugin, which are:
wp_wordpress_auditlog
wp_wordpress_auditlog_events
While I am glad your issue is solved, do not hesitate to get in touch with us should you have any queries, and thank you for your support.
Just wanted to make sure you noted both issues I discussed and not just the database table creation on update issue. The 2nd issue was about the long page load time when loading another page after view the Audit Log when “Refresh Audit View” is set to “Automatic”. Setting it to “Manual” fixes the issue, but it seems there’s some issue with the new “Automatic” view.
I have been seeing the exact same issue and came up with the same fix (deactivating and activating again). Thank you for confirming that the old tables can be deleted afterwards.
Hopefully this will be fix in an update soon? 😉 I’ll also report another issue I’ve been seeing in another thread.