Jun 21 2016
Jun 21

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).

Jun 12 2014
Jun 12
Blog Drupal

In multi user systems, it's usually much safer not to let users change the contents entirely in case there was a mistake or when it was needed to know what has changed by whom and revert the change if required. Drupal supports content revisioning and there are already some contributed modules that exploit this extremely useful feature like revisioning. However when it comes to content deletion, revision system can no longer be used because when a content is deleted, it gets removed from database entirely including all its revisions.

Entity soft delete has been developed to address this limitation. Luckily prior to developing this module another similar module had already existed (killfile) but killfile unfortunately supports only nodes. So i started from there and rewrote most part of it to make work for all entity types

I usually do not fork open source projects and try to contributed back to the orginal module since i beleive forking is allways the last option because it can waste lots of valuable resources. In this case i did not intended to publish the result since it was quickly developed to be used on one of my projects. Now even if the current maintainer of killfile accepts the patches, it's really difficult to port it back since many things have changed. And it was too useful not to publish it :)

You can read more about what this module is capable of here : https://drupal.org/project/entity_soft_delete

Jun 04 2014
Jun 04
Blog Drupal

Currently Drupal core does not offer any hook to do actions after a node/entity is inserted/updated/deleted in Database. So for example you can not send an email mentioning the node after the node is inserted because Drupal uses SQL transactions and the node is not yet fully written to database when hook node presave is called so if for any reason the transaction is rolled back, users will receive a false mail.

So Hook Post Action module introduces several new Drupal hooks to overcome this limitation
  - hook_entity_postsave
  - hook_entity_postinsert
  - hook_entity_postupdate
  - hook_entity_postdelete
  - hook_node_postsave
  - hook_node_postinsert
  - hook_node_postupdate
  - hook_node_postdelete

May 19 2013
May 19

In Drupal there are many different methods to turn long forms into multipage/multistep forms. The most known one is perhaps the great ctools module or even custom solutions using Drupal’s form API. However as you may agree with me none of these solutions are really that easy, specially when it comes to Ajax. Therefore many developers in Drupal community tried or still trying to find an even easier method. What I’m going to introduce to you is yet another magical method :).

Hopefully for content types (entity bundles) in Drupal we have Field Group module which can do lots of things including turning simple forms into multipage forms without a single line of code! However Field Group does not support Ajax and relies entirely on JavaScript.  It causes some very important limitation for advanced and complex forms. These forms usually have complex validations, fields on each page may require calculations based on fields from previous pages, or on some special cases it might be needed to have regular JavaScript less and Ajax less multipage form.

That would have been great if we could use the Field Group for all purposes, wouldn’t it? It was my idea for writing Field Group Ajaxified Multipage. Although the name of the module contains Ajax and Field Group, it works without Field Group module for custom forms and Ajax is also optional. I hope it makes life for you fellow developers easier J. Now let’s see how it works.

The first feature which enhances Field Group multipage feature just like Field Group module itself is extremely easy to use.

  • Setup your multipage field groups as usual for your entity/node
  • In your entity/node fields list , edit your multipage field group properties and check Ajaxify option
  • You can also enable only "Non JavaScript Multistep" option which does not require JavaScript to work. It's very useful for debugging purposes or very complex multistep forms. remember that the ajaxify should be disabled for this to work
  • Skip button : You can add skip button for any of the steps you like, simply clone the next button added by this module and change its title to t('Skip this step')

That’s it, but if you’re a developer you can do much more. The module adds several parameters to $form_state variable, you can use these parameters to decide what happens on the form considering the form step.

  • $form_state['field_group_ajaxified_multipage_enabled']
  • $form_state['field_group_ajaxified_multipage_group']

Here is a sample code :

