Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Feb 13 2012
Feb 13

Need a simpler UI to let administrators manage fields? We recently created a new contributed module called Simple Field. This module simplifies the UI for creating fields and adding them to content types and entities. It also provides granular permissions, so you're not stuck with a single catch-all permission for managing fields. You can see a demo of the module in action at simplefield-demo.ewdev.ca (login: demo/demo).

Why do I need Simple Field?

Imagine you're creating a Drupal site and you want to let your users create fields, but you don't want to give them the 'Manage Fields UI'. The Manage Fields UI is very powerful, but it also provides a lot of settings and configuration that can be confusing for non-technical users. Giving users permission to manage fields allows them to delete fields, and you might want more granular permissions to prevent users from deleting data on the site.

Simple Field Types

The Simple Field module includes a set of Field Types. Instead of a long list of cryptic types which can intimidate non-technical users, field types are things like 'Multiple Choice' or 'Yes/No'.


List of built-in Simple Field types

Simple Field types include a core field type, plus some field widget settings. For example, rather than choosing 'Boolean', users can choose 'Yes/No', which is a Boolean field with pre-configured options for yes or no. The user adding the Simple Field will not see the 'Options' field and won't be able to change the option values.

Of course, we can't anticipate all the Simple Field types that other sites will need, so the module is extensible and allows developers to define additional Simple Field types in code.

Creating Fields is as Easy as Pie

With pre-defined field settings, creating fields becomes much easier for users. Users just need to enter the label, whether the field is required, and help text. Some Simple Field types, such as 'Multiple Choice', have an options field, but that's it.


Creating a 'Yes or No' Simple Field

Attaching Simple Fields to Content Types

You can enable Simple Field on a per content type basis, which provides a nice UI for managing the Simple Fields for that content type. The module uses modals to keep the UI concise. You can create and attach files from the same page.


UI for attaching Simple Fields to a Customer content type

An Alternative UI for Creating Fields

The Simple Field module provides an alternative UI for creating fields, which only exposes some of the field settings to users. Other administrative roles can still be given access to all of the more advanced settings through the Manage Fields UI. The fields are stored in the database in exactly the same way, so everything like Views integration still works. All settings and weights are synchronized between the two interfaces.


Simple Fields appear in the Manage Fields UI

Granular Permissions for Fields

Permissions for the Simple Field module are very granular. You can control which roles have access to which field types and whether users can delete fields or remove fields from a particular content type or entity. For example, you can configure your site so that the users with the 'service rep' role can add Yes/No, Multiple Choice, and Short Answer simple fields to the customer content type. This way, service reps can add fields on-the-fly if they realize that collecting a particular piece of information from customers is valuable.


Simple Field Permissions

Adding Simple Fields to Entities: Fields as Content

While the Simple Field module can be used to add fields to bundles (i.e. content types) it can also be used for adding fields to entities. This opens up a ton of new possibilities. For example, you can create a survey entity and allow users to attach fields to each individual entity. Used this way, the Simple Field module is kind of like an alternative to the Webform module, allowing you to add fields to pieces of content.

Presentation at DrupalCamp NJ

Alex Dergachev presented a case study at Drupal Camp NJ on February 4, 2012 and included a demo of the Simple Field module. The case study shows our original use case for the module in the context of a Drupal project for a university.

Documentation

For information on creating new types, among other things, take a look at the documentation.

Dec 13 2011
Dec 13

DrupalCamp NYC 10 was one of the best Drupal camps I've ever attended. With around 400 attendees, it was definitely the biggest. Somehow, it still had the intimate feel of a camp and there were lots of opportunities for conversations and networking, both during the day and at the after party.

By scheduling ten sessions during each time slot, the organizers allowed more people the opportunity to speak, ensured that there was always something for everyone, and gave sessions an intimate, bof-like feel. We really appreciated the many high-quality sessions in the dedicated track for sysadmin and performance topics, with Nathan Goulding's Chef session and Mark Sonnabaum's XHProf session stimulating a lively discussion during the long drive back to Montreal.

Julia and I had the opportunity to present sessions at the camp:

