Cannot add frontpage as shortcut

The way to handle this would be to make Shortcut module recognize <front> like Block, Menu and other modules do. Erroring out on an empty path is actually fine and expected.

Issue is here:

shortcut.module line 624

return !url_is_external($path) && menu_get_item($path);

It calls menu_get_item to obtain information on the link. Problem is that there is no menu item so it returns a false.

If you comment out && menu_get_item($path) it accepts , but not suggested as I'm sure it will break things

Per my understanding this is problem in menu_get_item function. That function check table "menu_router" field "path" and return FALSE because there is no path for ''. But we can fix this in shortcut_valid_link() function.
shortcut.module line 622 should be:

return !url_is_external($path) && (menu_get_item($path) || $path == '<front>');

And we should use <front> instead of empty string for Path field.

First patch - needs tests still, but let's see what the bot says.

I don't think allowing <front> really solves this bug. Given the user interface here, it is nonintuitive to type <front>, because the form element will then wind up reading as http://localhost/d7/<front> which is nonsensical. So, people will still leave this blank expecting it to point to the home page, as per the original bug report.

Why not make an empty path correspond to the home page, as was requested? It really seems to me like the menu API itself should be changed to support that, but in case that gets complicated (especially for D7 backport), it would be pretty easy to have the shortcut module save <front> behind the scenes but display an empty string in the form instead.

I'm with david on this one. http://localhost/d7/ doesn't make sense. Ans I like his proposal

Isn't there a problem when you change your frontpage, with say views?

@bojhan, not really, behind the scenes will be used as the menu path and that will trigger the right frontpage on the front regardless to what that is set.
@David I'll come up with a new patch somewhere this week. We'll probably need an extra validation on the shortcut set to make sure there is only one link to the frontpage in that set.

Oke :) Seems like a quick fix

Patch which allows you to add a link to the frontpage with an empty path.

As Bojhan pointed out on IRC, <front> should be possible as well.

Needs work though - something is going wrong with adding the empty path - it doesn't show up yet.

Ok, this one should be better - add and edit shortcut links have 2 different submit handlers, didn't realize that first.

Tested both usecases, and it worked. Marked RTBC.

There are no tests yet.

Reroll for new core structure. Added '' as a path in testShortcutLinkAdd + extra update test for it.

#16: 934714-16.patch queued for re-testing.

I rewrote swentel's tests and updated it to reflect new file structure - I believe files have been added and removed since the patch was submitted. All credit for the fix itself goes to swentel.

Code style is good. Logic changes seem sane. I say RTBC

This too

Ok, looks like this approach has buy-in from folks, and it comes with tests, too!

Committed and pushed to 8.x. Moving to 7.x for backport.

Congrats on your first core patch caiovlp!

Backported #19 to 7.x.

Patch worked for 7.x-dev as well:

1. Tried to add new shortcut with <front> path
2. Got an error
3. Applied the patch
4. Tried to add new shortcut with <front> path
5. Shortcut was added
6. Shortcut points to the right page (home page)

Well, it's interesting that <front> works directly also, since the goal of the patch was primarily to make an empty string work here :)

But I checked that that works too (and the tests prove it as well), plus this patch looks good to me for Drupal 7, so... I went ahead and committed it to 7.x. Thanks! http://drupalcode.org/project/drupal.git/commit/160e454