<?php
function hook_form_alter(&$form, &$form_state, $form_id) {
  if (isset($form_state['field_group_ajaxified_multipage_enabled']))
  if ($form_state['field_group_ajaxified_multipage_enabled']) {
    $step = empty($form_state['storage']['field_group_ajaxified_multipage_step']) ? 1 : $form_state['storage']['field_group_ajaxified_multipage_step'];
    $page_group = $form_state['field_group_ajaxified_multipage_group'];

    //Best practive for accessing variables, it works even when this ajax grouping is disabled
    if (isset($form_state['values'])) {
      $values = $form_state['values'];
      if (isset($form_state['field_group_ajaxified_multipage_enabled']) && isset($form_state['storage']['all']['values'])) {
        $values = $form_state['storage']['all']['values'];
      }
    }

    if ($page_group['children'][$step-1] == 'group_two') {
      $form['actions']['skip'] = $form['actions']['next'];
      $form['actions']['skip']['#value'] = t('Skip this step');
      $form['actions']['skip']['#limit_validation_errors'] = array();
    }

    if ($step == count($page_group['children'])) {
      unset($form['actions']['preview']);
    }
  }
}
?>

In some cases you may want to alter the form after this module, for those cases there is new hook introduced by this module to use, it's similar to hook_form_alter :

  • hook_field_group_ajaxified_multipage_form_alter();
  • hook_field_group_ajaxified_multipage_form_BASE_FORM_ID_alter();
  • hook_field_group_ajaxified_multipage_form_FORM_ID_alter();
/**
 * Implementation of hook field_group_ajaxified_multipage_form
 */
function mymodule_field_group_ajaxified_multipage_form_alter(&$form, &$form_state, $form_id) {
}

So what about custom forms? The only difference is that instead of using Field UI to define form pages, an special paramter in $form can be used for form array. Just like this :

<?php
function myform() {
    $form['#groups_custom'] = array (
      'group_measurements' => array(
        'group_name' => 'group_measurements',
        'label' => 'Measurements',
        'format_type' => 'multipage',
        'children' => array (
          'gender',
          'birthday',
        ),
      ),
      'group_goal' => array(
        'group_name' => 'group_goal',
        'label' => 'Goal',
        'format_type' => 'multipage',
        'children' => array (
          'overall_objectiv',
          'duration',
        ),
      ),
      'group_steps' => array(
        'group_name' => 'group_steps',
        'label' => 'Steps',
        'format_type' => 'multipage-group',
        'children' => array (
          'group_measurements',
          'group_goal',
        ),
        'format_settings' => array (
          'label' => 'Steps',
          'instance_settings' => array (
            'ajaxify' => '1',
            'nonjs_multistep' => '0',
            'classes' => ' group-steps field-group-multipage-group',
            'page_header' => '3',
            'page_counter' => '1',
            'move_button' => '1',
            'move_additional' => '1',
          ),
        ),
      ),
    );
}
?> 

And the last thing is, unfortunately due to a bug in Drupal core, this method does not work well for registration form (admin/people/create), however a patch is proposed that fixes the problem. If you're interested please join the issue and help in making it ready (RTBC)

#208790: Changing "Create new account" button text breaks admin/user/user/create form

May 14 2013
May 14

If you know what calendar system is and not interested in knowing the interesting history of Calendar Systems module :) you can skip to the point at the end of the page "We need your help"

What's the calendar system ?!

A calendar is a system of organizing days for social, religious, commercial, or administrative purposes. This is done by giving names to periods of time, typically days, weeks, months, and years. A date is the designation of a single, specific day within such a system. A full calendar system has a different calendar date for every day.

Thus the week cycle is by itself not a full calendar system; neither is a system to name the days within a year without a system for identifying the years. There are many different calendar systems including Gregorian, Julian, Hindu, Arabic (Hijri, Lunar), Iranian (Jalali, Persian), and even many more. For further information please read Calendar

Calendar systems module makes it possible to easily support these different calendar systems via a pluggable architecture in Drupal. Currently Iranian, Arabic and Thai calendars are supported. The module is fully integrated with Drupal core, Date, Views and Schedule modules.