How to tell Views about your mongooses

Julia Evans presented a Views session about displaying custom data in Drupal using Views. She'll be doing a write-up soon to go along with the presentation.

Multilingual Site Building with Drupal 7

Drupal Camp NYC 10 The camp also featured one time slot for guided conversations (aka Birds of a Feather sessions) led by expert Drupalers who had presented throughout the day. These provided a place for Q&A amongst those with common interests. Setting aside a dedicated time slot ensured that there was a high level of participation.

A huge thanks to the organizers who put so much time and energy into planning the event. You guys made it look easy and fun! We're looking forward to heading back down to the tri-state area for Drupal Camp New Jersey in February.

Nov 14 2011
Nov 14

Alex, Tavish and I had a great time in the T Dot over the weekend at DrupalCamp Toronto. The camp was well-attended, there were lots of great presentations and BoFs, and we even came back with some very hardcore Druplicon touques (hats for you non-Canadians).

Here's a recap of the four sessions we presented at the camp:

Drupal 7 Higher Education Case Study

Alex did a case study on our recent work in using Drupal 7 to build an admissions portal for a major Canadian university, emphasizing how we were able to leverage Drupal 7's new Fields API to allow non-technical administrators to easily customize the online application form.

Responsive Design and Drupal Theming

I presented my approach to implementing responsive design in Drupal, including how to handling elements like Panels, tables, forms, and images. This session expanded on a blog post about responsive design and Drupal that I wrote last month.

Multilingual Site Building in Drupal 7

I also did a presentation on building multilingual sites with Drupal. My focus was on methods for content translation, which is also covered by this blog post.

Poutine Maker: A Tasty Introduction to the Field API in Drupal 7

Tavish, our superstar intern, introduced attendees to the Drupal 7 Field API with his popular Poutine-themed presentation. The presentation covered creating custom fields, including validation, saving, and formatting field data.

A huge thanks to all the organizers and sponsors for putting on such a great event, which gave us a chance to connect with many friends old and new. We're looking forward to heading back to Toronto for the Drupal Business Summit 2011 Toronto, on December 2nd, where Alex will be co-chairing a breakout session on Drupal in Higher Education with Jennifer Hols from ImageX Media.

Nov 08 2011
Nov 08

Whether we like it or not, testing takes a huge amount of time. Often a third of each web development project is spent testing, but it's not usually something that gets a lot of attention.

SimpleTest and Selenium testing are now relatively common topics of discussion in the Drupal community, but the actual testing process is less widely discussed. Figuring out what to test for, how to track the results of testing, and techniques for testing Drupal projects are difficult problems to solve.

Whatever testing or project management methodologies are used, improving the testing process can save valuable development hours and increase the chances of finishing projects on schedule. There are lots of challenges particular to testing Drupal projects, and at DrupalCamp New Hampshire in October, I got a chance to share some of this at a session about Improving Your Drupal Testing Process.

Benefits of Testing

Besides the fact that testing a website will find bugs that need to get fixed, testing can have other positive outcomes. Testing is a great opportunity to write technical documentation and documentation for site administrators. Bug reports can lead to documentation of known issues and help unearth unforeseen requirements.

Challenges of Testing Drupal Websites

Testing Content

Most Drupal sites are full of content, and testing a site with real-world content is one of the main tasks we're faced with when testing Drupal projects. Variations in content that can cause issues to appear include:

  • Quantity of content
  • Length of individual pieces of content
  • Interlinking between content
  • Different types of media
  • Language
  • Formatting

If a website includes a content import component, doing this at the beginning of a project is a great way to ensure that real content is tested as the site's functionality is built. For user-generated content, creating a suite of realistic test content that includes a variety of what users might enter is a great investment of time at the beginning of the project.

Testing Configuration

In Drupal, configuration is functionality and the configuration settings that you're delivering need to be tested thoroughly.

Since contributed modules often introduce functionality through the admin UI that is not relevant to the project at hand, documenting which functionality has been tested is important. A good way to clarify this is to use Features as a form of documentation, including certain confiuration settings in 'configuration' features which only developers can update. This can clarify what configuration is intentional and key to the functionality of the website.

