In this video Joe looks at using hook_views_data() in order to describe a database table to views such that views is capable of making queries to that table. We’ll talk about describing the table itself, and how to get it to appear in the views UI as an option that can be used as a base table.
Additional resources
Modules Needed
This video continues the process of adding a custom field handler started in the previous chapter.
Additional resources
In this video Joe continues the discussion of using hook_views_data() to describe a module's table to the views module. Building on what was covered in the previous chapter we now deal with exposing one of the individual columns from our table as a field that views can use for filters, sorts, and to display.
Additional resources
Modules Needed
In this chapter Joe will take a look at where to get a copy of the databasics code and what it does already. Throughout the rest of this series we will be working towards replacing functionality from the databasics modules with views integration in order to allow for greater flexibility in the ways that our module can be used. We'll talk about each of this pieces of functionality in this chapter.
Additional resources
Databasics module on GitHub
Overview of the Database Layer in Drupal 7
To get things started, in this lesson we'll create a new module, and use hook_views_api() to let Views know we want to use its API.
In this lesson, we give a brief overview of utilizing a very important feature when it comes to working with Drupal and that's Drupal.org. We show you how to get to the Views API documentation that is now part of Drupal's API documentation and teach you how to use the search function for finding particular function.
Additional resources
This chapter shows how to create a basic Rules action. It covers:
- The role of the module.rules.inc file
- Using hook_rules_action_info
- Writing action callbacks
This series covers the basics and some more of how to write your own plugins to extend the Rules module. It includes:
- A conceptual overview of the Rules modules
- Writing action plugins
- Managing rules data as parameters for Rules plugins
- Writing conditions
- Writing and invoking Rules events
This intro chapter contains a quick presentation of the Rules module from a conceptual perspective. It includes:
- Actions, conditions, events
- Data types: the importance of entities, relationships and tokens
- Lists and loops
- Components and parameters
- Some words about the Rules user interface
If you would like to see more about configuring Rules before continuing this series on writing code to integrate with the Rules module, you can watch the Learning the Rules Framework series. Note that Johan is using the Module filter module to provide the tabs and filter box on his module administration page.
Area handlers are used in the header, footer and empty text areas when creating a View. In this lesson, we’ll walk through creating our own area handler that can be placed in the footer to provide a summary of all the rows in our View.
In this lesson, we’ll take a look at how to modify the HTML output from Views, explore some of the default templates that Views provides, and learn about the various permutations of names we can give our template files to override output for everything from a large set of Views to a single field on a single View. We’ll also discuss the difference between displays, styles, rows, and fields when it comes to theming a View.
There's a reason views is the most popular module on drupal.org and it's pointy-clickly user interface is only a part of that. In this series we cover the ins and outs of writing modules that implement the Views API. Once you’ve realized the power of creating complex lists of nodes, users and other content via the views UI the next logical desire is to allow people to do that with the content provided by your custom module as well. This series will take an in-depth look at exposing your own database tables to the Views module so that users can use them as a place to pull content from including the fields themselves and meta-data about how they can be used to create relationships to other content on your site.
After getting the basics out of the way we’ll also take a look at writing our own custom field handlers to expose our module’s data to views so that it can be sorted, filtered, and queried in new ways. We’ll also look at implementing views plugins to do things like add custom access control options to views and to add new output styles.
Once you understand a bit more about how views works under the hood and how easy it is to tie in to that system you’ll be reimaging your solutions for all sorts of different problems.
In this video Joe describes the process of adding the rest of the fields from the databasics module to our implementation of hook_views_data() including how to differentiate between different data types like strings of text and numeric values and how this changes the views module's behavior. Then Joe talks about how to tell views about various tables that can be used in relationship to the databasics table via foreign keys like the node ID.
Additional resources
Modules Needed
In this lesson Joe will explain what an entity is and provide a little bit of history about how they came into being. We’ll also learn about some of the differences between custom entities and nodes (which happen to be a type of entity) and when, and why you might want to choose to write your own custom entities instead of using the node system or a more traditional datastore.
Entities were introduced in Drupal 7 as a way of taking the things that people loved about nodes + CCK in Drupal 6 and applying them to other types of data like users, comments, and taxonomy terms. The Entity API in Drupal 7 provides a set of common functions and classes to make it easier for developers to create their own custom entity types or to work with existing ones in a generic way. The API in Drupal core however is still missing some really useful tools and is supplemented by the Entity module in Drupal contributed which we'll make heavy use of throughout the series.
In this series we'll learn about the interplay between Entities, Entity Types, Bundles, and Fields and how to write custom code to deal with each of these things. The Entity API demo site files that we use in this series are all located in the Lullabot GitHub, as well as in zip files attached to the respective video pages, under the Downloads tab.
This series covers:
- What entities are and how they fit into the Drupal ecosphere
- EntityFieldQuery
- Entity classes, what they do and how to override them
- Providing an admin UI for adding/editing and deleting entities from Drupal
- Making entities fieldable
- View modes
- Creating custom UI's for dealing with entities
- Describing entity properties to Drupal
- Views integration for entities
- Entity Metadata wrappers
- Making entities revisionable
And much much more. This series assumes that you're already familiar with the basic tenets of writing modules for Drupal and makes use of things like hook_menu() without spending time explaining them. If you're not familiar with Drupal module development, you might want to brush up by watching our Module Development for Drupal 7 first.
Additional resources
Entity API Demo site files on GitHub
Entity module at Drupal.org
This lesson will explore the use of EntityFieldQuery to retrieve lists of entities from Drupal without directly querying the database which can be problematic in a system where the underlying schema can change depending on configuration settings in the user interface. Again focusing on writing code that will work with any entity in Drupal and isn't hard coded to your particular setup.
Additional resources
In the next set of lessons we're going to be writing to the code to create our own custom entity type. The goal is to create a video entity that stores embed codes for YouTube videos and allows us to display the videos on our site. In this scenario we don't want all the overhead that comes with using the node system, like comments for example, so instead we're going to write our own custom entity for storing the data. We're going to take a look at the completed entity type that we're attempting to build and just walk through all the various components. We'll take a look at creating/updating, and deleting a video via the UI, and also the views integration and fieldability of our custom video entities.
This lesson introduces students to Entity classes and illustrates what each of the main Entity classes does, followed by a more in depth look at the CRUD operations provided by the base entity class, and finally demonstrates overriding the default Entity class with our own custom Entity object to define a defaultUrl() for our entities and a new implementation of hook_menu where we can view an entity.
Note: At the end of the this video code is added to hook_entity_info() that references a VideoEntityUIController class, however, the definition of that class is in our sample code, but was not shown being added here. And it is necessary to follow along with the videos. If you're following along you'll want to add the following code to the bottom of your videoasset.module file. If you're curious about what it does it's explained in the last part of this video.
/**
* Our custom controller for the admin ui.
*/
class VideoEntityUIController extends EntityDefaultUIController {}
Additional resources
Update your hook_entity_info implementation to take advantage of the Admin UI provided by the Entity API and quickly provide users of your site access to all the Entity CRUD operations via the UI. The API gives us a really good head start but we still need to write some code in order to provide a useable form for administrators. The API doesn’t make any assumptions about things like validating input so we also need to take care of that ourselves.
This video adds a new permission that allows privileged users administer our new videoasset entities. If you're following along as a user other than user 1 you'll need to make sure you give yourself the proper permissions. In the video, I'm logged in as the user with the ID of 1 so I'm just granted the permissions automatically.
Note: If you're following along with the videos in sequence there's an error that needs correcting. At the end of the previous video code was added to videoentity_entity_info() that references a VideoEntityUIController class, however, the definition of that class was not added. Which, will cause a PHP error because the class is missing.
In order to correct this error, you'll want to add the following code to the bottom of your videoentity.module file. This just ensures that the class is defined so that there are no errors. If you're curious about what it does it's explained in the last part of the previous video.
/**
* Our custom controller for the admin ui.
*/
class VideoEntityUIController extends EntityDefaultUIController {}
In a later tutorial in this series, we'll customize the form for our video entity by adding more code to this class.
Note: At 14:10 on line 36 this line is added:
'#value' => isset($VideoAsset->id) ? t('Update video asset') : t('Save video
asset'),It should be:
'#value' => isset($video->id) ? t('Update video asset') : t('Save video
asset'),
So far we’ve seen that you can use entity_load and entity_view to display your entity. But what if you want more control over how your content gets rendered? In this lesson we’ll take a look at overriding the buildContent() method of our entity controller to spruce up the output a bit. We'll also overrid the save() method of the controller in order to populate the created_at and updated_at fields automatically when saving a video entity.
Note: In order to improve upon the security of the code in this lesson you'll want to make sure you're escaping all user input properly. The following code:
$build['embedcode'] = array(
'#type' => 'markup',
'#markup' => '<iframe width="560" height="315" src="http://www.youtube.com/embed/'. $entity->embedcode . '" frameborder="0" allowfullscreen></iframe>',
);
Should be updated to use the check_url() function when outputting $entity->embedcode to ensure that user entered content is safe for use in the context of a URL.
$build['embedcode'] = array(
'#type' => 'markup',
'#markup' => '<iframe width="560" height="315" src="http://www.youtube.com/embed/'. check_url($entity->embedcode) . '" frameborder="0" allowfullscreen></iframe>',
);