Newsfeeds

Drupal Begineers

Document is under development.

Written on June 18, 2013 - 11:27

First of all: I'm a featured speaker. I'll be hosting a session called 'Drupal 8 for Site Builders'. Come and watch to get an overview of all the wonders and power Drupal 8 has for creating a site. However, there are other reasons to attend DrupalCon Prague, and they are not Drupal related at all.

Kutná Hora

Kutná Hora is a little town, about 80 kilometers away from Prague, world known for its Sedlec ossuary which contains a lot of human bones, used for decorating the inside. While this may sound luguber, a visit to this small chapel is not something you will ever forget. And if you don't go inside, the top of the chapel has a skull, they really thought about everything. The easiest way to get there is by train and even arriving in the small station is worth travelling. I have seen it already, but will be going again, so feel free to join me.

CERN opendays

CERN, the European Organization for Nuclear Research, is opening its doors on 28th and 29th of september for the public for it so called CERN opendays. CERN lies in Geneva, Switserland, about 8 hours driving from Prague, or maybe 1 hour flying by plane. You'll be able to go down 100 meters underground and look at the Large Hadron collider and all other amazingly cool experiments scientists and engineers perform. Unless you are Daniel "dawehner" Wehner, you don't get that many chances to visit this place in your lifetime, especially since they only open it up publicly every 4 years. Tickets are for sale starting August, so keep an eye on the website if you want to go. That means I won't be attending the post-sprints, but honestly, I can live with that.

This module allows bulk deletion of nodes by specified filters either via Drupal Batch or Queue API.
Sponsored by ZOOM Graphics

Automatically applying tags based on any defined vocabulary and synonyms

The DrupalCon Prague team welcomes you to submit to our call for content for our September conference.

Why content, not papers? Well, the DrupalCon program has changed since we last did the call. We've listened to feedback from DrupalCon attendees, and we're hoping our new direction will really resonate with our audience. In addition to our regular great offerings of Sessions, BoFs, CXO, Keynotes and Training, we're excited to roll out a few new initiatives.

Getting a new RPG to the table.

Recently, I had a need to be able to backup a Drupal database but to skip a number of tables that I didn’t care about; mostly tables related to caching. Given most of these tables are prefixed with cache*, I was hoping for a way to specify tables to ignore using a wildcard character like ‘%’ or ‘*’.

A common scenario in the world of responsive design: a grid of elements needs to have different numbers of columns depending on the screen width. This can easily be accomplished using media queries and clever selectors, but what if the same effect is needed on another list of elements? With Sass, you might create a mixin to avoid rearranging your styles or even worse, copying and pasting those rules.

Let's take it to the next level. Other grids with different selectors need different numbers of columns across different breakpoints. What then? Create another, almost identical mixin? No! You're copying and pasting again! Instead, create one mixin that can be passed a few variables and sit back while it does all the work for you. How? Keep reading!

Before we get started, it's worth mentioning that this specific example is tailored to Sass and Zen Grids. If you are not using Sass, we'd highly recommend it. It just might change your life. As for Zen Grids, we've been using it a lot lately. If you're using a different responsive grid framework, that's cool, but you'll need to adapt small portions of the final mixin.

For those who are skimming: jump to the meat and potatoes of the article.

Creating a breakpoint mixin

If you aren't already doing something similar, this is a slick strategy for styling one element across multiple breakpoints.

First, create a simple mixin like so:

@mixin breakpoint($breakpoint-size) {
  @media all and (min-width: $breakpoint-size) {
    @content;
  }
}

You can pass that mixin pixel values, but if you're using it a lot (you will be), you'll probably want to define some variables. We don't like using device-centric names for ours (they aren't future-friendly), but we're going to here to keep things easy to understand.

Maybe you define these breakpoints:

$breakpoint-mobile: 320px;
$breakpoint-tablet: 768px;
$breakpoint-desktop: 960px;

As a general strategy, we prefer to use these mixins multiple times within a given element rather than spread the same element across a few "master" media queries. Notice we used min-width in the mixin above. By listing the breakpoints from small to large, the styles become additive and will override the same rules in smaller breakpoints.

Using the mixin could look something like this:

