I’ve been developing primarily with Drupal for around 7 years, but, after some careful consideration over the past few weeks, i’ve decided to move away from Drupal Development.

During those 7 years i’ve had some successes in launching sites, i’ve learnt a lot and improved immeasurably as a developer. However, i’ve also had plenty of frustrating moments and things that have taken much longer than expected.

I’ve also been feeling a bit burnt out while trying to rebuild a reasonably large Drupal 5 site on and off for the past 3 years. First attempts were made in Drupal 6 due to lack of contrib modules being ready, but then switched to Drupal 7.

I can’t blame all my lack of progess on Drupal, during that time I completed an international relocation and did several other projects, but I did spend a lot of time on it and found myself fighting Drupal a great deal!

Taking a Timeout

A few months a go, I decided to take a break from this rebuild, and rather than take on drupal sites for a client, I decided to do some python development, ironically enough, creating a developer workflow and deployment tool for Drupal (& other frameworks).

When the tool got to a working state, I started to switch back to Drupal development, and then it hit me - I just didn’t like developing in Drupal  anymore, the fun had gone and i was tired of forcing Drupal to do what I wanted and constantly chasing my tail trying to keep up with the painful upgrade cycles.

It took a while for me to come to terms with this, my first thought was I had to continue regardless as I have so much time invested in Drupal, and know my way around pretty much every area of code. But the feeling didn’t go away, and so I also spent some time researching alternatives.

Ruby on Rails had been on my radar for a while, and i had been planning to try it, but in the end I honed in on Django due to my experience using python. Once I immersed myself in a few tutorials it started to click and since then I haven’t looked back, and so far, recreating the site in question in Django is a much smoother process for me and it does feel like a relief to have changed direction.

Why post about this on DrupalNotes.com?

I didn’t post this as a rant about Drupal, or to flame any Drupal vs Django argument. I just wanted to get some of these personal feelings off my chest, and while I am by no means a notable member of the Drupal community, to say my goodbyes.

Over the years, i have come to appreciate the Drupal community and the infrastructure it has in place. There is a ton of functionality available that people have spent many, many hours creating. I had always intended to contribute more personally, for the reasons mentioned above, apart from a few modules and patches here and there, i didn’t manage to.

So, thanks to all you in the Drupal community for all your work, good luck with the transition to Drupal 8.

Ben aka smoothify

P.S. I’m not sure what to do with the domain for this blog, drupalnotes.com, as I won’t be active in Drupal any more, i’m unlikely to have many notes about it. If any one is keen to acquire it and finish the job please let me know.

I’m in the process of creating a style plugin module for the Bootstrap framework, specifically using the Bootstrap theme.

There are quite a number of similarly coded bootstrap styles available such as ‘panel’, 'jumbotron’, 'well’ which I want to have available as configurable styles.

I was in two minds whether to have one master style plugin that allows configuring all bootstrap styles, or multiple plugins each controlling their own.

The first has the benefit of less code duplication, but the number of configuration options in the UI could be overwhelming, and there would either be redundant options for some styles. The second option means lots of duplicate code that needs to be kept in sync.

Then, I remembered from another project I did using ctools that I could use the elusive 'get children’ & 'get child’ methods to create one master style and then lots of substyles that share some of the same code. I didn’t find many other style plugins using substyles, but one I did find is located in the panels/ctools modules - stylizer.

Here is what my style plugin declaration looks like.

$plugin = array(
  'title’ => t('Parent Style’),
  'description’ => t('Example style providing substyles’),
  // We offer substyles so provide callbacks to do so.
  'get child’ => example_style_get_substyle’,
  'get children’ => 'example_style_get_substyles’,
  'settings form’ => 'example_style_settings_form’,
);

In this case, i have decided that the parent style should not be selectable on it’s own, so i have omitted the 'render pane’ and 'render region’ options. I have however added the settings form, which i intend to share between the style plugins.

/**
 * Provides List of substyles.
 */
function example_style_load_substyles($substyle_name = NULL) {
  $substyles = array(
    'first’ => array(
      'name’ => 'first’,
      'title’ => 'First Substyle’,
      'panes’ => TRUE,
      'regions’ => TRUE,
    ),
    'second’ => array(
      'name’ => 'second’,
      'title’ => 'Second Substyle’,
      'panes’ => TRUE,
      'regions’ => FALSE,
    ),
  );
  if ($substyle_name) {
    return $substyles[$substyle_name];
  }
  return $substyles;
}

First step is to provide a list of substyles, this is a very simple array that could be provided by invoking a hook, or retrieving from a datasource. The structure of the array is completely up to you, and will depend on your requirements and what differences each style has.

/**
 * Callback to provide a single substyle.
 */
function example_style_get_substyle($plugin, $style_name, $substyle_name) {
  $substyle = example_style_load_substyles($substyle_name);
  return example_style_merge_plugin($plugin, $substyle);
}