Things that are Assumed to Work

When you're writing requirements for a Drupal project, a lot of things get glossed over or left over because it's assumed that Drupal core will handle them, or that they will 'just work'. It's important to remember these during the testing process:

  • Core Drupal Features
  • Security
  • Performance
  • Accessibility
  • Browser Compatibility
  • Integration with APIs
  • Import Scripts
  • Admin UI
  • Admin Workflows
  • Mail Servers

Using an Issue Tracker to Improve Testing

My presentation included a series of tips for improving bug reporting by taking advantage of issue tracking features. Over the past few months at Evolving Web, we've been working to improve how we use Redmine to manage projects and track issues, and this plays a big role in the testing process.

Since Redmine is an open source tool, we've written some custom plugins to extend what it does and customize it to fit our needs. You can read more about our Redmine Google Docs Plugin.

Regardless of which issue tracker you use, you can improve your issue tracking process by making sure that testing results in better bug reports:

  • Review issues before they're closed or resolved
  • Assign issues to the right person
  • Link to related issues
  • Don't make duplicate issues
  • Categorize and prioritize issues
  • Integrate specifications with the issue queue
  • Use pictures (i.e. screenshots)
  • Add lots of links (to the issue, to the config settings for the issue, to related Drupal.org issues etc.)
  • Include 'Steps to reproduce', or even a script to reproduce

Another key to making effective use of your issue tracker is making sure that there's an issue for everything. This means that these changes are documented and, hopefully, tested over the course of the development process.

  • Configuration changes
  • Adding a content type
  • Adding a user role
  • Installing a module
  • Installing a new language
  • Importing content
  • Writing custom code

Methods of Testing

Different situations call for different methods of testing. Some features, like validation or e-commerce transactions, are critical and very specific. These are well-suited to specific, scripted tests that can be repeated and tested frequently. At the other end of the spectrum, usability and design features are very difficult to test in a scripted fashion. Exploratory testing, in which tests can be adjusted on the fly by the tester, are better suited for these types of features.

Automated Testing

One of the major benefits of scripted tests is that they can be automated. Tests that are automated can be run frequently. Automation can also serve as documentation in the issue queue. Using a tool like Selenium IDE, non-technical testers can record the 'steps to reproduce' when creating a bug report.

What is Selenium IDE?

Selenium IDE is a Firefox add-on that makes it easy to record tests. It records your actions in the browser and then replays them when you run each test. Tests consist of a set of command, which you can edit. You can also 'verify' that an element appears on the page in a particular place. A simple example of a Selenium test for Drupal would be filling in the fields for a particular content type and then verifying that they appear in the correct place on the node page. The Software Testing Club has a great intro to Selenium series if you're looking for help getting started.

Sharing Tests

Automated tests can be hard to maintain, since they need to be updated as the functionality of the site changes. Sharing tests through version control or on a testing server can help reduce efforts in writing automated tests. Selenium tests include a 'base URL', which lets you easily change the base URL of tests so they can be run on different environments.

Managing Test Content

One of the first things you'll notice when running Selenium tests is how quickly you can create a lot of test content. Writing tests that create, verify, and then remove content is a good way to manage this. It will also avoid overlapping namespaces if you're testing items that have to be unique, like adding custom fields to a content type or creating users.

Test Suites

Besides writing individual tests, Selenium allows you to create test suites which group tests together and allows you to run them sequentially. This is really for a set of tests for a particular user role. Rather than including a login step at the beginning of each test, this means you can login once before the tests are run.

Beyond the Basics

Selenium also has a Web Driver which can run tests server-side and allow you to test in other browsers. This is useful if you want to extend what Selenium can do, run your tests automatically, or write tests by hand.

We've come a long way since the early days of tracking issues on a white board, but our quest to turn Redmine into the ideal issue tracker is far from over. We're also still figuring out the best way to integrate unit tests and automated tests into our development workflow. As Drupal projects become more complex, testing becomes more important to each project's success. We hope to share more about the evolution of our testing process in the near future, so stay tuned!