.headline {
  // Global and mobile styles
  font-family: sans-serif;
  font-size: 1em;

  @include breakpoint($breakpoint-mobile) {
    // Styles from 480px on up. Can override those previously defined.
    font-size: 1.25em;
    font-weight: bold;
  }
  @include breakpoint($breakpoint-tablet) {
    // Styles from 768px on up. Again, can override.
    font-size: 1.5em;
  }
  @include breakpoint($breakpoint-desktop) {
    // Styles from 960px on up. Overrides everything!
    font-size: 2em;
    font-style: italic;
  }
}

Keep in mind that you might use more (or less) breakpoints in any given element. You don't have to use every breakpoint in every element - just use what you need in each one.

This example produces the following CSS:

.headline {
  font-family: sans-serif;
  font-size: 1em;
}
@media all and (min-width: 320px) {
  .headline {
    font-size: 1.25em;
    font-weight: bold;
  }
}
@media all and (min-width: 768px) {
  .headline {
    font-size: 1.5em;
  }
}
@media all and (min-width: 960px) {
  .headline {
    font-size: 2em;
    font-style: italic;
  }
}

That gets us through using a simple mixin to change styles across breakpoints. Awesome!

Dynamic grid creation with Breakpoint Grid Breakdown

Now is when things get exciting. Remember the scenario that we proposed at the beginning of the article? We need to create one mixin that can accomodate styles for different grids with different numbers of columns across different breakpoints.

Note: the most common use case for this is styling a View. When doing so, don't use the Grid format! Use "HTML list" or "Unformatted" and this mixin will build the grid for you.

Here we go (with a heavy dose of comments):

// Breakpoint Grid Breakdown
// Displays a grid of items with a dynamic column count across breakpoints.
// For use with Zen Grids and a breakpoint-oriented mixin.
// @author Gus Childs http://drupal.org/user/1468898
//
// @param list $column-counts
//   A list of how many columns should exist on the respective breakpoints.
// @param list $breakpoints
//   A list of breakpoints to be used in the 'breakpoint' mixin. Corresponds
//   directly with the $column-counts list. Defaults to those commonly used.
// @param string $selector
//   The selector of each individual grid item. Defaults to 'views-row'.
@mixin breakpoint-grid-breakdown($column-counts, $breakpoints: $breakpoint-mobile $breakpoint-tablet $breakpoint-desktop, $selector: '.views-row') {
  // The selector, such as '.views-row'.
  #{$selector} {
    // Loop through the breakpoints specified.
    @each $breakpoint in $breakpoints {
      // Which breakpoint are we currently on?
      $key: index($breakpoints, $breakpoint);
      // How many columns should exist in that breakpoint?
      $column-count: nth($column-counts, $key);

      // Uses our breakpoint mixin to specify what should happen on the current
      // breakpoint in the loop.
      // Important: Adjust this if using a different mixin or strategy.
      @include breakpoint($breakpoint) {
        // Loop through the number of columns on this breakpoint.
        @for $i from 1 through $column-count {
          // Creates :nth-child selectors for each column. For example, in four
          // columns we would have the following selectors here:
          // &:nth-child(4n+1), &:nth-child(4n+2),
          // &:nth-child(4n+3), and &:nth-child(4n+0).
          $remainder: $i % $column-count;
          &:nth-child(#{$column-count}n+#{$remainder}) {
            // Important: this relies on the use of $zen-column-count, which is
            // specific to Zen Grids. $zen-column-count should be replaced with
            // a variable that represents how many columns you're using
            // within the current breakpoint (or globally).

            // How many columns of the general grid on my page should one
            // column of this specific grid take up? For example, if the whole
            // page uses 12 columns, and we have a 3 column grid going for
            // these elements, $page-grid-column-span would be 4.
            $page-grid-column-span: $zen-column-count / $column-count;
            // Which column should this specific column start on?
            $page-grid-column-position: 1 + (($i - 1) * $page-grid-column-span);

            // Important: adapt this if you aren't using Zen Grids!
            // If you are: this is where all the magic happens.
            // http://zengrids.com/help/#zen-grid-item
            @include zen-grid-item($page-grid-column-span, $page-grid-column-position);

            // Clear the first item in every row so they don't stack on top
            // of each other.
            @if $remainder == 1 or $column-count == 1 {
              clear: both;
            } @else {
              clear: none;
            }
          }
        }
      }
    }
  }

  // A clearfix so elements following this grid will be placed correctly.
  & > div:after {
    content: "";
    display: table;
    clear: both;
  }
}

