3 Things You Should Hide In Your Drupal Site (Many of you aren’t hiding them)!

3 Things You Should Hide In Your Drupal Site (Many of you aren’t hiding them)!

We manage a lot of Drupal sites and get to see lots of different methods and techniques developers use.

But there are often 3 common things that a lot of sites fail to address.

They can leave content exposed that wasn't intended to be seen by the public. This content is usually unstyled and indexable by Google. They may even expose sensitive information.Without further ado…

1. Hide your /node, people!

Call me a hacker, but one thing that I always look at on a known Drupal site is the /node page. Most developers don't bother the remove it or style it.

Some newer developers may not even realize it's a "page" that even exists. It often reveals content that was intended to be hidden.

Even though I shouldn't judge... I do use its view-ability as a gauge to see how good the developer was or if they take pride in their work.

What is the /node page anyway?

It's often called the River of News or RON. The /node page is like Wordpress's general blog functionality. It automatically lists the teasers of any blog posts in the site. It's usually intended for the homepage.

For Drupal, it shows content from any content types that has "Promoted to front page" checked. "Promoted to front page" is enabled default on new/default content types. Most people disregard it as unused if they aren't specifically using it.

/Node is also responsonsible for displaying the intial "Welcome to your new Drupal website!" text. In some cases, this message can remain in the site, so it's not always not just a listing of node teasers.

Why you should get rid of it.

I have rarely ever seen it used in the wild. Just like your appendix, it serves no purpose. You need to take it out.

It's bad for SEO

Not only is /node indexable by search engines, so is the content it reveals. If you have any hidden off-the-menu pages in your site, then Google will be able to find them and index them.

Also, if you goto Google and do a search for: inurl:node "Welcome to your new Drupal website!" - after about page 3 or 4 you'll start to see real full-blown sites that have their /node's "Welcome to your new Drupal website!" message indexed! There could be a negative SEO impact from rogue pages like this. It could be seen as thin or low-quality content in Google's eyes which could trigger a Panda penalty.

It's a potential Security Risk.

