In this presentation Karen walks us through the basic concepts of the Organic Groups 7.2 module, also known as OG. She looks at what OG can do for us, explains how it works in Drupal 7 with entities, and does a brief comparison of OG with a multi-site installation.
Additional resources
In this chapter we go one step further with multiple-value date fields, and use the Date Repeat API and Field to create automatically repeating dates. We cover all of the different ways you can configure a repeating date and explain what is going on behind the scenes.
In this tutorial we'll walk through downloading and installing the Search API module, the Search API Solr module, and their dependencies. Then we'll look at using the Search API Solr configuration files with our Solr server. These configuration files are specially crafted to help with indexing data contained in a Drupal site and allow Solr to have a better understanding of Drupal's entities, fields, and the data that they contain. For example, mapping a Drupal Field API body field on a page node type to the appropriate field type in Solr.
The gist of this tutorial is, locating the Solr configuration files in the search_api_solr/solr-conf/ directory, talking a little bit about what each one does, and then demonstrating how to copy those files into the configuration for your Solr server so that Solr will start using them.
After looking at the various configuration files, and then placing them into our Solr instance, we'll connect Drupal to our Solr server by creating a new Search API server configuration within Drupal's UI. This will allow us to confirm that our Apache Solr server, and Drupal, will be able to talk to one another.
By the end of this tutorial you should be able to configure Solr to work with Drupal, connect the two, and verify that the connection is working.
Additional resources
In this video we'll take a tour of the Views user interface, starting with looking at existing views, editing one of them, seeing what we have to work with, and then making som edits. The Views interface has a lot of configuration options so it's good to have a sense of what is available and where things are located. We'll use many of the pieces throughout the series, but this video gets you started by making a few simple edits and then reviewing our changes.
This video series will continue the Job Board example from the Fields for Site Builders series where we will discover ways to display all of the job postings, allow people to find the one they are looking for and easily apply for it.
There just a couple of components that make up the token system in Drupal 7, which is nice because it means fewer new things we have to learn. But, it's important to understand what those components are and some of the fundamentals of how tokens work in order to make the most of Drupal's Token API. In this lesson we'll take a look the use case for tokens, talk about token types, and the concept of global tokens vs. those that require some additional context in order to have their dynamic values calculated.
What are tokens?
Tokens are specially formatted chunks of text that serve as placeholders for a dynamically generated value. Here's a really simple example: You want to display a welcome message to user's of your site, and you want it to be personalized so how about you add their name and instead of just saying "Welcome", you can say "Welcome, Joe". In order to avoid having to hard-code a welcome string for every single user of the site it would be nice to dynamically generate the string. So you use a one like the following, "Welcome, [current-user:name]".
The [current-user:name] here is what Drupal refers to as a token. A string of static text that will be located and replaced with a dynamic value. This token is made up of a few parts, inside of the mandatory square brackets that signify that this is a token. The first part current-user: in this case is the token type.
Token types are used to group like things together into a namespace. User's for example have name, mail, and last-login properties. Nodes have title, nid, and author properties. Token type also plays an important role in determining what tokens are available in what context. User tokens for example might be available when sending an email to a specific user but node type tokens might be irrelevant in this use case. We need to be able to tell end user's what types of tokens can be used in what context so that they don't use a node token (which has no value) in a user context.
The second part, after the colon (:) is the token itself. This signifies what value will be substituted into the string containing the token. :name in this case indicates we want the current user's username. This also brings up another important point. Global vs. contextual tokens. Some tokens like this one [system:date] can be calculated without any additional information. Simply call the PHP date function and you've got a value. This token [current-user:name], on the other hand, requires knowledge about the currently logged-in user in order to be able to determine that user's name. This token requires additional context in order to be useful.
Additional resources
This lesson covers what an API is and why you might want to build one. Joe also explains the basic concepts behind any API and provides real world examples of existing APIs that you're probably familiar with as well as use cases for when and why you might want to build your own.
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
Typically our application is going to require testing of functionality that is restricted to only users with a certain set of permissions. Like creating a new node for example. In order for the DrupalWebTestCase browser to test these pages we need to first log in to our site. In order to log in we need to have a username and password that we can use to login. In this lesson we'll look at using DrupalWebTestCase::drupalCreateUser() and DrupalWebTestCase::drupalLogin() in order to gain authenticated access to our application and then access and submit a restricted form.
Here's an example of creating a user with the 'administer site configuration` permissions:
$new_user = $this->drupalCreateUser(array('administer site configuration'));
And then logging in as that user:
$new_user = $this->drupalLogin($new_user);
After that the SimpleTest browser will be logged in as that user and all requests that it makes will be authenticated. If you want to return to an anonymous user session you can use the DrupalWebTestCase::drupalLogout() method.
For more information about these helper methods check out the API Functions documentation in the Drupal.org handbook.
Additional resources
SimpleTest helper method documentation
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
Deployment Workflows
TopicTools and workflows for deploying code and configuration changes from one environment to another with Drupal-specific considerations.
The Migrate module itself contains some excellent examples of data migrations implementing the various APIs provided by the module and serves as the canonical documentation for how to write a migration. In this lesson we'll take a look at the beer and wine import examples provided with the migrate module as a way to familiarize ourselves with the concepts discussed earlier and to be able to see the code that makes up a basic migration before attempting to write our own. In practice these examples serve as a great starting point and can often times be copy/pasted and adjusted for your own needs.
Additional resources
In this lesson we'll continue to add field mappings to the basic migration class created in the previous lesson. We'll see how to add more information about the available source fields. We'll map more of the player source data fields to their equivalent destination fields and learn about some of the many ways that fields can be mapped. Finally we'll also cover mapping sub-fields which allows us to import data for things like the text format of a node's body field or the alt column in an image field. Information that's contained within a meta field.
Additional resources
In this lesson we cover downloading and installing the WYSIWYG module. We show the relationship between the WYSIWYG editor and Drupal Text Formats. We go over the basic settings of the WYSIWYG module, how to download and install an editor, and configurations necessary in Text Formats to make things work properly.
Use this handbook page on Drupal.org to determine which version of TinyMCE is supported with CKEditor: Editors.
Additional resources
See how the new JavaScript APIs and ajax framework in Drupal 7 allows you to implement dynamic behaviors without having to register a menu callback in the menu system or to write any jQuery code.
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.
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'),
Goes through the default content types of the Article and Page that are provided in Drupal 7, and shows the similarities and differences between the two. Also goes through some of the configuration options, which define the default settings whenever a new node is created.
This chapter goes through the process of passing a wildcard variable to a function via an argument from the URL. It creates a MENU_LOCAL_TASK tab on the node which inverts the text to display upside down. It uses a page callback function that is included within a separate file in order to save on how much memory is used.
Provides a overview presentation for how Drupal's menu system takes care of incoming requests via the index.php. Then it walks through the process of implementing a simple module that hooks into Drupal's menu system at the path of /magic. It then executes a page callback function of menu_magic_basic(), which outputs some simple markup text.
Additional resources
The Views module provides listings of data on your site: users, comments, nodes, and more. Any listing of data provided by the Views module is called a view, and most Drupal websites today use Views in many different ways. In this lesson we'll get an overview of the Views module, including some specific concepts and terminology like Data Types and Displays, along with a tour of the major view settings and what they do.