Sample GSoC Proposal Applications

cs_shadow's picture

Following are two real applications from Google Summer of Code 2014 which we thought are good enough to put up as examples. Having said that, none of them are perfect, so please treat them as inspirational material, and not as templates to copy from:

  1. WYSIWYG inline entity for Drupal 8 by Chandan Singh (cs_shadow)

  2. Port Securesite module to Drupal 8 by Shivanshu Agrawal (shivanshuag)


Project Title: WYSIWYG inline entity (D8)


Have you participated in Google Summer of Code in the past? No.
Have you applied to GSoC in the past? No.
Are you applying to any other organizations this year? No.
How many hours will you devote to your GSoC project each week? I plan to work a full 8 hour work day every weekday.
What are your other summer plans? No prior commitments as of now. If I’m selected for GSoC, it will be my only job this summer.


Have you ever worked with Git?
Yes, I’m fairly proficient with Git. For most of my assignments/projects, I prefer to use Git. So, I believe I have a decent knowledge of Git.

Have you ever utilized IRC?
Yes. I use IRC a lot. IRC is my preferred mode of communication. I tend to resolve majority of my issues and questions on IRC.

Have you completed Drupal Ladder for GSoC Students?
Yes, I’ve completed the ladder.
Link to my completed lessons:

Have you ever contributed code to Drupal?
Yes. Though, I’ve started contributing to Drupal fairly recently. Details of my contributions to Drupal can be seen here:

Do you plan to continue contributing to the Drupal project after GSoC is finished?
I definitely plan to contribute to Drupal even after GSoC. In fact, I’ve even the features on which I’d like to work immediately after completion of my project towards the end of this proposal, under the heading ‘Future Work’.

Have you ever built a Drupal site or helped on a Drupal project?
Yes. I worked as developer intern for PasteOnMyCity during last summer. Its a social networking site for users of same cities to help them collaborate with other users and businesses. The site was written in Drupal and I worked on fixing several issues and adding enhancements to the site. Most of my work involved working with their custom theme on D7 and modules like Views, flags, CKEditor, Sitetour. The project used Git as version control. Since this was the first time was learning Drupal, I took help from Lullabot tutorials.


Which project idea sparks your interest and why?
‘Project #3: Wysiwyg inline entity’ interests me most. A lot of content writers (including myself) use WYSIWYG editors fairly regularly and I always feel the need to embed external elements like images, videos and Drupal entities. Drupal entities are basically instances of a particular entity type, for example Nodes (content), Comments, Taxonomy terms, User profiles.
Being a developer also, I know its a pain to install, configure and enable a separate module for enabling the user to embed each different entity. So, making a standardized framework for all kinds of embeds will reduce the burden on webmasters and also provide a consistent user-experience, also lowering the amount of redundant code.

Project Description
The project aims at building a framework to support embedding of entities in WYSIWYG editor. The single framework will be able to handle all different types of entities in general. Upon successful completion, this project will deliver a robust set of APIs to support embeds, integration with Ckeditor and a basic UI. The developed framework will be released in form of a module called ‘WYSIWYG Inline entity’.

Link to ideas page:

Target Version: Drupal 8

WYSIWYG editors are one of the most used modules of Drupal and there are a lot of sites which use WYSIWYG editors as their input method. Most users prefer such editors over a plain html textarea for content-writing. And one of most important features that these editors provide is to embed entities, for instance media(images, video etc.) and node. There exist certain modules to achieve this, but there is a lack of standardization.

The issue being that each of these modules focus on kind of entity. So, in current setting, if one wants to embed both media and node, one has to configure and enable at least two modules. This is a cumbersome process for the site admin. Also, as both these modules do a more or less similar job, it leads to a lot of repetitive code. Moreover, the look and feel is also not consistent across these modules leading to a bad user experience.

The idea behind this project is to come up with a single framework to handle all kinds of WYSIWYG embeds. And thus eliminating the need for configuring a different module for every entity. Major focus of the project is to provide a robust set of APIs for embeds and integration with Drupal CKEditor (CKEditor is chosen because as WYSIWYG editors are being standardized in Drupal 8, CKEditor is the only one to be supported). Apart from this, the project will also deliver a minimal UI with a basic display configuration. The novelty of the framework will lie in the fact that all its elements will be completely pluggable so that other modules can easily extend it, provide new features, and improve user experience.
This framework will be provided as a module called ‘WYSIWYG Inline entity’. All parts of the module (especially the APIs) will be completely pluggable, which will allow other modules to extend, provide new features and improve experience.

