Remove Post by Email

[ericmann]

We said last year that we'd remove the post by email functionality from core as it was better suited for plugins. The Jetpack plugin has already added this functionality and, honestly, includes better functionality than the core version.

We should move forward with our plans to remove this feature.

I recommend deprecating it similar to the way the link manager was removed in 3.5. Essentially:

• New WordPress installations will never see the core feature
• Existing installations that aren't using it won't see it any more
• Existing installations that are using it will see a notice explaining they should switch to a plugin instead as the feature will be completely removed in the future

Basically, I want the option to go away, but I don't want anyone to start a riot if we remove a tool they're actively using.

[toscho]

Before we do that there should be a good, standalone plugin as replacement. Jetpack might be nice, but for many people it is just not an option due to many side effects.

[alex-ye]

Replying to toscho:

Before we do that there should be a good, standalone plugin as replacement. Jetpack might be nice, but for many people it is just not an option due to many side effects.

Yes I agree with you , We should publish an official plugin .

[ericmann]

Replying to alex-ye:

We should publish an official plugin.

That's what derailed this the first time 'round. We wanted to make post-by-email a "canonical" or "official" plugin and that never happened.

Before we do that there should be a good, standalone plugin as replacement.

No, we don't. Anyone who's not already using the feature will be unaffected if it goes away. Anyone already using the feature can still use it if we deprecate it.

JetPack is a perfectly reasonable plugin for the majority of people who need/want post-by-email functionality. Deprecating the feature (not turning it off, but warning people that it will be eventually disappearing) is the first step to encouraging others to develop a plugin that fills the I-need-this-but-can't-use-Jetpack void.

[rmccue]

+1 on deprecation, but I don't agree Jetpack is a good replacement for it. I think there needs to be a good standalone plugin to do this. I've got a ​reply by email plugin for bbPress; I might see about adding support for posting by email too.

[Ipstenu]

Given how fugly the current one is, and it's limitations, deprecate.

I want to see more plugins challenge Jetpack, since offloading the email parsing to .com's servers won't work for everyone (but that's a lot why that plugin is so much better than the core version).

[ericmann]

First pass at deprecating the post by email settings section.

[ericmann]

This first pass at a patch follows the same logic we used when deprecating/removing the Link Manager for 3.5:

• Default options for Post by Email configuration are no longer added to the DB on install
• New installs have post_by_email_enabled set to 0 (disabled)
• Old installs that are still using the default values (i.e. mail.example.com for mail server) will have the post_by_email_enabled option set to 0 upon upgrade
• Installations actually using the settings will have post_by_email_enabled set to 1
• The table on options-writing.php that presents the Post by Email settings is hidden if post_by_email_enabled is set to 0

This doesn't actually remove the option to post by email from core, but it hides it from new installs. Hopefully, this first step will encourage more well-written plugins that enable post-by-email functionality to show up in the community. We already have Jetpack, but quite a few people have voiced concern to that being the only player.

Hiding the feature in such a way will:

1. Encourage more plugin contributions
2. Not have a negative impact on those currently using the feature
3. Allow stubborn users/developers to easily turn things back on by changing 1 option in the DB, or by even adding a filter

The next step will, hopefully, be to actually remove the code for the feature in 3.7 or 3.8. But this should be a solid step forward for 3.6.

[JustinSainton]

Just voicing a reminder to check the db_version before 3.6 goes stable. IIRC, there was a link manager issue in an RC due to referencing a stale db_version.

[ericmann]

Replying to JustinSainton:

Just voicing a reminder to check the db_version before 3.6 goes stable. IIRC, there was a link manager issue in an RC due to referencing a stale db_version.

Solid reminder. The current patch is referencing the DB version as of 3.6-alpha (latest svn up) but can/should be incremented as things continue to develop.

[lgedeon]

Would be great if we could send a deprecation note via email to anyone that uses the feature. Reasoning: some people may be using this feature as their only interaction with their blog and never log in to see the notice.

[ericmann]

Replying to lgedeon:

Some people may be using this feature as their only interaction with their blog and never log in to see the notice.

At the very least, someone would have to log in to trigger the update in the first place. When we release a version deprecating the feature, we'll document it. When you upgrade you'll either see the announcement or the welcome screen with a list of changes. Either way, the person upgrading should be aware that the feature is going away.

[lgedeon]

Ha! I almost mentioned someone having to log in to update but I am notorious for answering objections that would never have been raised anyway. :)

