Drupalathon’ 17; Happy ending

It was a dream for me to conduct an event in my campus before I graduate (I guess all want something like that in their college life). It all began in late December 2016 where a group of  5 of us(Abhishek, Akash, Chiranjeeb, Prashant and myself) started thinking of a Drupal hackathon- Drupalathon’ 17 in our campus in connection with FOSS@Amrita, to help students get an overview of this powerful Content Management System(CMS) used by many exciting projects including The white house, Harward university, Grammy awards and so on.

We started contacting Drupal communities in and around India for sponsorships. The initial responses weren’t that great. At the same time, we got replies from Jet Brains and GitHub. We assumed it to be sponsorships as funding for the conduct of the event. But, they could only provide the stickers which we could distribute among the participants. Thanks to both these communities.

Months passed, we kept on contacting the local communities, not many responses and in March we could find an exciting update from the Drupal association itself who were ready to share our funding in the form of Community Cultivation Grant(CCG).

At the same time, we were also in talks with the local Drupalers in Bangalore and Trivandrum to find potential speakers who could lead the event. We finally ended up in Rakesh James from Valuebound whom I have met during DrupalCon Asia 2016 in Mumbai. The dates were initially set to March 25 but later on got shifted to April 22nd due to some permission delays.

But, at the last moment, Rakesh had to go to Baltimore to attend the Drupalcon which again brought new issues for us. We were feeling really down that we will lose all of our efforts if we couldn’t implement the plans effectively. To our good luck, Rakesh sorted out the issue by helping us get in touch with Nishant Kumar from his company. That was a huge relaxation for all of us from all the sudden happenings. He also got Chirag Shah, his colleague to help him for the event.

Again when it was nearing the event, April 22nd was declared as a working day,  making us more difficult for the event to occur due to the unavailability of the computer labs, duty leave permissions. We discussed with the speakers and they were kind enough to shift the event to the next day, Sunday, April 23rd.

We had 40 attendees for the event. It got started by 9:3 with Nishant Kumar introducing the participants to an overview of the Drupal ecosystem, its usability, how it stands apart from the current existing technologies. It was a totally interactive one with students raising their questions and clearing their doubts on the various aspects of this technology.

DSC_0339

Then Chirag joined Nishant with the installation of Drupal in the local systems. Most of them could install successfully by the lunch time. All were really enjoying the environment learning new things which could come into their real use may be once they start applying it.

IMG_20170423_135233The afternoon session mainly dealt with customizing the website and exploring the various cutting-edge features of this enormous CMS. Students also tried to work out some of them to enjoy the real beauty.

DSC_0298And it was really a happy ending for all of us. We got positive feedbacks from the participants and the speakers. We feel really proud to have conducted the event, breaking all the barriers and ending up a day, sharing the Drupal knowledge with the students of my campus. Thanks to FOSS@Amrita for all the support and encourage throughout entire planning and implementation phase of the hackathon.

Hope we could come up with more events in the future.

Advertisements

GSoC’ 16: Port Search Configuration module; coding week #9

I am part of the Search Configuration module porting process to Drupal 8 as part of the Google Summer of Code’ 16. I have been mentored by Karthik Kumar, Naveen Valecha and Neetu Morwani. If you would like to have a quick look at my works so far, please go through these posts.

The past week I worked on fixing some of the issues in the port process. Moreover, I could learn some important concepts in the process. I ported the helper functions of the search configuration settings to the form API.

Basically, settings were stored as helper functions in the Drupal 7 module. I ported the helper functions of the search configuration settings to the form API. Generally, forms are created and worked on using four important functions, namely, getFormId, buildForm, validateForm and submitForm. These definitions are stored in classes.

The basic format will be of the form:


use Drupal\Core\Form\FormBase;
 
use Drupal\Core\Form\FormStateInterface;
 
class searchForm extends FormBase {

 public function getFormId() {
    return 'search_form';
  }

  public function buildForm(array $form, FormStateInterface $form_state) {
    //create the form here.
    return $form;
  }

  public function validateForm(array &$form, FormStateInterface $form_state) {
    // Validate submitted form data.
  }

  public function submitForm(array &$form, FormStateInterface $form_state) {
    // Handle submitted form data.
  }
}

The getFormId() returns the unique id of the form. We need to write the features of the form in the buildForm(). It includes the structure of the form, various fields included and its corresponding types accepted. The validate form is for validating the contents entered into the form which is definitely an important part of any form. Finally, the submitForm() handles the works to be carried out once the user enters the data in the form fields.  This mode of arrangement of the form functionality makes it more standard and properly arranged.

Also, the deprecated functions were removed from the .admin.inc of the module. There were some underscore functions in the Drupal 7 module which supported the configuration and the form settings. These are to be added to the helper file of the module.

These were some of the basic functionalities I could work on and explore. Stay tuned for the future updates on this port process.

GSoC’ 16: Port Search Configuration module; coding week #6