Entities that are part of the scope of this project are:
Images, videos from an external URL.
Images, videos uploaded to site as file.
Reference to all intrasite entities like a node.

Brief description of major parts
- Low level API for embeds: The API will basically expose a function ‘embed_entity’ that will be called to embed any entity. This function will take different arguments to determine whether the type and path of the entity. Apart from the ‘embed_entity’ function, the API will also provide some helper functions relevant helper functions which will also be used internally. For example. to verify path and type of the embedded entity or to determine whether an external entity points to a valid URL.
- Text filter for embeds: This part will provide a hook for modifying WYSIWYG text. If the filter is enabled, it will check if any of the embedded entities have been modified (meaning the referred entity has been changed since it was embedded). If yes, it will modify the HTML according to the changes.
- WYSIWYG Integration: It will provide a basic interface to select type of entity based on source, and upload/select/insert desired entity based on the entity type. Also, it will expand the embedded entity into HTML and provide preview for the embedded media (if possible).

Mockups for the User Interface

Initial view of the editor

Select source and entity

Embedded an image

Embedded a node

Janez Urevc (slashrsm), GSoC Alumnus 2011
Shashwat Srivastava (darklrd), GSoC Alumnus 2010 & 2011

Difficulty: Moderate

Low level API for embeds - 02 June
Text filter for embeds - 16 June
Final module and integration with CKEditor - 18 Aug*

Its not possible to further breakdown integration with CKEditor because integration with CKEditor and coming up with an UI is largely independent. Hence, they are combined into a single deliverable, indicated with an asterisk(*).

Before 19 May: Study how existing modules (like media, node_embed) work.
19 May: Planning of framework and decision on structure of APIs
Writing down function signatures for all functions that will be exposed as a part of the API and other helper functions.
26 May: Low-level API for embeds*
Write functions to determine if a user-requested embed is valid or not. Also to check whether the given embed complies with the type of embed specified.
02 June: Low-level API for embeds*
Write functions to actually embed the entity into the node, modify database etc.
09 June: Text filter for embeds.
It must include settings to enable/disable the filter along with the filter itself. This filter check if any embeds have been modified and then modify HTML accordingly.
16 June: Finishing rendering of content and testing of the API and filter*
Making sure the embedded entities are rendered properly.
Writing automated tests for the API.
23 June: Mid term submission.
30 June: Writing SimpleTests for API and text filter*
Write more comprehensive tests and fix any bugs that might be encountered.
Release Alpha version of the module with the APIs and text filter for review and feedback.
07 July: Integration with CKEditor.
Integrate the APIs developed so far with CKEditor.
14 July: Developing Basic UI.
Develop basic interface for the user to interact with the CKEditor plugin to embed entities.
21 July: Modification of API to deal with updates in the embedded node.
Modify the API to make sure that the latest content is always displayed for an embedded entity after the source is modified.
28 July: Writing SimpleTests for CKEditor integration
Write SimpleTests for CKEditor integration.
Finish Documentation.
Release Beta version of the module.
04 Aug: Clean up UI
Make the interface of the CKEditor plugin more intuitive and better in terms of design.
11 Aug: Wrap up
18 Aug: Final submission

Developing low-level API for embeds has been allotted two weeks because I believe writing a robust set of API is the most crucial towards completion of this project. Following same idea, testing of the API also spans across two weeks. Such instances where a particular task spans across two weeks are indicated with an asterisk(*).

Which aspect of the project idea do you see as the most difficult?
Under this approach (derived from approach followed by ‘media’ module), the embedded entity is expanded to generate complete HTML for that. So if the original entity gets changed, the changes are often not reflected (at least not immediately due to caching and other issues). To tackle this problem so that the expanded HTML of the entity always remains up to date is the most difficult aspect in my opinion.

Which aspect of the project idea do you see as the easiest?
In my opinion, integration with CKEditor should be relatively easy because there are several modules which perform similar tasks and hence most of the code can be derived from those.

Which portion of the project idea will you start with?
I’ll start with planning the architecture of the framework, which broadly means answering following questions : how will content be stored, structure of text filters, low-level format of embeds etc. Once the architecture is finalized, I’ll start with developing a low-level API for embedding entities.

