Menu item which links to front page

I was pretty stoked when I figured out that I could create a home link using './' ... This seems like a better way to do it.

So what exactly does this do? And why? Why can't I leave the link empty?

> So what exactly does this do? And why? Why can't I leave the link empty?

Basically, this is to create a "Home" link as a navigation item. There's no way to do that currently. You can't leave it blank, because "Path" is required, and you can't enter something like / (even drewish's suggestion of ./ didn't work for me either) because it will give you a page not found error (with clean URLs disabled, anyway).

Maybe the path shouldn't be required then? Did we try that approach?

Right throughout menu.inc are assumptions that items do not have empty paths. Items with a blank path are filtered out of the visible tree and I think introducing this as a feature would generally create havoc.

I'm not very fond of this patch though...
- introducing a special token smells like a hack
- the token contains a word yet cannot be translated.

Maybe if the token was '/' ?

And maybe the performance tweaks and the call to menu_rebuild should be in a separate patch?

The reason I didn't commit this yet, is exactly that. It has this hackish smell. Like it is 'patch on' rather than 'build in by design'.

For what it's worth, the token for the front page is also used when specifying on what pages to show a block. (Individual block configuration)

sorry, i meant the <front> token is used in block settings.

If I have a site at: http://www.example.com/mysite/ how can I make a home link which points to that URL? (I mean, so the user sees that URL in the status bar when they hover.)

With this patch installed the home link points to http://www.example.com/mysite/?q=node

he's right the frontpage is everytime the same as http://www.example.com/mysite/
and for seo it would be good if this would stay so.
so you dont need to to variable_get('site_frontpage', 'node') it is enough if it would be ''

Here's a new version of this patch. It applies cleanly against HEAD.

It now checks for <front> in common.inc instead of menu.inc. This results in the menu item pointing to (for example) http://www.example.com/mysite/ if the path is <front>.

I have also snuck in a fix for http://drupal.org/node/32001 by making the Home breadcrumb link to <front>.

I'm still not convinced about that tag, but at least it behaves as I would expect now.

Boy, patches go stale quickly!

This version also refactors common.inc to remove a couple of duplicate chunks of code, so now the <front> tag only appears once in that file.

url() is an important function with regard to performance; url is often called 100+ times / page request. If time permits, I'd be interested in some quick benchmark results.

I set up a test harness omitting the call to drupal_get_path_alias.

The && $path != '<front>' adds 1% to the execution time.
The refactoring saves 1%.
So the patch is neutral.

Caching the clean_url variable in a static var yields a further 2% gain. So the attached patch implements this new feature with a modest performance improvement.

There also appears to be a lot of room for optimisation hiding behind the call to drupal_get_path_alias. But I'm not going there :)

Sorry for nitpicking but:

1. Why intval? We never use that.
2. Caching the result of variable_get() is quite uncommon. I suggest adding a code comment. It might also be worth documention <front>?

Thanks!

I used intval for performance. String comparisons and runtime type conversions are slow. By converting the variable once to a datatype on which it is faster to perform boolean operations we gain every time url is called.

In this version I have replaced the intval call with a more Drupal-like structure. And added some comments.

I am still not a fan of the <front> tag. But I have looked at allowing empty paths and it is not trivial to do so. The empty path is used as a termination condition on various loops that parse path segments. I'm sure menu could be converted to behave as expected with empty paths but I question the value of these changes.

Besides... is an empty path any more intuitive than <front>?

rerolled

Well, may not be immediately intuitive, but that's what the description text is for. The same flag is also used by the blocks module and the contrib sections.module, so it's at least consistent system-wide, which is perhaps more important than the tag itself being perfectly selected.

+1 on this.

I committed this patch because it fixes an annoying problem. Thanks!

I still think we should try to use the empty path instead. As such, I'm making this an 'active task' with normal priority.

In my installation I simply create a "home" menu item that links to index.php. But I'm assuming index.php is not everyone's home page?

Cheers,
Alex

I forgot to mention that I set "index.php" as my "default fron page" under admin -> settings -> default front page.

Cheers,
Alex

I see a whole lot of code being written, but I found a (non intuitive!) solution using Drupal 4.6.6.

1) Create a page (in my case this is node/1)
2) Create a menu item (mine is called "Home Page" and links to node/1)
3) Create a URL Alias from "node/1" to "/" (or wherever your home page is)

With this, it seems Drupal converts the link it would have had to node/1 with "/", which is what we were originally after. The browser then requests that, and Drupal returns whatever the home page contains (not necessarily the contents of node/1).

This isn't exactly 'nebie friendly' and requires nice URLs to be switched on, but it works. It might save someone an hour or two tinkering time!