If you depend on security by obscurity, (which you shouldn't, but people do anyway), then guess what? Your "hidden" content could be displayed here.

It makes me laugh when I see "private" content listed on /node. One time I even saw a page called "Company Passwords! So you can see that it isn't a great idea to leave /node exposed – or store passwords in a publically accessible page.

It's Ugly

I've never seen a well styled /node page. It's usually a jumbled mess of node teasers that you didn't want shown in the first place. If you are one of the few who styles node teasers rather than using Views, then you may be safe from this point.

It has no Control

Like I said before, all you can do out of the box is change the number of nodes that display on it. If you need a list of content, then you should be using Views.

How to get rid of it?

To get rid of it in Drupal 6 and 7, I have a simple custom module you can download or merge into your own custom module. For Drupal 8, it's now a View, Yea! So you can simply turn it off.

Here is a very simple custom module for removing /node from your site forever.

Optionally there is the Node Page Disable module which does the same as my custom module. Plus, it gives you a checkbox for turning it off – as if you would want to install this module, but leave /node enabled. I don't think so.

Want to see some examples?

Just for the fun of it, I took a look at some popular Drupal sites to see what their /node pages revealed.

I hope this rant of screenshots drives home the point that you should be hiding your /node. You can see the strange information and ugly layouts that it can reveal.

2. Hide Content Type Pages not intended for Display

It's popular to build content types used only for display in Views. So you wouldn't want it to have its own display page. I see this a lot with Homepage Slideshows. Ex. There will be a content type for a Slideshow image, then it's displayed through a Views Slideshow.

Well, the problem with this is that each individual Slideshow slide gets its own content display page (node/whatever).

You should hide these!

Why you should hide these.

There are a few good reasons to hide these content type displays.

SEO

Google will index them. Sure you could add a noindex on these content types, but it's better practice to not even reveal them.

They're Ugly

The content types intended for Views and not an actual display page usually isn't styled. It can be a hodge-podge of field labels, miss-aligned text, and huge images.

It's confusing for clients/end users

When a new piece of content is added (for ANY Drupal content type), it automatically redirects you to its content display page.

Put yourself in the shoes of the end user. If you land on this ugly content display page after adding a slideshow slide, then it can be confusing and frustrating. Questions fill your mind: Why am I here? What is this nasty page? Did my slide get included in the slideshow? How do I get back? Etc.

How to Hide them?

There are a few ways to fix the problem of unwanted content type display pages.

Make them look good.

You could spend some extra time to actually make these content type displays look good.

Redirect them

I prefer redirecting them. It's easy to do with Rules or Page Manager. You can handle what happens when an anonymous user views the display. You can also handle what happens when a site manager views the same display.

With Rules

Create new rule "Redirect Slide for Admin" with "Content is viewed" event
1. Restrict by type: Slide (or whatever content type you're redirecting)
Add a conditions:
1. User has the selected role(s)
  - Data selector: site:current-user
  - ii.Roles: administrator (or whatever role you use for adding content)
2. Content is of type (or Entity is of type – both do the same)
  - Content type = Slide (or whatever content type you're redirecting)
Add an action
1. Page Redirect
2. Set the Url to Redirect to.
Save
Go back to admin/config/workflow/rules and CLONE the rule you just made and name "Redirect Slide for Anonymous"
Edit condition
1. User has the selected role(s)
  - Data selector: site:current-user
  - Roles: anonymous
Edit the Action
1. Set the Url to Redirect to (if different).
Save it. Done.

Screenshot of my "Redirect Slide for Admin":

Screenshot of my "Redirect Slide for Anonymous":

With Page Manager

Goto admin/structure/pages and enable node_view
Add a variant
I'll call my admin one, "Redirect Slide for Admin", check "Selection Rules"
Selection Rule 1: Node type = Slide (or whatever content type you're redirecting)
Selection Rule 2: User role = administrator (or whatever role you use for adding content), next.
Response Code: 301 Redirect
Enter the path to redirect to.
Create Variant
For Anonymous users, click Clone and name "Redirect Slide for Anonymous"
Enter the path to redirect to (if different).
Click Selection Rules and change User: role to anonymous user
Save it. Done.

Screenshot of my "Redirect Slide for Admin" Node Template

Screenshot of my "Screenshot of my "Redirect Slide for Admin" Selection Rules

These are my preferred methods because page manger and/or rules are usually installed on my sites. So no need to install extra modules.

Use Rabbit Hole + Node Save Redirect

The Rabbit Hole module lets you control what happens if you view a content type's display page. If you don't want them to see it, then it lets you redirect or show an error. Note you can also use the Internal Node module which has similar functionality.

Using Node Save Redirect is for site managers adding content. It addresses my point above about "It's confusing for clients/end users". Node Save Redirect allows you to set a redirect, like to the homepage slideshow or maybe to a special admin display you setup for managing the slideshow after a new slide has been added.

3. Hide Taxonomy Term Pages not intended for Display

Sometimes an undesired or unknown side effect of using Taxonomy is that each Term gets its own display page.

Why you should hide these Term Pages.

An unstyled term page will display exactly like a /node page. The difference is, it doesn't depend on the "Promoted to front page" checkbox to be checked – and there can be thousands of term pages. You should hide these pages for the same reasons as you would hide your /node page.

Google will index them so they are bad for SEO.
They are Ugly because they usually aren't styled.
They expose "hidden" content.

What can you do?

Luckily there are quite a few options for dealing with Term pages.

Don't use Taxonomy

Sure Taxonomy is cool and appears harmless because it is enabled by default. But you should consider if you really need it or not.

If you're just using Taxonomy to set a single attribute or trait for a piece of content, then maybe you shouldn't be using Taxonomy at all. Using a basic List field on your Content Type may be all you need. It would certainly make things simple and get rid of the headache.

You can style them

By default, term pages display the node teasers. So you could simply style the Node teasers to look nice.

You can override them with Views

Views comes with a disabled override for the taxonomy/term/% path. So if you enable it you will have control over the information displayed on you term pages. It just gets a little hairy when you want to do a different view per Vocabulary. In which case I would defer to using Rules or Page Manager.

You can redirect term pages.

Using the Page Manager method outlined above for redirecting content types, you can do the same for taxonomy pages. It will let you specify different redirect paths per vocabulary. You can even make special conditions for individual terms. So it is super powerful. You would just enable the term_view instead of the node_view, then set your Selection Rules for taxonomy.

Rules isn't so great for this because it doesn't come with an event for reacting on the "Taxonomy term being viewed". I did find some custom code in the issue queue you can add in to get this event, but I haven't tested it.

Again Page Manager is my goto solution for dealing with unwanted term pages. It works great.

Use Rabbit Hole

The Rabbit Hole module also works for taxonomy. It lets you control what happens if you view a term display page. If you don't want them to see it, then it lets you redirect or show an error.

Don't let your site get Node Hacked

Despite revealing "hidden" content via the /node page or term pages. A curious hacker may monotonously "Node Hack" your site to find hidden content.

What is Node Hacking? Going through a site's url structure by /node/1, /node/2, /node/3…. you get the picture.

You can also Term Hack. It's the same as Node Hacking except you use /taxonomy/term/1, /taxonomy/term/2, etc.

So follow the tips for hiding your undesired Content type displays and Term displays. Then a Node or Term hacker won't find anything that wasn't intended to be seen.

Before you launch a Drupal site, ask yourself these questions:

Did I hide the /node page?
Are there any content types not intended for display?
Are my taxonomy term pages looking good?
If someone node-hacks, or term-hacks my site, will I get fired?

Be an awesome and thoughtful developer and hide your /node. Hide anything not meant to be seen. If it is meant to be seen, make sure it looks good.

Now go check your sites…

About the Author

Bob Kruse is the founder of Drupal Aid and a Drupal fanatic since 2008. He is also the creator of Cart Craze, an ecommerce website design gallery and Sick Journal, an online tool for keeping track of your family's health, sicknesses, and medications.