The reason behind developing this project was to ease the process of connecting to VPN. In my daily work I constantly required a VPN connection, Cisco AnyConnect client was the obvious choice but because I was facing some issues installing the same in Ubuntu so instead I choose openconnect. After following below-mentioned step, I am now able to get connected to a VPN using few mouse clicks.

System Requirements

Currently I have tested this only on ubuntu 16.04, hopefully, in coming days I will be adding installation instruction for other OS too.

Installation

Install expect using this command: sudo apt-get install expect

Steps for installing openconnect:
  First run command below to active th TUN module: sudo /sbin/modprobe tun
  Install OpenConnect: sudo apt-get install openconnect

Download this module and make openconnect script executable like this: chmod +x /path/to/openconnect.sh

Change these variables: GATEWAY, UBUNTUPASSWORD, USERNAME, PASSWORD present in script (openconnect.sh) as per your environment.

Run the script like this: ./openconnect.sh, this is when you are in the root directory of the module otherwise add path to your module.

Now we have to install Nautilus-Actions Configuration Tool, type this in the terminal: sudo apt-get install nautilus-actions

Launch the Nautilus-Actions Configuration Tool from the Dash after installing it.

First, click the New Action button on the toolbar and type the name of your action into the Context Label box, may be something like this: Connect to VPN

Click the Command tab and in Label box enter any suitable name like VPN and in Path box this: /usr/local/bin/vpn

Since we would need terminal for executing our newly created vpn command, in nautilus-actions tool, go to Edit > Preferences > Runtime Execution. In the "command pattern" field, enter: gnome-terminal -x sh -c COMMAND

Now we need to restart nautilus typing this command in the terminal: nautilus -q

After this you can access your newly created vpn command on right clicking under Nautilus-Actions actions.

Link to repo. Happy browsing

Recently the team with whom I work was assigned a task in which a business application was supposed to be built. After doing some research and after a lot of discussions we decided to use Bonita BPM.

Due to the intricacy of the task in hand and many more reasons (about which I may write in a different post) we decided to use UI Designer feature available in Bonita BPM studio. As this post is not about why and how to use Bonita so I will delve directly into issues which I faced and possibly found a feasible solution to it.

Before I start, I would like to say thanks to team at BonitaSoft for creating this wonderful software.

The UI designer allows us to create pages. These pages basically consist of widgets (both custom and few inbuilt by Bonita). In these pages, we can add assets (javascript, images, and CSS) both at page and widget level. In my use case, the application which we had created was mostly making use of custom widgets. The count of such widgets was nearly fifty(50). The problem was not due to count of these widgets instead of the way in which these widgets are rendered in a page created by Bonita. A custom widget in Bonita majorly consists of a template which describes the HTML markup of the widget and a controller used to describe the widget logic. When these widgets are added to a page, Bonita BPM engine basically adds a source to these widgets in a script tag. To have a clear understanding how it is done in HTML please refer the below image.

So now if there are N number of custom widgets then there would be N number script tags which basically means N number of HTTP requests for a page to render. In a real world application, these many calls are certainly obnoxious and bad for user experience. So how to solve this problem ?

Obviously the solution was to concatenate these individual js files and then minify them. To perform this action we decided to use Grunt as we were already using it as a task runner and this is when I learned how to create a task in Grunt. Grunt is basically a task runner which is used to automatically perform periodic tasks like concatenating and minifying files. So now what I did was created a task in grunt whose job was to concatenate these individual js files and minifying them, here is the link to part of my Gruntfile.js file which performs this task.

Task in grunt was ready and seemed to work perfectly only problem was how to use it with my python script. Since I have not before mentioned about my python script so explaining the same, the job of this script was to provide an unzipped version of the folder imported from UI designer with links to assets corrected in accordance with path to my main project directory.

Since now I had a CLI for executing Bonita related task in grunt and python script which allowed me to import application in my web page, so I decided to make a call to grunt task from my python script using call command in python. Please refer this link in order to understand working of python script. Now I have to simply run the script on the imported ZIP folder provided by Bonita and get an optimized version of the page. Please see below to have a look into the reduced number of HTTP requests.

