Breadcrumb Issue

I was about to open an issue about this, for the 6.x-1.2 version, but since this is already here I'll just follow up on this, not sure whether this should be a support request either.

It'd make sense to hide the breadcrumbs for the pages set to be the front page with this module, since you are in the root of the site...

I also noticed that the is_front variable isn't accessible (or set to true, didn't check actually, but the fact is that i get 'layout-not-front' in my body_classes) so I could not just hack it out in my template.php file... any pointers as how to go about doing this?

hiding breadcrumbs on the front page is done in your page.tpl.php file.

Example..if you have something like this in your page.tpl.php:

<?php if ($breadcrumb) {?><?php print $breadcrumb; ?><?php } ?>

change it to this

<?php if (!$is_front && $breadcrumb) {?><?php print $breadcrumb; ?><?php } ?>

dub

If it was that I wouldn't even have posted here heheh... unfortunately, using this module, $is_front is FALSE on frontpages that are served by this module. So the solution you propose doesn't work :X

Perhaps the way to go about this would be for the module to step in and define $vars['is_front'] to be TRUE if it is redirecting?

The front_page.module doesn't set $is_front to false. I tested the snippet before I posted it and it works as expected. There maybe a problem with your theme, if $is_front isn't working.

Try pasting this into your PAGE.TPL.PHP file...somewhere prominent...so you'll notice it when you look at your front page.
if ($is_front) {print "is_front is set to TRUE";} else {print "is_front is set to FALSE";}

dub

Now that you mention it, it should work, since the front page on the site information settings is set to front_page (the same as in advanced front page settings)... very weird. However, is_front is set to false on every front page served by the module.

My theme is not touching the variable, I've double checked the template.php and there is no mention of this variable there at all. Very puzzling... as far as I know, the variable is served by drupal on its own right? So if it's front_page it should work, you mention that in your setup it works properly when the module redirects to the configured frontpage for a role?, I'm at a loss here :X

oops sorry about the assigned to change... dunno what happened there! :X

Try pasting this into your PAGE.TPL.PHP file...somewhere prominent...so you'll notice it when you look at your front page.
if ($is_front) {print "is_front is set to TRUE";} else {print "is_front is set to FALSE";}

If you see "is_front is set to TRUE" on your Front page....it means $is_front is set to TRUE on your front page.

If you see "is_front is set to FALSE" on your Front page....it means $is_front is set to FALSE on your front page and there is something wrong with your theme. Like I said earlier, the front_page.module doesn't change the $is_front variable.

Hope that is clearer and makes sense..

Dub

I already did Dub... sorry for not mentioning it before. is_front is FALSE on all the frontpages that are geting redirected from this module.

I went ahead and searched around the api to see how this variable is set:
The function that is used is drupal_is_front_page():

function drupal_is_front_page() {
  // As drupal_init_path updates $_GET['q'] with the 'site_frontpage' path,
  // we can check it against the 'site_frontpage' variable.
  return $_GET['q'] == drupal_get_normal_path(variable_get('site_frontpage', 'node'));
}

And the variable itself is set in template_preprocess(), wich assigns the return value of drupal_is_front_page() to $variables['is_front']:

// Flag front page status.
    $variables['is_front'] = drupal_is_front_page();

So, as you can see, it is expected as far as I understand that is_front is set to false, since the path is not the same as what is set in site_frontpage. This is why I think that this module should provide its own frontpage_preprocess and intercept the variable to set it accordingly, if we are using a special frontpage.

you didn't mention you were redirecting away from the front page....if you're redirecting away from the front page..$is_front will obviously be set to FALSE...

Instead of using the $is_front variable...use the arg(0) function instead. it will be something like this:

$redirected_front_page_node = "2"; // the node id you are redirecting the front page to
if (arg(0) != $redirected_front_page_node) {
  print $breadcrumb; 
  }

I am not redirecting, the module is. When you set the options for each role, the module does a drupal_goto() call to that path you specify in the options.

I would perhaps use what you suggest in the last comment to hack around it, but in our case, we have a ton of special frontpage cases, so this isn't very scalable nor easy to maintain. It duplicates the work if there's a change in the future etc.

