administration

Recently I had to plan the unenviable task of adding terms from a new taxonomy category to dozens of nodes that had previously been created on a site. As I pondered my options (including a temporary Caribbean vacation) I remembered module I had seen pop up on Drupal.org called Views Bulk Operations or VBO for short. 

What VBO allows you to do create a view that will apply an action to many nodes at one time. So you must have the Views module installed and it helps to know your way around views a little bit because after installing and enabling VBO you'll need to create a Node view that will allow you to create a list of the nodes that you want to apply actions to.

The view that I created to make the taxonomy updates to the nodes in question had a pair of fields that allowed me to identify the nodes to update. Those fields for Title and Type, as in node type. This was just enough info to know for sure whether or not I wanted to make a change to the node. I added to the view a couple of exposed filters that would allow me to narrow down the list of the nodes by selecting the node type and a string of text from the title. The image below shows you what the finished product looks like.

So with this layout using exposed filters I can then make a couple of choices to filter the list down to the nodes I want to change. Then in the actions to take section I can indicate what I want to do by selecting the appropriate radio button. Then I can select one or more of the vocabularies in order to make that change. In my case I had added a whole new vocabulary with new terms so I chose Add the selected terms and then selected the vocabulary term that I wanted to apply (in this case from the Node Type vocabulary) before selecting the nodes (either one by one or by clicking the box next to Title to select all) then clicking the button (not shown in the image) at the bottom of the page to apply the update. At the end of the process you should see a confirmation that the nodes were updated. At that point you should double check a few of the nodes to make sure the updates were applied as you intended them.

Here's a little more about how I got to the end described above. The image below shows where you would select the style of Bulk Operations which is required for your view to offer you the correct options. Take note that the type of display you're looking for is one of Page. One more important thing to notice is the Access setting. Since this is the kind of function you would only want available to special users make sure you have Access set in a way that limits the ability to get to the page. In my case the user must have the permission to administer content types.

The image below shows the many options for the Bulk Operations style choice. Notice that I chose Modify node taxonomy terms as the only option. I don't know enough about the module yet to choose multiple options at once so I just stuck with the one.

The image below is what the preview looked like before I saved and attempted to use the view for the first time. Take note once again of the three elements. 

1. Exposed filters which allowed me to narrow down the list of nodes
2. The actions to take which should be consistent with my Bulk Operations settings choices
3. The fields, Title and Type, which allow me to identify whether or not these are the correct nodes to take action on

Okay, so now you're ready to do some damage (in a good way of course) and make big changes to your nodes in a very short period of time. A final word of caution though. I did all of this on a pre-production site so if I did make a mistake it wouldn't affect site users. If you are trying VBO out for the first time I recommend doing so on a test site so that you can get the hang of what you need to do without having to back out major changes. Of course, if you make the wrong changes using VBO you can always back those changes out....using VBO.

 I recently received an email asking me how to bring a Drupal site back online after taking it offline for site maintenance. For those of you who haven't done this yet you can take your site offline (and put it back online) by going to /admin/settings/site-maintenance. If you take your site offline for maintenance, then log out of the site you will get the "Site off-line message" indicated in your settings. To get back into your site all you need to do is go to /user/login. There you will be presented with the login form that you can complete in order to gain entry to your site.

It's important to understand that unless you specifically set the permission for "administer site configuration" under the system module then only user #1 can manage the maintenance status of the site. If you do want to grant this access to another user then you will also probably want to grant access to "access administration pages" as well. A screenshot of the appropriate section of the user permissions page (/admin/user/permissions) is included below.

I received another question recently that relates to roles and permissions as well. A reader asked how they could eliminate all of the extra fields below the node body when editing a node. An example of these "extra fields" is shown below.

This is what the node submission form looks like with the vertical tabs module installed. Vertical tabs is highly recommended for Drupal 6 sites. In Drupal 7 this is a core module so you'll have it out of the box. What about the fields though? Users should not see those "extra fields" as long as they don't have the "administer nodes" permission.