Google Summer of Code (GSoC) is into the next phase of coding after the mid-Term evaluations which got over by June 27th. This also reminds students to speed up the coding activities to complete the projects within the schedules provided in the proposal.

I am porting Search Configuration module to Drupal 8 as part of this year’s summer of code. GSoC is definitely turning out to be a venue for the young students from universities around the world to work on real-world projects under the experience of well-known developers, learning new technologies, making use of version control systems, with regular meetings and finally building up a software which is going to help a large section of the society.

I blog regularly, sharing my project progress. If you would like to have a glimpse of my past activities on this port, please visit this link.

Drupal 8 has introduced the concept of Html twigs in place of the PHP templates. So, the PHP template files have to be now ported to the Html environment. The .tpl.php template file is replaced by the .html.twig file for the module templates.  Templates are simply text files which can give outputs in Html, Latex, CSV or XML formats.

To print some data, we usually take the service of echo statements in PHP.  The print statements are replaced by {{ }} in Html twigs.

<?php echo t(‘Let’s start the process.’); ?>

is replaced by:

{{ ‘Le’s start the process’|t }}

The variable names have to be converted to simple names. For instance,

$page[‘title’]

becomes

{{  title }}

The PHP logics have to be replaced by {% %} syntax. This is applicable to all the logical statements.

<?php if ($page[‘title]): ?>

…..

<?php endif; ?>

is transformed as:

{% if form %}

……

{% endif %}

Also, the variables are replaced by simple names.

<?php if ($logo): ?>

is transformed as:

{% if logo %}

These were some of the basic transformations to get started into created the HTML twigs.The use of the Html twigs has made the templates look very simple and easily understandable. It is really easy to get the templates converted to the Html twigs. This is always one of the crucial requirements of porting modules from Drupal 7 to Drupal 8.

Stay tuned for further updates on this port process.

GSoC’ 16: Port Search Configuration Module to Drupal 8 : Mid Terms

I feel really excited to have cleared the mid-Term requirement for my project in Google Summer of Code (GSoC). The results of the mid-Term evaluations were announced June 28, 00:30 IST. This was the evaluation for the first phase of GSoC. In this evaluation process, set up by GSoC organisers, students and mentors have to share their feedback about the current progress of the project. Mentors need to give a pass/ fail grade. Students can continue coding once they clear the evaluations successfully.

I have been working on Porting Search Configuration module to Drupal 8. Please go through my previous posts if you would like to have a look into the past activities in this port process.

Last week I worked on testing some of the units of this module using the Php unit tests framework. Testing is an important process when it comes to any software development process. It plays a crucial role for any software. It helps us to understand the improve our software to the required level by making use of various test cases. We input various values and check whether the tests are passed according to the requirement. If any condition fails to our expectations, we need to make the required changes to suit the application needs.

Php unit tests are generally used to test some units of an application. To check whether the functions implemented gives the expected output, behaviour of the functions in various test cases, giving different types of arguments as inputs to check the errors or flaws for improving the application.

We need to install the Php unit for this process. You could follow this documentation for this process. Furthermore, they give a detailed analysis of the Php Unit Tests.

Once the installation is completed, we can start writing the unit tests for the functionalities we have implemented. The tests are generally stored in the tests/src/Unit directory of the module. The name of the unit test file will be of the format xyzTest.php. All tests are suffixed by ‘Test’. ‘xyz’ can be replaced by the functionality you are going to test.

The following is a simple test to check the sum of two numbers: sumTest.php

<?php
class SampleTest extends PHPUnit_Framework_TestCase
{
  public function testSum()
  {
    $this->assertEquals(2+2, 4);
  }
}
?>

As mentioned in this above code snippet, we need to create a class, with class name suffixed by ‘Test’ which is an extension of PHPUnit_Framework_TestCase. Now, we need to write the tests inside as member functions. The functions starting with the name test are executed. Here we are checking the sum of the two numbers. This is a very simple demonstration.

The tests are run by using the command PHPUnit. i.e,

$ phpunit tests/src/Unit/sumTest.php

The output generated on running the above test is:

PHPUnit 5.4.6 by Sebastian Bergmann and contributors.

. 1 / 1 (100%)

Time: 252 ms, Memory: 13.25MB

OK (1 test, 1 assertion)

Stay tuned for future updates on this module port.

 

GSoC’ 16: Port Search Configuration module; coding week #4

Google Summer of Code (GSoC), has entered into the mid-Term evaluation stage. This is a 1 week period from 21- 27 June, were students and mentors present the progress of their projects. Based on the reports submitted, students are made pass/ fail.

I have been working on porting Search Configuration to Drupal 8 in the past few weeks. If you would like to have a quick glimpse of my past activities on this port process, please go through these posts.

last week, I could learn some Drupal concepts which were really helpful for my project. In the previous versions of Drupal, the role permissions were stored in a role_permissions table in the Database. But now, in Drupal 8, the role permissions are directly stored in the role configuration entity.

So, as described above, in D7 and its preceding versions, role permissions were stored in a role_permissions database which had the role Id and the corresponding permissions. The permissions distributed to a role was retrieved in D7 using:

$permissions = role->getPermissions();

But, in D8, this is done by the

$permissions = role->getPermissions();

Another instance is that, to grant certain permissions to roles.

In D7 it was controlled by,

user_role_grant_permissions($rid, array(‘ access content’));

The role configuration entity remodels this functionality in D8 to:

$role->grantPermission(‘ access content’);

In connection with the term permissions, the most important aspect in Drupal is a hook: hook_permissions(). This hook, obviously as you might have guessed, distributes the permissions to various users; decides whether a particular user should be allowed to access a page or a content, granting and restricting the access.

This hook has been replaced in Drupal 8 by a module.permissions.yml file. This file contains the permissions and its specifications. We can write a driver function in a php file to add the dynamic permissions. This can be achieved by making a driver class in the php file and adding the behaviour of the permission we need in the member functions of the class. We also have to link this PHP file with our yml file to keep it active. This is done by adding a callback function in the yml file which references this php file.

To display special characters in a plain text string for display as HTML format, Drupal earlier versions used the function check_plain.  This had the general syntax:

check_plain($text); // where $text was the string to be processed.

This function has got deprecated in Drupal 8. This has been replaced by the \Drupal\Compoent\Utility\Html::escape($text).

I will be back next week with further updates on this port process.

 

GSoC’ 16: Port Search Configuration module; coding week #3

Google Summer of Code (GSoC’ 16) is entering into the mid-Term evaluation stage. I have been working on the porting search configuration module for Drupal for the past three weeks.

Search configuration module helps to configure the search functionality in Drupal. This is really an important feature when it comes to a content management system like Drupal. I am almost mid-way in the port process as indicated in the timeline of Google Summer of Code.

It is really a great feeling to learn the Drupal concepts this summer. I would like to take this opportunity to share with you some key aspects I had to deal with in the past week.

Once a module is installed and later on if some changes are amended, we need not rewrite the Drupal code. Instead, Drupal gives up the option to make use of a hook, function hook_update_N which helps us to write the update needed and the database schema gets updated accordingly. Currently, since my module is just going into its first release after this port process, I need not write an update function. I just have to make this update in connection with the earlier code. The same hook works for both Drupal 7 and 8.

Another feature is the hook_node_insert, this hook is invoked to insert a new node into the database. So, here we are writing into the database a drupal record. In Drupal 7, this insertion was done by the drupal_write_record(). But,in D8, it has been replaced by the merge query and the entity API. The merge queries support the insert and update options to the database.

In connection with the nodes, another hook function is the hook_node_update. This functionality updates the node contents which has been inserted into the Drupal record (database). This takes in an argument, obviously,  the node has to be passed, for which the updating is intended.

The hook_uninstall gets invoked as the name suggests, in the uninstall process of the modules. The hook removes the variable used by the module so as to free the memory. It also modifies the existing tables if required. The D7 version of Drupal used the  variable_del for removing the variables.

For instance,

variable_del($nameOfVariable);

// Drupal 7 code

This has been replaced by the delete() of the configuration API.

i.e,

\Drupal::service('config.factory')->getEditable('search_config.settings')->delete();

search_config.settings is the default configuration file.

I will post the updates on this port process regularly. Please wait for the future posts.

GSoC’ 16: Coding Week #2

Google summer of code (GSoC) seems to be a venue for students to get in touch with new technologies and be a part of many interesting open source organisations. Thanks to google for co- ordinating this initiative.

The last week was really a productive one for me in all aspects. I could manage time better to focus more towards my project. The climate here seems to have improved a lot. It’s now rainy here which has reduced the hot and humid climate to a large extent. My geographical location, Kerala, the southern part of India usually faces a fair climate.

If you are searching for a flashback of my previous GSoC’ 16 ventures, please have a look at these posts.

So, as you were expecting, now let’s talk about my activities in the second week of GSoC. The second week commenced with a bit more elaborative planning of the tasks to be carried out in the coming days. My main intention for the week was to discover more Drupal hooks and adapt it to my project code.

Wondering, what are hooks?

Hooks, in the simple definition, are PHP functions which have an inbuilt meaning given by Drupal to interact with modules. They also give us the freedom to extend the functionalities. The api.drupal.org gives wonderful explanations about the various hooks in action and their modifications that have come in the different Drupal versions.

Topics I have covered:

I would like to take this opportunity to share with you some of the concepts I could grasp from the previous week of GSoC.

  • hook_install
    • This performs the setup tasks when the module is installed.
  • hook_schema
    • This hooks the database schema for the module. This is invoked once the module is enabled. This resides in the .install file of the module.
  • hook_theme
    • This is for enhancing the module’s theme implementations.
  • hook_permission
    •  This hook defines the user permissions of the module; granting and restricting permission to the roles.
  • Configuration API
    • The Drupal variables are replaced by the configuration API.  You need to define the properties and default values in the new format.

Hoping to learn more Drupal concepts in the days ahead. I will be posting the updates regularly. Stay tuned for more Drupal concepts.