Node Publishing Controls
Drupal can handle some pretty advanced publishing scenarios. The core installation provides us with a handful of settings that enable us to control many aspects of how nodes are published. In this video we are going to dig deeper into node publishing and revisioning options.
Our main publishing settings are found on the node edit form. There are three sets of fields that work together to give us a considerable amount of control over the publishing process. They are:
- Revisioning information
- Authoring information
- Publishing options.
In this video we are going to review the standard way these settings are intended to be used.
However, it's important to note that Drupal is so configurable you can make these settings work different if you want to. But to get started though I recommend we start with our standard usage.
The first setting we want to look at are our publishing options. And here we see three check box options. The first one, published determines whether typical site visitors can view this content. To see how this works let's pull up another browser where we are now an anonymous user where we can see things from their point of view. We're here on the homepage and we see the node. If they click through they can see the full node view, pretty standard. Now if we uncheck this box and click save now if I run back to our anonymous user, we get an access denied they can't view that node. If we run back to the homepage again the node is gone and the node list.
The node will also disappear in things like search and other lists throughout the website. Let's go ahead and republish our node. Check publish, save, and now the node is back. Let's look at our other settings, this second check box determines whether or not the node teaser shows up on the homepage. We've already seen how this works in other videos. This last one though we haven't seen yet. This is basically should this node be at the top of any list.
So for example the list that's on the homepage. Most lists are sorted in chronological order although there are other ways of sorting, what's nice about this check box is that it assures that any particular node is always at the top of that list, I should point out here that there are many different ways for node lists to be built in Drupal. The primary way for admin's to build these lists is to use the views module. For the most part Drupal does not automatically enforce the settings in these custom built lists. It's up to the site developers to make sure that happens.
I recommend that when you build custom lists that you follow the intent of these options to keep a consistent UI. We'll cover custom built lists in later videos.
Now let's take a look at our publishing information. You'll see we have two input fields where we can specify the author of the node and the creation date of the node. By default the authors who originally created the node although this can be changed. The author input is not just for the purpose of attribution.
The node author should be viewed as the owner of the content. Node authors can be given special permissions. For example a typical way to set up a site is that copywriters can create nodes and edit their own nodes but not nodes created by other people. Therefore, being listed as the node author gives them additional permissions on these nodes. The authored on just provides a date of when this content was published. One interesting note is that if you put in a date before the current time on the server the node will be unpublished until the server hits that time. So it's a way that you can queue up nodes for future publishing.
Now let's take a look at another one of Drupal's powerful publishing controls, the revisioning system. This system allows you to keep a history of node revisions. It's great for facilitating editing where you might want to make a change to a node but get back to previous versions. This is particularly useful for quality control where you have multiple authors and editors. You can use revisions to create drafts that editors then can later review for publishing. You can even create drafts of live nodes that can be reviewed by editors while the last approved version is still live on your site. So let's take a look at how this works by making an edit.
Let's say that our legal department comes back and says we need to attribute this article back to the place it was originally published. So we just want to add a new line and now we want to scroll down and save a new revision in case we ever want to go back to the previous version. So we check this box and then we want to put in a message as to why we created this revision. We click save and now we see our new line here which is exactly what we expected but we did get something new, we now get this revisions tab. We can click on it and it will allow us to get back to our old version if we want to.
We also see this is our note as to why we created this revision. It's a nice handy way for editors to understand different back up points they want to get to. So let's go ahead and do a revert, we confirm it, close out and our line is now gone. But we still have our revisions tab. If we look at what it actually did, it cloned our original version and created a new revision of it up here. So this is a great tool we can use to keep histories so that none of our work ever gets lost.
In this tutorial we covered some of Drupal core built in publishing controls. You can combine these settings with user roles and permissions to create even more powerful publishing work flows. For example, you might want to make a calendar of user generated events. Anyone can submit an event, but they have to be approved by an editor before being published. As you might expect, there are additional modules that even further extend your ability to control publishing. We'll explore advanced content work flows in a later video after we cover user roles and permissions.