With that breakpoint, your styles elsewhere become as simple as this:

// Create a grid of unformatted views rows that has one column on mobile, two
// on tablet, and four on desktop.
.view-id-fancy-grid {
  @include breakpoint-grid-breakdown(1 2 4);
}
// Create a grid of unformatted list items that has one column on mobile and
// tablet, and two on desktop.
.list-of-items {
  @include breakpoint-grid-breakdown(1 2, $breakpoint-mobile $breakpoint-desktop, '.list-item');
}

The first example will generate the following CSS structure using Compass:

@media all and (min-width: 320px) {
  .view-id-fancy-grid .views-row:nth-child(1n+0) {
    /* Zen Grid output to position the only column (removed for simplicity). */
    clear: both;
  }
}
@media all and (min-width: 768px) {
  .view-id-fancy-grid .views-row:nth-child(2n+1) {
    /* Zen Grid output to position column 1 (removed for simplicity). */
    clear: both;
  }
  .view-id-fancy-grid .views-row:nth-child(2n+0) {
    /* Zen Grid output to position column 2 (removed for simplicity). */
    clear: none;
  }
}
@media all and (min-width: 960px) {
  .view-id-fancy-grid .views-row:nth-child(4n+1) {
    /* Zen Grid output to position column 1 (removed for simplicity). */
    clear: both;
  }
  .view-id-fancy-grid .views-row:nth-child(4n+2) {
    /* Zen Grid output to position column 2 (removed for simplicity). */
    clear: none;
  }
  .view-id-fancy-grid .views-row:nth-child(4n+3) {
    /* Zen Grid output to position column 3 (removed for simplicity). */
    clear: none;
  }
  .view-id-fancy-grid .views-row:nth-child(4n+0) {
    /* Zen Grid output to position column 4 (removed for simplicity). */
    clear: none;
  }
}
.view-id-fancy-grid > div:after {
  content: "";
  display: table;
  clear: both;
}

The part that really makes the magic happen is the use of :nth-child. The Internet Explorer wizards among us may remember that IE 8 and lower don't support :nth-child by default, so you'll need to use Selectivizr to do so. There's a Selectivizr module if you need it.

Less comments, please!

For the brave souls who have wrapped their brains around what's going on:

// Breakpoint Grid Breakdown
// Displays a grid of items with a dynamic column count across breakpoints.
// For use with Zen Grids and a breakpoint-oriented mixin.
// @author Gus Childs http://drupal.org/user/1468898
//
// @param list $column-counts
//   A list of how many columns should exist on the respective breakpoints.
// @param list $breakpoints
//   A list of breakpoints to be used in the 'breakpoint' mixin. Corresponds
//   directly with the $column-counts list. Defaults to those commonly used.
// @param string $selector
//   The selector of each individual grid item. Defaults to 'views-row'.
@mixin breakpoint-grid-breakdown($column-counts, $breakpoints: $breakpoint-mobile $breakpoint-tablet $breakpoint-desktop, $selector: '.views-row') {
  #{$selector} {
    @each $breakpoint in $breakpoints {
      $key: index($breakpoints, $breakpoint);
      $column-count: nth($column-counts, $key);

      @include breakpoint($breakpoint) {
        @for $i from 1 through $column-count {
          $remainder: $i % $column-count;
          &:nth-child(#{$column-count}n+#{$remainder}) {
            $page-grid-column-span: $zen-column-count / $column-count;
            $page-grid-column-position: 1 + (($i - 1) * $page-grid-column-span);
            @include zen-grid-item($page-grid-column-span, $page-grid-column-position);
            @if $remainder == 1 or $column-count == 1 {
              clear: both;
            } @else {
              clear: none;
            }
          }
        }
      }
    }
  }

  & > div:after {
    content: "";
    display: table;
    clear: both;
  }
}Wrapping up

We understand that this can be overwhelming for someone who isn't extremely familiar with Sass and Zen Grids. While this won't be a plug-and-play solution for the faint of heart, we hope it will get some folks thinking and set others out on the right foot. If you end up using this on a project or have any suggestions for improvements, we'd love to hear about it!

