10up / simple-new-post-emails

Allow site members to check a box and get new posts via email. Includes a widget.

Simple New Post Emails

Allow site members to check a box and get new posts via email. Includes a widget.

Description

Allow site members to check a box and get new posts via email. The checkbox appears on the user's profile, as well as an optional widget for your site. Works especially well for intranet sites.

User profile option

Widget in Twenty Eleven

Requirements

• WordPress 3.0+

Installation

Simple New Post Emails is most easily installed automatically via the Plugins tab in your dashboard. If other WordPress emails do not send from your installation, neither will these.

Frequently Asked Questions

Where are all the configuration options?

The premise of this plugin is to keep things as simple as possible, particularly in the UI and UX. There are many other great plugins available that provide more functionality (typically with the cost of a more complex user experience), as well as email newsletter services. Some configuration is possible via hooks. If a hook isn't available to accomplish what you need, please open an issue on GitHub.

Support Level

Archived: This project is no longer maintained by 10up. We are no longer responding to Issues or Pull Requests unless they relate to security concerns. We encourage interested developers to fork this project and make it their own!

Changelog

A complete listing of all notable changes to Simple New Post Emails are documented in CHANGELOG.md.

Contributing

Please read CODE_OF_CONDUCT.md for details on our code of conduct, CONTRIBUTING.md for details on the process for submitting pull requests to us, and CREDITS.md for a listing of maintainers of, contributors to, and libraries used by Simple New Post Emails.

Like what you see?

simple-new-post-emails's Issues

wp_mail call fails silently

I noticed in testing for 5.0 that the call to wp_mail in send_mail at https://github.com/10up/simple-new-post-emails/blob/master/simple-new-post-emails.php#L161 is failing silently when $to is empty, which is the default. Digging deeper, an empty check in wp_mail's processing appears to have been added in https://core.trac.wordpress.org/changeset/38058.

I think this means the plugin has been effectively broken for a few years. Womp womp.

I suspect broadly handling a false result from wp_mail is not going to be simple, but we can at least set a default to header value.

Add filter docs

Test against WordPress 5.9

Is your enhancement related to a problem? Please describe.

Is your enhancement related to a problem? Please describe.

Describe the solution you'd like

• test WP New Relic on WordPress 5.9
• open issues for any incompatibilities noted in testing
• resolve issues identified in testing
• bump "tested up to" version
• if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
None

Additional context

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Enable admin to configure to address

Given use of the bcc:, there has to be a valid to: address - but using the default (currently pulls the admin email address) may not be ideal.

Not sure if this should be an option (decisions not options and all) or perhaps a filter?

Release version 0.7.1

This issue is for tracking changes for the 0.7.1 release. Target release date: TBD.

Release steps

• Branch: Starting from develop, cut a release branch named release/0.7.1 for your changes.
• Version bump: Bump the version number in simple-new-post-emails.php and readme.txt if it does not already reflect the version being released.
• Changelog: Add/update the changelog in CHANGELOG.md and readme.txt.
• Props: update CREDITS.md file with any new contributors, confirm maintainers are accurate.
• New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .gitattributes.
• Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
• Merge: Make a non-fast-forward merge from your release branch to develop (or merge the Pull Request), then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
• Push: Push your trunk branch to GitHub (e.g. git push origin trunk).
• Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone. The release should now appear under releases.
• SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
• Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/simple-new-post-emails/. This may take a few minutes.
• Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
• Punt incomplete items: If any open issues or PRs which were milestoned for 0.7.1 do not make it into the release, update their milestone to 0.8.0 or Future Release.

Only show widget to logged in users

Because this plugin was originally developed for an intranet, I failed to notice that logged-out users will still see the widget, even though it's currently useless for them.

Test against WordPress 5.8

Is your enhancement related to a problem? Please describe.
Once WordPress 5.8 is released, we'll want to test Simple New Post Emails to see if any incompatibility issues arise.

Describe the solution you'd like

• test Simple New Post Emails on WordPress 5.8
• open issues for any incompatibilities noted in testing
• resolve issues identified in testing
• bump "tested up to" version
• if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
none

Additional context
Related: #29, #38.

i18n

Currently nothing is set up for localization. We should fix that.

Better handling for large numbers of users

Right now the email is sent to each user via BCC, with a separate header item set for each. There are various limits that may become problematic: line length per RFC2822 (not sure if PHPMailer sets each header array item to a new line or implodes/concats all on one), mail server limitations on number of BCCs, and anecdotes about BCC emails remaining in queue until all deliveries are complete, with errors triggering a re-send even to already-completed deliveries.

Two thoughts: we could batch addresses for BCC lines to save on the repeated Bcc: characters, and we can make any changes that need to be made to support batch sending.

readme updates

• add version badge
• add support level section and badge
• add license badge
• add tested up to badge
• add readme.txt
• move changelog to its own file

Test against WordPress 5.6

Is your enhancement related to a problem? Please describe.
Once WordPress 5.6 is released, we'll want to test Simple New Post Emails to see if any incompatibility issues arise.

Describe the solution you'd like

• test Simple New Post Emails on WordPress 5.6
• open issues for any incompatibilities noted in testing
• resolve issues identified in testing
• bump "tested up to" version
• if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
none

Additional context
n/a

Fix the repo structure for the GitHub deployment actions

I've been working with @jeffpaul and indirectly @helen to get the GitHub deploy actions working for this repo. We noticed they weren't working in May and thought it was related to the way it was added after the assets directory (see #17 #18).

It failed again when trying to update the readme for 5.5 tested up to, at which point Helen noted:

Sounds like issue is its removing CHANGELOG.md, LICENSE, and everything in assets which is correct behavior but also means it’s failing
Would need to manually remove those first and then it can run
the best thing to do is to do a manual commit removing those files
And then probably change the repo to use .wordpress-org instead of assets for consistency, then it will run
And that way it will work in the future 

Today I tried various and silly combinations of removing and restructuring things (see #20 #21 #22 #23) and I'm still having issues. Now, if the action runs and .wordpress-org is present in the repo, there’s an error saying “Other files have been modified; changes not deployed” - see https://github.com/10up/simple-new-post-emails/runs/1014001024?check_suite_focus=true

But if .wordpress-org is not present, there’s an error saying “rsync: change_dir “/github/workspace/.wordpress-org” failed: No such file or directory (2)” - see https://github.com/10up/simple-new-post-emails/runs/1014019760?check_suite_focus=true

I need to dive more into what the action is doing and what it needs to be successful, so I can pick that back up soon. Any guidance or suggestions will of course be appreciated. And I think I owe 10up some GitHub build minutes. :)

Add Test Cases in Test Lodge

Describe your question

Add Test Cases in Test Lodge

Code of Conduct

• I agree to follow this project's Code of Conduct