Post by email

My objective for this project is to make usage of the feature “post by email” as simple as possible and at the same time to give much more flexibility and options then current solutions can offer. To introduce a new way to manage posts from many email addresses (contributors).

This project will be introduced as a plugin without changing anything in the core (it can be eventually included in core outside of the GSOC or during – this thing have to be discussed, I don’t insist on a stand alone plugin but it will be more reasonable to see if this is worth including in the core and then include it).

Problems with current implementation:

  • It can’t be managed intuitively, you have to read documentation in order to get things done. For example during configuration you have to enter port and ssl server address and these can be new unknown things for some users. Or in order to enable the “automated browser activation” you have to include an iframe and in order to enable “action-based activation” you have to add a new function to functions.php
  • In case you didn’t enabled “Automated Browser Activation” or “Action-based functions.php Activation” you have to go to a specific link to publish posts submitted by email and this isn’t intuitive (at least for me)
  • You have to keep secret you host email to avoid spam. It is a good thing anyway when nobody knows what you are using in the backend to perform some operations but it shouldn’t be a problem if somebody finds out this email.
  • You can’t have multiple contributors which will be managed easily. There is just one “from” and “to” email. (I will presented a new approach below)

These things I want to resolve by usage of the email services APIs for a closer interaction between the WP plugin and the email which is used as host (gmail used as example). Also an extended use of IMAP and POP protocols.

Features of the proposed plugin:

  • Easy management of multiple contributors by email
  • Anti spam measures
  • Easier activation
  • A lot of settings available to configure a fully automated posting by email
  • Support of IMAP and POP
  • Creation of posts using HTML and Markdown
  • Possibility to work with attachments
  • Fully configurable posts (using header, description below)


host_email – is the email address on which posts will be send

white_list – a list of all email addresses from which mails won’t be deleted and accepted by the plugin

host_email can be of 2 types:

  1. Fully supported by the plugin
  2. Partially supported by the plugin

host_email fully supported by the plugin:

Will be a list of well known email services like: gmail, yahoo, hotmail which will be fully supported by this plugin. This means that:

  • When user activates the plugin or changes the host_email he have to introduce just email address and its password. There is no need to specify port, server/ip, protocol. It would be very handy for non IT users who may think: “What the hell is a port? I introduced my email and password, isn’t that enough?”.
  • No spam. For this type of emails will be used filters (and boolean operators) to delete all the emails which came not from one of the emails from the white_list on the smtp server. (this functionality will be doubled/re-controlled by the plugin on the server where site rolls, explained below)

host_email partially supported by the plugin:

Any email which supports IMAP or POP protocols. This means that:

  • When user activates the plugin or changes the host_email he have to introduce not only the email and its password but also: port, ip/server and protocol. This will be an universal solution covering 98% of all emails (because I’ve never seen in my life an email which doesn’t support POP or IMAP but the mighty www say that such thing exists).

So, the only visible thing for user between these 2 types will be the number of fields he needs to complete. But how about no spam? Well for fully supported host_emails there are those filters, but I said that these functionality will be doubled/re-controlled by the plugin. Well, “no spam” problem will be resolved for partially supported host_email and doubled/re-controlled for fully supported host_email through POP or IMAP protocols. Plugin will go through all emails to see if they are from one of email addresses from the white_list, if they aren’t delete them.

In order to expose my idea as close as possible to what I have in mind I will present the UX because at the end of the day this is most important thing.

Description of the screen/functionality when user activates the plugin

Page with:

  • Textbox labeled “email”, followed by an “@” and a dropdown of fully supported email services (“”, “”…) with an “*” in right of it (required).
  • Textbox labeled “password” with an “*” in right of it (required).
  • 2 radio buttons first is checked and labeled “Fully supported email” and the second one is labeled “Custom email (POP or IMAP)”.
  • 2 buttons labeled “submit” and “cancel”.
  • Link to a page (from a blog or to the description of this plugin on wordpress where you can find more detailed information about this screen and options available on them). The link will be labeled “what does it mean?” or “more information”.


Fig. 1

If user hits the “Custom email (IMAP or POP)” radio button there will be a smooth transition (no jumps) using JS(jquery) and the content above radio buttons will change.

  • Textbox labeled “email” with an “*” in right of it (required).
  • Textbox labeled “password” with an “*” in right of it (required).
  • Textbox labeled “server/ip” with an “*” in right of it (required).
  • Textbox labeled “protocol” with an “*” in right of it (required).
  • Textbox labeled “port” with an “*” in right of it (required).