If you'd like to easily grab the code or perhaps even submit a pull request, it's on GitHub!

Additional settings for "Long text with summary" widgets.

Currently implemented:

• Always visible: removes the ability to toggle the display of the summary component
• Required: makes the summary component mandatory

Building sites using Drupal Commerce is something we often do at Marzee Labs, but when EnjoyThis approached us to build an e-commerce site for The London Distillery Company featuring a “design your own whisky cask” part, we immediately seized that opportunity to do something different. In this post, I’ll review the architecture of the project.

Challenges

The new site for The London Distillery Company had to appeal to a young urban crowd. EnjoyThis took on the challenge of creating a visually appealing design using big images, bold typography & plenty of videos (which they shot themselves).

Drupal Commerce was chosen to build the site, which needed a lot of customization that would have been beyond most open-source ecommerce platforms. We needed multi-country & multi-continent shipping which influences shipping costs, delivery times & taxes. We also needed to offer customers the possibility to use coupons, so they’d get free shipping, receive a percentage off their purchase, or get a free bottle for every three bottles they buy.

The most challenging part of the project was to allow visitors to design their own bespoke casks, choosing from options such as barrel size (40 liters, 180 liters, or 220 liters, for the very thirsty ones!), wood type and barley. Every one of these options has a different price and attributes, and some of the options would in turn enable more options. For example, if you pick the Maris Otter barley type, you might want to take the peated or the non-peated version.

After the user has customized his or her own cask, we allow them to share their configuration via mail, Twitter or Facebook, so we needed unique URLs for every cask combination.

The first step in the “design your own whisky cask” process. Selecting a different option triggers an AJAX request that loads a different product combination. Try it out yourself.

UX and Front-end

The secret of marrying a good UX implementation to the one-pager “design your own cask” is very simple: relying on what Drupal Commerce gives us. The danger would be to sink in heavy template usage to accommodate the markup. Instead we used a couple of preprocess functions, as well as the standard and almost untouched commerce HTML.

Javascript-wise, we pass very limited amount of variables from Drupal PHP to Drupal behaviours, and hook our code to rely on what Drupal Commerce gives us. This means that we don’t have to hack our way around, and can keep the custom code down to a fairly human, understandable level. That said, we did hit a few walls, and butted our heads against the desk a couple of times, especially in some event bubbling that commerce was “offering” us.

All in all, the best decision we made for this uncommon commerce page was to keep most of what Drupal Commerce would give us out of the box and do a make up with jQuery rather than reinventing the wheel.

Under the hood

To build out the “design your own cask” tool, we started from a description and a price for each of the attributes that would made up the final cask: a 20-liter barrel costs that much, adding the peated option would add that much, etc.

We made the maths and found that a user can chose between roughly 200 different cask combinations. Each combination is built out as a separate product and bundled in one single product display (see the bespoke page), taking advantage of Drupal Commerce’s flexible product / product display separation. We built a script to generate the different combinations, and used Commerce Feeds to get that data into Drupal. Future price changes are then easily synced using the built-in synchronization of Commerce Feeds.

Each combination also shows a breakdown of the costs of each selected attribute. Selecting the “peated” option for the barley type would add an additional 200 pounds for example. We store that data in a separate node that is referenced from the product entity. Every time an attribute is selected by the user, we receive a correct reference to the price breakdown node of that particular combination and extract these components using jQuery.

The third step in the cask configuration. The visitor can choose the type of barley, which in turn triggers new choices.

We are very happy with the final site, especially the "Bespoke Tool" which we recommend you try out. Drupal Commerce proved to be a very flexible framework, even for a use case that requires more than just the typical product pages.

Disclaimer: our friends at EnjoyThis designed the whole site, including beautifully shot images and videos to promote the whisky distillery. Marzee Labs architected and implemented the e-commerce part using Drupal Commerce and implemented the User Experience of the “design your own cask” part.

Drupal makes it easy to add fields to your site, which you can use to trigger custom functionality in your modules and themes. It's nice, but there's also a dark side. As sites grow more complex, these fields can get out of hand, resulting in one or more of these outcomes:

• An utterly exhausting number of fields, without any way to see which ones are important
• Fields without any logical grouping 
• Fields that do nothing
• Fields where certain combinations of choices result in poorly displayed content or broken functionality
• Fields more suitable for admins than content creators