Nov 03 2011
Nov 03

Last weekend, we headed down to Manchester for DrupalCamp New Hampshire. Building on last year's successful Drupal beginner training day, the local user group organized an awesome one-day camp with 30+ great sessions, training, and even a code sprint.

The camp had a great turnout, with over 140 hearty New Englanders (and two foolish Floridians!) braving an epic blizzard (dubbed "Snowtober") that knocked out power for much of the state.

I really enjoyed having a chance to present on Evolving Web's approach to Drupal testing and QA, which included Alex's impromptu demo of Evolving Web's custom Redmine plugins for Google Spreadsheet integration and simplified wiki editing.

Snowtober in New HampshireThe camp featured five session tracks, which meant there was always something for everyone. The after-party at a local microbrewery was a great way to reconnect with friends and catch up on Drupal gossip while drinking a locally brewed pumpkin ale and watching the snow fall. I'm very glad that the power didn't go out until midnight!

You can find photos and tweets from the camp via this Storify page.

Prep for DrupalCamp New Hampshire I'd like to thank Jake Strawn (@himerus) and Michelle Lauer (@bymiche), for organizing a great event, and for hosting me and other attendees at their place for two nights. They're simply an awesome Drupal couple.

Oct 04 2011
Oct 04

We've been hearing a lot about responsive design and the future of the web recently. At DrupalCamp Montreal this September, Jen Simmons and Jake Strawn talked about why responsive design is taking hold. I was inspired to try out some of the techniques they talked about, and decided to convert evolvingweb.ca to be more responsive.

Unlike creating an iPhone app for your website or throwing together a mobile theme, applying responsive design to your existing site requires you to change the design of your website. What I thought would be a few small adjustments to the theme turned into a larger project to make our design and theme more flexible and robust.

What is Responsive Design?

Rather than designing a site that works for one screen size, or designing separate themes that work for different devices, the goal of responsive design is to build a website that adapts to the width of the user's screen and works for both large and small screens. This involves creating a flexible-width layout that will adapt as the screen size changes, and writing some CSS specific to screens with a particular size so that you can trim down or hide certain elements at smaller widths and restrict the width of the page at large screen widths.

Media Queries

Currently, the main technique for implementing responsive design is to use media queries. Media queries allow you to include CSS files based on the size of the user's screen or device. At different screen widths (or device widths), you can load different CSS files which change the layout and styling of the page. You can do this either by targeting screens with a particular minimum width, maximum width, or both.

CSS for Larger Screens

To include CSS files for screens larger than a certain width, you can use the following in your mytheme.info file:

stylesheets[screen and (min-width: 760px)][] = css/screen-760.css
stylesheets[screen and (min-width: 960px)][] = css/screen-960.css

The screen-760.css file is loaded for browsers the width of 760px, but also larger screens. It allows for a total page width of 760px and also defines a layout for the columns to fit in that width.

The screen-960.css file is loaded for any a screen width of 960px or larger. It restricts the width of the page to 960px and allows for normal-sized column widths (i.e. 640px for the main content and 320px for the sidebar). If you're converting an existing theme to be responsive, this will contain a lot of what used to be in your layout CSS file.

CSS for Smaller Screens

Include the following in your .info file to include CSS for screens smaller than a certain width:

stylesheets[screen and (max-width: 320px)][] = css/screen-320.css
stylesheets[screen and (max-width: 480px)][] = css/screen-480.css

The screen-320.css file would only be loaded for screens 320px wide or narrower. The screen-480.css file would be loaded for screens 480px or narrower. Notice that since a device that is 480px wide will load both files, it makes sense to load the screen-480.css file second so it overrides the styles in the 320px stylesheet.

CSS for a Range of Screen Sizes

You can also effectively set a range of screen sizes that your CSS will target by combining a min-width and min-width in your media query.

stylesheets[screen and (min-width: 480px) and (max-width: 760px)][] = css/screen-480-760.css

Inline Media Queries