On submit, if any of the fields aren’t completed or they are in an incorrect format, the screen will return the corresponding error message with a suggestion how to repair it. If all the fields are valid application will send a verification email on host_email and then try to read this email (verify connection). In case that one of them failed then application will output the corresponding error message. If there were no errors then on the screen will appear through a smooth transition a confirmation message and a button “next”.


Fig. 2

When user click “next” use another smooth transition which will delete everything but “what does it mean?” link and the screen now will contain:

  • Textbox labeled “contributor”.
  • 2 buttons “add” and “skip”.

When user clicks “add” application controls if the field is valid, if no display the corresponding message. If it is valid sends a verification email from host_email to this email. Then displays the message “An email was sent to {email}. To activate it just follow the link.”. At this point email is already added to the white_list but it is not activated. The link will send back an email to the host_email, plugin will read it an activate this email. (This last part have to be discussed/researched more). User can click “skip” and add a contributor (an email address to the white_list) later.


Fig. 3

At this point plugin is already fully functional, have a “from” and “to” emails, so it contains all the functionality of current core implementation.

Also on activation in the settings of wp-admin will be added a new section “Post by email” with the following subsections:

Host email

The screen will contain:

  • The name of host_email followed by a link/button “edit/change”. If user clicks it will be a smooth transition to a page similar to Fig. 1 if current host_email is from the list of fully supported email services and Fig. 2 if not. Which will behave in the similar way with just one difference, on “submit” after all the validation user won’t appear button “next” but “back” and one more button will appear if email was changed “notify all contributors about the change of host email”. Also I want to mention that not post will disappear and not a single setting of any contributor will be reset because everything is saved into db.
  • A dropdown labeled “update every” with “minutes” in the right of it (default value have to be discussed).
  • Another dropdown labeled “default post category” with all post categories and subcategories in it.
  • A button labeled “Update” which will update posts by email now.
  • A button labeled “show logs” which will make a smooth transition to a page which will contain all the logs of post by email plugin.


Fig. 4


The screen will contain:

1) Table of all contributors (white_list). Columns of the table:

  • “Email” – will contain email address which have in front an icon/label indicating if the corresponding contributor confirmed his participation (followed the link sent to him when adding this contributor). The email address will be clickable opening the screen with all the options of this contributor. See (“Contributor”(#1)).
  • “Number of posts” – each cell will contain one value (green) if all posts are approved or 2 values: on the left (green) – number of approved posts and on the right (red) – number of unapproved posts
  • “Last post” submitted on (timestamp)
  • “Actions” – which will contain 2 links/buttons labeled “Activate” (green) or “Suspend” (red)

2) Button “Send categories” – on mouseover the following helper will be displayed “send to each contributor post categories available for them”, on click will do exactly what is said in the helper and display a result “All selected active contributors received their available post categories”.

3) Button “Activate” – on mouseover the following helper will be displayed “activate all selected contributors”, on click all selected contributors will be activated and their corresponding cells in the “Actions” column will change their values to “Suspend” (red)

4) Button “Suspend” – on mouseover the following helper will be displayed “suspend all selected contributors”, on click a yes/no dialog box will appear stating that “you are about to suspend all contributors, are you sure about this?” if “yes” all selected contributors will be suspended and their corresponding cells in the “Actions” column will change their values to “Activate” (green)

5) Button “Reconfirm” – on mouseover the following helper will be displayed “reconfirm all contributors”, on click a yes/no dialog box will appear stating that “you are about to request reconfirmation from all contributors, are you sure about this?” if “yes” all selected contributors will be deactivated and their corresponding icons/labels  in the “Email” column will change their state to unconfirmed.

6) A texbox with a button in the right “Add new” – on mouseover the following helper will be displayed “add a new contributor”, on click will validate the field returning the corresponding error if necessary, if everything is ok will send a confirmation email from host_email to this email and display the following message “An email was sent to {email}. To activate it just follow the link.”.


Fig. 5

Read, edit, delete, publish a post submitted by email

User just have to go in the default posts section from wp-admin and do whatever he wants with the post.