History

Eight years ago when i wanted to build a website for our LUG (TehLUG) as the webmaster, I started looking for a proper CMS software, I did a bit of research and after presenting the result to the community members, Although i doubt anyone knew about Drupal at that time, at least in my country, I decided to use Drupal (Drupal 4, I remember For installing a module i had to manually create its tables on database :) ).

I used Drupal for four reasons and one of them was multilingual support, as a matter of fact, Back then Drupal was among the very few softwares with proper multilingual support. But in many cases when you have a multilingual website you also need localization support which wasn't fully supported in Drupal. One of the important parts of localization which was missing was supporting different calendar systems. Just like all the open source softwares at that time the only supported calendar system was Gregorian.

Fortunately i had a multi-calendar PHP class as part of my propriety framework CML (As you may remember in those times it was quite common for most programmers and companies to develop their own framework!) So i only had to write a Drupal patch to somehow fix the problem for that particular site. And that's what i did.

Not much longer after, I started using Drupal more seriously. I converted my old website into Drupal and offered Drupal as a solution to my clients. Therefore i needed a more maintainable way to add multi-calendar support. So I decided to write a small patch for introducing a new hook and put everything else inside a module. Although the module was limited, that worked quite well. Then i thought, this might be a great opportunity to pay it forward to Drupal's community, and the calendar systems module was born.

The development was very slow at the beginning, the implementation was complex and my time was also very limited. We highlighted the difficulties here to gain people's attention.

Things started to change few years ago when Drupal became more popular, several people started contributing small patches, ideas, proper bug reports, sandbox projects, helping in issue queue, maintaining the module, etc. These contributions motivated me to start working on a super release for Drupal 7, implementing the features users really wanted.

It means if we help module developers in any way we can, in many cases we guarantee continuous development of our favorite module. We don't have to be developer to be able to help! Please read Ways to get involved.

We need your help

Calendar system requires a very tiny core patch to fully work, although applying it is very easy, module reports whether it's applied or not in Drupal status page and it's integrated with Patch Manager module, still it's difficult for non-experienced users to use it, and obviously it has to be reapplied every time Drupal is updated.

Adding something to core has always been a time consuming task even if it's small change (It's a good thing actually that ensures core quality). So i wanted the module to become more popular and have more community support to worth this effort. Now it's popular with 10,000 downloads and at least 600 sites using it so it was time to port the patch to the next major version of Drupal which is Drupal 8.

The patch was already proposed to core by a fellow developer, so i rewrote it to meet core requirements and set it to needs review (Thanks to Gaelan and wuinfo for helping in completing the patch). The good thing is that the patch is not only for Calendar Systems it's a generic patch that introduces a new hook to make it possible for third-party modules to alter format_date function. If we can get it into core it might even be possible to back port it to Drupal 7

There is not that much time left till Drupal 8 release, please join in and help me to make sure it gets into the core :)

Patch’s issue : Allow contributed modules to alter the format_date() function result.

If your calendar system is not supported, writing a plugin for it is easy

Dec 20 2009
Dec 20
Blog Drupal

In Drupal it's possible to overwrite and extend a theme using sub-themes! So i usually create a custom theme for my site as a sub-Theme of a base theme and try to put all the site specific stuff to that theme instead of the base theme, although it's tricky! and sometimes i have to spend hours finding a workaround for not completely implemented sub themming features but i think it worth it. Because this way no only i can easily update the base theme but also i can patch the base theme in order to fix bugs and add new features and then contribute all this changes back to the community :)

Currently i'm using Acquia Marina as base theme on my website, I've found several bugs on this theme. fixed them and sent the patches to its issue queue. This time however i wasn't so lucky because Acquia Marina's developers are quite busy with the next major version of their awesome theme and none of the maintainer seems to have time to review and commit this patches. So I decided to share the patched version of this great theme with the community.

You can find it here : Drupal's Acquia Marina Theme version 1 patched!

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web