/**
 * Callback to provide all substyles.
 */
function example_style_get_substyles($plugin, $style_name) {
  $data = example_style_load_substyles();
  foreach ($data as $id => $substyle) {
    $substyles[$style_name . ’:’ . $id] = example_style_merge_plugin($plugin, $substyle);
  }
  return $substyles;
}

Now it’s time to provide the callbacks for the style plugin - these load the substyles from the above function and pass it into a merge function:

/**
 * Merge the main style plugin with a substyle to create a sub plugin.
 */
function example_style_merge_plugin($plugin, $style_name, $substyle) {
  $plugin['name’] = $style_name . ’:’ . $substyle['name’];
  $plugin['title’] = 'Example: ’ . check_plain($substyle['title’]);
  $plugin['substyle’] = $substyle;
  if (!empty($substyle['panes’])) {
    // Make this substyle show up as a pane style.
    $plugin['render pane’] = 'example_style_render_pane’;
  }
  if (!empty($substyle['regions’])) {
    // Make this substyle show up as a region style.
    $plugin['render region’] = 'example_style_render_region’;
  }
  $plugin['weight’] = 0;
  return $plugin;
}

Finally its a case of providing the render functions and the settings form. These are just like the regular style plugin ones, except you can retrieve the substyle information and there for with some logic you can adapt to suit your needs.

/**
 * Theme function for the pane style.
 */
function theme_example_style_render_pane(&$variables) {
  $output = “;
  $settings = $variables['settings’];
  $content = $variables['content’];
  $style = $variables['style’];
  $substyle = $style['substyle’];

  switch ($substyle['name’]) {
    case 'first’:
      // Here you could call your own theme function.
      $output .= 'First Style’
      break;

    case 'second’:
      // Here you could call your own theme function.
      $output .= 'Second Style’
      break;
  }

  return $output;
}

The full style plugin code is available as a gist here:

https://gist.github.com/smoothify/7289790

I’ve spent the best part of a day searching through statistics / analytics modules for Drupal. One thing i’m sure of is there is no shortage of them, but I haven’t found one that quite suits my requirements.

For the site in question a drupal 5 -> 7 migration, its going to be using an external caching mechanism (likely to be varnish) so by default the node counter will not be triggered.

Now there is a variety of ways to solve the node counter issue using javascript to trigger the node count. Better Statistics for instance can take care of this.

However, I also need to track which nodes are popular within certain timeframes, such as per day, week and month. The site gets a reasonable amount of traffic (~1M pageviews p/month) so it needs to be performant.

Radioactivity can acheive this functionality, but it is a complex module and seems to have issues when using revisions of entities, which should be fixable but caused me to have a rethink. I looked at other modules such as better statistics, scoville, but none seemed to meet the requirements.

I then moved on to the google analytics api based module since the site has been using GA since launch.  That is probably the direction i’m going to go as the data is already there and can be as granular as i need it.  Again none of the modules quite fit what i need, primarily the weekly and monthly statistics - so it looks like i need to make some improvements to one of them.

Here is a quick list of the statistics related modules I came across for D7. It would be really helpful if there was a comprehensive comparison page for statistics and metrics related modules.

Native Drupal Solutions

• jStats - https://drupal.org/project/jstats
• Better Statistics - https://drupal.org/project/better_statistics
• Statistics Pro - https://drupal.org/project/statspro
• Statisics Advanced - https://drupal.org/project/statistics_advanced
• Statistics AJAX - https://drupal.org/project/statistics_ajax
• Statisics Counter - https://drupal.org/project/statistics_counter
• Drupal Most Popular - https://drupal.org/project/mostpopular
• Node View Count - https://drupal.org/project/nodeviewcount
• Scoville - https://drupal.org/project/scoville

Google Analytic Based

• Google Analytics - https://drupal.org/project/google_analytics
• Google Analytic Reports - https://drupal.org/project/google_analytics_reports
• Google Analytics Sync - https://drupal.org/project/google_analytics_sync
• Google Analytics Counter - https://drupal.org/project/google_analytics_counter

After many months of procrastinating, I’m finally writing the first post of Drupal Notes.

I registered this domain some time ago as a place to share thoughts, ideas, understandings and general ramblings. However, life, as it often does, got in the way.

I have been developing in Drupal for approximately 7 years, during which time I’ve learnt a lot of things in all aspects of the development process - including dev ops, module creation, theming, deployment and server provisioning.

One thing, I have not yet mastered is creating a Drupal blog for myself quickly without getting stuck in details and the dangerous art of perfectionism.

So, I cheated, this site is created in Tumblr, and in some point in the future I may cover the creation process of a fully Drupal 8 version of Drupal Notes.

My first series of posts is going to be about getting a development toolkit setup.

Signing off for now

Ben