Contributor (#1)

This screen will contain:

1) Contributor name

2) Link/button “Reconfirm”

3) Link/button “Activate” (green) is contributor is suspended and “Suspend” (red) if contributor is activated

4) Link/button “Delete” – on click a yes/no dialog box appear, asking “this will completely delete current contributor, are you sure about this?”, if user selects “yes” then another dialog box will appear asking “send a notification to the contributor?”

5) Table of all post with columns:

  • “Title” – will contain the clickable post title (redirecting to the default “Edit Post” from WordPress) in front will have an incon/label to indicate if post was published or not
  • “Categories” – will contain all categories
  • “Date time submitted” -submitted by the contributor (not date published)

6) Dropdown “Default post category”

7) A hierarchic list of check-boxes of all categories with a dropdown in the right which have 2 options “approve before publish” and “publish without approve”


Fig. 6

Creating a new post

When user creates a new post he can do it in 2 ways:

1) Just write a simple email in RTF (rich text format) in this case he can but don’t need to include a header (see below), subject of email will be used as post title and post category will be the one specified as default category on the page of this contributor, if it is not set then will be used default category for host_email.

2) Use one of the following: HTML or MD (markdown) where he must include a “header” which will look like:

Title: How to create a plugin for wordpress
Categories: WordPress, Open Source
Type: html

(or maybe header can be substituted by some special tags)

And then goes the content itself. Markdown and html types will be implemented with preventing the “html injections” which are “bad injections” (JS, iframe…) and invalid HTML syntax. This is resolved using strip_tags() and by existing solutions for HTML validation and tag autoclosing.

Attachments it is a very important thing, most probably it will be resolved by including some special tags which will be parsed by the plugin and then downloading the corresponding attachment and including it into the default WP media library.

The problem with the images is that you can have 2 types of images:

In first case special tags will be used to retrieve the corresponding attachment on server (adding to the media library).

Second case:

  • Live it as a remote link
  • Try to download the image and store it on server

(this have to be discussed, maybe it would be reasonable to add such an option to the plugin, add a special section dedicated to attachments)

Also there is a problem with image size and can have a couple of solutions:

  • Leave image without sizes (browser will scale it automatically)
  • Leave image with default sizes (as it was in email)
  • Have an option to scale image based on some parameters (ex. max-width: 1000, max-height: 400, crop: false, scale: true). Then you’ll have to know the default image sizes and scale appropriately (which is possible only if there is a direct access to the image). There are php libraries which offer all the needed functionality to perform this manipulations.

(this also have to be discussed, maybe it would be reasonable to add such an option to the plugin)

Posting can be done in another way (which wont be implemented in this plugin, but if the WordPress community will request it and offer help, it can be implemented): when admin adds a new email to the white list (or modify settings for one of current emails from white_list) automatically to this email is sent a form which will contain a title textbox, a category dropdown (with available for this specific email address), a textarea and a submit button which will send all these information to the host_email. This is very time consuming to implement because in order to make a html form for email which will look good in different browsers and services is a hell of a lot work.


  • All posts by email will be saved into the default $wpdb->posts but some data will be added in _postmeta table (like email address which posted it, date time when host_mail received, if this is unnecessary it can be deprecated). If post by email plugin is uninstalled all posts will be still valid because they are saved in the default posts table. Also there will be for sure a table which will keep all the data about host_email and contributors, probably _usermeta table which will contain all information about emails from white_list and host_email. Maybe there could be a reason to create separate tables, but this have to be discussed.
  • Each email option like gmail or hotmail have their own APIs and they will be added separately. The first version of the plugin will work just with one or two, for example gmail, because it is so awesome and popular, and yahoo but with a plugin structure which will offer a relatively easy integration of other mail services. Eventually I want to include more fully supported email services but the order of their inclusion and if this is necessary have to be discussed.
  • There is also a possibility to import settings of the post by email from the current implementation in core on users demand (this have to be discussed if it needs to be implemented or not).
  • The update of posts by email will be probably done using wp_crone() I never used it before but I was suggested that it could be a very good solution to this problem. So, I’ll have to do some research about this point, play around with this function a little bit.

Milestones and deliverables schedule:

6 – 26 May: Learn about WordPress plugin development as much as it is possible using 2 courses from which I got from my friend and just by coding, trying different things.

