Email can be complicated, with lots of potential issues related to configuration, deliverability, etc.
To help with auditing emails that a site sends, including debugging and fixing any issues, we need a good email logging system. I think this is valuable enough for our target market to be included with ClassicPress, probably as a core plugin.
I’m imagining basically a custom post type with a lightly customized archive page, like a few meta fields about the email and whether it was sent successfully or not. This could also include an option to resend previous emails and an option to disable email sending entirely for local development, except for logging the emails that would have been sent.
WP Mail Logging – WordPress plugin | WordPress.org already does a lot of this.
Semi-related discussion and links to other related petitions here: ClassicPress emails not coming from admin email · Issue #363 · ClassicPress/ClassicPress · GitHub
In particular https://petitions.classicpress.net/posts/163/smtp-integration-settings-as-core-plugin would be a fairly natural tie-in here. It would be great if the SMTP settings used to send each email would also be saved as part of the archive metadata.
Read-only archive: https://petitions.classicpress.net/posts/190/add-email-logging-feature
Author: James Nylen
Vote count: 12
What is the current feeling on this? I have my own plugin that I use on every site to log emails. Not sure now if it should be part of core or stay plugin territory.
I think the more we add to core, the more we take off chances for plugin developers to do something.
The more we take away from core (or do not add to), not only we give chances for developers, but also make it leaner.
Thus my general take on these things is, if a plugin can do it (or a theme) then that should be done by a plugin or theme.
Core really should just focus on the CMS part, which is to communicate between the UI and the Database, providing a set of functionalities and hooks to interact with it.
Thus I think we should close this and other similar petitions as non-actionable, imo.
I did not see this is a proposal for a (core) plugin… I am not sure, but loudly thinking IMO Core plugins should be the things we take away that already exist in core. But then, if someone has time to create and maintain this officially, why not, since it wouldn’t be in core anyway, just a plugin that one could install or remove.
If you read above you will notice the op proposed that as a core plugin feature…
I think since an SMTP plugin dir CP exists, this logging feature can be added to that, if the plugin dev is willing to implement it?
yeah, jus saw it and updated the comment
Yes, I would vote for it as a core plugin too.
What is the definition of a core plugin?
I though that a core plugin is a core functionality that you take out of core so that the user can enable/disable it. Like the comments system or XML-RPC.
But if it never was in core before, is it not just a common plugin?
The idea in general of the logging functionality is good, I use one I built some time ago. But it is definitely not always needed. And as @anon66243189 said, probably other developers need other meta data or a different log UI, so keeping it as a standard plugin will allow diversity and freedom.
I was the original author of this petition, apparently. I’m fine with keeping this as a regular plugin.
As stated above, this should remain a plugin.
This topic was automatically closed after 3 days. New replies are no longer allowed.