Auto delete logs not working

Hey @jcornell, thanks for the report. I’ve managed to replicate the issue my end and a fix will be in place for the next update (v1.5.3)

I’ve just pushed a new version (v1.5.3) which should resolve this issue

@wardee I installed v1.5.3 on Monday morning and now 48 hours later, the logs still date back 6 months instead of 4 weeks as desired.

Hi @jcornell, I need more information to replicate this my end, everything is working as expected for me. As I understand the issue is that logs from 6 months back are not being cleared despite the option in the settings page being set to 4 weeks.

Can you try disabling the auto delete functionality by selecting “no”, save the settings page. Afterwards re-select “yes” set the interval to 4 weeks and save the settings again and see if this resolves the issue.

Rather than waiting for it to re-trigger you can install a plugin like WP Crontrol, look for the cron task (it’ll have mail catcher in its name) and trigger it to run immediately, rather than waiting for it to trigger at the end of each day.

Also does anything come up in your errors logs?

I changed the plugin settings as you suggested. I also triggered the cron task manually using the WP Crontrol plugin. The problem remains.

I don’t know where to look at error logs to see if any relevant messages are there.

Hi @jcornell, I’m afraid without any method of being able to replicate the issue I can’t help. If you find exact steps to recreate the issue then do let me know and I’ll take a look

I ran the wp-cron task for this in one of test sites with DEBUG on and got the following log message:

[07-Jul-2021 18:49:36 UTC] WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‘)’ at line 2 for query DELETE FROM wp_mail_catcher_logs
WHERE id IN() made by do_action_ref_array(‘wp-mail-catcher_0’), WP_Hook->do_action, WP_Hook->apply_filters, WpMailCatcher\ExpiredLogManager::removeExpiredLogs, WpMailCatcher\Models\Logs::delete

Thanks for this, it looks like it’s complaining because it’s trying to delete 0 logs this needs to be resolved but I don’t think it’ll fix your issue – I’ve added this to the GitHub issue and it will be resolved in the next update. If you find out any further info let me know.

There were no emails logged in this test environment so that explains why there were none to delete.

I created two emails there which were logged by your plug-in. I then waited two weeks, changed the setting to delete logs over 1 week old, and re-ran the cron event. The two emails logged were deleted as they should have been.

Back to the problem environment in which it is not working, with now 2204 emails logged over the last seven months. I hesitate to turn on debug in this environment because our users access it at all hours and I don’t want to disrupt them. Is there another way to see what might be happening to prevent the deletions?

There must be a specific email or group of emails that’s causing the issue. The best option is to get a backup of the live database, install this to your local and then test which emails are causing the issues there. If you can recreate the email causing the issue that would be a massive help in resolving it

I’ve manually deleted older rows from wp_mail_catcher_logs table gradually over the last few days. The oldest row now is from 7/21/2021 which means all of the rows there now were created after I first reported this problem and after I updated to version 1.5.3 on 6/28/2021. And I have the setting to delete everything older than 1 week and still nothing is getting deleted. So it seems that the data in the table is probably not the problem.

I also compared the table structure to the one in our test environment where the email log deletions work successfully. They appears the same.

Do you have any other suggestions?

If it works on one instance but not another then there is possibly an issue with your infrastructure. I’d suggest hiring a developer to investigate further, if there is an issue that can be replicated on a fresh WordPress install then please log it on our GitHub tracker