27 May: I am accepted (hopefully)

28 May – 16 June: I have 20 days in order to discuss with mentor and other wp-hackers each point from my proposal and decide 100% what will be each step of UX, every click and field validation, which will be aggregated in a technical assignment by me, with sketches. Also there is a possibility to include in technical assignment UML class diagram. In parallel I will be experimenting with email APIs, IMAP and POP trying to build a prototype of the plugin in order to get as much knowledge and experience as it is possible before actual coding starts. This will give me a better vision on the problems in implementation which aren’t obvious from the first sight. Also will allow me to build a better logical structure of the plugin back end based not only on theoretical knowledge but also on some experience.

17 – 19 June: GSOC officially starts. I will present to the mentor technical assignment developed by me, all the experience related to posts by email and the architecture which I came up with. Discuss these things with mentor and make the needed changes until the approach/architecture, technical assignment and re-factored schedule will be approved.

20 June: Start coding everything from scratch.

20 – 23 June: Create the 1) “on install/activation” and 2) “on deactivation/uninstall” part. Which will contain things like: inserting(1) and deleting(2) the corresponding fields in DB tables, add(1) and delete(2) subsections in the settings of wp-admin.

24 – 28 June: Creating the html (with css) for all sub pages of the post by email section in the settings of wp-admin.

29 June – 3 July: Creating the basic structure of host_email, contributor_email and posts_submitted_by_email classes and their interfaces.

4 – 7 July: Implement all the methods of host_email which will cover the functionality behind the creation of host_email (during plugin activation) and edition of host_email available in the wp-admin settings, make sure that all fields in db are inserted and updated as expected.

8 – 11 July: Implement the structure of the client(js/jquery)/server(ajax and php) side validation  and applying it to the previous developed functionality

12 – 15 July: Implement all the methods of white_list_email class which cover all the functionality behind the creation of the first email/contributor in the white_list, creation, edition, deletion of contributors in the wp-admin settings, make sure that all fields in db are inserted, updated and deleted as expected. Also adding all the needed client/server side validation.

16 – 19 July: Implement the update functionality which will cover the mechanism that fetch mails from host_email every x minutes. Emails fetched will be stored properly in the db (in default posts table) and test that it works as expected (the hardest part so far).

20 – 30 July: Implement the update functionality through IMAP and POP which will cover the mechanism to fetch mails from host_email every x minutes. Emails fetched have to be stored properly in the db (in default wp posts table) and test that it works as expected (the hardest part so far).

1 – 2 August: At this point I should have some kind of a pre-beta version which will work and posts will be published by email. So, these days I will use to test and fix any bugs which I will find in the functionality implemented so far. And do all the necessary to pass the halfway mark.

3 – 5 August: Implement the functionality which will delete through IMAP and POP all emails which came not from contributors (white_list)

5 – 7 August: Implement the filters through email service API and make sure that they work properly.

8 – 10 August: Test all the functionality implemented so far and fix founded bugs, see if I missed something and fix this.

11 – 13 August: Implement the usage of headers (or special tags). Make sure that they are handled correctly and all the needed information is saved into DB.

14 – 17 August: Allow emails from the white_list to send posts in html, make sure that nothing can break the front end (“html injections”).

18 – 21 August: Allow emails from the white_list to use markdown, make sure that nothing can break the front end.

23 – 31 August: Implement the attachment functionality. (Another hard part of the functionality)

1 – 6 September: Testing and fixing all bugs, ask friends, maybe wp-hackers to help me with test cases and maybe testing itself.

7 – 15 September: Code refactoring, testing, again code refactoring, again testing, and so on. In parallel I will begin to write the documentation.

16 September: No more coding at all.

16 – 27 September: Writing documentation, conclusion, things to improve, getting feedback from mentor other wp-hackers. Posting the plugin public, for all WordPress users.

P. S.

If there will appear any bugs in this project after GSOC finish I will resolve all of them, without discussions (just because it will take less time for me than anyone else). If I will not manage to include anything listed above till the end of GSOC (like provide more email services options or markdown edition anything from not core functionality) or will appear requests for new features which I’ll consider cool to include I’ll do my best to implement them. Also I will try to create some documentation, maybe a short video tutorial for a faster learning curve from UX point of view.


Get every new post delivered to your Inbox.