Breadcrumb "home" link points to example.com/node in 4.7.3

Defenitely should be investigated. I decided to revert back to an older version because of this "bug".

Is this perhaps related to: http://drupal.org/node/59222 ?

i suspect the problem is in menu.inc -> menu_get_active_breadcrumb()

in the supposedly working 4.6.9 code, the home link is set as follows:

  $links[] = l(t('Home'), '');

in the current 4.7.3 line 533 code, it is set as follows

  $links[] = l(t('Home'), variable_get('site_frontpage', 'node'));

I would imagine the fix is to change it back.

bumping priority on this as it's a very important bug to those who are concerned with losing google page rank due to having duplicate pages.

patch works great for me on a 4.7.3 site that had this problem.

Many thanks:-)

OK, bit of background info in order.

Pretty much from the beginning of recorded history

  $links[] = l(t('Home'), '');

Dec-27-2005 - Issue 36465

  $links[] = l(t('Home'), '<front>');

Aug-7-2006 - Issue 72352

  $links[] = l(t('Home'), variable_get('site_frontpage', 'node'));

Which brings us to today and this current issue. Just wanted to record the history of this line of code.

OK, from what I can tell, Issue 72352 is a 'hack' to make the i18n module work as desired. I believe the correct fix for that issue is to fix i18n (or whatever module it is that depends on including country codes in urls [ie: example.com/en/]).

I reccomend undoing the 72352 patch and adding some comments to discourage folks from messing with it.

Does this mean that if one doesn't currently use or is never going to use the i18n module, the fix in comment #3 will do? Or should the latest patch be applied irrespective of this?

the second patch contains what i believe to be the correct one.

and if you never use the i18n module, you won't run into the problems that issue 72352 'fixed'.

i'd run with the 2nd patch for now and check this thread before upgrading to the next release of drupal to verify that the /node link problem is fixed.

@Harry: Many thanks for that clarification.

Please don't link to discussions on drupal.org from the code comments. Summarize the discussion in 1 or 2 paragraphs and include that in the comments. Thanks.

summary added, links removed

<front> is meant to be for UI only since an empty string would be the way to specify the front page, but that is not visible in something like a list of paths. For code, a simple empty string is correct.

yeah, wasn't sure why link was changed from '' to '' in http://drupal.org/node/36465 . assummed it was for a reason.

We just can't change the front page URL in a minor release.

Now, a major release is a totally different issue. I removed the second, empty hunk which failed anyways and I deem this RTBC.

I removed 'Google' from the comment since that is trademarked, etc. Perhaps the documentation for this choice should be in the function documentation for url().

Committed to HEAD.

i'm no trademark lawyer, but i believe trademarks are for protecting references to other products that are NOT the trademarked item. (ie i couldn't create a search engine called Harry's Google). But I don't think it's illegal to use a trademark when referring to the object to which the trademark legally applies.

plus, i think pagerank is (TM) too.

point of the elaborate comment is that hopefully nobody will re-break this section of code to fix a bug in *another* module. people are very picky about this pagerank business.

backport for the 4-7 branch.

Then label it as 4.7.

We just can't change the front page URL in a minor release.

We just can't change the front page URL in a minor release.

I think this is short-sighted - It concerns me that very few results show-up in a search for this issue, particularly when breadcrumbs are a common feature, and this issue has never been rolled-out. I can only surmise that there are a great many sites unknowingly suffering as a result.

I have a completely different front page module at "?q=front", and it took me ages to work out why it sometimes appeared at www.example.com/ and sometimes at www.example.com/front, which I really didn't want.

As far as I can see, there is no need for /node (or /front for me) ever to appear *externally*, for the benefit of any Drupal module. Here's my reasoning:

As soon as _drupal_bootstrap() gets to DRUPAL_BOOTSTRAP_PATH phase, "prior to loading modules and invoking hook_init()", it calls drupal_init_path() (in path.inc) which, if $_GET['q'] is empty, does

  $_GET['q'] = drupal_get_normal_path(variable_get('site_frontpage', 'node'));

So before any module gets to see it, the path has already been set to ?q=node (or ?q=front in my case). Therefore no module ever sees a blank path, and there's no way that I can see that the current patch can break anything.

If this is right, www.example.com/front or /node or whatever should only ever be visible internally, never externally to refer to the home page. Of course /front or /node is still there, if you really want to link to them, and they will still behave as the front page because drupal_is_front_page() does that.

Best wishes, Mark.

Really the larger issue is here or one of the issues mentioned in THAT issue: http://drupal.org/node/65493

url() should return / when $path == frontpage

I disagree with We just can't change the front page URL in a minor release.

The frontpage/home URL is "/" in 4.7.x. If it isn't, it's a bug.

-K

applied