Opened 12 years ago
Last modified 4 years ago
#22942 assigned enhancement
Remove Post by Email
Reported by: | ericmann | Owned by: | chriscct7 |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 3.5 |
Component: | Keywords: | has-patch | |
Focuses: | administration | Cc: |
Description
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.
Attachments (7)
Change History (54)
#5
in reply to:
↑ 4
;
follow-up:
↓ 6
@
12 years ago
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 .
#6
in reply to:
↑ 5
@
12 years ago
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.
#10
@
12 years ago
+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.
#11
follow-up:
↓ 21
@
12 years ago
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).
#12
@
12 years ago
- Keywords has-patch needs-testing added
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 ifpost_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:
- Encourage more plugin contributions
- Not have a negative impact on those currently using the feature
- 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.
#13
follow-up:
↓ 14
@
12 years ago
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.
#14
in reply to:
↑ 13
@
12 years ago
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.
#15
follow-up:
↓ 16
@
12 years ago
- Cc luke.gedeon@… added
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.
#16
in reply to:
↑ 15
@
12 years ago
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.
#17
@
12 years ago
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.
#21
in reply to:
↑ 11
@
12 years ago
- Cc bikertom@… added
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.
#22
@
12 years ago
Researching this, I noticed the Codex entry references Postie, which appears to be a full replacement for wp-mail.php with new functionality.
#23
@
12 years ago
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...
#25
@
11 years ago
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.
#27
@
11 years ago
- Keywords 2nd-opinion removed
- Milestone changed from 3.7 to Future Release
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.
This ticket was mentioned in Slack in #core by helen. View the logs.
9 years ago
#36
@
9 years ago
- Keywords needs-patch added; dev-feedback has-patch needs-testing 3.9-early removed
- Milestone changed from Future Release to 4.3
- Owner set to chriscct7
- Status changed from new to assigned
- Summary changed from Deprecate Post by Email to Remove Post by Email
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, #19984, probably more
Related via Settings Removal:
#32396
#37
@
9 years ago
- Keywords early 4.4-early added
- Milestone changed from 4.3 to Future Release
Per ticket:32396#comment:37 we're moving this to 4.4 early for time and other considerations
#38
@
9 years ago
- Keywords early 4.4-early removed
- Milestone changed from Future Release to 4.4
Restarting this for 4.4. Will have a refreshed patch for this probably next week.
The patch will contain 3 things:
- Removes the code involved in post-to-emails from core.
- Removes the settings for post-to-emails form core
- 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
#40
@
9 years ago
- Keywords has-patch added; needs-patch removed
22942.2.diff - oops @chriscct7, didn't see your comment. Take a look and see if you would change anything
This ticket was mentioned in Slack in #core by sergey. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by wonderboymusic. View the logs.
9 years ago
#43
@
9 years ago
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.
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.