If you're concerned about what your users who can contribute content to your site are seeing I recommend that you do two things. First, check your permissions in the Node Module section of the User Permissions page to see what the appropriate role can and cannot do. Second, create a user for yourself with a role equal to that of your contributors. This way you can login with the contributor role and see what they see. The Masquerade module looks like something that would assist with switching on the fly so you don't have to log out and log back in. You can also use separate browsers or use something featured in the Google Chrome web browser called an incognito window.

At this point I think it's worth noting just how important roles are on your Drupal site. They are definitely worth thinking about. Out of the box there are two user roles which are anonymous and authenticated. Those roles are in addition to the everything (or "god") role that is granted to user #1 on the site. If you're going to have a site where people cannot sign up for accounts (configure that at /admin/user/settings) then you won't have to spend too much time on it. Your user setting options are pictured below.

If you are going to allow people to sign up for accounts then think hard about the access they will have. If you're in a situation where there will be other administrators or site editors then it is likely that you will want to set up additional roles (do this at /admin/user/roles) to give those users special permissions. For example, if you have people who are editing content or perhaps moderating comments then you would create a separate role, assign the appropriate permissions to the role then assign the role to that user. Roles can be assigned manually in the account page of a user as shown in the picture below.

If you want roles to be assigned automatically I suggest that you investigate the Auto Assign Role module. I haven't used it yet but I have it on my list of modules to try for another site that I am working on.

If you have any ideas, tips or tricks related to user roles I'd love to hear about them in the comments.

Lesson Nine of my special Getting Started With Drupal series of videos.

This lesson provides instruction on how to move a localhost Drupal site to a web server. Steps shown in the video include creating a domain, creating a web database, exporting the local drupal database and importing the exported database to the web database.

The premium version is a full resolution (1024x768) version that contains additional content as indicated below.

I've had good reason to think about security on my Drupal sites lately. This site and a few others were hacked recently. The result of the hacking was a script injected into both the generated pages and the RSS feeds of the site. I picked up on the hack pretty fast because the RSS feeds on the site were not behaving correctly and that broke something else that relies on the feeds to work. I also checked the site in Internet Explorer and things weren't displaying properly.

I spent about an hour investigating the issues before I realized that the site had been hacked for sure. One of the first things I did once I realized that the site had been hacked was that I took it offline. Whatever the script that had been injected into the site was doing it couldn't have been good. Then I took steps to correct the situation.

Since multiple sites were affected I assumed that somehow an FTP user password (which I thought was obscure enough) had been compromised. So I changed every password I could think of. Then I uploaded the latest version of Drupal to all of my sites. Next I checked the directories to see if there were any suspicious files remaining. Finally I checked the site RSS feeds and pages for signs of the script that I had found when I discovered the problems. It was only after taking those steps that I brought the sites back online.

The process was time consuming and painful enough for me to cause me to remember how important security is for any type of site you put up on the web. I should've known better since I've been caught by spammers before, but it's been a long time so I got a bit complacent.

I'd like to pass on some tips (and links to related modules) that can give you an idea of some of the security features to take advantage of when you're using Drupal.

From time to time people will ask me questions about problems they are having with content not displaying properly in nodes. Site developers may have problems displaying images, javascript, flash and php code. The problem is usually related to the input format chosen when publishing the node. The following video provides a very detailed look at how input formats work within Drupal.

Quicktime Video

Input Format Basics

There are three "out of the box" input formats for Drupal. These formats can be found on your site at admin/settings/filters.

1. Filtered HTML - This format allows very basic text input and some HTML. This is a good format for comments and user generated content since it limits the ability of the user to add malicious code to the node.
2. Full HTML - This format allows the full range of HTML tags including <embed> codes that are typically used for inserting widgets or embedded videos. This is my preferred format as a site administrator for creating all nodes and blocks on my sites. You can open this up to site users but it's recommended only for logged in users that have accounts at your site.
3. PHP Code -  This format allows the posting of PHP code. This is used to customize the nodes on your site. There is a gallery of PHP snippets on Drupal.org where you can find examples thay may help extend the features of your site. This is a format that should only be available to admin users of the site. Opening up the PHP format to users jeopardizes the security of the site. So take great care when using this format.

The input formats in Drupal are highly customizable so you're not stuck with the exact formats that come standard with Drupal. Since these input formats greatly effect how and what content is posted to your site it is definitely a worthwhile investment of time to get to know them better.