You might see the notice when updating, but many installs are being automatically updated by hosts now. If the host sees the notice they might realize their client never logs in and needs to be notified by email. Maybe.

[adamsewell]

Fixed a typo in previous patch

[mighty_mt]

Replying to Ipstenu:

offloading the email parsing to .com's servers won't work for everyone

That's exactly why I don't like Jetpack's post by e-mail feature. I've written a plugin that hooks into the 'wp_mail_original_content' filter and parses/modifies the original body of the e-mail. This obviously doesn't work with Jetpack because the content has already been parsed/sanitized before it reaches my blog...

I know that wp-mail.php is quite rudimentary and can be a little buggy but I think it's a good base to build on. Would be very interested if it was made into a plugin and extended with some new functionality.

[codebykat]

Researching this, I noticed the Codex entry references ​Postie, which appears to be a full replacement for wp-mail.php with new functionality.

[juk220]

I am applying now for the gsoc post by email project. And I would like to create that

good, standalone plugin as replacement

here is the description so far:
​http://jukgsoc13.wordpress.com/

I would be glad for any kind of feedback, things that would be great to include, questions...

[codebykat]

Updated for 3.7

[codebykat]

Just added an updated patch for 3.7; now that the Post By Email plugin is ​in the repo, this can be reconsidered for a merge into trunk. In addition to deprecating the options and removing the admin menu stuff if no options have been set, it guts wp-mail.php, which for now just calls the action of the same name.

If options *were* set, the admin menu now displays a link to the plugin (which will read the existing options in on activation, so nothing will be lost); in other words, those who are using the existing functionality will need to install the plugin to continue using it. This is by design, as the code in Core has multiple problems.

[helen]

Probably late for 3.7. Somebody else can move it back if I'm wrong, but sounds like a great candidate for testing now and landing in early 3.8.

[codebykat]

Super minor update to the previous that fixes spacing as per coding style guide.

[codebykat]

@helen - Cool, I will keep this updated against current trunk.

[codebykat]

Here's the version for 3.8.

[codebykat]

Updated to fix merge conflicts with inline documentation added to wp-mail.php.

[ocean90]

#32397 was marked as a duplicate.

[chriscct7]

The email to post feature has many bugs, and currently does not work for the vast majority of usecases as the version in core requires an http mailserver (it does not support an https one).

The goal is to remove the entire feature from core for all installs (as it simply doesn't work) including the associated file and settings and move them to a plugin that Kat nearly completed a while ago. On install of 4.3, if one of the options for the mail to post is set to a non default value, we'll automatically download and activate the new version of the plugin which fixes the bugs and supports https mailservers from WordPress.org.

A patch for this has been started

Related Bugs:
#4337, #4965, #5252, #22942, #19984

Related via Settings Removal:
#32396

[chriscct7]

Per ticket:32396#comment:37 we're moving this to 4.4 early for time and other considerations

[chriscct7]

Restarting this for 4.4. Will have a refreshed patch for this probably next week.

The patch will contain 3 things:

1. Removes the code involved in post-to-emails from core.
2. Removes the settings for post-to-emails form core
3. An upgrade routine that detects if the post-to-emails settings have a non-default value, and if so download and activate the new plugin that's now hosted on .org

[wonderboymusic]

22942.2.diff​ - oops @chriscct7, didn't see your comment. Take a look and see if you would change anything

[helen]

Bringing over what I said in Slack:

: well, even though it’s hidden, i think we may still need to take a multi-step approach where we prompt about the plugin now and then actually remove code in the next release.
: the plugin HAS to at least have the appearance of being maintained and people ready to support it, though.
: even though we don’t even really support it in core, the switch over will bring attention and it’s pretty rude to just leave people stranded
: another thought would be to reply to the first post-by-email after the update to 4.4 with an email letting them know, in case they don’t log into the admin.

[Frank Klein]

I consider that the Gutenberg merge is a good opportunity to revisit this ticket. Creating posts via email does not really fit with the new editing approach.

[SergeyBiryukov]

#49386 was marked as a duplicate.

[claytoncollie]

@frank-klein Agree that we should revisit this ticket now that Gutenberg is more mature.

@SergeyBiryukov how can we get it going again? Maybe talk to @chriscct7 ?