Read

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.

I have a lot of ideas about what people want (or need) to learn when it comes to Drupal. My ideas are a function of what I want to do with Drupal and this strongly influences the things that I research, learn, then teach others. My research reveals that there are a lot more things that people want to learn about Drupal. Certainly more than I can offer personally on this site. There are many good Drupal sites and blogs out there but I also know that many people who are working with Drupal and have ideas about the platform are not blogging about Drupal for a variety of reasons. It would be nice to hear from people in that situation because I think they could bring a lot of good knowledge to the table. There are also situations where people are writing about Drupal but their site might not have the reach they would like since they spend most of their time doing other things. Either way, I'd like to be able to help these folks get their knowledge to the wider community.

What I would like to do is create a platform for people who want to write about Drupal so they can reach the wider community and do so without either having to set up their own separate website or spend an inordinate amount of time promoting their own site. At the present time (according to Google Analytics) this site receives about 75,000 page views per month from 23,000 unique visitors. We also have over 900 subscribers to the main FeedBurner Feed and syndication via Drupal Planet. So what gets written here tends to get seen by a decent audience. I'd like to give you the opportunity to get your Drupal ideas, opinions, tutorials, etc. in front of that audience. If you write something good and I decide to publish it here I will pay you for it.

In my capacity running this site I get a steady stream of inquiries and requests for assistance with everything from initial installs to theme issues to the configuration of modules and more. I have to admit that while I do the best I can to offer advice on these issues many of them are outside the scope of my knowledge. In fact, sometimes when I get inquiries I'm struck by two thoughts that underscore the nature of Drupal. The first thought is that I have a lot to learn. The second thought is that Drupal is one complex system. These thoughts lead me to some blanket advice that I believe can help a lot of people who are just getting into Drupal and scratching their heads about how to tackle what may seem like a monster task.

As I said I have a lot to learn about Drupal. This is after almost four years of building sites with the platform. So the first pieces of advice that with help the hike up Mount Drupal easier are to expect to keep on hiking and focus on the ground in front of you. To put it in clearer language, Drupal requires continuous learning and it's best to focus on learning what you need to know now instead of being in awe of all that you've yet to learn. This situation is not unique to Drupal. The necessity for constant learning is required with any system that is being constantly improved. This is worth pointing out because every day more people are getting introduced to Drupal who came from a world of closed source systems or html-based, non-dynamic websites. What was once relatively static is now a moving target...forever!

A Commitment To Learning

So a commitment to open source web systems is a commitment to learning. I think that Drupal is a complex system. It's also a powerful system and because of that you can do great things with it. I think what draws people to Drupal tends to be the shortcomings of other systems (I once heard someone say that WordPress was like a gateway drug for future Drupal developers) as well as the well known possibilities of Drupal. Those possibilities come with an overhead though. That's why some other advice I would give to people who are new to Drupal is to spend three hours learning for every hour that you try to do something with Drupal. There's no science in that ratio but I've come to believe that initially that this works better than if you flip it around and spend three hours of doing for every hour of learning. 

As far as I'm concerned toying around on a development site is akin to learning. I'm surprised at how many emails I get that start out with something like, "I'm new to Drupal and working on a site for a client..." For the clients sake I say this. Build that learning time into the development estimate. Because it's better to take longer and get it right than to rush it and force inferior process or functionality on the client. Drupal is just not a start today, launch next week (or even next month) system if you're not very familiar with it. The extra time for learning is worth it. It's worth waiting a few months to launch a site that you can be confident does what you want it to do while at the same time you're confident that you can manage it. What's the down side of this approach? The only possible downside is that you spend all this time and Drupal ends up going away or falling apart somehow. That's not happening. So what you're doing is making a valuable investment in the future of how systems are developed on the web.

Focus On The Task At Hand

Then there's the second part about putting your head down and focusing on the ground in front of you. The world of Drupal code is vast. Just look at all the modules on Drupal.org. There are more every day. And older ones are being improved upon to add new functionality. What that means is that if you are new to Drupal and you are keen on packing your first site launch with every feature found in Facebook or MySpace then you're going to run into trouble. Start a list of things that you would like people to be able to accomplish on your site. Prioritize that list and then focus on the top three things. Research the possibilities for making those three things work very well. If you can't make one of those things work well then skip it and pick up number four on the list. Keep in mind that you're implementing these things in addition to getting used to the core Drupal functions like administering the site. You are much better off launching a site with three things that work rock solid than ten things that work half way. You'll be swamped. You'll feel overwhelmed. And you might blame Drupal. Blaming Drupal for being overwhelmed is like blaming a mountain for how high it is. Drupal mountain is big. Take it one step at a time and you'll enjoy the hike.

Get To Know The Admin Functions

I have some other advice to offer. When you first get started with Drupal take a stroll through the admin section. Click on every link you can find in the core admin section. Study each page so that you can see what's available. Perhaps make notes about things you don't understand about the interface or the available options. There's a lot going on in the back end. All of it is important to the site that you will create and maintain for many years perhaps. I know that there is an urge to start doing something more right away. I've been there so I can't point fingers. But when you're done doing whatever it is come back and make a point of clicking all of those links. I've gotten so many notes from people who had probably slapped their foreheads after I pointed some simple out. My responses are usually delayed so I always hope that they were able to find out via Drupal.org or some other Drupal forum. That investment of time in the admin area can hopefully prevent some undue frustration.

