Speeding up Drupal 8 module creation using Drupal Console

Though Drupal 8 is technically advanced compared to its predecessor, writing a module involves a lot of boilerplate code. There were many gotcha moments when I forgot to add a namespace and got puzzling errors. Fortunately, all that code can be generated automatically using a tool called the Drupal Console. Drupal Console is another cool addition to the Proudly Found Elsewhere school of thought as it leverages the Symfony Console component to handle the CLI part.


Note that Drupal Console supports only Drupal 8.0.0-beta4 at the time of writing this.

Get the latest version:

$ curl -LSs http://drupalconsole.com/installer | php

Move it to somewhere convenient so that it can be used throughout the system:

$ mv console.phar /usr/local/bin/drupal

Go to the drupal root directory of any Drupal 8 beta4 setup and run:

$ drupal list
Drupal version Drupal Console 0.5.2 - prod

[options] command [arguments]

 --help (-h)           Display this help message.
 --quiet (-q)          Do not output any message.
 --verbose (-v|vv|vvv) Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug.
 --version (-V)        Display this application version.
 --ansi                Force ANSI output.
 --no-ansi             Disable ANSI output.
 --no-interaction (-n) Do not ask any interactive question.
 --bootstrap-file (-b) Path to Drupal bootstrap file (core/includes/boostrap.inc).
 --shell (-s)          Launch the shell.
 --env (-e)            The Environment name. (default: "prod")
 --no-debug            Switches off debug mode.

Available commands:
 cr                            Rebuild and clear all site caches.
 drush                         Run drush into console
 help                          Displays help for a command
 list                          Lists commands
 cache:rebuild                 Rebuild and clear all site caches.
 config:debug                  Show the current configuration
 container:debug               Displays current services for an application
 generate:command              Generate commands for the console
 generate:controller           Generate controller
 generate:entity:config        Generate EntityConfig
 generate:entity:content       Generate EntityContent
 generate:form:config          Generate ConfigFormBase
 generate:module               Generate a module
 generate:plugin:block         Generate plugin block
 generate:plugin:imageeffect   Generate image effect plugin
 generate:service              Generate service
 router:debug                  Displays current routes for an application
 router:rebuild                Rebuild routes


Drupal Console currently supports generating PSR-4 compliant code for plugins, controllers, modules, services, entities and forms.It also has basic debugging commands for listing current configuration and routes. Never write a Drupal 8 module from scratch again. Use Drupal Console instead!


Developing an admin theme in Drupal

From the very beginning, I used to wonder if there are any fancier alternatives to the “drupal blue” interface we take for granted in Drupal admin themes. I then discovered the best fit(so far) in Rubik. Since Rubik, not much has happened in admin theme space. I’d rate shiny as a close second.

How much effort goes into creating a fancy looking admin theme from scratch? Is it very straight forward and easy? I first decided what an admin theme would need to have:

  • configurable interface I don’t mean the configurable theme settings(which is useful though). I should be able to cook up my own color and font combinations.
  • shouldn’t be a subtheme by itself. Rubik has this problem. It needs Tao. Not sure why exactly, but having 2 themes for admin increases my code footprint a lot.
  • Responsive ain’t needed. We don’t need admin themes to be responsive.They are going to be used by site editors in their desks. So, we can rule out all device support safely for admin themes. Responsive bartik seems to have a different take on this.
  • icons, icons. Visual iconography is sparesely used in most admin themes, excepting rubik. This needs a lot of improvement, given the advent of tools like fontawesome.

With these design goals in mind, I started brewing a simple admin theme for Kalvi. The choice of tools needs a brief mention here.


No brainer. To have a configurable UI of sorts(goal #1), this was quintessential. SASS is “dev configurable” and meets the goal perfectly. I might switch to a non ruby based setup(like libsass/node) sometime in the future.


From whatever research I did, no admin theme uses Fontawesome. I believe this could be a great combination instead of using image icons.

Rubik adds icons using the theme_admin_block_content function. I adapated the same code. Font awesome needs a slightly different approach.

Here’s the SASS code for adding Fontawesome icons via code:

@mixin icon($icon) {
  @extend %icon;
  content: $icon;

@mixin icon-before($icon, $padding: 10px) {
  &:before {
    @include icon($icon);
    padding-right: $padding;

%icon {
  font-family: FontAwesome;
font-weight: normal;
  font-style: normal;
  display: inline-block;
  text-decoration: inherit;
  line-height: 1;

If I wanted to add an icon to a class, I just needed to call the “icon-before” mixin with the appropriate icon glyph, like

@include icon-before($icon-cubes);

I had to do some dirty hacks too, like add warning, info and error icons by changing the DOM via js. Drupal could use some theming flexibility here. core maintainers, please take note.


I was bored of the stock checkboxes and radio buttons. Turns out this guy was too, and he created iCheck. I used it to customize the look and feel of option elements in forms.


We’re just getting started and already 2 3rd party dependencies. Bower was the defacto tool to manage frontend dependencies. Note that these needs to be explicitly checked in, as Drupal.org does not package bower dependencies, though I hope it does some day as Bower is becoming increasingly indispensible for frontend dependency management.


Maninly used for grunt watch. Compiles SCSS to CSS and reloads the page if any js/CSS files are modified. There are a lot of tools popping up in this segment, like Gulp.js and Broccoli.


Layout and grid systems are misunderstood as only meant for responsive design. I presonally find semantic grids(especially the clean syntax of Susy2) very productive for general HTML layout.

A few git commits and several doses of caffine later, this is what I end up with.

Why .npm?

I spent a couple of frustrating hours with a strange issue where drush crashes silently when I try to enable the theme. This had to do with node_modules directory containing .info files and drush wrongly interpreting it as a module/theme. The solution was to move all node related tools to a .npm directory. Apparently, drush does not traverse directories beginning with a dot. This is documented here and here.

List of common elements

Admin themes don”t need lots of regions, unless you are doing something creepy. But you have to take care to have a checklist of items to be themed:

  1. form elements
  2. breadcrumb
  3. color scheme
  4. pagination elements
  5. warning, error messages

Other cool TODO ideas

  1. convert it to a frontend framework based theme(like bootstrap, semantic UI or Bourbon) for uniformity’s sake.
  2. Create a specialized UI for panels/panel based workflow(IPE).

It is not the perfect Drupal theme, but at least I shipped it. Download it from drupal.org. Let me know what you think!


I wanted to host my blog on a platform which is not tied to a single backend or stack, is dev friendly(git push deploys your app etc) and has a copious free tier. Also, ability to tweak around the look and feel and no-fluff things like markdown were attractive prospects. Openshift seems like a good fit and can’t complain so far. Oh, and did I mention its dev-friendly too? Ghost comes to mind when I think of a no-fluff blogging platform. I was able to tweak a ghost quickstart with a theme borrowed from here, and behold, ladies and gentlemen, the result is in front of you to judge.

Update(27th December 2015)

Lot of things changes since I hosted this blog. I figured that I was slowly iterating towards a CMS-y blog. Things like managing e-mail courses, contact forms, heavy editing, revisions etc. Things which are best done by a CMS(think Drupal). This blog is now powered by Drupal 7, Panopoly to be precise and hosted using DigitalOcean(Note: referral link).