I just think it makes sense for the module itself to intercept the variable like I described above... since the users expect it to act as the front page. That way people could just use the variable for whatever tweaking is needed, including having the frontpage body class etc etc. I don't know if you are following me...

Once you redirect away from the front_page.module the front_page module has no control over the output...that's why there are text areas provided on the settings page, so you can insert custom front pages for different role types.

As a suggestion..if you are unable to paste content into the text areas...try pasting the following into the text areas an switch the PHP input filter on.

$node = node_load('2'); // change the node ID to suit
print  node_view($node, $teaser = TRUE, $page = FALSE, $links = TRUE);

Ow I think i am finaly understanding what's going on here... so is_front works if you provide the content for the front page in each text area, but if you select in "Select type: " -> "redirect", then is_front will be FALSE, since its just another node.

Thanks for your patience on this Dublin Drupaller, I was misunderstanding the module I think. Yes I was redirecting (duh).

We'll probably go the way you suggest, loading the node itself in there. Although we'll have to get one node or another depending on the language, so in this case the following code works great:

global $language;
switch ($language->language) {
  case 'es':
    $nodeid = '14505';
    break;
  case 'ca':
    $nodeid = '14504'; 
    break;
}
if ($nodeid) {
  $node = node_load($nodeid);
  $output = node_view($node, FALSE, TRUE, FALSE);
  print $output;
}

I paste it in here for those after me that have the same needs.
This way, you are in the front page (root of the site), and all the rest follows, no breadcrumb, frontpage body class, etc. etc.

Again, my apologies for the confusion, and thanks very much for your input!

hmmmm, i am also using redirect, because of its flexibility. So I definitly need a workaround for this on several sites. This does not only affect breadcrumbs unfortunately.

So I've reviewed the module to look for an option to change is_front for pages. Allthough it's a really helpful module, the code is a bit hard to maintain or extend, it seems. Due to missing encapsulation, there is a lot redundant code and sub-parts cannot be directly accessed from outside.

Anyway, I've provided a patch against 6--1-2 below which (again, terribly) takes several parts of the front_page page callback to check if a certain path is a front_page path for the user (if redirect is chosen for the role). This one will be used in a module-own preprocess_page hook. Same could possibly be done for preprocess_node hook. This way you have a proper is_front variable in your template. (NOTE: you have to clear the cache to see the difference)

(For testing convenience, there is also an already patched version of 6-1.2)

thanks japintrat..

I'm a little confused to why you would go to all that trouble when it's easier to embed the node in the front page rather than redirect (See the snippet posted above)

Also, I had a quick look at your patch...am I correct in thinking that your patch checks every single page load to see if it's a front_page redirect?

There's an update due soon for the front_page.module. It's been a while since I looked at the code and I notice that a few patches and some code have slipped through into the module that perhaps shouldn't have.

Redirecting is probably the most commonly raised issue with the module so I'm going to replace the redirect option with an embed option instead in the next versions.

Now that we talk about improving the module, I'll drop this idea here:

Perhaps it would make sense to allow the user to choose a node directly in there, instead of pasting the code to embed the node... I think when people are redirecting, they mostly mean to use that node as the front page.

Having the posibility to use an existing node as the frontpage would very much push this module forward imho... Of course we should stil allow the user to embed php code if they want, yet most cases would be solved if the module just let you choose a node, and it would embed it itself.

Of course this raises the question of multilingual setups which we could tackle in diferent ways, choose a node per language, or have the module grab the translated node if it exists.

We could perhaps recycle or take nodereference as an example for this :) What do you think?

you have some good ideas there Manual...I've opened up a new discussion thread here: http://drupal.org/node/382370 which will be easier for others to spot and join in.

dub

Hm yes, the redirect is really quirky. You are right that it is probably better to embed nodes, though I don't like the idea of having only nodes there. Of course, you could also write different php code to embed views or that kind of stuff. Best thing to have would be something that is similar to the core frontpage handling, I mean some kind of path-embed, although i've no idea how this could be done either.

Hmm ... hell yeah the patch doesnt make things much better and its a performance loss as you nailed it. So, redirect is going to be abandoned, right? I am okay with that, so far.