Depending on your design, you might end up with a lot of screen-size-specific CSS files. Sometimes it's more appropriate to use several media queries within a CSS file, using the @media rule.

@media screen and (max-width: 480px) {
  #page {
      width: 480px;
  }
}

Device Width vs. Browser Width

I should clarify that using min-width means that the CSS file will be loaded based on the browser width, so this will apply to users of large monitors who resize their browser. This is really useful for testing your responsive design, since you don't need to switch devices to see your design change, just change the width of your browser. If you only want to detect the device width only, use min-device-width or max-device-width.

It's Not Working on Android!

In addition to adding these media queries, Android devices need a 'viewport' meta tag to being able to detect their own screen width. Adding the media queries above won't have any effect on Android devices until you add this meta tag to your site. You can add it from your mytheme_preprocess_html() function using drupal_add_html_head() like this:

<?php
  $meta_viewport 
= array(
    
'#type' => 'html_tag',
    
'#tag' => 'meta',
    
'#attributes' => array(
      
'name' => 'viewport',
      
'content' => 'width=device-width'
    
)
  );
  
drupal_add_html_head($meta_viewport'viewport');
?>

What to do about Internet Explorer?

Internet Explorer versions 6-8 don't implement media queries. For these versions of IE, you can either implement some kind of responsive solution with javascript, or you can decide not provide the responsive layout for IE users, which the approach I took. In this case, you still need to provide CSS targeting IE so that users viewing your website on a larger device with IE will not see a full-width design. To implement this approach, the CSS you'll want to add for IE will likely be the same as what you added for screens that have a min-width of 960px (or whatever your widest page layout is). Drupal doesn't allow you to add a CSS file more than once, so you'll have to create a duplicate CSS file. My solution was to create a separate screen-960-ie.css file and use @import to include in it all the CSS from the screen-960.css file.

You can add a CSS file for IE only using the Conditional Stylesheets module. You can also add the file from your template.php file using drupal_add_css() and setting the browsers parameter.

Designing for Mobile

The instructions above will get you started adding media queries to your Drupal theme, but I think there's a lot to be said about how to actually create a 'mobile first' design. As themers, we're not used to designing and writing flexible-width themes for tiny devices. Even though you might like the idea of 'mobile first', your client probably expects you to design for standard-sized monitors and adapt the design for smaller devices afterwards.

Adapting a design to be responsive after it's fleshed out for a fixed-width screen is not an easy task. You can stack columns on top of each other at smaller widths, make certain elements smaller, and remove others altogether, but some elements are going to be hard to adapt. If you resize your browser to a smaller width, you'll notice a lot of awkward layouts (i.e. an image that takes up almost the full width of a column, with just a couple words wrapping to the right of it).

The best approach is to start thinking about how to make your theme responsive as you're designing and building it, and testing it at various screen widths as you go. This is going to be a challenge when the designer and themer are different people, especially if the designer is working exclusively in Illustrator or Photoshop.

Writing CSS for Responsive Design

Here are some tips to get you started writing CSS for responsive design.

  • Watch out for elements that are positioned absolutely. Will they overlap with other items at smaller screen widths?
  • Make sure your horizontal menus items wrap gracefully. Try centering them on smaller screens and using the CSS3 white-space: nowrap property.
  • Check the line-height on text that wraps at smaller screen widths.
  • Set a max-width for images of 100%, as well as for the HTML tag that wraps each image.
  • Set a max-width of 100% for form elements as well.
  • Watch out for elements with a fixed height or width. Try setting a min or max width or height instead.
  • Watch out for elements that are altered with javascript, including slideshows and text replacement tools.
  • Watch out for text that floats next to images. Do you need to change this behaviour for smaller width screens?

What do do with Tables and Panels

I found dealing with tables and Panels to be a huge challenge. Columns could be removed at smaller widths, or stacked on top of each other rather than sitting next to each other.

  • Panels layouts with more than one or two columns will not work well on smaller screens. Try writing CSS to remove columns or float columns differently at smaller widths.
  • If you're using grid-style Views to display non-tabular data, consider another display technique.
  • If you need to display data in a table, consider using advanced CSS techniques as described in this article.
  • Some of your mobile users will have an app for displaying spreadsheets on their device, so consider generating a CSV for users to download if you have a lot of tabular data to display.

