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).
Additional resources
If you've done any module development, you're probably familiar with hook_node_view and Drupal's arrays of doom. In this lesson we'll show you how to get easier access to the same information using entity metadata wrappers. We will use the entity_metadata_wrapper function to retrieve a new EntityMetaDataWrapper object that provides an interface for easily accessing an entities property and field values. We'll use the getPropertyInfo method to expose information about individual properties, and the getIterator method to access fields that contain multiple values, such as tags. You'll see that by using meta data wrappers you can also access properties on referenced entities, such as the email address of the author of a node, without having to load that information independently.
Metadata wrappers also provide a consistent way to access properties common to all entities. For example, every entity in Drupal has a unique ID property or a human readable label, but these properties often have different names. User name vs. node title. Metadata wrappers allow you to access this information in a consistent way.
Additional resources
Revisions are an important concept in a content management system. Keeping track of all the edits that have been made to a particular entity over the course of its lifetime. A paper trail or sorts. This lesson takes a look at what is required in order to make our Entities support revisions.
If you've worked with Drupal's node system and enabled revisions then you've seen Drupal's basic revision handling in action. Every time you save a node, it creates a new version of that node. You can roll back to previous versions and keep track of how a piece of content has changed over time. Entity API also supports the concept of revisions and in this lesson we're going to take a look at adding revision support for our video entities.
In order to take advantage of this feature, we'll need to modify our database schema to accommodate storing multiple versions of the same entity. We'll move all fields that we want to make "revisionable" into a separate table and set up a new unique version ID field so that we can keep track of revisions.
Then we will update our hook_entity_info implementation to tell the API that we want to use the revision system and make some changes to the code in our VideoEntityController so that when an entity is updated we save a revision instead of overwriting the current data.
Finally we'll need to write a simple UI for viewing older versions of our video entity because the Entity API does not provide us with this code by default.
This chapter walks through how you can conditionally add either JavaScript or CSS to a content element as well as how to cache the content with Drupal's caching system. Additional notes: The cache will clear the first time cron.php is run AFTER whatever time you've specified as the cache expiration date in your code. Which you could easily calculate to be 30 seconds in the future and then store that timestamp in the database. However, you would also need to make sure that cron was running frequently enough to clear the cache every 30 seconds.
Additional resources
Render Arrays overview (Drupal.org)
In this video we'll look at adding yet another field handler, but in this instance we will be adding a Views field that does not directly map to an actual field in the database. Instead we will be creating our own variation on some data and adding it as a field that can be used in our views — a field that shows the percentage of page views as a black bar graph.
One of the most common things to do with Views is export a view from your site and store it in code as a default View. This is what Features module does when you create a feature with a view in it. In this lesson we'll export our sample site's view and add it to our module with hook_views_default_views().
In this video Joe will walk through writing a custom field handler for views. Demonstrating how to extend the set of handlers that come with the views module in order to provide new functionality or for dealing with new types of data. In this case we'll look at how to treat the numerical values in the databasics module as percentages in views. The method used to write a field handler in this video is similar to overriding other handlers like filters and sorts that will be discussed in coming chapters and provides some important foundations for understanding how to work with all views handlers.
Additional resources
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.