These problems grow out of fairly innocuous roots. Let me use a simple example:

You've added a field to your page content type called "layout" which lets you choose between two options: a page layout that prominently displays the image you've uploaded to the image field, and one that emphasizes text without displaying any image (you use some CSS being the scenes to do this magic).

Naturally, choosing the "Strong Text w/out Image" option, turns the image field into a "field that does nothing." It's easy to justify, but the more you let this, and other field mismanagement creep into your UI's, the more frustrated your new users will become.

Fortunately, we have some options for managing these kinds of issues:

• The Conditional Fields module provides an admin UI for letting you set up dependencies and conditions for fields without any programming. One great use is to hide "fields that do nothing" based on the contents of previous fields. It's like usability gold.
• The Field Permissions module lets you hide fields on a user permissions basis, which is great if you've got advanced functionality in fields, and you really want to simplify things for content creators.
• The Field Group module lets you combine fields into groups with a variety of UI options, like collapsible containers, vertical tabs, horizontal tabs, and others. This is great for providing whatever form interface is most intuitive for your users. You can also look into the Field Collection module for a additional options.
• The Computed Field module lets you dynamically pre-populate fields with whatever values make sense. Smart default values = big win for users.

If you'd rather make changes in the code than the UI, the Form API in Drupal 7 has a lot of the features that these modules provide. Form states allow developers to programmatically trigger behaviors like hiding, showing, or populating fields based on the states of other fields. Collapsible fieldsets allow for logical grouping of fields and you can set whether their collapsed by default or not.

And being sensitive to the default state of fields makes a huge difference. Here's my usability rule of thumb, regardless of whether I'm using contributed modules with admin UI's or the Form API that comes with Drupal:

Required fields (or those of major importance): Expanded by default
Optional fields (or those of minor importance): Collapsed by default
Fields that do nothing: Hidden

What advice do you have for managing fields in Drupal?

The Volleyball Landesverband Württemberg (VLW) is responsible in organizing official Volleyball competitions in Württemberg, Germany.

They provide game data via XML, thus enabeling interested Clubs to display customized score tabs, results, next game announcements and season schedule.

This module is written for the needs of my local club FV Tübinger Modell, but may be usefull for others as well.

This module also features integration to the (restricted) XML game data service of the Deutsche Volleyball Liga (DVL) for the 1.Bundesliga and 2.Bundesliga.

The Auto-download module allows privileged users to create automatic downloads for their sites.

First, the user creates an 'assignment' between an existing node page in Drupal and a file (can be external).

When any user accesses the page associated with the assignment, the requested file is automatically downloaded.

After the 'assignment' has been created, it can later be changed and toggled on/off.

'Prefer alias' does two things.

