Oh, thanks @antipole for the message!
I’m taking a look into the Log emails plugin code and will try to help.
G’day @kubitomakita,
Log Emails plugin author here. My plugin currently uses a CPT for email logs. Current release saves them with post_status ‘publish’, here’s a version that uses a custom post_status instead:
https://www.dropbox.com/s/kzfh0tpv4syqtna/log-emails-1.3.0-dev.zip?dl=1
That works for a notification I tried where the trigger was on published post. Haven’t tried with other triggers, but it sounds like it didn’t help antipole.
My ultimate solution is to move to a custom table, which is on my TODO list but probably won’t happen until later this year. Is there a filter hook we can utilise to exclude my CPT from triggering notifications?
cheers,
Ross
Hi Ross,
I was looking at your plugin’s code and haven’t found anything that could cause the issue. The post status doesn’t matter because there’s also the post type tested.
I installed Email Log plugin and found out that postponing the actions in my triggers is causing this.
Here’s what happens. The Notification trigger is listening to an action, ie. post_updated. It sets up all the variables and postpones the execution to save_post action. But in the meantime, your plugin is adding another post calling the save_post action. The Notification trigger is called again, invokes the phpMailer and here we go again.
I tried to patch it in my plugin but I failed. Potentially you could patch it in your plugin, but I also tried and it’s not so easy. Also doesn’t feel like a proper solution.
I’d need to think about it more as this issue could be related to other issues I have, like duplicated notifications.
G’day Kuba,
Yes, it appears that the post type is not being tested when triggers are processed, so any posts created on a trigger get caught by the hooks you have set up on the initial post. Perhaps storing the post ID of the post you’re processing could help — i.e. you see a post being created / updated, check its post type, save its post ID, then your triggers only process for posts of that ID.
cheers,
Ross
Ross, that would definitely help but I think I need something more robust. Checking the ID would mean edit of each and every trigger and a requirement to write that checks for every future trigger.
I was thinking about unhooking the actions, but it doesn’t seem to work. Will figure it out.
This has gone a bit quiet. Can @kubitomakita or @webaware kindly let me know where this is headed?
If no solution is in the works, I may have to look for other approaches.
thanks
G’day antipole,
I’ve done all I can, short of the planned rewrite to replace the CPT with a custom table. That’ll happen but probably not until December. If Kuba can’t restrict his plugin’s actions to specific post types, then your best bet is to use a different email logger that does’t store data in a CPT.
cheers,
Ross
On my end, the fix is not an easy thing too. It alters the very core of the plugin and there’s a big risk, so I cannot rush this. Will be definitely a subject of the next release but when it will be don – it’s very hard to say.
I have been trying to use this plugin because the Pending Submission Notification plugin seemed to be no longer working and seems abandoned.
Having spent the day trouble-shooting Pending Submission Notification I have discovered I had set an invalid email address for delivery. Having corrected this, it is working fine for me. [Yes, I am very embarrassed by this error!]
Anyhow, I no longer need to fall back on this notifications plugin and withdraw my request for a solution to the problem discussed above. Of course, the underlying issue remains, but please do not sweat about it on my behalf.
Many apologies for the trouble caused to @kubitomakita and @webaware and thank you for your attention and investigations.
No worries, it made me clean up some code and recommit to moving from a CPT to a custom table. All good.
cheers,
Ross
Just to let you know, the notification logging will be implemented in the core plugin.
Thanks for your time guys!