Resources

Beyond Responsive Design

For some use cases when mobile performance is a priority, you'll probably want to go beyond responsive design and actually change the markup of the page for different devices. To get started doing this in Drupal, try the Mobile Tools or Context User Agent. However, mobile detection doesn't replace responsive design, and using device detection is probably out-of-scope for most Drupal projects.

Responsive design is really exciting and a great challenge for both designers and themers. While using a base theme that provides a responsive layout is great, it doesn't mean that you don't have to think about responsive design. We need to understand how different screen sizes effect our designs and how to meet the challenge of responsive design by creating more robust and more flexible themes.

Sep 30 2011
Sep 30

This September, to kick off Drupal Camp Montreal 2011, the Montreal Drupal community held our first large-scale Drupal code sprint. The sprint was held from September 14-16 at Notman House and carried on at the camp until September 18th. The sprint was spearheaded by Gábor Hojtsy who is leading the Drupal 8 Multilingual intiative. Francesco Placella, who has contributed to Drupal 7’s field translation API as well as the Entity Translation module, was also a key contributor.

In Quebec, support for multilingual websites is extremely important as most projects include some type of multilingual user interface and content. Holding a code sprint for the multilingual initiative was a perfect opportunity for our community to contribute to Drupal. Overall, there were over 15 contributors who attended the code sprint including developers, UX designers, site builders, and new-comers to Drupal. Our whole team participated in the sprint and three of our developers attended all five days of the sprint.

The code sprint covered a lot of ground, including documentation, UX improvements, and patches to Drupal core and the Entity Translation module. UX improvements were proposed for installing new languages and configuring languages in Drupal. Core development was done to improve how various Drupal APIs handle language. Since most Drupal developers don't have experience with multilingual, this is key to improving Drupal's overall multilingual support. For an overview of all the progress made, read Gábor’s summary of the sprint or watch his presentation from the camp on the Drupal 8 Multilingual initiative. Here’s a summary of our contributions:

Code

Logan Smyth worked on creating new functions for managing multilingual field items (http://drupal.org/node/1260640), adding support for Javascript versions of t and formatPlural (http://drupal.org/node/488496), moving the language domain and prefix settings to the language negotiation configuration page (http://drupal.org/node/1280530), and creating a new API for managing Locale source and target strings (http://drupal.org/node/361597).

Tavish Armstrong worked on language handling in the form API (http://drupal.org/node/1280996), the API for deleting languages (http://drupal.org/node/1260528), and compatibility between Node Clone and Entity Translation (http://drupal.org/node/1230858).

Thomas Getgood, our newest developer, worked on a patch to enable bulk field language updates when switching field translatability for the Entity Translation module (http://drupal.org/node/1279372).

Documentation

Suzanne Kennedy, our front-end developer, worked on multilingual documentation with Sylvain Aube of Whisky Echo Bravo. Together, they cleaned up the existing documentation and added pages on Entity Translation (http://drupal.org/node/1280632). They also pushed to make the Drupal multilingual documentation guide a top-level handbook on drupal.org, which it now is. You can learn more about the Entity Translation module and how it compares to Content Translation from Suzanne’s presentation at DrupalCamp Montreal.

Thank You!

The sprint was a huge success, and a great milestone for the Montreal Drupal community. In addition to learning more about the multilingual intiative and how languages are handled in Drupal 7 and 8, we learnt a lot about contributing to Drupal, issue queue management using IRC, and how to write tests. Thanks to Francesco and Gábor for making the trip to Montreal from across the Atlantic! Thanks to Notman House for providing the venue for the first three days of the sprint, and McGill for hosting the camp and sprint over the weekend. The Drupal Association also provided us a community cultivation grant, which paid for Francesco's flight from Italy and Acquia flew in Gábor Hojtsy from Hungary as part of their sponsorship of the camp.

We’re looking forward to helping organize another sprint in Montreal in the near future!

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