It would be awesome to have a cron job to automatically delete logged emails after a specific amount of time

What WordPress, PHP and Simple SMTP versions are you using?
Simple SMTP 1.2.3

Describe the bug
The custom post type to store logs uses default capability type with no additional capabilities.

Expected behavior
The capability required to view/delete logs should be related to an admin role, for example manage_options.

What WordPress, PHP and Simple SMTP versions are you using?
WordPress 5.8.1 Multisite, Simple SMTP 1.2

Describe the bug
The labels of the site table is not localized with __()
If applicable, add screenshots to help explain your problem.

What WordPress, PHP and Simple SMTP versions are you using?
WordPress 5.8.1, Simple SMTP 1.2.0.

Describe the bug
Checkboxes are missing the label element.

With an input label the clickable area is enlarged and the user knows better what the option do. Clicking on label marks the checkbox.

This requires the function settings_field_generator in class-settings.php to accept one more optional argument that hold the label text. Don't know the preferred way for this is.

Steps to reproduce
Steps to reproduce the behavior:

1. Go to /wp-admin/options-general.php?page=wpsimplesmtp and see all checkboxes

Expected behavior
Something similar this e.g. /wp-admin/profile.php with the structure
<label for="input-id"> <input name="input-id" type="checkbox" id="input-id" value="false"> Mark this to do this </label>

Screenshots
Default with no description

Yoast SEO with description

Some general improvements for use cases when the plugin has been network activated on a multisite. To be clear, the plugin works fine on Multisite, but this is to give some extra benefits for doing so.

A regular admin cannot change a site URL, so why would it mess with the email setup? It would be good to give network administrators the ability to disable the capability for regular site admins, and only allow the super admins to control it.

• Permit super admins to restrict email configurations.
• Overarching override (e.g. set the mail server, but leave the site admin to configure name etc).
• Global email log view.

PHPMailer has support for the OAuth authentication type, but this is not in-turn supported by the GUI or input options found in this plugin. TLS is still the primary way of authenticating with SMTP servers, but there's a growing trend with bigger corporate networks to require OAuth authentication where possible, including with SMTP servers.

Placing this issue here as a guider to work on the OAuth implementation. I'd also appreciate if anyone seeing this ticket could list off a few SMTP services that support OAuth too, and any Docker OAuth SMTP containers I can add into the CI process would be fantastic.

https://github.com/PHPMailer/PHPMailer/wiki/Using-Gmail-with-XOAUTH2

Side note: I'm aware the industry standard is slowly becoming APIs for dispatch. Unless a major shift is upcoming I feel adding API services will be a big shift from the 'simple' approach this plugin takes, as it will soon complicate things by needing additional libraries pulled in and custom functionality. Most, if not all, providers still provide SMTP options at this point in time and so will not be on the roadmap for inclusion.

Nice to have that in the unlikely event the encryption keys are regenerated, an alert is shown to the administrator that the password needs to be set again.

In general the Travis CI and the general testing process needs to be rethought due to the main unit testing depending on Docker, but will cross that bridge later since it 'works'.

The compose file currently hard-depends on PHP 7.4, and the plugin page claims compatibility of PHP 7.0 upwards. Instead of testing every release of the plugin, the CI server should verify the tests against each version of PHP to quickly rule out additional codes that could cause compatibility problems.

e.g. I have a preference for strict mode PHP, which would depend on PHP 7.3 or higher. If I slip and use strict typing, it will break the plugin on old PHP sites.

• Move from Travis CI to GitHub Actions.
• Improve test case coverage.
• Consider adding PHPCS to the CI process?

What WordPress, PHP and Simple SMTP versions are you using?
e.g. WordPress 5.8, PHP 8.0, Simple SMTP 1.1.2 & 1.2 beta.

Describe the bug
Found in PR-43 - #43 (comment)

A notice error is generated when you save the settings page, where the password field has been over-ridden by a higher purpose.

Steps to reproduce
(with DEBUG_MODE set to true).

1. Generate a MS instance, network activate the plugin.
2. In Network Mail, set a password (tool used in this was mailtrap.io).
3. Go into a child site SMTP settings.
4. Save the settings page.

Expected behavior
The settings page saves (problem only occurs when debug mode is on).

What WordPress, PHP and Simple SMTP versions are you using?
e.g. WordPress 5.6, PHP 7.3, Simple SMTP 1.0.0. The more, the better.
Newest, upgraded.

Describe the bug
A clear and concise description of what the bug is.
Multisite site admins can see email password in plain HTML.

