The first step to defining a custom field is telling Drupal that our module provides a field. This is done by implementing hook_field_info(), hook_field_formatter_info(), and hook_field_widget_info(). The combination of which provides some basic information about our field including a label, description, default settings, and basic information about how the field will be formatted and what widgets can be used for data collection.
In this lesson we'll implement the basics for the following hooks:
Doing so will allow us to enable our module and see our new field type appear in the list of available fields to add to a content type. The field won't do much beyond that yet, but it's a good start towards telling Drupal about our custom RGB field type.
If you want to just follow along and look at the already written code you can grab a copy in the companion files section of this page and use that to follow along.
Before diving into the code it's important to understand some of the building blocks that make up the Field API. There's a lot of different terminology in the Field API and it helps to understand what each of the terms mean. As well as understanding the relationship between the Fields and Entities in Drupal 7. Knowing these things will give you a strong foundation on which to start exploring the Drupal 7 Field API.
Terms & concepts covered in this video:
- What is a field? what is an instance?
- How do fields relate to entities?
- Field types
- Field storage
- Field widgets
- Field formatters
For more information about these terms see the Drupal.org handbook page: https://drupal.org/node/443540
- Field CRUD API - creates field instances and bundles, e.g.) what you see on the manage fields page.
- Field attach API - connects entities and fields, uses info from Field Info API to retrieve defined fields and do things like display their widget on the appropriate entity form when someone tries to edit an entity.
- Field info API - retrieve information about defined fields and instances.
- Field storage API - pluggable back-end storage for fields. Defaults to SQL backend provided by core.
- Field language API - provides native multilingual support for fields.
Before we can start building our custom field we need a vanilla Drupal site to work with and a skeleton module. This lesson will ensure you've got Drupal 7 up and running and walk through creation of a basic .info file and .module file for the module we'll be building. If you're already familiar with Drupal module development this lesson can likely be skipped and you can simply download the attached starter files, add them to an existing Drupal site, and continue on with the next lesson.
Grab a fresh copy of Drupal 7, and install it. If you need a refresher on installing Drupal checkout this series.
You'll also want to download and install the devel module as we'll make use of some of the debugging functions in provides (namely dsm()) in later lessons in this series.
Alternatly, you can grab the .zip file under the companion files listed on this page which contains Drupal 7, and a database dump you can import to get started.
Fields are the building blocks of Drupal's powerful content modeling system. The field API allows for the development of custom field types to suit almost any data display and collection needs. Developers can create custom field types that can be bundled together and attached to various pieces of content. Fields allow a Drupal Site Administrator to create an information architecture that matches the needs of each individual site.
This series will provide you with all the information you need to be able to define a custom field in your own module. After completing all the lessons in this series, you should have a firm grasp of the Drupal 7 field API and the tools and knowledge you need in order to define your own custom field types.
Prerequisites
This series requires an understanding of PHP and basic Drupal 7 module development. For a refresher, or if you get stuck, check out our Drupal 7 Module Development series.
Additional resources
Drupal 7 Module Development series (Drupalize.Me).
Congratulations! The Our Media website now includes all the major features that the staff wanted. We’ve used the Workflow Access module to create a distributed system for content management, preventing collisions when editors review content they are responsible for. We’ve also provided the team with an editorial workflow, which makes it easy for them to track changes to content as it moves through the editorial process. On top of that, all of this is done in a consistent, easy-to-use interface, so editors quickly find the content they need. In this summary, we'll take a tour of the completed Our Media site, discuss our implementation points, and review the modules we used and discussed throughout the series.
Additional resources
We have half of our editorial process in place. Existing editorial groups can now edit content they are responsible for, and only that content. However, to enable editors to effectively manage the flow of articles coming in, we need something else: an editorial workflow system that allows them to easily determine when an article is ready for review, and to either send it back to the reporter when it needs more work, or to publish it on the site when it’s good to go.
Out of the box, Drupal allows a piece of content to be either published or unpublished. When the “published” checkbox is unchecked on the node editing form, only users with the “administer nodes” permission are allowed to view the content. That’s enough for some sites, but it doesn’t give our reporters and editors as much control as they need. For example, there’s no way for a reporter to mark an article as an in-progress draft and come back to it later. In addition, there’s no easy way for an editor to tell a reporter that an article needs more work—the editor must contact the author manually.
In this lesson, we'll get an overview of how the Workbench Moderation module can do this for us. We'll look at Workbench states and transitions, and how we use these to moderate our content.
Additional resources
As you’ve probably guessed by now, we’ll create an access control mechanism that grants users with the “national editor” role editorial access to content tagged with the term “national news.” Users that have the role “cultural editor” will eventually get editorial access to content that has the term “culture” attached. In this lesson we'll limit our users to the correct section by configuring Workbench Access, setting the correct permissions, and then assigning our content to sections. This will get everything in place to finish up our access control.
Additional resources
We now have our new editorial system in place and the Our Media site is ready to go. We’ve met the needs of our client, but there are some other modules that are also worth checking out:
We have more detailed instruction in another video on using the Views Bulk Operations (VBO) module.
Additional resources
The final step to complete our site for Our Media is to get the editorial workflow in place. In this lesson, we'll add moderation to the Article content type, create the correct States and Transitions we need, and then finish up by setting permissions so it all works the way we expect.
Additional resources
We have a lot of work to do to set up our editorial workflow. In this lesson, we’ll focus on getting the basics started, and continue with the more advanced work in future lessons. In this lesson we'll enable the main Workbench module, and configure the permissions. Then we'll take a quick look at the My Workbench area to make sure we have it set up correctly.
Additional resources
We need to create an editorial process for our site, which can seem complex at first. We need to provide some form of access control, so that editors who are responsible for the “culture” section on the site can only see draft articles in that particular section. On top of that, we need an editorial workflow that integrates with that access control feature so the editors can control which content is in which state at any given time. Lucky for us, Workbench provides exactly what we need. In this lesson we'll get an overview of what comes in the Workbench project and get a look at the main My Workbench page.
Additional resources
Let’s extend our Workbench implementation with one of the more advanced features our client has asked for. We’ll build upon the structure we’ve created with the Taxonomy module (the “News sections” vocabulary), and use that to grant users with specific roles access to content tagged with one of the “News sections” terms. In this lesson we’ll start with a little preparation work by creating new roles and users so we can test our access control to make sure it is working as expected.
Additional resources
The next step in our editorial workflow is to combine Workbench with our News Section vocabulary to allow content management to be delegated according to existing editorial groups. To do this we'll use the Workbench Access module, which is included in the Workbench package. In this lesson we'll review how Workbench Access integrates with various hierarchies, and understand what Sections are, and the setting we have available to us.
Additional resources
Since we haven’t been creating much content on our site, the My Workbench page is rather empty. This can make it hard to understand what’s going on and to grasp the module’s possibilities. This is a situation that you’ll encounter often when developing a site: at a certain point, you need content to test a certain feature, or to verify what a certain section on your site will look like. The Devel Generate module, which comes with the Devel module allows us to quickly generate sample content, users, taxonomy, and menu items, so testing functionality on our new site becomes a lot easier, since it will more closely resemble an actual site. In this lesson we'll enable and configure Devel Generate, and then run it to get a bunch of filler content set up on our site.
Additional resources
One of the basic tools for any news site, and most sites with a lot of content generally, is taxonomy. Taxonomy may sound like a big, fancy word, but it’s just a technical term for a way of organizing and classifying things, like content on a website. If you’ve sorted your family photo album, filed your email in folders, or argued with a friend about whether a band is punk or ska, you’ve already worked with taxonomies! If a site has a lot of content, editors need a way to group it into categories. By doing so, they make it possible for users to easily navigate the website and find the content they’re looking for. Additionally, assigning content to categories, whether by using a predefined set of sections or a free-for-all tagging system, opens up all sorts of interesting possibilities. For instance, site builders can expose content with similar tags on article pages. Or they can turn the category pages into rich landing pages, pulling in all kinds of different content that has the same categories assigned to it. In this lesson we will cover the basic things you need to understand about Drupal taxonomies: vocabularies, terms, and how to use them with content types.
Additional resources
In the Drupal Jumpstart series, you learned about Drupal paths and how to use clean URLs. One reason to use clean URLs is so that they don’t look so ugly. That helps, but still leaves the URLs lacking a bit. Having a URL with node/123 in it doesn’t really tell either humans or search engines much about the page itself. Isn’t it much better to have a URL with something like "article/new-moon-discovered" in it? That will be much more memorable, and the addition of pertinent keywords in the URL makes for better search engine optimization. In this lesson we'll look at a module that helps us automate this process, Pathauto. We'll get an overview of core path aliases, and how pathauto patterns and replacement tokens work.
Additional resources
To get those handy human-readable URLs on our site, we are going to use the Pathauto module. As we discussed earlier, this relies on the Token module as well as the core Path module. The Pathauto settings are divided over two pages: one page to set up the actual replacement patterns, and another one to configure Pathauto’s general settings. These configuration pages can seem a bit intimidating at first. Luckily, most of the defaults are what most sites will want to use anyway, so that makes our job with configuration a lot simpler than it may first appear. In this lesson we'll configure some path patterns using tokens, and then get all of our existing content using the new patterns by using the bulk update feature of Pathauto.
Additional resources
The Taxonomy module is included in core and is enabled by default when you install Drupal, along with a Tags vocabulary, which you can use to allow users to freely tag their content. In this lesson, we'll create a new vocabulary, populate it with the terms we need, and then add the vocabulary to our article content type.
Additional resources
