Drupal front page class (.front)

Hello. It’s a long time since I needed to ask anything about Drupal, but I have a few issues/questions now.

In this instance, I am wondering why Drupal adds its front page class to all pages that spin off from the front page (via the pager links). Surely, the .front class should only occur on the front page?! Or at least vary the classes. This oddity (one of many) never worried me until now, at which point I am wondering how to make a change on the “real” front page without affecting the others in the hierarchy. Even a unique class for the most recent node (one target of my planned changes) would be better than nothing.

Any suggestions/insights?

Drupal is really goofy with a lot of the markup it arbitrarily adds.

If you have a page.tpl file in your template’s directory, then open it up and add the following code somewhere before where the html tag starts. Make sure it’s within php tags :


$isfront = (drupal_is_front_page()) ? " this-is-front" : "";

Then go to the leading body tag (or whatever) and add this to the body classes part:


<body class="<?php print $body_classes.$isfront; ?>">

The drupal_is_front_page() will return true if it’s the front page, which will set your $isfront class variable. If not, then your variable will be blank. You’re then tacking it on to the rest of the body classes there, and you should be good to go. If it’s the front page, then you should have a new class: “this-is-front” to work with.

Thank you for replying. That looks promising (though I haven’t tested it yet). And yes, I think that “goofy” sums it up well, although much stronger words have been hurled at it in frustration!

However, I am now thinking about more extensive changes that are beyond CSS. Would my best tactic be to set up a custom home page using Views? It would have probably the latest four/five article teasers with the most recent teaser styled differently.

Having done that, what is the best way to show the older articles? Link to Drupal’s own pager pages (since they are already there), set up another View for that, or something else?

Update: I have tested your code. It adds the extra class to all pages in the pager hierarchy rather than just the front page itself, so it doesn’t get around Drupal’s strange idea that all those other pages (/?page=2, etc.) count as the home page.

@adh32, I don’t understand what the issue is that your having… Is it that you haven’t assigned a front page in the info page and are sort of running it like a blog where all of the posts published to front are in a pager; then when you go from the first 10 to the second 10, etc… the front page has the “front” class?

Hello, Andrew. Yes, you are pretty much spot on. It’s just a blog-like magazine, with articles written by a few contributors, and its layout differs little from the standard Drupal/Wordpress way of doing things.

I set up a page–front.tpl.php file for a few small changes, but what I want now is a much more distinctive front page. One that highlights the latest content, shows the teasers for a few more articles, but does not use the same layout as the other pages in the pager system. That is the crucial part. I’m not sure yet whether it should still be part of that system, i.e. use a pager. I have a Views archive anyway.

It’s only now that I’m bothered by Drupal’s use of the front template for all pages in the pager.

Ok, yeah, that’s what I thought might be going on… I’ve only got one site where I’ve set it up that way myself so I haven’t spent a lot of time messing about with it.

Here’s what I would do and hopefully this is in Drupal 7… Get the Context module, it will allow you to add body classes based on some sort of criteria. I would create a new “context” with the Condition based on the path being something like: /page=*

The Reaction would be to Theme HTML by adding a class of: not-front

Then you can set your CSS for a declaration of body.front.not-front .some-div-that-needs-attention {}

Otherwise, yes you could use views or view blocks on archive pages to do it.

Make sense?

Yes, that makes sense. Thanks for the tip, Andrew. I think, though, that I will need to do something with Views because there is sidebar content on the older pages that I want to keep there but remove from the home page. So far, my initial experiment with Views didn’t allow any way of making that distinction. Should I create a page using a new content type, create a template for it, and add my View to it? Is that how it’s done? Very confused by the options.

How’s that sidebar controlled? Is it a block?

If it is then in the blocks config, you can make it visible or not using the same trick with the path and wildcards “*”

Otherwise if it’s a hard coded div or something, you could use CSS and the body class to makeit disappear when ou don’t want to see it.

Andrew

Yes, the content is a series of blocks, although it is in a parent DIV for layout. Could you clarify the bit about the path and wildcards? I’m sort of familiar with how the wildcard works, but I can’t see how it could be used to differentiate between the home page and the query string pages that spin off from it. I use the Global Redirect module, which sends example.com/node to example.com/, in case that makes a difference here.

Sure, I’d be glad to explain… Hold on a dew minutes and I’ll write out my approach.

Ok, this is my approach to theming which might be a bit different than the way others approach it.

CSS
When I build a theme I try to make it as simple as possible and if at all possible I like to limit my page.tpl.php files to a single multipurpose template file with multiple regions (#left, Content, #right) that I’ll collapse and make invisible (width:0; height:0; display:none; ) when not in use. So I might decide to have a thee column layout for most of the site but get rid of the left column on the homepage. In that case I’d have CSS rules like:

body.front #left {
    display: none;
    width: 0;
    height: 0;
}

body.front #content {
    /* Add more width to make up for the missing left column*/
}


BLOCKS

Blocks can be told to display for a variety of reasons. One of the easiest ways to make blocks show or not show is by the path and global redirect won’t really affect it if it’s done right. It’s probably a good idea to mention that path and pathauto come in really handy when you are showing/hiding blocks based on a path.

In the block config page, you’ll see “Show block on specific pages” with options for “all pages except”, “only the listed pages” and then PHP filtering. This is where you decide how you want a block to show up. If you want to show a block on every page except for the homepage, you can put in the <front> token. Any page that is designated as the front page will not show that page. It might take some experimenting to mess around so that the front page with the pager doesn’t show up but you might be able to do that with PHP filtering.

Let me know if any of that makes sense… I was typing it out while thinking about it so it might be a bit all over the place.

Andrew

Thanks for your help, Andrew. I can’t say that I would use a CSS solution in that way, though (some of our visitors are likely to use text browsers and other such alternative things). But your input is always appreciated.

Slightly off-topic, but why do you combine 0 dimensions with display:none? The 0 dimensions are unnecessary.

The key to the CSS approach working is to make sure that on pages that the divs are made to display:none, they don’t contain any content. It doesn’t matter if a screen reader recognizes an invisible region if there is no content in it and of course you do that by controlling the visibility in your block config screen.

It’s absolutely foolproof and if it’s a practice you adhere to on all sites, it’s easy to administer.

All screen-readers will respect display:none on its own. JAWS with IE used to need visibility:hidden as well if it happened to apply to a span inside an anchor, but that little quirk no longer applies. Ultimately, as long as the browser’s API respects what display:none is supposed to do, the screen-reader will never even see it. There is an exception for form inputs in some screen-readers and browsers, but that isn’t changed by dimensions.

That’s good to know.

How did you make out with the visibility of your blocks?

Well, I’ve given the brain a rest for this evening! I’ll do some more experimenting with Views, and maybe Panels as well, and see if I can settle on the best way for this case. I did some Googling, but didn’t come up with much: it seems that no-one else has ever asked about why all the “older article” pages get handled the same as the front page in every respect.

Sure… Let me know how you make out. Blocks is my favorite method. I typically use the show on all pages except method and on occasion have used PHP to filter out as well.

I absolutely stay away from panels as much as possible. I’ve seen some real messes made through the use of panels and I’m not a huge fan. That said, there’s a new interface initiative called SPARK that uses panels which I’m quite intrigued with so I might have to change my mind about them.

Have a good night!

Andrew

Cheers for heads up. Not used Panels before.