• Keeps your users going to the URL aliases of your site (assuming you aren't using auto-aliasing)
• Notifies the proper privileged users when URL aliases don't exist for node pages.

Real Estate Mortgage Calculator is a mortgage calculator. It is designed to operate with the Drupal Real Estate module, but also can be used on any other Drupal site.

After searching around, I noticed there was no simple solution for a US based phone number formatter. There are a couple solutions (Phone and Phone Number) for US and International, using a separate formatter and field, but nothing I could see that I could use with a simple textfield.

This module adds an extra formatter to textfields that allows you to select "US Phone Number". The module converts the phone number into the standard US phone number format.

To set up:
1. Turn the module on like usual (Drush en phoneus)
2. Create a textfield, and limit output to 10.
2. Under manage display, select "US Phone Number".

Output: (123) 124-1234

Add 'Alt,' 'Attribute', 'License,' and 'Title' fields to every image. If only one field is filled out - duplicate and populate field information to 'Alt' and 'Title' field if one is filled out and the other isn't. Show all entered information on hover and hide empty fields. Open an overlay to edit the individual image.

We have rolled out an experimental feature to export tours (in Inline Manual terminology Topics) that are compatible with Drupal 8 tour module. You can now use the Authoring tool and Inline Manual infrastructure to manage your tours. These exported tours you can play out of the box in Drupal 8. If you are after more advanced solution, that can be used for your clients, check out the Inline Manual module.

Currently I am developing a module for our own issue tracker. Of course our issue tracker is build in Drupal; so it is a Drupal module. The development started, after I tried the Dashboard module in core, and some contrib modules. I will leave those unnamed. Not that there is something wrong with the modules, they all have their audience, but I want to take it a step further.

First I must admit: I am a big fan of Panels. I know, I know... something must be wrong with me; It is slow, it is for site builders, not for real programmers, and all kinds of other arguments... I say: blah, blah, blah. I am not here to argue about Blocks vs Panes or Display Suite and Context. Been there, done that (And believe me, we do a lot of Drupal module development)... I just prefer Panels and Panelizer for most use cases; period.

With that out of the way, I can come to the point; Why develop a new module, when there are already good Dashboard modules? The reason is simple. It is not 'only' a dashboard module, users can change the way they see a page. They don't have to be owner of the content, they just drag-n-drop the order in the display and show or hide stuff to their liking. Another user can drag-n-drop the order of the same content to his or her liking. So... how to use it, and what is so cool?

How I came to development of this module.

First forget Panelizer for a moment. We start with Panels and the Page manager of ctools. It is standard behaviour of Panels that you can override a node view page, so that you can use Panels to construct the node page.
Suppose there is a node type called 'issue'. That node type holds all issues (dûh). The node type has a lot of fields like detailed description, assignee, project, status, attachments and more... We need all those fields.. they have a purpose, but it also gives us a display nightmare. Different users find different stuff important. Account management only cares about the hours and how fast things are picked up, project leads want a decent way to estimate and relate stuff and the developer need to access all the fine details, including the attachments.
So what I did was overriding the default node view with a Panel and started playing around. Assignee at the top, description lower.. etc, etc. It took me a while to figure out a way to display everything and to have a display that I liked. First my buddy from account management showed up in my office... "Listen, I realy like your hard work (typically a sales guy), but I want to see also all previous issues for this project, or maybe even every issue from the same client, and can client name go on top, together with the reporter?". Luckely I did build it all with Panels, so 15 minutes and some Views magic later, I did my job... Happy sales guy!
Next in line was the Project lead. "Can't we show related issues? Issues might have something in common because of a particular modules or so.." No, is not an answer for a devoted developer, so again some views, search api thingies... and woot! I did have a cool pane with related stuff. Then a developer showed up. "What is all this stuff on my issue pages? It is way to crowded... Just give me clear instructions, don't bother me!" Woops... developers... they have their own way of saying things.. All I understood that something was completely wrong.

How to fix this with a custom module?

It was clear that there never could be an agreement on what field on top, what is important and what not to display on that page. So I developed a module called Panels User Override. The administrator provides a 'sane' layout of the page. He even provides some extra stuff that is not in the normal display. A user then can drag-n-drop the way he/she sees the page. So every user can have the issues his or her way, without me doing anything... fantastic! This module also opend the way for a new frontpage of our issue tracker. It will be (in the near feature) a Panel page, with way more possibilities then our friend 'Dashboard', that only works with 'Blocks'.

What this module is not.

It is not Panelizer. It cannot be compared to Panelizer. I see no reason why it cannot work together with Panelizer from a technical perspective, but I cannot come up with a use case. I think you will create a nightmare for your users. You then can override displays that are already overriden per node... See a whole thread on this topic in the issue tracker of this module.
I already did make the module available it in my sandbox on drupal.org, but it is not ready to promote it to a full project. It might never see the full project status. One of the main problems is the way it does access checks now... it simply doesn't do any access checks. So you can also override Panels, that you have no access to, and drag-n-drop panes that are not available for you. Not a real problem... it does no harm that you can change the order on things you will never see, but it is weird for the user. I do have some ideas how to fix that.
Problem is that I don't have a context on edit. Possible ways to solve this are:

1. The edit/override can only be started from a context (e.g. edit THIS layout). Thing is that this doesn't make it clear that you also edit the same display for all other contexts (nodes).
2. Leave all intact as it is now and load a default context on edit. But I simply cannot figure out a way... how to do this? I see that the developers of Panels have the same issue with this, because the preview is also loaded without a default context....

Well.. test it, review it, patch it and come with better ideas! But don't depend on it. It might change, dissapear or never be touched again, without notice. So use this custom developed module at your own risk!