My hope is that the advice in this post can help to make the transition to Drupal easier for some people. There's another more universal benefit of all this effort as well. In many ways the situation with Drupal mirrors other parts of our lives. Drupal is constantly changing. So are our lives. New functionality is constantly appearing just as new opportunities and tools are popping up in our lives. Change and complexity is all around us. So learning to slow down, be patient and embrace learning, especially in the early phases of introduction, is a very good thing. The benefits of such an approach extend to other areas. At least I think so. Oh, and one more thing. Have fun with it. Drupal should be fun. If it isn't then perhaps it's time to slow down and focus on the fundamentals.

I'll conclude by letting you know that I consider myself to be about as average as any person who builds Drupal sites can be. I've done some programming in my time but never PHP. I used to work with Dreamweaver, like so many have, but even then I wasn't a web developer by trade. These are the philosophies that have helped me, as a non-developer, get to the point where I can make some things happen with the Drupal platform. There's lots of other sage advice to be had especially at in-person Drupal meetups and on Drupal.org. This is just one more drop into the sea of Drupal advice because the goal of this site is to help you learn one drop at a time.

The difference in the ouput of the two editors this particular post is subtle because I haven't added any extras (such as bold, italics, or alignment) to that first paragraph. But I think many people (especially folks new to web development) will agree that the wysiwyg editor view is more familiar and more inviting when it comes to creating content. There are certainly many more possibilities for those who don't have html skills.

Which Editor?
As of Drupal 6 there isn't a wysiwyg editor that is part of the core release. So that means if you want to have pretty post editing then you'll need to select a module of choice, install, configure and hope like heck that it works for you. But what editor to choose? Some of the more popular ones are FCKeditor (seen in the screenshot above), TinyMCE and BUEditor. Because this is open source the landscape with respect to wysiwyg changes over time. FCKeditor still works with Drupal but there's a new version called CKeditor that represents the next generation. Another interesting but less popular option is Whizzywig.

Once you've made your choice of editor then you need to get it installed and configured which is not necessarily the simplest task. In the case of FCKeditor and TinyMCE you download the actual editor separately from the module then upload the files to somewhere in the directory of the module. This is a step that often causes a bit of confusion. Thankfullly there's now a module called Wysiwyg that eases the integration process for these editors. If you use Wysiwyg then you can just upload the editor's files to the sites/all/libraries folder which you would create and then use the Wysiwyg module to configure the editor. Wysiwyg makes it simple to try out different editors and it supports the most popular editors.

Having tried installing different wysiwyg editors as both standalone modules and via the Wysiwyg module I've come to the conclusion that the Wysiwyg module is the way to go. The one issue that I have had with the Wysiwyg module is the fact that you may not have access to all of the various configuration settings that you would if you installed the standalone editor module. The upside is that you have a much simpler install and configuration process.

Let's Talk Images
The inclusion of images is a very important topic that comes up when discussing wysiwyg. Content creators want a simple way to include images in their posts. Most editors make it easy to link to an image but uploading and inserting images into posts typically causes problems. IMCE (installed on over 60,000 Drupal sites) is a very popular option that works well for me. There are some headaches that occur when using IMCE with a standalone editor module. This is where the Wysiwyg module offers additional benefits. The IMCE Wysiwyg Bridge allows you to easily use IMCE along with your editors that are enabled via the Wysiwyg module. For the moment this only applies to TinyMCE and FCKeditor but it could change in the future.

It's worth noting that I think that IMCE works best when using it for inserting images into posts and not when you're looking to create a standalone image gallery. Because while IMCE does do thumbnails it doesn't create galleries or cover more advanced actions like cropping and watermarking.

Beware Input Formats
Input formats are something that you want to consider when using wysiwyg editors. Drupal comes standard with 3 input formats, Filtered HTML, Full HTML and PHP code. For the most part if you're editing posts with a wysiwyg editor and insterting images then you want to use Full HTML. Notice that I said you want to use Full HTML. What about your users? If people are signing up to write blog posts then you probably want them to use Full HTML too. But if you allow anonymous comments you probably want to have a more restrictive format like Filtered HTML that only allows certain tags.

Input formats can be a very complex topic. Make things easier for yourself and have a look at the Better Formats module. Better formats offers you more flexibility with your input formats for content types. My favorite feature is that it allows you to specifically assign an input format per role. The simplest example of this is giving authenticated (signed in) users access to Full HTML and giving anonymous (not signed in) users access to Filtered HTML. It also gives you separate options for nodes and comments. This is very helpful and allows you to fine tune your content editing much more than allowed by the core features.

Drupal 7 And Beyond
It appears at this time that Drupal 7 does not include a wysiwyg editor by default. A recent post I saw indicates that there will be, "Improved support for integration of WYSIWYG editors." That being the case installing and configuring wysiwyg editors will continue to be an important skill for some time in the future for Drupal site developers. Whether or not that's a good thing or a bad thing will depend on who you ask. Hard core, old school developers would probably rather choose and configure the editor they like best rather than being stuck with what the Drupal community decides is the best option. People newer to Drupal development would probably prefer a default editor that also handles post images as well. I think that a good compromise would be to have a default editor that admistrators can choose to disable in favor of a different editor.

If this is a subject that you're passionate or curious about then see the Wysiwyg group over on Drupal.org. Lots of good information and discussion over there.

Additional Learning

• Install FCKeditor Using WYSIWYG API
• Getting Started With FCKeditor
• Understanding Input Formats