custom_url_rewrite cannot rewrite front page

I fear this is not a bug. Where to you want the front page to link to?

In my case Drupal is serving both as a regular website and as a Facebook Application. I need to detect when a request is made that it is intended for my facebook app. But I want drupal to handle it as if it were a regular request. I'm not sure I should go into all the complexities in this issue, but here's my attempt to briefly describe it...

I instruct facebook to call my drupal instance at a URL like:
http://www.drupalforfacebook.org/fb_cb/1/node/1234
In this example, drupal is installed on drupalforfacebook.org, /fb_cb/1 tells me that application #1 is who this request is intended for. And node/1234 is the regular path. Note this is an internal URL used by facebook, a user's browser would show apps.facebook.com/drupalforfacebook/node/1234.

So, my settings.php parses the /fb_cb/1 part and learns what it needs to know. It uses custom_url_rewrite so that drupal treats the request as /node/1234. And my custom_url_rewrite works the other way too. So if drupal produces the url for node/456, I change it to /fb_cb/1/node/456.

What I need is for drupal to produce the url for / or <front>, then I get to change it to /fb_cb/1. Currently this is impossible. I can map /fb_cb/1 to the front page, but not the other way around. I want this for two reasons. First, if drupal produces a page with a link to the front page, I want the link to be to /fb_cb/1. Second, if drupal does a drupal_goto to the front page, it goes to /fb_cb/1. (The links on pages I can hack my way around, the drupal_goto I cannot).

I suppose you could argue this issue is a feature request rather than a bug, although I would disagree. To argue this is not a bug is essentially to say "custom_url_rewrite should be able to alter any path used by drupal; except the front page because while there are good reasons to modify other paths, there will never be any reason to modify the path of the front page." But whether this issue is a request, a bug, or a will not fix, users of Drupal for Facebook will need to apply this patch.

I'm no expert in the i18n module, but I learned about custom_url_rewrite from it's example. It has a complicated hook_init which changes $_GET['q'], I think specifically to handle the front page. With this patch I suspect that code could become much simpler.

Hey sorry about the previous essay. A shorter answer would be:

I want the front page source path to map to the front page alias path, and vice-versa.

Thanks for the clarification.

I'm not sure this could go in that way. The handling of the frontpage is specific in order to guarantee that all outgoing links pointing to <front> or its alias(es) will be rewritten as /. This way, there is no duplication of content and everyone (especially the search engines) is happy.

Your patch changes that, and links to <front> will point to the alias, not / as it is meant to.

Two suggestions for the next steps:

1. Base your developments on Drupal 6, that has a refactored and more flexible custom_url_rewrite_outbound()
2. Suggest another patch that does not change the default behavior (one way to do this is to put the custom_url_rewrite() call out of drupal_get_path_alias(), in a similar manner as Drupal 6)

In my testing with the patch applied, I have not changed the default behavior. It's only when my custom_url_rewrite kicks in that the URL of the front page changes. Otherwise I don't see how it changes, am I missing something?

I agree that Drupal 6 (and beyond) is ultimately what I need to support. I just haven't had time yet to upgrade Drupal for Facebook, and I'm still working on Drupal 5 sites that use it. I wasn't aware the API changed for D6, but I suspect there was good reason to change it. Thanks for the link, I'll read up on it.

Just looking at the code for url() in Drupal 6, I see that custom_url_rewrite_outbound is called even if the $path is <front>, so no problems there.

I see my options as (a) improve this patch so that it can be committed to D5, or (b) leave this patch as is, and just refer Drupal for Facebook users to apply it manually. So it's not the end of my world if this patch does not get in.

When you said,

links to <front> will point to the alias, not / as it is meant to,

do you mean that people are setting up a path alias for "<front>"?

On second thought you are right: in Drupal 5, drupal_lookup_path(), called by drupal_get_path_alias(), verifies that the path is not empty anyway, so we are safe here.

If you want this patch to go in, I would suggest taking the route 2 in my comment above: refactor url() in Drupal 5 the same way it was done for Drupal 6 (ie. (1) if the path is <front>, convert it to '', if not pass it to drupal_get_path_alias(), (2) then call custom_url_rewrite() on the resulting path unconditionally). Marking as code needs work.

What's the verdict ? ;)

The patch solves the problem. It's very difficult to get a change like this into core. Damien suggested changes to the patch which might be enough to get it committed. If someone feels this is important enough, they will make a new patch and try to get it in. Myself, I just use the patch above.

Tagging