I know the above approach may not be the best way to solve this problem hence it would be really helpful if other people can suggest changes or any other solution. Anyways I had a wonderful time solving this issue as I learned how to create tasks in Grunt and eventually calling them via the almighty python.

P.S. I had created a similar task in Grunt for optimizing CSS files (refer link to grunt file present above), the present python script already calls this task when executed.

P.P.S. The above Grunt task and python script obviously can’t be used in every scenario but I think they can easily be tweaked as per environment in order to make it work.

I am writing a post nearly after a gap of one year, reason being I had been busy in various college activities. Recently I joined a company as an intern where I am working in their backend team. The title of post already suggests about it's content but before diving into it, I would like to discuss the reason for developing Termipull. Like many other people, the code collaborating platform which I used in my daily work is Bitbucket.

The workflow which I follow in my day to day work is that when I am working on a new feature or a bug, I create a new branch from my master branch and make require changes in the code while staying in the newly created branch. Once I am sure about the code, I commit those changes. After committing those changes the only things remaining to do are pushing those changes to the branch I am working on and then finally making a pull request. Obviously before making a PR you want to be sure that your current branch is UpToDate with your origin's master.

The reason for making Termipull was to save the amount of time which I was wasting while making a PR. The process of making PR on bitbucket is cumbersome because for pushing the commits you every time need to enter your username and password and once you have done this in order to finally make a PR you need to use Create pull request button present on the create pull request, web page of your forked repository.

So in order to save my time I decided to create Termipull. Right now it has been made to suite my needs in my current workplace but anyone who is familiar with git and after reading the documentation can modify the code according to their requirement.

The code currently present has not been properly tested and does not raises error or checks for error. It is something which I would be adding in coming days. Also it is humble request to make suggestions and point out errors to make the Termipull more better. Any help in improving Termipull is appreciated.

This post is about the progress which I have made while porting print module to Drupal 8 as part of GSoC 2015. Below is an excerpts about the work done in week twelve while work done in week eleven can be tracked over here.

The GSoC coding period is coming to end and it feels good to say that past twelve weeks have been very productive and satisfying experience for me. During the coding period I learnt about so many new things ranging from important things like usage of composer to include external dependencies, using twig templates to render content, cache usage in Drupal, third party integration in Drupal to minor things like using Asana to manage project’s progress, making use of pull requests on GitHub, writing blog and many other such things. The work involved during the coding period was very interesting and as a result I managed to maintain a streak of 69 days on GitHub(the streak is still active). I would also like to thank Drupal community for clarifying my doubts and providing me help whenever I made a noise on IRC.

