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
This lesson takes a look at working with the already existing entities in Drupal such as users and nodes and demonstrates some best practices for working with them in your own custom module. We'll focus on writing code that will work with any entity type and isn't hard coded to work with just nodes or just entities.
Additional notes:
There is a typo in the video. Joe created the variable $types = 'comment'; in one spot and then used it as entity_load($type, ... which obviously wouldn't work because the later is missing an 's' on the end. The downloadable code for this video doesn't have the typo.
Additional resources
This chapter shows how to cluster different form elements into fieldsets as well as how to expand the Forms API renderable array a tree that preserves the structure and hierarchy of the form. We'll expand the Form Fun example module and talk about the #tree property. This video uses krumo() and dsm() functions. You will need to download, install, and enable the devel module to use these functions. These functions allow you to see what variables are available to you. To accomplish the same task without using the devel module, you can add the following snippet to your module: drupal_set_message('' . print_r($vars, true) .'');
Note: There is a typo in the code used in this video. The function form_fun_tree()
is missing a parameter, and should be as follows function form_fun_tree($form, &$form_state)
.
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.
This lesson demonstrates the bare minimum needed to create a custom entity type and to load an Entity from the database. We’ll look at implementing a minimum viable hook_entity_info, talk about the relationship between the Entity API and the Schema API and use entity_load to retrieve a single entity record from the database.
Note, although it would be considered best practices to name the entity with the name of the module, e.g. videoentity_video, we did not include the module name prefix here because it is tedious to type it all out and to say "videoentity_video" without confusing people.
In the next lesson we'll cover the various entity classes and how they work. However, if you just want to get straight to using your entity and doing things like $entity = entity_load();
you'll need to declare a controller for your new entity type. Simply add this 'controller class' => 'EntityAPIController'
in hook_entity_info()
. That will get you started, and well talk about what exactly that line does in the next lesson.
Note: the video doesn't mention the 'primary key'
element in the schema array (although it is in the code). This bit is necessary for the schema to install properly and work with the Entity API so if you're following a long make sure you add that part as well.
Additional resources
This video goes through the process of creating a configuration form in order to save settings to the variables table in the database, and how to integrate those variables into your module.
Correction
The $item
array in the function demo_menu()
should be named $items
, to match the return $items;
line. (Either that or return $items;
should be fixed to return $item;
.) Just make sure the array you are building matches the name of the variable you are returning.
Additional resources
This video walks through the handy devel module from http://drupal.org/project/devel and demonstrates the tools it provides for debugging, inspecting and analyzing the code and SQL queries happening on your site. In this video you'll also learn about some of the helper functions built into the devel module that make it simpler to inspect the large nested arrays that you'll commonly come across when writing code for Drupal.
You may not have heard of the function dsm() before now. It is a legacy function and dpm() is the newer name. The two functions are identical since dsm() is just a wrapper for dpm().
The idea is that dsm() was a poor name for the function, it's short for drupal set message, but what was later decided that drupal print (as in print_r) message was better.
The difference between those two and kpr() is that dpm() does a permissions check to make sure the current user has permission to view devel's output, and then puts the krumo'd variable dump into the message queue via drupal_set_message(). This means that dpm() will work and let you see the output even if you're redirected. Great for debugging forms. kpr() just krumo's and dumps the value right here, right now. No permission check, no regard for where the content is being spit out.
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)
This video describes a number of the most important configuration files within MAMP that are commonly edited in order to run a web application like Drupal locally. There's a brief tour of the http.conf file, and then walks through the process of upping the max_allowed_packet limit from 1M to 2M within the my.cnf, which was a renamed copy of the my-large.cnf file. It's also a good idea to turn off binary logging on your local development by commenting out log-bin and binlog_format lines within this my.cnf file. Addi then shows you how to raise the PHP memory unit from 32M to 256 by opening the php.ini file and changing the memory_limit value. Finally, she shows you how to use MAMP's version of PHP and MySQL from the commandline by editing your .bash_profile and adding a number of paths to your default PATH. Note: The configuration files may have moved between versions of MAMP. You should check for where the MySQL cnf files are for your specific version of MAMP. A quick Google search can probably get you set in the right direction.
To learn how to install MAMP, see the Installing MAMP Server tutorial.
Additional resources
More information on Development Environments
This videos goes through the process of creating a form with Drupal Forms API that is single select list that has a validation, submission and redirect functionality.
NOTE:
Their is a typo in the code displayed in the video. The function
function form_fun_cake(&$form_state)
is missing the $form paramater and should instead be
function form_fun_cake($form, &$form_state)
Curious about when you're supposed to translate "title" and when you should leave it alone? Here's the answer: You don't need to translate the 'title' attribute of an array that defines a menu item because Drupal will take care of that automatically. In fact, you shouldn't translate those as they'll end up getting double translated if you do. This is because Drupal end's up using this string of text in a number of different ways some of which don't actually need to be translated and others that do like for example when it's the title of a page or the text of a link in the menu system. The #title (and #description) property for elements in Form API array however are your responsibility to translate.
Probably the most common use case for view modes is teaser nodes. Or, a node being rendered in the teaser view mode. View modes allow entities to be displayed different depending on context, and also allow other modules like Field API that participate in the entity rendering process to adjust their behavior depending on the requested view mode.
In this lesson we’re going to take a look at an ‘authenticated’ view mode that we can use to adjust the display for any authenticated users. Then we’ll update Entity Controller class and make use of this new view mode in our ::view() method.
NOTE: in the video Joe forgot to change the 'member' label to "Member" and then later in the video when we view it in the UI it is corrected. The sample code included with this video has the correct label.
In this lesson we're going to take a more in-depth look at the UI controller we used earlier to create our administrative UI for the entity. We'll walk through how the controller adds menu paths and the like, without us needing to do any extra work, and then clean up our form-builder functions by overriding the UI controller's method, so that we can gain control of the name of the function that's called.
This lesson takes a look at exposing the data in our entities to views. Lucky for us the entity API handles a lot of this for us. We’ll take a look at what we get for free, using the EntityDefaultViewsController class provided by Entity API module. We'll also discuss ways that we can customize this controller, which we'll tackle in a later lesson.
"There's a module for that."
You've probably heard this before. Many times you can find a module that provides the functionality you need — or at least pretty close to what you need. Drupal's contributed module projects number in the thousands, but what if there isn't a module for your use case? You just might need to build a module for that.
In this series, you will learn about the tools and resources available to Drupal developers, including where to find documentation and what APIs are available to you, both on drupal.org and api.drupal.org. We'll take a look at the Devel module and learn how to use it to inspect the variables, objects, arrays and other things at work under the hood of Drupal 7.
You'll build several different modules that explore and interact with Drupal's various systems and API, including:
- Form API
- Menu system
- Hooks
- Render API
- Theme system
- Database API
Over the course of this series you'll be able to:
- Describe the anatomy of a module
- Implement common hooks
- Write more secure code
- Interact with Drupal's menu system
- Create and alter forms
- Peform CRUD operations on a database
This series starts with the basics and moves you step-by-step to more advanced concepts. Even if you are quite comfortable with PHP but are struggling to understand how to appropriately interact with Drupal 7's API, the lessons in this series can help you develop "The Drupal Way."
Additional resources
In order to make the most of the entity APIs integration with other modules, such as Views, we need to describe the properties of our entity in more detail. The API can infer some information about a property based on our schema but we need to tell it that the integer stored in the updated_at column is actually a timestamp. We will do this by implementing hook_entity_property_info()
and describing each of our entities properties. With these definitions in place you will be able to use the formatters in Views much like you would for individual fields on content types provided by core.
Note: Before you implement hook_entity_property_info()
the API makes an educated guess about each property but once you've defined a single property, the API expects you to define all of the properties for your entity. Use the .install
file in your module to get a complete list of the properties you need to define with hook_property_entity_info
. You can also define additional properties that aren't mapped to fields in the database (these can be used for static properties).