This lesson includes a short presentation that explains the basics terminology and architecture of the migrate module and the components that make up a custom data migration. We'll talk about the Extract / Transform / Load process and how it relates to data migrations, the types of data sources that the migration module can read from, and a little bit about how the code in both the migrate module and our own custom migrations will be organized.
Additional resources
In this lesson we'll cover downloading and installing the Migrate module (version 7.x-2.6) and ensuring that our local environment is ready to be able to run migrations via both the UI and drush. Once that's setup we'll take a high level look at the migrate module's UI and drush commands to familiarize ourselves with the tools that we'll be using throughout the rest of the series. This will also help formalize some of concepts introduced in the previous lesson.
Additional resources
Migrate module project page
migrate-7.x-2.6-rc1 download
Migrate module documentation
Introduction to Drush series
Drupalize.Me Migrate module series code on GitHub
This series is focused on using the Migrate module to import data that exists in various different sources into a Drupal 7 website. The Migrate module provides an extremely flexible and robust framework for accessing data from various sources and importing or migrating that data to Drupal. With built in support for creating core Drupal data types likes nodes, users, and taxonomy terms, the Migrate module is one of the best solutions available for importing content into Drupal.
This series kicks off with Joe Shindelar explaining the basic components that make up a data migration, and the terminology and code that is specific to the Migrate module. Then continues with a series of lessons that take you from installing the Migrate module to writing and running your own custom data migration.
Throughout the series Joe teaches us how to run a data migration using both the Migrate module's UI and drush, and some of the plusses and minuses of both methods. Joe also talks about the various different sources, or types of data, from which the Migrate module can read data and how to map the unique fields in a row of source data to their corresponding Drupal content types and fields.
By migrating from a single source into two different Drupal content types we'll also have the opportunity to learn about creating relationships during a migration and mapping the resulting information to an entity reference field. During the course of writing a custom migration Joe will show us how and where we can add code to perform additional runtime data munging during our import process. We'll learn about importing data into multi-value fields, and even providing defaults for fields that don't have information. Then we'll look at some of the tools the migrate module provides for collaborating with team members in order to create a successful migration path.
Finally we'll wrap up the series by looking at a couple of different techniques for debugging our migrations and dealing with pesky source material that just doesn't want to be imported.
Because this series is focused primarily on writing custom data migrations, and since the Migrate module itself requires at least some amount of code to be written to perform a migration, it is suggested that students be familiar with PHP and basic Object Oriented Programming techniques. Although not required to run a migration, Joe uses the drush command line tool extensively in this series. If you need a refresher on using drush take a moment to watch our drush series.
Additional resources
In this lesson we'll take a look at running migrations via drush rather than via the Migrate module's UI. We'll take a look at the commands provided by the Migrate module and talk about what they do. Then we'll practice running, rolling back, and otherwise interacting with migrations via drush commands. Throughout the lesson we'll learn about some of the functionality you get from running migrations via drush that are not provided by the UI, like the ability to specify a single record to migrate with the --idlist flag. Finally we'll learn about why in most cases drush is a better tool for running large data migrations because of the limitations imposed on the UI. Pay close attention to this lesson since throughout the remainder of this series we'll be running all of our migrations via drush.
Additional resources
In this lesson we'll take a more in-depth look at the migrate module's UI with a focus on being able to identify and execute custom migrations. For now we'll work with the provided example migrations just so that we have something to work with. Throughout the lesson we'll learn how to run a migration to import it's data into Drupal, rollback a migration that was previously run in order to set a clean slate, and other ways we can interact with a migration via the UI. Then we'll discuss some of the challenges inherit in running migrations via the UI and Drupal's Batch API and how to identify them.
Additional resources
Converting an exisiting theme to Omega takes time and some planning, but Omega gives us plenty of options of moving things around the page all without touching a piece of code. When working with a grid layout we use Omega to set all of our content to span the proper columns all while moving our content from zone to zone so it is placed properly on the page. We will cover:
- Moving content from zone to zone
- Choosing proper zone column widths
- Splitting column amounts to create right and left columns
Once all of this is complete we are just a few steps away from getting into some CSS and really making our theme come together as an Omega sub-theme.
Additional notes:
If you want to touch code, you can edit the .info file as such (for the first part, moving branding zone):
settings[alpha_region_branding_zone] = 'header'
...
settings[alpha_region_branding_weight] = '3'
...
settings[alpha_region_header_first_weight] = '1'
...
settings[alpha_region_header_second_weight] = '2'
Responsive design is more than a just a buzzword these days but a standard practice of good web shops when building out a site. Omega provides a responsive design out of the box and gives lots of options to layout your content in the proper places and the ability to work with the break-points all with a User Interface. In this lesson we will cover:
- Omega responsive options
- Column settings for your grid layout
- Omega responsive layout settings
- Device viewports and media queries
We end the lesson getting our new sub-theme ready to handle our 960 robots theme and the 16 column setup we designed it with.
If you prefer working with code, instead of the web UI, you may configure your theme as follows to change your column settings from 12 grid columns to 16 in your theme's .info file:
Find and replace all the instances of:
_columns] = '12'
with:
_columns] = '16'
There may still be additional regions that also need to be set which weren't the full width. You can edit other regions as needed, such as:
_region_user_first_columns] = '8'
change to:
_region_user_first_columns] = '12'
Deploying Your Code
FreeIn this lesson we will take the code we have committed to our remote repository and manually push it to our production server. We will cover how to setup deployments on beanstalkapp.com and the some of the advantages of using a tool like this.
A question we are commonly asked is: how did your production environment recognize the new feature?
Answer: Reverting a feature reverts it back to what is in code. So by updating the code it always looks to the code so there is no need to revert it. You usually revert a feature if you have made changes that are stored in the database and you need it to look back to the code as your database changes are not what you wanted or are wrong. If the changes you made in the database are what you want, then you update/recreate the feature.
One thing we haven't looked at in our feature yet is Drupal roles and permissions. Here we will create a role associated with out Blog feature and look at how we can roll that important bit in.
In this video we are using the Environment Indicator module to visually distinguish between different environments.
Additional resources
Features project (Drupal.org)
Introduction to Drush Series (Drupalize.Me)
https://github.com/DrupalizeMe/drupalize-lullablog (GitHub.com)
Features will auto-detect dependencies for you, which can be very handy, but at times it can also be very frustrating when you don't want them to. In this video we introduce the Features Plumber module and show you how to use it to finely control your dependencies.
We are sometimes asked how Features can be removed. Since a Feature is just a normal module, you can disable it on your module administration page, and even uninstall and completely remove it from your modules folder. That will completely remove the feature from your site.
Note: The Features plumber module is no longer necessary if you're using Features with Drupal 7. The functionality provided by this module has been included into newer versions of the Features module. So as long as your Features module is up-to-date you should be good to go. The concepts from this video do still apply.
Additional resources
Features project (Drupal.org)
Introduction to Drush Series (Drupalize.Me)
https://github.com/DrupalizeMe/drupalize-lullablog (GitHub.com)
Walks through the process of first adding the search block to the node template file, and then explains some of the best practices for incorporating JavaScript scripts within your theme. Walks through how to protect the dollar-sign variable, and how to use the Drupal behaviors instead of the document ready so that your JavaScript will fire not only on page loads, but also if there is any dynamic material being loaded on the page through asynchronous page loads. We'll show you how to select the jQuery selector to target the desired element, and how to conform to Drupal's best-practice coding standards when it comes to integrating JavaScript and jQuery into your theme. You can learn more about jQuery itself with the Introduction to jQuery Series.
To use Query in no conflict mode, because was not defined.
Add this line on the top: jQuery.noConflict(); more info here: http://api.jquery.com/jQuery.noConflict/
To improve how the search box looks, you need to modify the following:
currently : search-theme-form
modify to: search-block-form
and then in the property in line 321 to look like this:
/* Header quick search */
#header form#search-block-form {
top: -165px;
Additional resources
Shows how you can use the ajax framework in Drupal 7 to load additional content onto the page dynamically after clicking on a 'read more' link.
The sample code for this series is in the Downloads tab for the first video in this series: http://drupalize.me/videos/introduction-jquery-and-javascript-drupal#do…. If you're skipping around, and things aren't working, you may benefit from going back to the beginning and completing each of the videos in order.
Emma Jane Westby introduces the series. In this series, you'll learn how to transform a static design file into a whole Drupal theme. We'll work through three major steps.
- Develop a style guide based on the design patterns we see in our design files.
- Build out Drupal so that it has all of the elements we need in place.
- Work with theming files to decorate Drupal.
Additional Resources
In addition to the lessons in this series, Emma has assembled an extensive FAQ on Drupal theming.
In this lesson we'll take a tour of the theme you'll be building. The design we'll be working with was created by Betty Bisenthal. It's a fairly simple design with three columns and a banner image. It has been used as a starting point for several years by many people who are learning to theme. In this lesson we'll take a look at:
- the design we'll be working with
- variations of this design created by other students
- how Drupal was customized to accommodate our design
- the Sass used to create the layout for the site
By the end of this lesson you'll be able to describe the shape of the design used throughout this series, and identify variants of the design.
Additional resources
In this lesson we're going to learn about the front end development strategy of theming by components. This strategy relies on being able to break a design into individual components. Elsewhere on the Web this technique has been described as “atomic design” or “interface pattern pairing”. No matter what you call it, developing a pattern library of components is going to make it a lot easier to convert your design to a theme. This is an overview lesson that explains the strategy we'll be using in future lessons. More specifically, we'll look at:
- two popular pattern libraries
- an overview of how pages are built by Drupal so they can be rendered in a browser
By the end of this lesson you'll be able to identify components from a static design file by referencing a pattern library.
Additional resources
SMACSS (Scalable and Modular Architecture for CSS)
Over the last couple of years we've seen the rise of object oriented CSS. There's been a lot of work done by smart folks to categorize different types of rules that we use to style our sites. We're going to take advantage of this work and use it to create a style guide. This foundation piece will help us to map the elements in our static design to the elements that we will build, and theme, in Drupal.In this lesson we'll create a style guide from our design with:
- Base rules
- Layout rules
- Component rules
By the end of this lesson you will be able to create a text-based style guide of your design which accurately describes your site according to base rules, layout rules, and component rules. You will be able to further supplement this style guide by adding relevant images which reference the exact component the style guide is describing.
In the previous lesson you created a text-based style guide. It's now time to extract the necessary assets from our static design for use in our theme. To complete this lesson you will need a design application capable of opening a .psd file. The video demonstrates Photoshop, but I typically use Gimp. Either is fine. And if you don't have a graphics program, you can watch the video, but simply download the assets which were extracted during the lesson. By the end of this lesson you will be able to identify page-level design assets which need to be extracted from a design file for your Drupal theme.
Additional resources
In this lesson we will convert the style guide into a series of stubs which we can view in a Web browser. The design was originally created using the templates from the 960gs. We'll use this same grid framework to ensure all of our margins are automatically adopted. Grid frameworks are excellent for rapid prototyping of designs. Ultimately many front end developers choose choose to write their own for the final theme; however, if you're just getting started try to stick with a grid framework to reduce the number of things that you need to fight with.
The original theme that was created for this design used the NineSixty base theme. There are some nifty features in this theme which are great for more complex designs; however, it is not responsive, and does not use Sass. To bring the lessons up-to-date we'll be using the 960-Compass Plugin to generate our stub files and give us some sample Sass output to work with.
By the end of this lesson you will be able to convert a style guide to a series of stub files in Sass (or CSS) using SMACSS conventions and a grid framework.
Additional resources
SMACSS (Scalable and Modular Architecture for CSS)
In SMACSS there are both major and minor layout rules that need to be created. The major layout rules are often handled by a grid framework and are used to describe big areas on your site, such as your Drupal regions. The minor rules are used for the components (for example how a picture aligns next to a paragraph of text). In this lesson we'll start by review how Sass allows us to use semantic naming for our CSS layout classes. Then we'll adapt the sample Sass provided by the 960 Compass Plugin so that it uses the necessary structure for our design.
By the end of this lesson, you will be able to implement the layout rules from your style guide as a Sass file using the 960 Compass Plugin as a reference.
Additional resources
The final step before we step back into Drupal is to create a checklist for all the things we need to implement in Drupal. Using our style guide as a starting point, we'll ensure that every design decision which has been made can be implemented in Drupal. Your checklist might also include notes about which modules should be used to build each of the components from within Drupal. Creating a checklist might seem like a trivial task, but it's really important that you know exactly what you're about to build so that you don't get overwhelmed once you step into Drupal. By the end of this lesson you should be able to create a document with all the instructions, and notes you will need to apply your style guide to a Drupal site.