Future Work (to be done after completion of this project)
First and foremost, I’ll provide support for the developed module, because I believe providing support for a module is as important as developing it.
Apart from that, following is something I’d like to work upon after the completion of this project.
So, once we have a robust API serving as the backend of all the embeds, the next step is to provide a better UI. The idea is that instead of explicitly asking the user to paste a link and its type, it would be nice if a plugin could do it on the fly. User will just have to paste the link and the framework shall analyze that link. Upon analysis, the link will be classified as an entity and processed in corresponding fashion henceforth.

How will deal with project, task, and time management? Will you utilize software? If so, which tool and why?
I will use a project management system like Asana to manage tasks and time both. I prefer Asana because I’ve worked on Asana before and the fact that it provides very good interface for adding tasks and their deadlines. Me (or my mentors) can add the tasks on Asana and I’ll mark them as complete as and when I finish them. This way my mentors can track my progress in a fine grained manner.

How often will you communicate with mentor? How will you communicate with mentors?
I'll have two meetings per week with my mentors. Upon discussion with my mentors, we've decided to have a google hangout Monday and Thursday of every week. It will typically be a 15-20 minutes discussion mainly to catch up with my progress. We'll have more regular discussions on IRC itself.


Project Title: Port Securesite module to Drupal 8


Have you participated in Google Summer of Code in the past? If so, for Drupal? If not, for which organization? Please describe your participation in Google Summer of Code.
Have you applied to GSoC in the past and are you applying to any other organizations this year? If so, please explain.
How many hours will you devote to your GSoC project each week? What are your other summer plans?
My college semester ends in first week of May. After that I will be able to devote 8-10 hours a day (more if necessary) till the last week of July. After that, my college reopens in August but I will still be able to devote 5-6 hours a day for the project. I don’t have any summer plan other than GSoC.
Have you registered an account at and joined Link to your account please!


Have you ever worked with Git?
Yes. My github profile -

Have you ever utilized IRC?
Yes. My freenode nick - shivanshu

It's required that you complete "Drupal Ladder for GSoC Students" before applying. Please provide evidence.
In the issue , I have rerolled a patch which shows - I can install drupal, use git, create a patch, test them. Screenshot -

Have you ever contributed code to Drupal?
I have recently contributed patches to fix some issues of the securesite module. I also became one of the maintainers of the securesite module recently and have already committed code to it’s 7.x-2.x branch.,
Have you ever built a Drupal site or helped on a Drupal project?
Yes. My first encounter with Drupal was when I had to build an internal wiki for our institute(IIT Kanpur). Apart from that, I have also built another site - which is the site of Programming Club of IIT Kanpur.

If you have not previously contributed to any open source projects, can you provide example code from school?
I am a prolific coder and most of the code I have written can be found at


Which project idea sparks your interest and why?
I am interested in project number 4 - porting securesite module to drupal 8 because I like the use case of the module and I am already familiar with basic http auth and digest auth.

Treating this project as a real proposal, provide your implementation plan with as much detail as possible such as weekly time breakdowns, methods of mentor communication, project management, and when to expect specific results/deliverables.

The porting of this module has following parts-
Drupal 8 configuration management system- Drupal has moved from configuration based on variables to configuration stored in yml files. One of the first step towards porting the module will be to change the module to use this configuration system. This will also involve making logical configuration schema for the module.
Basic Auth Using Modular Authentication System of Drupal 8 - Drupal 8 has introduced a modular authentication system which includes basic http auth along with the cookie based sessions. Secure site module provides access restriction based on - http basic auth, http digest authentication and form based authentication. In the drupal 8 port, http basic auth has to modified to use the existing basic auth service.
Drupal 8 services and events - Drupal 8 has introduced services in place of many hooks and global variables are used by the module ex- hook_boot and global $user. To port the module to drupal 8, appropriate changes have to be made
Theming - Theme API in drupal 8 has been changed to use TWIG theming templates instead of PHP templates. Current theming implementations in the module have to be changed accordingly.
HTTP Digest auth - In HTTP digest auth, digest of the password is sent across the network to prevent MITM attack. For this, digest of the password is stored on the server independent of Drupal installation. This mechanism requires user to create a separate database for storing password digest and setup scripts provided by the module to manage password (drupal should have the ability to store passwords but not retrieve them). A separate script is provided for authentication.
Improvement in the UI - UI improvements will be aimed at making it easier to set up digest authentication. There will be separate configuration for the digest authentication which will be similar to drupal installation. The php script will check for the database and ask for its credentials(it will also warn the user to move the config file generated to a secure location ). Then, it will ask for the location of the scripts for the digest authentication. It will also prompt the users to change the file system permissions on the all the files in the digest_md5 directory so that only administrators have access to them.