During the coding period IRC channels (specifically #drupal-contribute and #drupal) and drupal.stackexchange.com came to my rescue a lot so I would recommend any newbie to use this whenever they face any problem. I would like to say thanks to my mentors(Erik, João) from bottom of my heart who helped me in both coding and managing the project. Also I would like to say thanks to slurpee and cs_shadow who weekly used to take time out of their busy schedule and monitored the progress of the project.Since now I have worked under a mentor, I have now realized that mentoring is not an easy job since people volunteer to mentor take extra time out of there daily busy schedule. I also think that people who volunteer to mentor are amazing because they do this to show their support to open source and not because it involves some kind of monetary benefits.

Now talking about the stuff which I did this week, since most of the objectives of the project were completed last week itself so this week I spent I lot of time in cleaning up the code and doing proofreading. One more important thing which was remaining was to move the code to drupal.org. I managed to do this task this week and presently the printable module can be accessed over here while the pdf_api module can be accessed over here. I must say it was a very proud moment for me when I moved the code for the modules on d.o because after doing that I officially became co-maintainer of two modules on Drupal.

In coming days my objective is to add description about the module on the project page so that it may be easier for people to use the module. One more thing which I will be doing is to do more proofreading so that any remaining problems are rectified. Since managing and doing review of the project present on GitHub is more easier compared to d.o hence in coming days more active development of the module will be taking place on former and the newly introduced changes will eventually be committed to drupal.org.

The printable module can be accessed by visiting this link and pdf_api module can be accessed by visiting this link.

This post is about the progress which I have made while porting print module to Drupal 8 as part of GSoC 2015. Below is an excerpts about the work done in week eleven while work done in week ten can be tracked over here.

Since most of the important expected features in the PDF sub module were completed last week therefore this week as asked by the mentors, time was spent in proof testing the working of the module. The way it was supposed to be done was very interesting and unique for me because I was asked to create a PDF based on the material used previously by the mentors while dealing with a client. The demo PDF can be seen over here.

The PDF was supposed to be created keeping in the mind that it should be comparable to a document which can be used in the daily office work. The content of the PDF was supposed to contain text of various sizes and color, images of various formats, tables and HTML supported header and footer. Also one more thing was supposed to be kept in mind while making the PDF that as a user of the module I was not suppose to make too many changes in the present code while trying to implement advance features. This was important from real world perspective too because in daily usage too as a user we expect the module to provide us all the functionalities and not needing to interfere with the original code.

The expected PDF was created without making any advance changes in the code of the module hence assuring the fact that the module at present can be used in its development release. The created PDF can be seen over here. Since a modified footer was expected to used in the demo PDF hence I made a small change in the code where I am calling PDF generator object from the printable_pdf module. The introduced code is as follow:

$this->pdfGenerator->getObject()->SetFooter('This is a footer on left side||' . 'This is a footer on right side');

This week I also added another important test in the module which tests the rendering of PDF. The test can be seen over here. The way this test was implemented was totally new to me because this test has an external dependency on PDF parser library whose job is to convert PDF to text. So the test firstly saves the PDF in a particular location then with help of this parser converts it to text. The text now is used to create a new node where the content is asserted for main body of PDF along with header and footer. The way PDF parser extracts the text can be seen below in the code and remaining portion of test can be viewed via the above link.

$this->drupalGet('printable/pdf/node/' . $node->id());

$parser = new \Smalot\PdfParser\Parser();
$pdf    = $parser->parseFile('modules/custom/printable/src/Tests/testPDF.pdf');
$text = $pdf->getText(); </code>

Next week more focus will be on improving the quality of current code and improving the code standard by running the code sniffer. Some progress of PDF part of module can be viewed over here and remaining over here.

This post is about the progress which I have made while porting print module to Drupal 8 as part of GSoC 2015. Below is an excerpts about the work done in week ten while work done in week nine can be tracked over here.

This week I mainly worked on the issues raised by the mentors and also completed some more functional tests. The issues related to pdf (api) module can be seen over here while issues related to printable modules can be seen over here. One of the interesting task was to make the option to configure binary file of wkhtmltopdf library available as a field in the PDF configuration form.

Since the field to configure binary file of library should only be shown to user if wkhtmltopdf class is present in the drupal environment hence I made use of ClassLoader::classExists(); to check presence of library and then accordingly making the field available. So my final code looks something like this:

$wkhtmltopdf_present = ClassLoader::classExists('mikehaertl\wkhtmlto\Pdf');

  if ($wkhtmltopdf_present && $pdf_tool == 'wkhtmltopdf')

    $form["settings"]['path_to_binary'] = array(

    '#type' => 'textfield',

    '#title' => $this->t('Path to binary file'),

    '#default_value' => $this->config('printable.settings')->get('path_to_binary'),

    '#description' => $this->t("Enter the path to binary file for wkhtmltopdf over here."),

   ); </code> 

Another way to implement this could have been by installing library module and then making use of libraries_get_path() function, the reason this method was not preferred because currently library module for Drupal 8 is still in development phase and also it is not sure where the installed external libraries for the modules would be kept. In Drupal 7 external libraries were kept in libraries folder but this may change for Drupal 8 in future.

Details about other issues which I managed to solve this week can be seen in the recent commits which I have made over here. This week I also managed to write functional tests for checking presence of links in the node view and check configuration form of PDF, these can be seen over here.

Some progress of PDF part of module can be viewed over here and remaining over here.

This post is about the progress which I have made while porting print module to Drupal 8 as part of GSoC 2015. Below is an excerpts about the work done in week nine while work done in week eight can be tracked over here.

This week I again re-visited PDF generating libraries. And this time I managed to add dompdf to PDF submodule. It is an HTML to PDF converter and is compliant with CSS 2.1. The library is available on GitHub over here and was easily installed via composer by adding following lines as a requirement in composer.json file of the module:

{

"require" : {
   "dompdf/dompdf" : "0.6.*"
}

} </code>

The library makes use php-font-lib hence when we are installing library using composer it is recommended to set parameter DOMPDF_ENABLE_AUTOLOAD defined in the dompdf_config.inc.php file to false. This was done by adding following lines in the generator

define('DOMPDF_ENABLE_AUTOLOAD', false);

require_once ‘/path/to/vendor/dompdf/dompdf/dompdf_config.inc.php’; </code>

After following the above procedure I was finally able to generate PDF for my node’s content. It is one of the problem of this library that it does not supports rendering of SVG images but the themes logo which are present in Drupal 8 are of SVG type hence they are not able to render themselves in the PDF. I am still searching a solution for this but currently it seems that the user who wants to have a logo in the PDF will have to themself convert SVG to any other compatible formats like png or GIF. The dompdf generator still lacks function for generating header and footer which I will be adding in coming week.

In this week I was able to add some more unit tests in the module mainly related to testing of configuration of tabs and block generation. The tests can be browsed over here. Next week after completing the dompdf generator I will be taking care of some of the loose ends present in the code and then will be adding some more functional tests.

Some progress of PDF part of module can be viewed over here and remaining over here.

This post is about the progress which I have made while porting print module to Drupal 8 as part of GSoC 2015. Below is an excerpts about the work done in week eight while work done in week seven can be tracked over here.

This week I invested again most of the time in writing some more tests for the module (my previous attempts at writing unit tests can be seen over here). But this time I learned to write some functional test. In Drupal if you want to write functional test then Simpletest is the required testing framework. We don’t need to worry about installation of Simpletest framework because since the release of Drupal 7 it comes already with the core and in Drupal 8 since it is not enabled by itself so you need to enable it by heading to /admin/config/development/testing.

Running the functional tests in Drupal 8 is very easy and they can be executed using both command line and user interface. All the tests written for the module must be kept within the src/Tests folder of the module so that Drupal recognizes your test. Though a very good explanation about functional tests in Drupal 8 is present in drupal.org over here still I would suggest you to refer to this link for seeing some really good tests being written for a sample module.

Most of the knowledge required to write functional test are present in above posted links but I would like to share with a code which I wrote to test the existence of printable version of nodes. Below written code is only portion of test which I had written under the class name PrintableNodeTest. I have extended the NodeTestBase class present in the core for this particular test in order to reuse the preprocessing work done by the latter class.

public function testCustomPageExists() {

  $node_type_storage = \Drupal::entityManager()->getStorage('node_type');

  // Test /node/add page with only one content type
  $node_type_storage->load('article')->delete();
  $this->drupalGet('node/add');
  $this->assertResponse(200);
  $this->assertUrl('node/add/page');
  // Create a node.
  $edit = array();
  $edit['title[0][value]'] = $this->randomMachineName(8);
  $edit['body[0][value]'] = $this->randomMachineName(16);
  $this->drupalPostForm('node/add/page', $edit, t('Save'));

  // Check that the Basic page has been created.
  $this->assertRaw(t('!post %title has been created.', array('!post' => 'Basic page', '%title' => $edit['title[0][value]'])), 'Basic page created.');

  // Check that the node exists in the database.
  $node = $this->drupalGetNodeByTitle($edit['title[0][value]']);
  $this->assertTrue($node, 'Node found in database.');

  // Verify that pages do not show submitted information by default.
  $this->drupalGet('node/' . $node->id());
  $this->assertResponse(200);

  $this->drupalGet('printable/print/node/' . $node->id());
  $this->assertResponse(200);
  $this->assertRaw($edit['title[0][value]'], 'Title discovered successfully in the printable page');
  $this->assertRaw($edit['body[0][value]'], 'Body discovered successfully in the printable page');   } </code> 

I hope comments present in the code are sufficient to understand the working of code but still anyone willing to learn more about it may refer to this link where functional tests for the module are being currently written. Next week I will be writing some more functional tests and then proceed to adding dompdf library to PDF sub module.

Some progress of PDF part of module can be viewed over here and remaining over here.

This post is about the progress which I have made while porting print module to Drupal 8 as part of GSoC 2015. Below is an excerpts about the work done in week seven while work done in week six can be tracked over here.

Last week I managed to finish work on mPDF and TCPDF generator and also most of the requirements for the pdf sub module were completed. So this week I started writing some unit test for the module. Writing tests for the module was a totally new experience for me because earlier the tests which I had written were mostly for the issues on drupal.org hence they were not that much complicated.

Ofcourse before starting to write some unit tests I tried to understand the concept by going through several resources but the best material is present over here in my opinion so any one willing to learn the concept of unit testing may refer to same. Going through the unit test present in module residing within the core will also help. Refer to this link if you want to learn how to run them.

Currently it is one of the issues of the core in Drupal 8 that the unit test present within a module residing inside the custom folder will not be identified by this command ./vendor/bin/phpunit/phpunit/phpunit –list-groups. The problem lies inside the phpunit.xml.dist file present within the core. If you change the line which says ../modules/custom/tests/src/Unit to ../modules/custom/*/tests/src/Unit then your problem will be solved and unit test written for your module will be identified by the core.

Most of the concept and knowledge required for writing unit test can be obtained through above links hence I do not intend to write about them but some code for which I had to do some additional search I would like to mention about them below:

Mock object which support chaining methods:

$routematch = $this->getMockBuilder('Drupal\Core\Routing\CurrentRouteMatch')
  ->disableOriginalConstructor()
  ->setMethods(array('getMasterRouteMatch', 'getParameter'))
  ->getMock();
$routematch->expects($this->exactly(2))
  ->method('getMasterRouteMatch')
  ->will($this->returnSelf());
$routematch->expects($this->exactly(2))
  ->method('getParameter')
  ->will($this->returnValue($this->getMock('Drupal\Core\Entity\EntityInterface')));

Disabling original constructor of class while calling them:

$entity_definition = $this->getMockBuilder('Drupal\Core\Entity\EntityType')
  ->disableOriginalConstructor()
  ->getMock();

I would recommend anyone willing to learn more about this code refer to this link where unit tests for printable module are being actively written. Next week I will be writing some more unit tests and then try to wrap up PDF sub module.

Some progress of PDF part of module can be viewed over here and remaining over here.

This post is about the progress which I have made while porting print module to Drupal 8 as part of GSoC 2015. Below is an excerpts about the work done in week six while work done in week five can be tracked over here.

Last week I had managed to finish work on wkhtmktopdf generator so this week I started to work on mPDF and TCPDF generator. This week was different compared to weeks because midterm evaluation had to be completed about which I was excited in an unusual manner.

The present printable module differs a lot from it ancestor module print mainly speaking with respect to its current architecture. One of the major changes introduced is keeping a separate module pdf_api outside of printable module. So in the present scenario all the preprocessing required before actual PDF to be generated is done in printable_pdf module which is a sub module of printable module and all the calling required to function of PDF libraries is done in pdf_api module. So in this way user only need to be majorly aware of one module(printable_module) where configuration settings of PDF is being taken care.

The module is currently making use of repos present at these links mPDF and TCPDF to generate PDF. Since this week generators for both mPDF and TCPDF were completed so naturally it was obvious that I was curious as to why we require both of these libraries. On searching a bit I found out on this link the majpr points in favour of both the libraries.

Some of the major points in favour of TCPDF were that it natively supported SVG format along with text and element strokes while mPDF could be favoured because it fully supported CSS3 hence it rendered far superior quality HTML templates.

The module currently provides user with options like to either save or show inline the PDF, select various page sizes, choose different orientations and set a header and footer. Since the header and footer which are being rendered currently are not configurable right now hence I will be making then configurable next week.Along with that I have planned to write some tests so that module’s working status can be verified.

Some progress of PDF part of module can be viewed over here and remaining over here. Some of the pull requests made during development can be seen over here.

This post is about the progress which I have made while porting print module to Drupal 8 as part of GSoC 2015. Below is an excerpts about the work done in week five while work done in week four can be tracked over here.

The week five of coding period ended and as planned I started to work on generating PDF using third party libraries after fixing some errors and code style in the module coded till now. As expected the week turned out to be very eventful and very exciting for me atleast because I really like the idea of interfacing Drupal with external libraries and tools, mainly because it makes Drupal more useful and easier to use.

The first external library which I am using to generate PDFs is wkhtmltopdf. The library is an open source command line tool which renders HTML into PDF. It runs headless and do not require a display or display service. The library is awesome mainly because quality of PDF generated by this is far superior than other PDF generating libraries.

Since the amount of intial work invloved before actually getting a PDF format of HTML content was extensive so I am using a PHP wrapper for the same. I had option of either using phpwkhtmltopdf or snappy. After using both I decided to go with former mainly because of the large number of utility functions provided by the wrapper and easily followable documentation.

Selecting wrapper was only a start, I had initially tested the library using some random HTML document (it didn’t involved interface of Drupal) and the result were as expected. But when I tried to generate PDF via rendering of HTML content generated by twig template a network error kept showing: ContentOperationNotPermittedError

By doing a lot of debugging I came to conclusion that presence of base tag in twig template was causing problem. On removing it the error does not shows up and PDF is generating successfully. Since I think this is problem of binary file of library so I created an issue for same in both wrapper and library repo on GitHub.

Since this week I was able to create plugin for wkhtmltopdf libary so next week I will be focussing on resolving any further issues which I face while using this plugin and also start to work on generating plugin for mPDF library.

Some progress of PDF part of module can be viewed over here and remaining over here.

This post is about the progress which I have made while porting print module to Drupal 8 as part of GSoC 2015. Below is an excerpts about the work done in week four while work done in week three can be tracked over here.

The week four of coding period has ended and most of the time was spent in doing code refactoring. This week I was mostly focused in completing the deliverables which I had proposed in the project’s proposal. As proposed I was able to complete print module core along with print HTML module.

Though most of the code was completed in last week but it lacked efficiency and robustness so a lot of time was spent in refactoring. Many places where procedural calling of function was being done was replaced by Dependency injection, instead of doing preprocessing in the twig templates the code for same was moved to module file. One of the important change which was brought was to use JavaScript in place of jQuery. In Drupal 7 jQuery was included in the page by default while rendering which means using JavaScript or jQuery didn’t made any difference but in Drupal 8 since loading of jQuery has been made optional so using JavaScript for writing less complex scripts was the obviously the best choice. I must thanks to my mentors who did a thorough code review this week and helped me improved the quality of code.

In this week User Interface of module was also implemented. The UI is still incomplete because pdf generating version of module is still remaining which is the major task in coming weeks. Since pdf generation will involve using third party libraries like wkhmltopdf so I have started to generated pdf file using them without Drupal so that I may be able to understand there working.

This week something even more exciting happened, I managed to break my previous longest streak of seven days on GitHub. The present streak is of thirteen days and which I do not want to break any time soon.

The progress of module develpoment can be viewed over here.

The week three of coding period has ended and this time I learnt about something very new to me, Twig template. In Drupal 8 Twig has replaced PHPTemplate as default templating engine which meant that the theming of module had to be done from beginning.

Also since my module deals with creation of printer friendly version of nodes so it makes it even more important that theming should be paid more importance. The reference material present on drupal.org are good but still the things were not getting clear to me so I browsed more and more and finally found this small blog on Twig which helped me understand.

In the process of learning theming I learnt about concept of rendering in Drupal and most importantly about invalidating catching while rendering, I mainly used getListCacheTags() to serve my purpose. Also knowing the that I can use template_preprocess_module() to create temporary variables and then rendering them in my templates was very helpful.

In the present week I managed to develop a partial working prototype of module with not all but many configurations completed like links for printer friendly version are being shown in blocks as well as below the entities. Ofcourse the user can disable and re-enable these links. I have created view modes for the print version and hence generated core.entity_view_mode.$entity_type.$view_mode.yml file. I was impressed by the fact that I had to import configuration for this file becuase it was something very new to me.

Next week I will mainly be working on completing the configuration of module and try to rectify the problem which I have found in this week.

The progress of module develpoment can be viewed over here.

The second week of coding period has started and its time to be more serious. But along with being serious I must say that I have began to like Drupal 8 mainly because of object oriented approach required to be used while coding and various APIs present in it which makes our work a lot easier.

Even though I am saying that the APIs have made our work a lot easier but I forgot to tell you that finding a particular API that may come in handy in a particular situation is not easy mainly because of large code base of Drupal. Also as per my experience till now following object oriented approach of programming is difficult in the beginning but after some time we get used to it and eventually begin to like it.

In the second week I had two meetings with my mentors. During the meeting I came to know about this wonderful CodeSniffer available at this link. I think it can prove to be very helpful to other GSoC students too because since as a newbie we make mistake in following Drupal 8 coding standards and this tool can prevent that from happening. Also my mentors told me that adding comments like @todo and/or mock class/method/function to mark loose ends in the code always makes the task of module development easier in the latter stages.

The task completed in this week were carried out as stated in the proposal. The functions being called in the controller were completed. The plugin which would display a printable version of page was also implemented. A lot of changes were made in the schema file of module because of inclusion of various setting options in the module. A base class for plugins was created whose main job was to generate HTML output of page and pass it to the reponse object.

The module makes use of Html Page Crawler in order to do pre-processing on the node, the details about which I will be posting in my next blog. For the next week I have planned to complete configuration setting provided for the printer friendly version of module and also providing configuration tabs for other plugins.

The progress of module develpoment can be viewed over here.

The coding period for GSoC 2015 started from 25th May which means that student are expected to start writing the code for their proposed projects.The start of coding period always bring excitement and anxiety within the students because they know that code written by them would be for the first time used by so many people.

I was too excited by the beginning of coding period but the feelings were subdued a little bit because my end sem exams were starting from 27th and coding period from 25th. But the fact that I had started to work on project a little early and support from my mentors (Erik, João) helped me to complete the project part which I had proposed to do during the first week of coding period.

I had a meeting with my mentors on Skype on the day coding period started and we discussed about the architecture of module and other minor important things like platform over which module should be developed, name of the module.Also during the meeting the name of module was decided as “printable”. The name cannot remain as print because Symfony considers it as a reserved keyword.

During the first week of coding period, I took some time to design the configuration form of the module. I managed to figure out that since in Drupal 8 so many things have been made as an entity so the print friendly version must be possible for many of them.

Finally I am populating only those entities in my form which has render controller as view_builder. Initially the module will be providing users with options like opening the print version on new/same page,option to add your CSS. The controller for the module has also been created but the functions called in them still needs to be completed which I have planned to complete next week.

By the end of week I also figured out that for providing the link to printer friendly versions of various entities like comment, content, user blocks can be used because they can prove to be very user friendly and also they go along with architecture of Drupal 8. I have currently started to complete functions used in controller and hope to complete those along with a plugin for the block in coming week.

The current develpoment of the module can be watched over here.

Hello every one my association started with Drupal started a year ago when I became an intern at Marg Software Solutions. This company is too much diversified and there are the various genres in which it caries out its business. The department under which I got to work dealt a lot with open source stuff and I was lucky to get the opportunity to work on Drupal related projects.

Since the last few months I have not only learnt a lot about building sites using Drupal but also most importantly realized the magnanimous influence of open source community in today's world. I learnt that there is a whole large community consisting of people who are working out of their interest in order to develop this content management system.

When I learnt about this community then it kind of opened my eyes and as a result of which I too made up my mind to start contributing to this wonderful open source project. Obviously before starting to contribute you need to learn about several tools and technologies but that also isn't a problem as some wonderful members of this community have made several tutorials which makes the task of contributing very easy.

I may assure you all who want to contribute to this open source project that there are several resources present,some of these are present on Drupal main sites and other are present on various other sites description about which I will be providing in a different tutorial.

In recent few months I have tried contributing to Drupal and find out the best possible way for a novice to contribute is by solving issues and try submitting patches. Since the day I came to know about this open source concept I have always wanted to contribute towards this.So here I am wanting to spread knowledge about Drupal using tutorials to teach people how they can solve an issue.So wait for my next post for diving into world of Drupal ...

Next