Drupal aggregator

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.

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.

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 discussion on responsive Sass strategy and how to solve the common problem of numerous grids needing varying numbers of columns across many breakpoints. Can we accomplish this with one mixin?

ESDevelopment posted a photo:

Desarrollo de Web Dinámica con CMS Drupal
dsh.mx

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?

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!

Adding color support to a Drupal theme allows site owners/administrators to modify the theme's color scheme directly from a settings page, rather than having to edit any CSS.

I'm currently assessing color integration options for Neptune and have found DesignKit to be a quick, easy, and flexible alternative to direct color module itegration (as used by Garland and Bartik). On the flip side, there are a couple of caveats (see below).

This tutorial will focus on implementing basic color configuration, although DesignKit also supports image configuration and more advanced color configuration (including color blending/shifting).

On Tuesday, June 18, at one o'clock EDT, I will be on a panel for an Ask Me Anything (AMA) on Reddit - http://www.reddit.com/r/IAmA/ - The topic will be ALS and Assistive Technology.

So why should you attend?

First, it's only an hour or so, and it'll look better if more than one or two people show up. Besides, it'll be a great opportunity to spend your lunch hour with me. Being online simply makes it that more simple.

Next, if you have any pressing questions, such as how do you manage to write awesome modules for Drupal when your hands are completely useless, then this is your opportunity!

My qualifications: I was diagnosed with Lou Gehrig's Disease about two years ago, just before my newborn's first birthday. At first, my arms and hands were weak, so I purchased a magic touch pad and keyboard for the mac. By September, I needed to supplement this with Dragon Dictate (Naturally Speaking on the PC). This combination served me well until last year, when my hands became too weak to control the touch pad, so I began looking at eye gaze solutions.

The first iteration was a custom built eye gaze tracking system built by my father, from an open source concept over at http://www.eyewriter.org/ . It was cumbersome and difficult to calibrate, however, so beyond a couple of proof of concept demonstrations, I didn't really use that much.

Then about July I got a head tracking piece of software for the Mac, which served me well for a few months. However, it was doomed from the start, as my neck strength was already failing.

So in September of last year, I finally got a Tobii PCEye, and used it to control the mouse, while I continued to use Dragon to dictate code and emails to the computer.

Finally, this January, my voice had degraded to such an extent that I gave up struggling to keep training and retraining Dragon, and now use the Tobii, in combination with Dasher, an open source word predictor for use with eye gaze systems, to control all aspects of the computer.

I'm planning to get a stand alone Tobii system next month, which will allow me to speak when I have lost that ability entirely, using my own voice banked with Model Talker, and have also begun a trial using a brain computer interface (BCI) for the possible loss of eye movement in the future.

By far the best thing I have done during the course of this debilitating illness has been to try to stay one step ahead, by training myself to use the next bit of software or hardware before I actually need it. I believe that where medicine has completely failed patients with ALS, technology has taken up the banner, and offers the only hope.

So join me Tuesday at 1:00 for an AMA on Reddit, to have a chance to chat with me live. I'll post the URL here and on Twitter: http://twitter.com/aaronwinborn soon before the session starts.

read more

As I've outlined in the previous post Drupal 8 core now has 3 core modules (+1 proposed, +1 hidden) to deal with language support. This tidbit will be about the simple language setup features provided by Language module, which is the base for every other language feature.

Language module provides a simple language overview screen. You can reorder existing languages, remove languages (except the site default language, which on the screenshot is Hungarian) and add new languages. It is not anymore possible to have enabled and disabled languages on your site. This feature resulted in a confusing mess where some places and permission combinations allowed for the use of disabled languages and it was used a means to stage certain new content. Just use proven content staging techniques (or unpublished posts) for new language content.

While working on a project for a customer we had the requirement to display different parts of an exposed form of a view in different regions of the page. Additionally not all parts of the form should be visible on all pages of the site (i.e. the search box should be visible on all pages whereas other exposed filters or sort options should be visible on the result pate only).
Normally we would manage this by using some hook_form_alter()-magic and/or create a custom block with a coded form in it. But a hint of Daniel Wehner (dawehner) pointed me to a different solution:

drupal planet english

In most of the cases, there are several developers working at the same project, each of the have its own manner of writing the code, but anyway at the end, the code must be simple, testable and reliable. This article describes how to reduce the visual complexity of the code with return value early in “if” statements, which can lead to a higher code quality.

Usually we write code with many “if” statements:

<?php if (something) { // do scenario 1 } else { // do scenario 2 } ?>

There are a lot of cases when “scenario 2” looks way shorter than “scenario 1” in terms of number of lines. For better readability it is way better to switch order of scenarios for such cases. Specially when you have “return” statement somewhere in scenario 2. Lets take a look at examples:

<?php $node = menu_get_object(); if (isset($node)) { ctools_include('plugins'); $output = '<div class="invite_event_btn"> ' . ctools_modal_text_button(t('INVITE'), 'invite/nojs/invite/form/' . $node->nid, t('Send Invitation'), 'ctools-modal-modal_invite-style') . ''; $output .= '<div id="modal-message">&nbsp'; return $output; } return FALSE; ?>

We can see that in both scenarios that we have the 'return' statement and scenario 2 is way shorter. So it is really would be nicer to write this piece of code in the following way:

<?php $node = menu_get_object(); if (!isset($node)) { return FALSE; } ctools_include('plugins'); $output = '<div class="invite_event_btn"> ' . ctools_modal_text_button(t('INVITE'), 'invite/nojs/invite/form/' . $node->nid, t('Send Invitation'), 'ctools-modal-modal_invite-style') . ''; $output .= '<div id="modal-message">&nbsp'; return $output; ?>

Less code we have in curly brackets – the better.

Let's take a look at another example:

<?php function module_modal_invite_form_validate($form, &$form_state) { if ($form_state['values']['text'] != '') { $emails = explode(",", $form_state['values']['text']); $valid_emails = email_validate($emails); if (!$valid_emails) { form_set_error('', "Please enter a valid email address."); } } else { form_set_error('', "Please enter at least one email"); } } ?>

It can be rewritten in the following way to make it more readable.

<?php function module_modal_invite_form_validate($form, &$form_state) { if ($form_state['values']['text'] == '') { form_set_error('', "Please enter at least one email"); return; } $emails = explode(",", $form_state['values']['text']); $valid_emails = module_email_validate($emails); if (!$valid_emails) { form_set_error('', "Please enter a valid email address."); } } ?>

As you can see, with returning value early in “if” statements can reduce visual complexity of your code so other developers will get its idea easier. Even this small improvement can lead to higher code quality and easier maintenance in the future.

Do you have any similar “small” recepies you use every day coding? Please share your experience in the below comment form or on our social profiles, Twitter, Facebook and Linkedin.

Language English Tags: DrupalDevelopmentTutorialsCheck this option to include this post in Planet Drupal aggregator: planet

(Apologies for how long it took me to get this post published. We had few things to deal with right after DrupalCon which made it difficult to hop right on this post.)

Personal blog tags: board meeting

During update work of the site of our Drupal department (http://php.sfdev.com) we faced following task: to upload rectangular images but to show circle ones on the pages of our site.

In the case if we are going to display circle image form Image or Media field it is easy to set image style preset and use it in the field display. But Rotating banner (https://drupal.org/project/rotating_banner) does not allow to use image styles without hack module.

It is extremely worth practice to hack contributes module even in no feather development status :-)

But how can avoid to hack module and use image style to make image be circle?

By the way to do circle images with image style preset you can use ImageCache Action Module (https://drupal.org/project/imagecache_actions)

Ok, back to our task. We can try to use hook_preprocess_image(). In our theme template.php file we put following code:
<?php
function sfdev_preprocess_image(&$vars) {
  if(isset($vars['attributes']['class']) && $vars['attributes']['class'] == 'rb-background-image') {
    $url_splits = explode(variable_get('file_public_path', conf_path() . '/files/'), $vars['path']);
    $vars['path'] = image_style_url('circle', file_build_uri($url_splits[1]));
  }
}
?>

Fortunately each rotating banner add 'rb-background-image' to each image. So we can separate this kind of images from the other ones:
if(isset($vars['attributes']['class']) && $vars['attributes']['class'] == 'rb-background-image') {

Before implementing hook_preprocess_image we should create 'circle' image style to use it in this function.
To make Drupal create circle image we should just simply request it via image style URL:
image_style_url('circle', file_build_uri($url_splits[1]));
So the main idea to put image style URL instead original one.

By the way, after some discussions we decide to create circle images manually, because in some cases they should not be circle :-)
And these cases are not predictable :-(

Blog tags:

• Planet Drupal
• FAQ

An itch to scratch For a while, I've wanted to contribute a module back to the Drupal community and actively maintain it. I can't exactly tell you why I wanted to do this but it's been a burning desire.

I know there are a lot of projects that have been abandoned and can use some help (Nodereview being one that I'm still trying to keep up with) but I wanted to be in the driver's seat and intimately understand the code having written it. I hope that makes sense.

However, I didn't want to write anything on a whim. I wanted the module to be something that was useful and something people could use. An idea finally came to me as I was working to develop a site of my own (separate from this site and something I'll be discussing in a future post as it should help drupal developers find new business).

Thank you Flag Friend Recently I've been helping out with some work on the Flag Friend module around the javascript link not working - if your using the module, you can follow the issue here: https://drupal.org/node/1433122. In doing so, I became pretty familiar and comfortable with the Flag module code and API. Then, as I was working on a project, I thought it would be cool if people could flag a node in order to maintain it and a site administrator could approve that flag. I couldn't find a way to easily do that and so, the Flag Application module was born.

Flag Application Description If you're interested in the module, you can find it here: https://drupal.org/sandbox/yaworsk/2020689. Essentially, Flag Application integrates with the Flag Module to create the custom Flag "application".

Just like other flags, users can flag nodes with an application. Administrators are provided with an administration page to review applications and can either approve or deny the application. All applications are listed as pending prior to administrator review.

Additionally, this module integrates with Rules to allow for custom actions once an application has been approved or denied. However, I still have to write specific actions for the module itself (i.e., approve / deny an application) -- currently the module only provides conditions to react to.

If you end up checking out or using the module, I'd love to hear your feedback.

Start:  2013-06-19 (All day) America/New_York Sprint Organizers:  David_Rothstein

The monthly security release window for Drupal 6 and Drupal 7 core will take place on Wednesday, June 19.

This does not mean that a Drupal core security release will necessarily take place on that date for either the Drupal 6 or Drupal 7 branches, only that you should prepare to look out for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release).

There will be no bug fix release on this date; the next window for a Drupal core bug fix release is Wednesday, July 3.

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

As marketing professionals we get paid to turn a phrase on behalf of our clients but we are no less creative when we turn the lens inward to focus on our own strategies. Recently the term omni channel marketing has come into more common usage in the digital space. So what  is omni channel marketing and why should marketing managers and web development directors care?

Omni what?

Welcome to another Commerce Module Tuesday! Today we are looking at Commerce Recurring Framework, maintained by Pedro Cambra (the screencast is about the new and highly anticipated 2.x branch). We will go through setting up a healthy recurring bill that would have your Commerce Kickstart 2 site sending out $7 toothbrushes once a month.

(Video after the break.)