Detailed Description (only if this is a new idea, otherwise if there is a description -online, please provide the URL):

Expected Deliverables: (list the main items that you will deliver be during the program):
- A fully functioning module for drupal 8 which is able blocks unauthorized access to website using basic http auth or digest auth or form based auth as chosen by the user.
- Unit tests for the module
- Documentation for the drupal 8 port of the module
- A video explaining how to use the module

Timeline (break down by every week of GSoC)
Bonding Period
21 April to 18 May: Getting more familiar with drupal 8, drupal coding standards
Coding Period 1
19 May - 25 May: Creating configuration schema and Upgrading variables to configuration system
26 May - 01 June and 02 June - 08 June : Fixing the deprecated api’s
09 June - 15 June: basic auth mechanism
16 June - 22 June: Bugfixes, refactoring the code, write unit tests
Mid Term Evaluation
23 June: Mid term submission
Coding Period 2
23 June - 29 June: form based authentication
30 June July - 06 July: http digest mechanism - script for storing and managing password
07 July - 13 July: http digest mechanism - script for auth using the stored password and realm
14 July - 20 July: theming
21 July - 27 July: Improving the UI
28 July - 03 Aug: Bugfixes and refactoring
04 Aug - 10 Aug: Unit Tests and writing documentation
11 Aug - 17 Aug: Make a video explaining how to set up securesite module
18 Aug: Final submission

Mentors: Lee- and serpicody

Difficulty: Easier

Which aspect of the project idea do you see as the most difficult?
Most difficult part of the project is the http digest authentication due to many different components like managing separate database for passwords and scripts to add new users and authenticate using digest involved in it.

Which aspect of the project idea do you see as the easiest?
The easiest part of the project is theming because the module has only one page, which contains the login form and the password reset form, to be themed. Apart form that, the changes in theming are mostly in the templating language but the rest of the architecture(hooks and preprocess/preprocess functions) does not have any major changes.

Which portion of the project idea will you start with?
I will start with the Configuration Management system first because it is the most logical step to port the module and independent of other parts. All the other parts make use of the variables defined by the CMI.

How will deal with project, task, and time management? Will you utilize software? If so, which tool and why?

Time Management:
- Blog post every week on my blog - to give an idea to everyone of what has been done and how has it been done. These blog posts will also provide support for writing documentation later for the module.
- Meetings with mentors two times a week through Hangouts.Time and day? I prefer Tuesday and Thursday any time between 15:00 to 19:00 UTC
- I will always be online on IRC while I work

How will deal with project, task, and time management? Will you utilize software? If so, which tool and why?
- 15 minute SCRUM meetings with the mentors every Tuesday and Thursday of project at noon Chicago time (22:30 IST)on Skype
- On discussion with the mentors, we have decided upon a project management tool in which I will add the tasks, comment, update, and log time to each task. I will log time daily.
-Weekly blog posts. These blog posts will also provide support for writing documentation later for the module.

Why Me?
- I am already familiar with drupal and also securesite module, so learning period for me will be less and I can spend more time on coding.
- I am one of the maintainers of the module and have committed some code and submitted some patches for the module. -

I am Shivanshu Agrawal, a student of IIT Kanpur, India. I came across drupal for the first time when I was developing a wiki for the institute. Since then, I have been a follower of drupal and have also made more sites using it. I have always been a tech enthusiast and web technologies interest me the most. I am an active member of Navya(FOSS community of IITK which aims at increasing awareness about Open Source and quality of computing in the campus community. I am also the coordinator of Programming Club of IIT Kanpur which aims at improving the programming culture among students of the institute. Though I have not contributed much to drupal until recently, I have started and I am enjoying it. I am looking forward to an enjoyable summer with GSoC.

image00.png25.59 KB
image01.png33.85 KB
image02.png18.36 KB
image03.png34.58 KB