You've got content, but where does it go? How do visitors find content and move around your site? Here are your guides to tagging content with keywords, creating menus and other links to content, arranging menus and blocks, and other tasks related to the "where" of your content.
Drupal offers a very flexible system for "tagging" your content – that is, attaching keywords to it for use in organization or searching. Why do that? As software developers and webmasters everywhere have discovered, tagging content makes it so much easier for software to know what content is about. With tags on content, a program can instantly pick out, for example, all news articles that are about politics, or all product catalog listings that are cooking-related and are books (i.e., not just any cooking tools or any books, but only cookbooks). The same goes for tagged content on your site.
It's a very powerful tool that makes many things possible – so powerful and flexible, in fact, that the possibilities are overwhelming at first. This page will outline basic ways you can make use of tagging to organize your site content.
First, a word about terminology. Let's revisit the discussion of "category" from Important Terminology!:
Drupal lets you assign keywords, or "Terms", to your nodes. The language it uses to discuss this, however, is frankly confusing. Here's your guide:
That passage provides more examples that clarify what we'll discuss on this page, and it sets up terminology we'll use too. A short review that puts those words into their places:
We're going to discuss taxonomy, the use of "keywords" or "tags" to classify and organize your content. Instead of those popular words, though, Drupal calls keywords or tags Terms. It calls a group of related Terms a Vocabulary. So we'll talk mostly about Terms and Vocabularies, but we'll avoid the superfluous word category, other than to note that we need to visit a form called "Categories" to manage our Terms and Vocabularies.
Got that? Good!
Let's note from the start that all your content already has a built-in tag: its node type – Page, Story, Blog entry, etc. (I'm calling this "tag", not "Term", because Drupal doesn't technically treat node type as a Term.)
So even if you stop reading here and create or use no Terms, you're already classifying content in at least one way, and can organize it based on node type. For many sites, that simple organizational ability will be enough. Just use Blog entries for, say, news; Stories for product info; Pages for company info; etc. Set a 'news' menu item to call up all Blog entries, a 'products' menu item to call up all Stories, and so on. There you go: simple organization for a simple site. See Linking to Content for more.
A site of even moderate size or complexity, though, will quickly outgrow that scheme. If you'd like to explore a deeper way to organize content, read on.
Here's where to find our form for playing with Terms:
Navigation » Administer » Content management » Categories
The list you see under this tab is a list of Vocabularies. The three columns in the list:
The name of the Vocabulary.
This isn't a "type" of Vocabulary itself. Rather, this displays the node types that can use the Vocabulary. For example, if a Vocabulary which you named 'topic' happens to list "Page, Story" under 'type', that means only Pages and Stories can be tagged with Terms from the Vocabulary named 'topic'; Blog entries can not use those Terms.
Things you can do with the listed Vocabulary. See details below.
Before you can create and use Terms, you need to create one or more Vocabularies to hold them. If that's not already done for you, read on. Here's what you see on the 'Add vocabulary' form:
The name of the Vocabulary. It will appear on the list of Vocabularies, and on the forms for creating content that uses the Vocabulary.
Optional extra information. Feel free to ignore these.
As discussed above: what node types can use this Vocabulary? Check those that apply.
For example, if you are creating a Vocabulary called 'Product Category', and know that you only want to use its Terms with Pages (the node type you plan to use for your product info listings), you should check only 'Page'.
If unsure, check everything! If you're the only one entering content, there should be no harm. But if you're allowing others to create content on your site, put a little thought into it. For example, you may be allowing others to post Blog entries on your site. Do you want to allow them to tag their entries with Terms from your 'Product Category' Vocabulary, or not? This is the time to decide.
There are a lot of choices under this heading (not all of which are really connected to hierarchy).
Disabled, Single, or Multiple: Just as menu items can have "child" sub-menus, your Terms can have "child" sub-Terms below them.
If you select 'Disabled', that won't be the case for this Vocabulary; it will have one "flat" level of Terms beneath it.
If you select 'Single', you can have child Terms, even in multiple layers. For example, your 'Product Category' Vocabulary may have the Terms 'tools' and 'machinery' – and under 'machinery', more specific child Terms like 'pump', 'generator', and 'purifier'.
More layers are possible. Your child Term 'purifier' might have 'filtration', 'reverse osmosis', and other purifer types below it, as "grandchild" Terms.
If you select 'Multiple', a child Term can appear under more than one parent Terms. For example, you could have the Term 'lathe' appear as a child under 'tools', and appear as a child under 'machinery'. Just select as many parents as you like when creating the Term (for the second and later Terms, use your computer's "mutiple select" key: Command for Macs, Ctrl for Windows machines).
With multiple parent Terms selected, the new child Term will appear separately under each parent. It's still a single "instance" of the Term, though; if you pick one of the Term's appearances for modification or deletion, you'll modify or delete all its appearances in that Vocabulary.
What's the point of these hierarchies? In addition to general orderliness in your Vocabulary, you can make use of useful techniques, such as a single link that returns all content tagged with the parent Term and its child Terms. For example, you can create a link returning content tagged with 'machinery', or any of 'pump', 'generator', and the other child Terms below it. That link will catch any nodes dealing with machinery products, even a node only has the Term 'pump' and not 'machinery'. See Creating Links.
Related items: The usefulness of this is unclear. Look forward to an explanation later.
Free tagging: An interesting option that lets you create a Term on the fly, typing it in when you create content. This may be useful when creating a list of Terms in advance would be a nuisance.
One example: You're creating a site that posts celebrity gossip. You'd like to tag each node with the discussed celebrities' names, but there are far too many to include in a list (and they keep breeding, too). On-the-fly Terms may be the perfect solution.
Multiple select: Another useful option. A node can always take a Term from each of several available Vocabularies, but checking this option allows a node to use multiple Terms from the same Vocabulary. For example, a product listing for a machine repair manual could be tagged with 'machinery' and 'books', two Terms from the same Vocabulary. The result: a page that listed products tagged with 'machinery', and a page that listed products tagged with 'books', would each display this product.
Note: When creating a node with multiple Terms from a Vocabulary, clicking the second Term will only un-click the first. You need to hold down your computer's "mutiple select" key (Command for Macs, Ctrl for Windows machines).
Required: When creating a node, you normally are free to choose no Term from a given Vocabulary. But not if this setting is checked! You won't be able to submit the node without a selected Term. This is a useful setting when you are allowing others to submit content, and want to enforce tagging.
This will determine the placement of the Vocabulary on the list of Vocabularies – an item of very little importance. Feel free to ignore it.
Fields for these may appear, but they are not important for this form. Ignore for now.
Clicking 'edit vocabulary' on the list of Vocabularies takes you to this form. It's the same as the form for adding a Vocabulary; see full procedures above.
At long last, we get to the meat of your Vocabularies. Clicking 'list terms' on the list of Vocabularies shows you two things: a list of the included Terms, and a link to add more Terms (see below).
The list of Terms has two columns: 'Names' and 'Operations'. The latter only holds a link to edit the Term. The former is more useful than it first looks: the name is also a link that calls up all content tagged with that Term. This will come in handy when making menu items and other links that call up content based on Terms. See Content Paths and URLs and Linking to Content.
The final item to cover, and an important one. This is the tool to create new Terms.
Clicking 'add terms' switches to an 'Add term' tab. Here's what it offers:
If you have a "hierarchy" of Terms (see Disabled, Single, or Multiple: above), you'll have the option to pick a "parent" Term (assuming there's already at least one Term in the Vocabulary). Pick '<root>' to place the Term at the "top level", with no parent Term. Or pick an existing Term to place your new Term under it as a child Term.
The name of the Term: 'products', 'news', 'general info', 'France', whatever you want.
Type in some info on the Term, or its intended use, if you wish. It's generally not important.
The usefulness of this field isn't yet clear. Ignore.
If it matters to you, you can use "weight" to set the Term's location inside the Vocabulary. A "light" (negative) weight will place it higher on the list; a "heavy" (positive) weight will place it lower. Many admins won't consider this important.
Fields for these may appear, but they are not important for this form. Ignore.
Now that you've got Terms, what to do with them? Simple: when you create content, you'll see Terms listed under 'Categories' on the node's edit form. From the list(s), pick whatever tags you want to attach to that node. This is briefly described under the heading Categories on Create a Page Node.
As described earlier, you can set which node types can use which Vocabularies. When creating a node, each available Vocabulary will appear as a separate list. You can choose a Term from each Vocabulary list – or even multiple Terms from any Vocabulary which has "multiple select" enabled (see above).
Once content is tagged, you'll be able to perform tricks with those Terms. See Content Paths and URLs and Linking to Content.
You can create whatever Terms you can think of a use for, grouped into whatever Vocabularies you like. There are infinite possibilities – which always makes it hard to get started.
It's difficult to immediately envision all the ways to set up your taxonomy, and all the possibilities for using it. Here's a general suggestion for starting out:
Sit down and do a little thinking about what keywords you may want to call upon in the future. You'll probably want at least two main groups of keywords (and thus, at least two Vocabularies): one that describes what a piece of content is, and one that describes what the content is about. (At least, I've always found that useful.) See examples below. You may want additional Vocabularies, depending on what your site is about.
Next, fill each Vocabulary with Terms. If your site already has some Terms set up, delete any you know you won't need, and add Terms you think you will need. If in doubt, add a Term; it's easier to add it now and ignore (or even delete) it later if it turns out unnecessary, than to add it later (and belatedly tag all the old content that you now want that Term attached to).
Finally, on the technical side: if you're not worried about other users tagging content in odd ways, go for flexibility. Allow your Vocabulary to use multiple heirarchy and multiple select. If those features turn out useful, you've got them on hand; if you end up not using them, no harm done.
In summary: You can change your taxonomy and its workings any time down the road, but if you have a lot of content already in place, you'll have a big job going back and re-tagging all those old nodes. A little strategizing up-front can save you a lot of work later.
Here's a simple set-up that works for a lot of sites:
This Vocabulary is for Terms that describe what the content is. Not node type (Page, Story, Blog Entry, etc.), but its intended purpose within your site. Fill this Vocabulary with Terms like 'news', 'general info', 'essay', 'report', 'article', and so on. Some child Terms may make sense: 'news', for example, could have child Terms 'announcement' and 'press release' under it.
This Vocabulary is for Terms that describe what the content is about. More than the above Vocabulary, appropriate Terms here will vary widely by site. Fill it with Terms that make sense for yours: 'product', 'company', 'website', 'celebrities', 'hobbies', etc.
For more detail, add child Terms. For example, the broad Term 'product' could have product categories (or specific products) under it as child Terms.
The above two Vocabularies should enable pretty powerful organization of content. Any content should fall under a combination of one Term from each vocabulary (or more than one from each).
For example, a notice about an upgrade to your company's website would use the Terms 'announcement', 'company', and 'website'. General company background? 'General info' and 'company'. A case study on a new product? 'Report' and 'product'.
As another example, a site for collecting recipes might do well with this taxonomy:
Same as above, but recipes themselves are key enough to this site to be considered a major type of content, not just a topic under 'general info' or some such. Add a new Term, 'recipe', to the Content Type Vocabulary. (You'll also want to decide on a consistent node type to use for recipes, such as Page or Story.)
Fill this with Terms like 'main dish', 'desert', 'appetizer', etc.
Fill this with Terms like 'Chinese', 'French', 'Mexican', etc.
With this set-up, it's easy to see how your site can quickly call up, say, all Chinese main dish recipes (via the Terms 'recipe' + 'main dish' + 'Chinese'), or any other combination. Bon appetit.
Setting up your Vocabularies and Terms can take a little effort, as does remembering to tag content as you create it. But as your content grows, the ability to locate and organize it via those tags will make the work well worth it.
This is important stuff. One of the keys to grasping Drupal is to understand that creating content is just a small part of the picture. Creating a node is simple enough; telling users how to get to any node, via links in menus or elsewhere, is the start of building a site.
How do people get from one page on your site to another? Links, links, links!
But what is a link? It's just an instruction for the browser to jump from the current page address, to a new page address.
You can create links to any page whose address you know. So how to you find, or create, the address for a page? If you want to know, here's your guide. (And if you already know the address for your target page, and are ready to create a link to it, jump ahead to Creating Links.)
Every node you create in Drupal automatically gets a path – an internal "address" that identifies it. Drupal automatically gives these paths names that aren't too pretty, such as taxonomy/term/7 or node/53.
A URL is the whole address, starting with your site domain, that a browser uses to reach a page. The above node with path node/53 could be reached by visitors at www.drupalace.com/node/53, for example.
The above node/53 is an ugly path that creates an ugly URL. There's nothing technically wrong with that at all, but many people like nicer-looking addresses. Fortunately, you can define a nicer, alternate path – what's called an "alias" – when creating a content item.
(A note: Drupal inconsistently uses the word "path" to sometimes mean the content's address in general, and sometimes to mean an alias. I'll use "path" to mean the internal address of a content item, and "alias" to mean an alternate path. These are pretty standard usages, so no capitalization is needed.)
An example of an alias: If your 'Corporate Vision' page has the path node/53, you can also give the page an alias such as vision. The page can then be reached at the URL <your site domain>/node/53, or the alternate URL that uses the alias, <your site domain>/vision.
As described under Create a Page, you can easily create an alias when creating or editing a node. Look for the field 'URL path setting', and type in an alias. Stick to regular letters, numbers, hyphens (-) and underscores (_) in your alias; avoid other characters, including spaces.
If you want to change a node's alias, just edit the node to do so, as above.
You can't give the node more than one alias that way, though. If you'd like to do that, and otherwise manage aliases in bulk, head here:
Navigation » Administer » Site building » URL aliases
There are two tabs:
Pretty simple: a list of aliases, followed by the "real" path that Drupal created (like node/13), followed by options for editing or deleting the alias.
Here's where you create an alias. Enter the Drupal-created path into the first field, and your desired alias in the second. Follow the rules under Setting an alias above.
How would you like your site to generate an alias for you automatically whenever you create new content? It can be a very useful thing, and is handled by a function called Pathauto.
If your site has Pathauto enabled, you'll find an administration form here:
Navigation » Administer » Site configuration » Pathauto
There are a lot of settings, and an overview will have to wait for later. For now, you should be able to work things out through the instructions on the form.
It's handy that you can set an alias for any new content you create, but how do you find the path for any existing content?
This is the most obvious method: open the page you're interested in, and check its URL in your browser's address bar. The part of the address remaining after <your domain name> is the page's path. Copy or otherwise make note of it, and you're ready to use it in links.
Your administration forms contain a number of "master lists" of content and paths. Once you're at any of the lists below, clicking on the item of interest, or just "mousing over" it and seeing the URL that appears in the browser's status bar, will let you know the item's path.
Navigation » Administer » Content management » Content
Navigation » Administer » Site building » URL aliases
Navigation » Administer » Content management » Comment
A link to a whole Term can be a very useful thing. Even better, Drupal automatically creates a path for each Term. You can't just use the Term name, like 'product', as the path; you need to use the path that Drupal gave the Term. Unfortunately, a little digging is required. Here's how to do it:
Navigation » Administer » Content management » Categories
As discussed in Terms, Vocabularies, and Categories: "Tagging" Your Content, that's the list of Vocabularies, or groups of Terms. Click 'list terms' for the Vocabulary containing the Term you want. The list of Terms will appear. Click or "mouse over" the Term you want; you'll see the the URL containing the Term's path.
Example: You want a menu item to link to the Term 'technology', listing all nodes tagged with that. Go to the Categories form, as above, to see your Vocabularies. There's one named 'Content Topic', which contains the Term you want; click 'list terms' for that.
There, on the list of Terms, is 'technology'. Click it. It should return the page we're looking for, listing all 'technology'-tagged nodes. Note its URL, which may be something like <your site domain>/taxonomy/term/12. The path taxonomy/term/12 is what you can use as your menu item's path.
Links are how visitors get from one page to another. You'll probably put a lot of links in menus – a menu being just a list of links to other content. But you may also place links directly inside content text, or inside a block's text.
You may want links that point to a specific content item on your site, or a specific page on an outside web sites. Or you may want powerful links that pick up and return a list of multiple content items from your site's database.
There's a lot you can do. Here's a basic guide to linking:
A link is a pointer to another page or node address. The first thing you need to know is the target page's address: its path (or if it's external, such as a page on another website, its URL). If you haven't done so, see Content Paths and URLs.
You're now armed with the paths you need for the links you'll create. Next:
Every menu item needs to specify a path; sending the visitor to that path is the purpose of a menu item. When creating or editing a menu item, you input the path into the 'Path' field. See Working with Menus: Administration Form.
For an internal path, you only need to input the path, not the entire URL (starting with http://<www.yourdomain.com>). For example, if the link is to a product description page with the path products/home/superbroom, then products/home/superbroom is all you need to input.
For an external URL, input the whole URL, starting with http:// .
For an email address, write mailto:, followed by the address: mailto:info@google.com , for example.
To place a link into some text, such as text that says "click here" and sends the user to some other page or site, use the 'insert/edit link' function in your text editor. See the instructions for your text editor under Using Text and Image Editors.
If you want to show an external URL itself or an email address, you likely don't need to use the 'insert/edit link' function. Type the URL or email address normally – like www.google.com or email@google.com – and the text editor should automatically convert it into a link. (This only works in fields that use a text editor like TinyMCE or FCKeditor. And if it still doesn't work, you may need to configure your Input Format – a topic for later.)
Recall that a "Term" is a "keyword" that tags your content. You can link to a Term, which will return all nodes tagged with that Term. For example, you can make a menu item named "See All Products" which links to the Term 'product', and when clicked returns all nodes tagged with the Term 'product'. An instant, simple product catalog!
A Term has a path like any other content, as described in Content Paths and URLs. Use it like any other path.
Now comes the powerful stuff: combining multiple Terms in one link. You can create a link that returns all nodes that are tagged with the Terms 'product' and 'technology', for a narrow list of only nodes that deal with both of those topics. Or you can create a link that returns all nodes that are tagged with the Terms 'product' or 'technology', for a broader list of all nodes about either of those topics.
First, note the path for each Term you'll use. For the following examples, say you'll use three Terms whose paths are taxonomy/term/1, taxonomy/term/5, and taxonomy/term/13:
AND combinations: Write the path like this:
taxonomy/term/1,5,13
to return nodes tagged with all three of the Terms.
OR combinations: Write the path like this:
taxonomy/term/1+5+13
to return nodes tagged with any one of the Terms.
Use the same format, separating numbers with commas or plusses, whether you're combining two Terms or twenty. (Naturally, you'll replace the above "1", "5", and "13" with the appropriate numbers you confirmed for your Terms.)
If you think the above sounds hard to remember, you aren't alone. It's definitely strange that OR combinations, not AND combinations, use the symbol "+" in their syntax. It sounds backward. Chalk it up to an odd quirk of Drupal, and move ahead.
Terms can be "hierarchical", with "child" Terms placed below a "parent" Term. (See Terms, Vocabularies, and Categories: "Tagging" Your Content.) One example: a Term 'machinery', with child Terms below it like 'pump', 'generator', etc.
If you'd like to create a link that picks up content tagged with the parent or any of its child – 'machinery' or 'pump' or 'generator' in the above example – there are three ways.
The first and simplest in concept: Make sure that you tag all pump-related nodes with 'pump' and 'machinery'. A link to the Term 'machinery' will pick up all pump info. But if you forget to include the tag 'machinery' on your Model 501 Grease Pump product description node, the link will miss it.
The second is as described above: link to the combined terms, like taxonomy/term/1+5+13. This link will catch the Model 501 Grease Pump node, on which you included the 'pump' tag but forgot the 'machinery' tag. That's better, but there's another problem: as you add new child Terms, you need to keep updating the link to include the new Terms (so that it ends up looking like taxonomy/term/1+5+13+24+25+31+33 and on and on.)
The third way is as follows. Link to the 'machinery' Term only, and tack on /all at the end of it. It might look like this:
taxonomy/term/1/all
That will pick up content tagged with Term 1 ('machinery' in this example), plus any child Terms below that, even any new ones you add. Handy!
Menus are the key to your site – they're the way by which visitors get at your content.
A menu is a list of links to content. Menus can appear in a horizontal line at the top of your pages, as with many web site designs. Or they can appear along the sides in blocks, another common design.
A specific link in a menu – a "menu item" – can link to a specific node. Or, calling on the full power of the database behind your site, it can pull up a list of nodes based on some criterion.
There's a big administration form for all menus on your site:
Navigation » Administer » Site building » Menus
At the top of that form, you'll see four tabs: 'List', 'Add menu', 'Add menu item', and 'Settings'. An overview of the tabs:
This form lists every menu currently created for your site. Immediately under the menu's name are one or more options:
This brings up a form that lets you change the name of the menu. That's it.
If the menu is one that you, and not the Drupal system, created, you can delete it from here.
This is an important one: it lets you add a new menu item to the menu. The link takes you to the 'Add menu item' tab; see Add menu item below.
Under the above choices is a list of the items – the links – in the menu. Its columns are:
The name of each item. Clicking on an item's name simply activates that link, the same as selecting it in an actual menu.
The 'Expanded' column refers to how sub-menus appear. A menu item can have multiple menu items beneath it as a sub-menu. See the Navigation menu for a perfect example: the item 'Administer' has a sub-menu 'Site building' below it, which in turn contains items like 'Blocks'. If a submenu is expanded, then it will appear with its contained items visible. If it is not expanded, then a viewer will have to click on the submenu to see its contained items.
The 'Operations' column has links to edit, disable, or delete a menu item.
Editing a menu item follows the same procedure as creating one. See Add menu item below.
Disabling a menu item is a useful technique. It takes the item off of the visible menu, but retains it on the administration form, where you can easily enable it again later.
Finally, deleting a menu item removes it for good.
There's not much under the Add menu tab: just a field to input the name of a new menu. This is for creating a menu as a block. The new menu will appear on the Menus administration form as only a name, with no items underneath; you'll then want to add menu items.
Once that is done, you're ready to have the menu appear on the site. Head to the Blocks administration form, find your new menu's block under the Disabled list (it'll have the name you created for your new menu), and place it on the page where you like.
See Working with Blocks and Placing Menus on Your Page.
This is where you add a menu item – a link to content, whether a node (or list of nodes) within your site, or an external URL (such as a page on another website).
Here are the fields on the form:
You'll see this option if you have multilingual capabilities installed in your site. For each of the active languages, you can insert a custom title and description (see explanations below). For example, if you have a menu item called "services", you can input "servicios" as a Spanish equivalent.
When a visitor switches languages, translated menu items will appear in the appropriate language.
This is the name of the menu item, as it appears on the site: 'home', 'products', 'contact me', or what have you.
Whatever you input here will appear as a "tip" when a visitor places the mouse pointer over the link ("hovers" over the link, as the techies term it). It's a good way to describe the link a little, without using a long title. For examples, hover your pointer over the links at the top of this page.
This is the meat of your menu item: what does it link to? You can input any external link (such as http://www.google.com) or an internal link to content within your site.
Internal links are a big, rich topic. See Linking to Content.
Menu items can be nested underneath other menu items (for example, menu items for several products, nested under an 'All Products' menu items). Normally, the nested "sub-menu" items appear only when the parent menu item is clicked. But if you check the 'Expanded' checkbox for your menu item, any sub-menu items nested under it will be visible within the menu, even without a visitor clicking.
Another important setting: what menu your menu item appears under. Click the drop-down menu. Available menus, and the menu items beneath them (indented with hyphens) appear.
Heirarchical (or "nested") menus are possible as well. "Sub-menus" – the "children" menu items of "parent" menu items – appear on the list, using deeper indentations.
Choose a menu's name to place your new menu item inside that menu. Or choose a "parent" menu item, to place your new menu item underneath it as a "child" sub-menu item.
Where in the selected menu will your new menu item appear? Set the "weight" for each item in the menu to order them: the "lightest" weight will appear first, and the "heaviest" weight will appear last.
For example, you might set the weight of a menu item 'main page' as -10, and a menu item 'contact us', as 10. The link 'main page' will appear first, and 'contact us' last. A menu item with a weight of, say, 0 will appear in between the two.
This form has a couple of settings related to site-wide handling of menus:
Here you set an important item: your primary menu. Most web sites have one "main menu": a menu with important links for visitors like 'home', 'about us', 'links', and so on. Drupal gives this menu special treatment: most graphic Themes automatically display the primary menu, usually at the top of every page.
How do you create your primary menu? Easy:
1) Create a menu for the purpose, if it doesn't exist already. The items should generally be your most important pages or "sections", starting with 'home' (or 'main page' or 'front page' or whatever you prefer to call it).
Name this menu 'primary menu', 'main menu', 'site menu' or some such.
2) Open the 'Settings' tab (the topic of discussion here). Under 'Menu containing primary links:', choose the menu you created above.
When you click 'Save configuration', you'll now have a primary menu.
What's a secondary menu? It's a special menu, like the primary one, that many Drupal graphic Themes reserve a special place for.
But many Themes don't display secondary menus, and a lot of Drupal users scratch their heads over what it's for. If you like, set a secondary menu here (as you did above for a primary menu), click 'Save configuration', and see whether anything shows up, and where.
There's an explanation on the Settings form: "If you select the same menu as primary links then secondary links will display the appropriate second level of your navigation hierarchy." In other words: If your primary menu has parent items with child items under those, then the parent items will show up in the primary menu location, and the first layer of child items will show up in the secondary menu location, when the appropriate parent item is selected.
It's easier to see than to explain. Give it a try.
This setting is probably meaningless unless you are allowing multiple users to create new content, and menu items linking to that content. See Creating Menu Items on the Fly.
The Menus administration form is one place where you can create menu items (see Working with Menus: Administration Page).
There's another way to create a menu item: when you create or edit a node, you can create a menu item for it on the fly.
For example, you create a node with company information, and want a link to that node to appear in a menu called 'site menu'. You could create the node, head to the Menus administration form, and create a new menu item within the menu called 'site menu'.
There's another way to do the same: when you create the new node, you can create a menu item right then and there. On the 'Submit Page' form (or 'Submit Story', etc.), look under 'Menu settings', and set the menu item's title, description, parent item, and weight. When choosing a parent item in the drop-down list, you are of course free to choose a menu itself, or a "parent" menu item (making the link to your new node a "child" menu item of the "parent").
There's one difference from creating the menu item using the Menus administration form. You don't set a path when creating a menu item on the fly. The link's path is automatically set to the node you just created.
See Create a Page Node and Working with Menus: Administration Page.
When making a menu on the fly, you can place it under any menu or menu item that appears in the "parent item" list (which should be all of the menus and menu items in your site).
But if you have multiple users allowed to create content, you may want to restrict their placement of on-the-fly menu items into just one menu. For example, if you allow users to submit news articles to your site, you might restrict them to creating on-the-fly menu items under a menu called 'news stories', and not under other menus on your site.
To do this:
Navigation » Administer » Site building » Menus
Click the 'Settings' tab. At the bottom of the form, under 'Content authoring form settings', you'll see 'Restrict parent items to:'. Here you can set the single menu to which on-the-fly menu items are restricted. (Keep it at 'Show all menus' for no restrictions.)
-- coming later --
First, a note:
Following common writing practice, I'm capitalizing words in the titles of EDAM pages. But I leave "pages" uncapitalized in this page's title, to avoid confusion. This page is about placing content on any web page (uncapitalized, generic meaning), and isn't specifically about the node type that Drupal calls Page (which I capitalize).
End note.
Here I'll cover how to place your nodes – your Story nodes, Page nodes, Blog Entry nodes etc. – onto a page in your site.
Hmm? Isn't it a little late in the manual to be writing about putting content on pages? And hasn't EDAM already covered the topic here and there?
Yes, there's been some discussion already, such as how to create a Story node or Page node, and how to "promote" these to the site's front page. But there's more to the story.
First, it's good to review the ways to build a page from a single node, versus building a page from a list of many nodes. There are more ways to do the latter than have been presented so far.
Second, to make things even more fun, there's the big Drupal Truth that you need to wrap your head around: despite the convenient wording used above, you don't actually "place" nodes on a page; rather, you tell Drupal to create a page that picks up and lists your target nodes (and adds other content as well).
A participant on the drupal.org forums said it better than I can:
The basic concept of a CMS (content management system) like Drupal, is that you don't create pages as a whole. You create bits of content and other elements (nodes, blocks, header, navigation...) and you configure the CMS so that it puts your page together on the spot. - marcvangend
Whether you find that a big shift in thinking or not, absorbing it is a key to making great stuff with Drupal.
With that, on we go!
There's not much to cover here. As already discussed, when you create a node, Drupal automatically gives it a path (like node/53), or you can give it a path yourself (like product_catalog).
To create a page from that node, then, you don't really need to do anything special. Just go to the node's path (presumably via a menu item you've created for the purpose), and Drupal will whip up a page centered around that node, surrounded by the blocks, graphical elements, footer, and other accountrements you've set up for the site.
That's it!
Many sites use the front page to list a number of nodes, or to list short excerpts from a number of nodes. But you can, if you like, set Drupal to build your front page around a single node, as above. See Setting the Front Page.
You'll often want to make a page not from a single node, but from a list of several nodes. I haven't yet come across a technical Drupal word for such a page, so I'll call it a 'node-list page'.
There are several ways to make a node-list page. What's important is to first understand the way you don't do this in Drupal. You don't create an empty "container" page – say, a blank page with the path product_catalog – and then say, "I want this node and this node and this node to appear on that page". That's a common misunderstanding among new Drupal admins, though it's a very understandable one: it does seem a logical way to do things, and some content management systems do have you do things just that way.
Drupal has you do something else: it has you specify the criteria for selecting multiple nodes – for example, "all nodes tagged with the Term 'product'", or "all Blog entries posted in 2007". That's all you do. Drupal then creates a list from those selected nodes.
That's at least the general rule (the front page provides a special case, discussed below). At first glance, it may seem limiting: you can't just pick this node and this node and this node and tell them to appear on a certain page; you have to give Drupal some criteria for picking those nodes, which means you have to find – or create – something in common among those nodes (like node type, Terms, posting dates, etc.).
But it's more powerful than it is limiting. When you want a catalog page to list all 100 of your products, the thing that you can do – give Drupal a single instruction to build the page product_catalog from all nodes tagged with the Term 'product' – is a lot better than the thing that you can't do – laboriously edit 100 product nodes to tell each one that you want it to appear on the product_catalog page. It's strong mojo.
This is the business of having Drupal call up all nodes tagged with a Term (like 'products'), and has already been covered in multiple steps. Here they are together:
1. Get the path(s) for the desired Term(s). See Content Paths and URLs.
2. Create the link to the Term(s). See Creating Links.
3. Place the link in a menu or wherever desired. See Working with Menus: Administration Form.
As an example, you might create a node-list page by creating a menu item that links to a path like taxonomy/term/49+58. That's a perfect example of creating a page that doesn't even exist as a 'page' in the way that other web platforms might see a page. Rather, you created a link with instructions, not a page per se.
Drupal has a built-in easy way to list all blog postings, under the assumption that this is something you're likely to want to do. As above, the path is key; place that path as a link in a menu item, and you've got an easy way to create a page which will list any and all published Blog entries.
Path for all published Blog entries:
<your site domain>/blog
Path for all published Blog entries by a specific user (for sites with multiple users):
<your site domain>/blog/<user name>
You can build a list of nodes based on node type, date, author, and countless other factors, or some complex combination of those, allowing really useful tricks. The secret weapon here is an add-on function called Views.
Building a View is a rich-enough topic that it'll get its own page here shortly.
Many sites use the front page to list a number of nodes, or short excerpts from a number of nodes. This is easy to do in Drupal, which treats the front page in a special way. You can make your front page a node-list page in one of two ways:
1. Take any path from the above – a path to a taxonomy Term, to a blog, or to a View – and set that path as the default front page.
2. Set no special path as the default front page. Rather, on the Edit form for all nodes you'd like to appear on the front page, check 'Promoted to front page' under 'Publishing options'. (This is an exception to the Drupal Way of "building" a node-list page via instructions; it's a method, like some other content management systems use, of telling specific nodes to appear on a specified page. Drupal offers this option only for the front page!)
For details on both of the above, see Setting the Front Page.
What appears on the site's front page, the first page people see when visiting <your site domain>?
Many web sites, especially blogs, list a number of postings, articles, or other nodes on the front page, usually with the most recent node at top. If the nodes have short text, the page may display the title and whole text of the nodes. If the nodes have long text, the page may display the title and a short excerpt ("teaser"); visitors can click on a title, or a "Read more" link, to display the whole node as a page.
However, you don't have to go that route. You can instead have the front page built around a single node, or even some special page like the login form. Or like many sites, you could go for a busy and annoyin– er, colorful and exciting splash page.
It's up to you. You have several choices:
Here's the setting to do this:
Navigation menu » Administer » Site configuration » Site information
At the bottom is the field 'Default front page'. Put in the path (without <your site domain>) of the node. For example, if you have a Story with the path node/43, then input node/43, and that'll become your front page. If it's a Page with the path greetings, then input greetings.
The path you enter into 'Default front page' doesn't need to be that of a single node. It could be a path for a page listing many nodes, such as a taxonomy-based list of nodes, a list of all Blog entries, or a list constructed from a View. (See Creating a Page from a List of Nodes for ideas.) Or it could be any other specific page on the site – say, the login page, if that's the first thing you want visitors to see. (See Logging In.)
It's up to you. If it has a path, you can enter it as your default front page.
As mentioned under Creating a Page from a List of Nodes, Drupal offers a special way to fill your front page with nodes, a way that isn't available to other pages. The Edit form for nodes offers a 'Promoted to front page' checkbox under 'Publishing options'; check that, and blammo, the node will appear on the front page! That makes it easy to place multiple, utterly unrelated nodes willy-nilly into a list on the front page. See Create a Page Node for more details.
(For this to work, you don't want to specify a path under the 'Default front page' setting discussed above. Leave it blank, or simply input node and nothing else.)
This method offers a second way to achieve #1 above, a front page built around a single node. Just check 'Promoted to front page' for your chosen one node only; voila, a one-node front page. (You'll probably want to give it no teaser, so the title and full text of the node will appear on your front page.)
You may have access to advanced settings at
Navigation menu » Administer » Site configuration » advanced front page settings
The settings here are complex, but basic instructions appear on the form. An overview is a topic for the future.
Blocks are the chunks of text or information that appear on the left and/or right sides of site pages. (Some site layouts can also sport blocks at the top and the bottom of pages.) Drupal provides many ready-to-use blocks with useful information, such as links to popular content; you can create your own blocks as well.
There's a handy form for working with blocks:
Navigation menu » Administer » Site building » Blocks
At the top of the Blocks form, you'll see options for 'List' and 'Add Block'. List is what lets us lay out blocks on the page; let's look at that.
Immediately below List, you'll probably see several links. These are links for various graphic Themes your site may be able to use, allowing you to set different block configurations for each Theme. There's no need to worry about it now.
Below that are some built-in, brief instructions on administering blocks.
Below that is a list of blocks available for your site (though most of them likely don't yet show up on your site). The blocks appear on the list in groups according to where on pages they're currently set to appear, or under the group 'Disabled'.
Blocks are listed with the following columns of information:
A description of the block. (Not all of the descriptions are necessarily easy to understand...)
Where on the page the block will appear. You can set a block's region freely. (If you look carefully around the Blocks form, you'll see these region names appearing where the blocks will appear. Only the block form offers this visual guide to page regions.)
If region is set to <none>, the block will not appear at all – that's how you "turn off" a block.
If region is set to "left sidebar" or "right sidebar", the block will appear along the left or right side of the page, respectively.
You may also have options for "header", "footer", and "content". These place the block toward the top of the page, bottom of the page, and within the main content of the page, respectively. Not all blocks will fit well into those regions, though; some Themes may not allow blocks there at all. Feel free to experiment, but for now let's focus on the favored regions for blocks, the left and right sidebars.
If you have multiple blocks in a given region (as you often will), weight determines the top-to-bottom order of those blocks. You can freely assign each block a weight, from -10 to 10. "Lighter" weights (lower numbers) will "rise" to the top; "heavier" weights (higher numbers) will sink to the bottom.
For example, you give the "User login" block a weight of 1, and the "Recent popular content" block a weight of -2. You set both to appear in the left sidebar. "Recent popular content" has the "lighter" number, and so will appear higher up; "User login" has the "heavier" number and so will appear underneath.
If two or more blocks appearing in the same region have equal weight, they will appear in alphabetical order of their titles.
Your block form may have a check box with this name. Checking the box will turn off the block when your site comes under a heavy load – i.e., when it's being visited by many readers. Those crowds can slow down your site, resulting in some frustrated visitors; the throttle checkbox will turn off unimportant blocks under those conditions, to help keep your site fast.
It's an interesting feature, but there's no need to worry about it until your site is in the envious position of having to engage in crowd control.
Here we have the links to configure details of specific blocks, or even delete blocks you've made yourself. (You can't delete key blocks that are provided by Drupal; you can turn them off by setting their region to <none>, which is just as good.)
Click 'Configure' in a block's Operations column to set details of how it appears or functions. The options available to you may vary by block, but here are the key options common to all blocks: the block's title, and a handful of settings that determine when the block does or doesn't appear on your site.
Set your options as below, then click 'Save block' at the bottom of the form.
This is separate from the block description. The block's description is what appears in the block form's list of blocks; the block's title is what appears to web site visitors. You can freely change the block title, or even leave it blank.
Can users decide whether or not to turn the block on and off? Typically, you won't be concerned about that; set the block to 'Users cannot control whether or not they see the block', and be done with it.
The other two options do give users the option to turn the block on or off – but it's an option only for logged-in users, not anonymous visitors.
If you leave these check boxes blank, the block will be visible to all users. Otherwise, it will only be visible to the selected roles.
User roles are a topic for later. For now, you might want to make a simple choice among these three options:
a) Leave block visible to everyone: leave all roles unchecked.
b) Leave block visible to administrators and other registered users, but not anonymous site visitors: check all roles but 'anonymous user'. (This is useful for administrative and other "private" blocks.)
c ) Leave block visible to anonymous site visitors, but not administrators and other registered users: check only 'anonymous user'. (This is useful for any information blocks that you want visitors to see, but that just get in the way for you once you're logged in. Advertisement blocks would be a good example.)
Similar to how the above settings can show the block only to specific user roles, these settings can show the block only on specific pages. Limit yourself to either of the first two options:
a) Show on every page except the listed pages. If you leave this blank, the block will appear on any page. If you input, for example, about, the block will appear on any page but the page <your site domain>/about.
b) Show only on the listed pages. If you leave this blank, the block will appear on no page, so be careful! If you input, for example, taxonomy/term/1/, the block will appear only on the page <your site domain>/taxonomy/term/1/.
Under either option, you can specify multiple pages; just hit return after each one, entering one page per line.
Users with a little computer savvy can use the * wildcard character. For example, taxonomy/* would specify any page that began with taxonomy/, whether taxonomy/term, taxonomy/term/1/, taxonomy/term/25/, etc.
At the top of the block form, next to the 'Lists' link, is a link for 'Add block'.
The resulting form is simple, with only two items to input:
Input a short descriptive name or sentence. This will identify the block on the block form's list of blocks.
This is the block content that a site visitor will see. Good ideas for content in a custom block include company contact information, a favorite quote, or a special announcement.
Input the information and click 'Save block'. Your browser will go back to the Blocks administration form, and you'll find your new block somewhere on the list under Disabled.
You can now set your new block's region and weight, as described above. You may also want to configure it, as described above. It's a little inconvenient, but Drupal doesn't let you set all of the configuration options at the same time you create the block; you have to create it as the first step, then configure it as the second step.
A final note: On the Blocks form, you'll also see the option to delete your new block, should you for some reason not be enamored with your creation.