Steps to reproduce
Steps to reproduce the behavior:

1. Log in as site admin in WP multisite install
2. go to subsite mail settings page: /wp-admin/options-general.php?page=wpsimplesmtp
3. Inspect source (view HTML)
4. See password in clear text as input value=""

Expected behavior
A clear and concise description of what you expected to happen.
Password is already stored in database, and site admin mail settings is greyed out - no need to fill input fields.

Screenshots
If applicable, add screenshots to help explain your problem.

Each commit is currently being tested against mailtrap. While this works well enough for the main repository builds, PRs made from external repositories (as experienced by Kebbet) will fail each build, as they do not have these settings in their own repository secrets. Since the docker-compose instance this project comes with contains an SMTP mocking service, it would make much more sense to adjust the build process to run against this instead. This will mean PRs and forks will be able to run per-commit and PR tests just fine.

EDIT: Correction - The build process does not currently use docker-compose.

At work I was assigning user accounts en-masse when I became suspicious a site was connected to the wrong mailserver. It hit me at this point a really useful feature to have would be the ability to send a test email via WP-CLI.

This can be expanded to multiple different facilites, such as:

• Sending test emails (#66).
• Checking/setting configuration.
• Retrieving the log (#66).
• Reading emails (#82).

The decision made to go via custom tables works perfectly. However, it's not necessary to do it this way. It would be more system-beneficial to store the logs as a hidden custom post type instead.

Would be nice to allow users to adjust number of log entries in the table via WordPress filters. Will try a POC.

Mistakenly thought this was due to #61. When the multisite settings have been configured, but no changes are made in the local site admin, an error is thrown in the email log.

Could not instantiate mail function.

This is due to a faulty check for no configuration during the email dispatch in class-mail.php:79. Since the multisite options are set, but local settings are not, the settings do not reach the PHPMailer configuration.

Should have an option to switch off dispatch.

What WordPress, PHP and Simple SMTP versions are you using?
e.g. WordPress 5.8.1, Simple SMTP 1.2.0.

Describe the bug
The table layout is a bit off, see screentshot. PR #49 fixes this. Should be handled together with #45 so all strings are possible to translate as well.

WordPress provides a tool for looking/erasing personal data stored about individuals. It would be beneficial if the tool was able to locate emails inside the log that reference these individuals and remove or redact their personal information.

Side note: The tool should check regardless of the logging feature status, in case logging is disabled but a historical log is still present.

The default log mode view is 5-per-page, which is too small for general inspection and usage. The default should be increased to 20 to balance a decent view of the log, with not causing the page to be too extensive.

What WordPress, PHP and Simple SMTP versions are you using?
Simple SMTP version 1.2.3

Describe the bug
The following files should not be part of a release

• .distignore
• package.json
• package.lock

What WordPress, PHP and Simple SMTP versions are you using?

• WordPress 5.8.2
• Simple SMTP 1.2.3

Describe the bug
I have noticed the logs are still in the database after having uninstalled the plugin

Steps to reproduce
Steps to reproduce the behavior:

1. Enable logs
2. Send some emails
3. Disable and remove the plugin
4. Reinstall the plugin
5. Look at the logs

Expected behavior
All plugin data, including logs should be deleted.

What WordPress, PHP and Simple SMTP versions are you using?
WordPress 5.8.1, Simple SMTP 1.2.2

Describe the bug
Clicking labels for checkboxes does not work, for parameter should contain the ID for the input field. Sorry for a late find, just tried the latest version.

Steps to reproduce
Steps to reproduce the behavior:

1. Go to '/options-general.php?page=wpsimplesmtp'
2. Click on 'any checkbox label'

Expected behavior
Checkbox should be ticked. It is not.

Screenshots
If applicable, add screenshots to help explain your problem.

Report in from this WordPress support message - the Log viewer table does not display correctly on mobile.

Hello! Firstly thanks for this plugin, much nicer than all the bloat of WP Mail SMTP etc.

One little problem we've had is that we need to be able to set the SMTPSecure setting on the PHPMailer instance for authentication to work. For now I've hacked the following in below line 83 in class-mail.php

$phpmailer->SMTPSecure = 'ssl';

I believe the value of SMTPSecure can be ssl or tls but I haven't really looked into it.

It would be great if this was configurable, we use the wp-config.php defines but I guess it should be a UI option too. I'm happy to try to submit a PR when I find a moment if that is useful?

This plugin pulls information from this repo. if you wish to see a setting appear or noticed a suggestion from Quick Config is incorrect, open an issue in this repository instead.

https://github.com/soup-bowl/wp-rest-api-smtp-sources/issues/new/choose

What WordPress, PHP and Simple SMTP versions are you using?
develop-branch

Describe the bug
Running docker compose up -d returns

The terminal process "/bin/zsh '-c', 'docker-compose -f "docker-compose.yml" up -d --build'" terminated with exit code: 18.

Steps to reproduce
Steps to reproduce the behavior:

1. Get a M1 Apple computer
2. Clone repo
3. Run docker compose up
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots

References
Maybe a help link, I will try switching to MariaDB.
https://stackoverflow.com/questions/65456814/docker-apple-silicon-m1-preview-mysql-no-matching-manifest-for-linux-arm64-v8

WordPress Core is planning on moving to PHPMailer 5.5 to 6. Best to keep track of this (and push for development once in edge) so that the unit testing - and future releases - are correct.

The ticket, the plan, and the code.

What WordPress, PHP and Simple SMTP versions are you using?
WordPress 5.8.1, Simple SMTP 1.2

Describe the bug
The line breaks in e-mails are missing when viewing sent mails from the log.

Steps to reproduce
Steps to reproduce the behavior:

1. Send an e-mail with line breaks. Just the standard ”Plugin has been auto updated” should do it.
2. Go to log table
3. Click ”View” for the sent e-mail
4. Compare line breaks between e-mail and the log entry.

Expected behavior
The log entry should display the line breaks.

Screenshots

What WordPress, PHP and Simple SMTP versions are you using?
WordPress 5.6.2, PHP 7.4.15, Simple SMTP 1.1.

Describe the bug

An error of type E_ERROR was caused in line 29 of the file <scrubbed>/wp-content/plugins/simple-smtp/src/mail/class-maildisable.php.
Error message: Uncaught Error: Class 'PHPMailerPHPMailerException' not found in <scrubbed>/wp-content/plugins/simple-smtp/src/mail/class-maildisable.php:29
Stack trace: 
#0 <scrubbed>/wp-includes/pluggable.php(498): wpsimplesmtpMailDisable->send() 
#1 <scrubbed>/wp-content/plugins/simple-smtp/src/mail/class-mailtest.php(110): wp_mail() 
#2 <scrubbed>/wp-includes/class-wp-hook.php(287): wpsimplesmtpMailtest::test_email_handler() 
#3 <scrubbed>/wp-includes/class-wp-hook.php(311): WP_Hook->apply_filters() 
#4 <scrubbed>/wp-includes/plugin.php(484): WP_Hook->do_action() 
#5 <scrubbed>/wp-admin/admin-post.php(70): do_action() #6 {main} thrown

Steps to reproduce
Steps to reproduce the behavior:

1. Install Simple SMTP on vanilla install.
2. Check 'disable emails'.
3. Send a test email.

If all the SMTP credentials are saved in the admin interface and a database occurs, the hacker will have all the necessary credentials to send fraudulent emails.

Proposal to encrypt the password in the database, as it would then require extensive tools or hacking the filesystem to get the SMTP credentials.

Note to self to add a new deployment process to check exclusively for readme changes of the project root, so that for readme updates and changes to the tested status don't require a new version tag to be launched, or manual intervention with the Subversion repository.

Related: https://github.com/10up/action-wordpress-plugin-asset-update

There's a growing trend with some sites to install plugins found on open development platforms instead of via the WordPress plugin site. I have no plans to stop the Codex variant of the plugin, but with a minor change to the plugin file & CI/CD process it should be possible to provide builds via this GitHub repository alongside the WordPress plugin store.

There's two Git-based plugin installers - Afragen's and Radishconcepts - that I'm aware of that can have supported baked in. I can adjust the pipeline to drop a zip copy of the plugin into the release directory, which should then (ideally? Need to read up) pick up in the updater processes.

The version number is currently 0.3.5, which implies this project is in pre-alpha status. Considering the main version has been stable for quite some time, and the plugin is being used in production environments, it may be worth considering jumping ahead to version 1.0.0.

Presently, the log will continue to log indefinitely. An option to purge the log would be good to clear the log of so many entries, and also the ability to delete specific logs.

The strings in smtp-config.js is not translated in the UI.

Some helpful links.

• https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/#handling-javascript-files
• https://developer.wordpress.org/apis/handbook/internationalization/#internationalizing-javascript

The code segment recommendation for disabling the log auto-delete does not render correctly post-md.

The SMTP quick selection dropdown has vanished.

The cause of this is that my server (soupbowl.io) has undergone a CMS change, and in the process this has blindly broken the password selector. The endpoint is no longer available.

Options are:

1. Provide a new endpoint for the option selector.
2. Remove entirely based on usage (personally discovered this to be more of a hinderance than any actual benefit).

Essential plugin functionality not impacted.

WordPress 5.9 is due for release 25th Jan 2022. Will be good to give the plugin a good test before marking it was 5.9 compatible prior to the full release, to help assure updaters that the plugin will work.

Latest changes in Core appear to be to upgrade the library to PHPMailer 6.5.3.

Since logging was added, there's now been a few additional requests for functionality tailoring.

• Issue #57 for allowing users to change the log pagination.
• Issues #70 and #71 about purging logs.

It may now be a good time to add configurable options to the log viewer, to let people set their configuration choices via the GUI. A first-pass mock-up could look like this:

(Considering splitting the latter two under a seperate heading since the pagination count could be changed into a user variable instead of a system one).

Thoughts welcome.

Suggestion, use network_admin_url instead of admin_url( 'network/… in class-multisite.php

WordPress 5.7 is due for release on 9th march 2021. It's highly unlikely this plugin will break from that update but the supported version will need incrementing, so this is a note to human-test the current production release on the upcoming version.

If 5 entries are logged, the pagination will suggest that there's another page. This obviously displays nothing as there's nothing past it.

I've added the ability to adjust a custom HTML page, inside the plugin directory. This was a short-sighted addition as each plugin update will replace this file.

The feature can be kept by checking for a file outside of the plugin directory (e.g. in wp-content), however it might be better to deprecate this feature. Nobody really needs a custom email test, as it's designed just to check the server is working.

Once removed, the HTML email test can use the same text strings that the plaintext dispatch does.

Kebbet on the WordPress support forum has pointed out that the text domain differs from the WordPress repository slug. This means the translations will fail to deploy as they'll match the wrong plugin.

https://wordpress.org/support/topic/take-version-to-stable/#post-13947742

What WordPress, PHP and Simple SMTP versions are you using?
develop branch

Describe the bug
Can not activate plugin in dev environment. What am I missing?

Steps to reproduce
Steps to reproduce the behavior:

1. run docker compose up
2. Set up WP.
3. Go to Plugins
4. Try to activate the SImple SMTP-plugin.
5. See error message

Warning: require_once(/var/www/html/wp-content/plugins/simple-smtp/vendor/autoload.php): failed to open stream: No such file or directory in /var/www/html/wp-content/plugins/simple-smtp/wp-simple-smtp.php on line 32 Fatal error: require_once(): Failed opening required '/var/www/html/wp-content/plugins/simple-smtp/vendor/autoload.php' (include_path='.:/usr/local/lib/php') in /var/www/html/wp-content/plugins/simple-smtp/wp-simple-smtp.php on line 32 

Expected behavior
Thought the plugin could be activated.

Screenshots

Discovered while investigating #61. The password encryption routine does not impact the settings found in the multisite. Since they run a seperate update settings routine that's not directly handled via the WordPress core, the update hook does not take the middleware action of encrypting the password before storage.

Uncaught TypeError: document.getElementById(...) is null
    wpss_load_quicksettings https://name.tld/plugins/simple-smtp/smtp-config.js?ver=1.1:32
    wpss_loadin https://name.tld/plugins/simple-smtp/smtp-config.js?ver=1.1:18
    jQuery 9
    wpss_loadin https://name.tld/plugins/simple-smtp/smtp-config.js?ver=1.1:15
    <anonymous> https://name.tld/plugins/simple-smtp/smtp-config.js?ver=1.1:103
smtp-config.js:32:28

A check if the table exists inside the wpss_loadin before the API-request is done should fix it.

The current log scrapes emails and their headers, but discards storing their attachments. This is a fundamental feature for sites such as WooCommerce shops that would be dispatching receipt, invoice and/or products via attachments. Currently if an email needs to be resent with attachments, it would need to be re-processed.

There exists a warning on the installation page to inform a potential user that this is not implemented, but I'm leaving this ticket here as a reminder to... Well, actually implement it.

When a test email is sent, there’s no feedback from the UI when the logs are turned off.

I think a notification would be helpful for both success and error, whether logs are enabled or not.

Note: notifications are used when you resend a logged email.