In this Lullabot Module Monday lesson, we take a look at the Style Guide module. Comparing Drupal themes is tough: the screenshots they provide are often based on heavily tweaked sites with plenty of slider blocks, tweaked media attachments, and other just-so content. Figuring out the "basics" — how a given theme styles core HTML elements and recurring Drupal interface patterns — can be tough! Fortunately, the Style Guide module can help.
Additional resources
In this Lullabot Module Monday lesson we are introduced to the Publish Button module. It's a simple problem, but a serious one. You've put your content editors in front of Drupal for the first time, and they can understand the node form without any problems. They understand taxonomy terms, grok menus and node references… but they get nervous when it's time to save their work. "Will... will this be published as soon as I click 'save?'" Normally, there's no good way to make the distinction between saving and publishing a piece of content explicit. Site builders can set a content type to be unpublished by default, then give editors the broad "administer nodes" permission, but that's clumsy solution that forces editors to dig for what should be a simple action: publishing or unpublishing a post. That's where the Publish Button module comes in.
Additional resources
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>',
);
Bundles are an implementation of an entity type to which fields can be attached. In this lesson we’ll take a look at configuring a single bundle type for our entities in order to allow us to make them fieldable by hardcoding the bundle information into hook_entity_info(). This is the most basic implementation of bundles. Then we’ll look at adding the ability to attach fields to our newly created bundle.
In this introductory series you will learn how use the Domain Access project to let you manage multiple "sites" with different domain names from just one Drupal installation. Domain Access "multisite" works differently from the core multisite feature in that you truly only have one site to manage. There is just one code base and one database. Domain Access takes advantage of Drupal's node access system to give the illusion of multiple sites. In this series we start off by getting some context through several presentations that explain what Domain Access offers, and why you might use it, how DNS and Apache web servers work, and what you need to understand about the node access system. Once we dive into the hands-on work, you will configure Apache to work with multiple domain names, and get Domain Access installed on your site. Then you will configure a very basic Domain Access site, learning how to share and restrict content, change themes, and set up permissions for fine-grained access control.
Additional resources
Domain Access project (drupal.org)
This series will implement the same example as the Multisite series did, but with Domain Access instead. You can see and compare the two methods. First, let's look at some other examples using Domain Access and see what we get when we download the package from Drupal.org. We'll also talk about the features provided, along with some things to be aware of and consider when choosing Domain Access.
Additional resources
Domain Access project (drupal.org)
Domain Access can do its magic because of the Drupal node access system. In this tutorial we'll walk through the basics of how this system works, highlighting the two main methods, and then explain why this may be important information for you. We won't be diving into the code side of things, but instead outline the basic concepts for anyone who needs to interact with this system. When using a module like Domain Access, you should be aware of the Drupal context in which you are working, even if you hopefully never have to dive into the details.
Additional resources
Controlling Access to Content Overview (drupal.org handbook)
Node access developer documentation (api.drupal.org)
In this tutorial we will get hands-on with Domain Access by getting the module installed. This is a more involved process than a regular module installation, but we just need to make sure we have a few things in place first. We're going to need to make sure we have our domains functioning correctly through Apache, and then add the Domain Access include file to our settings.php. With the configuration and module in place, we'll also verify that it is working properly and take a look at our domain list.
After watching this tutorial you will be able to properly install the Domain Access module, with its additional steps, and then verify that the installation was correct.
Additional resources
Domain Access project (drupal.org)
Domain Access Configuring settings.php (drupal.org handbook)
Installing the Domain Access module (Drush instructions) (drupal.org handbook)
With the main Domain Access site installed, we now need to get our other domain names added to the site and working. In this tutorial we'll review the settings for domains, add the Alumni and News domain names, and then test that all three domains are working properly.
Additional resources
Basic Domain Access module configuration (drupal.org handbook)
One of the biggest reasons to use Domain Access is to control the content for multiple domain names. In this tutorial we'll dive into content on our three sites. We'll start by sharing content across all the domains, and then create domain-specific content. To make managing the content across our domains easier, we'll then enable the included Domain Content module. This will provide us with some nice administrative tools to keep track of things.
In addition to different content, you may also want to differentiate your domains in how they look and change some of the basic site settings to make them appear more as separate sites. In this tutorial we'll use the Domain Config and Domain Theme modules (included in the Domain Access package) to let us do just this. We'll change our settings on one of the sites to set the homepage node to the About page we created earlier. Then we'll make the Alumni site look quite different by giving it a new theme. Through this process you will understand things you need to watch out for when configuring Domain Access sites, and how to be appropriately cautious with your settings.
To really make Domain Access work the way you need it, you need to make sure you set up your roles, users, and permissions correctly. We've been setting things up on our site as the administrator, but so far our site is not configured for other people to be involved. In this tutorial we're going to configure the permissions so that we have authenticated users who can create and edit content on particular domains. We'll also have several editors. Two of the editors can only manage content on their particular domains, while one editor will have access to all content across all three domains.
In the process of setting this up we'll review the Domain Access permissions documentation, then dive into configuring them. We will also look at how we can set a default domain for a role, even though we won't need that for this use case. To test things out, we'll create some content as different users and see how the editors can or can not interact with that content.
To get things moving in this lesson, we are starting off having already created a number of users, and adding an editor role to the site. We don't walk through this process in the lesson, so if you need a refresher for creating roles and users, you can watch Hands-On: Creating Roles and Users from the Using Drupal series.
Additional resources
Domain Access Permissions (drupal.org handbook)
With the basics of our three domains set up, you're ready to build out your sites. We've covered the main steps to get you started, but you'll find that there are a lot more options available to you as you build. Which additional modules you use will depend heavily on your particular needs. In this tutorial we'll talk about the other modules that are included in the Domain Access package, which we haven't used in this series. We'll also look at a list of other contributed modules that work with Domain Access to extend its feature set even further.
Additional resources
Domain Access modules (drupal.org handbook)
Domain Access related contributed modules (drupal.org handbook)
Before we set up a multisite we need to understand how Apache and Drupal work together to deliver the site we intend. In this lesson we'll look at the documentation for Drupal multisites, and then discuss the way you need to set up your Drupal directories. We'll also review the workflow that Apache and Drupal go through to get the correct site displaying in the browser.
Additional resources
Multi-site - Sharing the same code base (drupal.org)