This article is part of the Google Summer of Code blog series.

Last week, I wrote a blog post to introduce my coding summer with Google, Drupal and also presented the community bonding period. If you missed it, I would recommend having a look, before jumping into this blog post.

In this blog post, I am going to write about the project progress after 1 week. By looking at the project road map, the first-week plan was to build a prototype (proof of concept) of the Mailhandler module in order to make sure our concept is sustainable. That means I jumped into the real coding. Before presenting code, let's explain the project workflow we are going to follow.

During the project development, I am going to use Git version control system and its feature branch workflow. Feature-branch workflow uses a central repository (master branch) and separate (feature) branches. Master branch is the main branch of the project and represents the official project history. For each deliverable item, I will create a new (feature) branch that will contain all the commits related to that feature. That will allow me to make commits (improvements) easily without affecting the master branch. After getting a review from the mentors, passing the tests created pull requests can be merged into the master branch.

Last week, I set up Travis CI for my project. It is a great continuous integration tool that allows you to build and test projects hosted on Github. The best thing about Travis is that is completely free for open source projects. The template for setting up Travis CI for Drupal is available on Drupal - Travis Integration repository.

Each feature branch will need to pass tests in order to be merged into the master branch. That being said, we will follow Test-Driven Development principles and keep the master branch "clean". If you are interested in reading more about feature branch and other git workflows, Atlassian website could be a great resource of information.

As Mailhandler is heavily based on Inmail framework my goal was to create a MailhandlerNode handler plugin for it.
First, I had to create a config entity that represents an Inmail handler. Besides all the default settings there is a plugin: mailhandler_node option. It allows Drupal plugin system to find our handler plugin class.
Handler has an interesting method - invoke() which accepts 2 parameters: $message and $processor_result. A message parameter represents a mail message object and processor result collects outcomes of a single mail processing pass. This method is triggered every time handler processes a message. For now, it only contains a self-explanatory createNode() method.

In the next weeks, it will be extended by authentication, validation etc. It is worth to mention here that I added content type configuration option where a user can select a content type of a node that's being created. A user can select one of the content types available or specific _mailhandler "content type". It represents our detection mode that extracts content type information from the mail subject. However, that feature is not implemented yet and will be expanded further in the following weeks.

The progress I make with the project can be followed on my Github repository.

In the next week, I am going to extend the prototype, implement a basic test coverage in order to meet the requirements and merge the pull request. Also, the handler configuration form will be extended to allow a user to create a mapping between mail properties and corresponding node fields.