Hi. I'm new to your module. I learned about it when users of my module reported an issue, http://drupal.org/node/246694.

After some investigating, I've found two problems. First, when facebook calls drupal, it uses a URL which ends in a slash, and has to end in a slash, Facebook gives no choice. So this line in Global Redirect causes problems:

$request = trim($_REQUEST['q'], '/');

Second, Drupal for Facebook uses custom_url_rewrite(). Global redirect ends up always redirecting here:

      if ($alias != $request) {
        watchdog('debug', "Global redirect from $request to $alias (because the two are not equal)");
        drupal_goto($alias, $query_string, NULL, 301);
      }

I believe this is a problem for any modules using custom_url_rerwite, including i18n, as reported here: http://drupal.org/node/153950

So, I'm seeking some advice to resolve these two issues. One approach is to simply say "you can't enable both Global Redirect and Drupal for Facebook." Another would be to enable Global Redirect for regular browser requests, but disable it when it is Facebook making the request. My modules can tell when the request is a facebook request, but as far as I know there is no way to programatically prevent Global Redirect from doing its thing. And perhaps there is some way the two modules can coexist without interference but at this point I'm not sure what that is.

Thanks for any help.

Comments

Dave Cohen’s picture

(disregard the watchdog statement in the above code. I added it trying to track down the problem.)

Dave Cohen’s picture

With the caveat that I have not tested very much...

It may be possible to have Global Redirect not do its thing when custom_url_rewrite is enabled. I'm not sure whether this is desirable when using i18n module, but it certainly is with Drupal for Facebook. I changed the if clause at the beginning of globalredirect_init() to

  if(isset($_REQUEST['q']) && function_exists('drupal_get_path_alias') && !isset($_REQUEST['destination']) && ($_REQUEST['q'] == drupal_get_normal_path($_REQUEST['q']))) {

And with that, Drupal for Facebook works OK and Global Redirect works when its not a facebook canvas request.

nicholasThompson’s picture

Thanks for bringing this up - not many people will be using Facebook, Drupal AND GlobalRedirect, so this is a bit of an edge case on its own... However it does look like there is a fair bit of overlap between this facebook issue and the i18n one...

patchak’s picture

Is there a way to see all modules that use that function? (custom_url_rewrite) Cause if removing that would work this seems like an acceptable solution...

Patchak

nicholasThompson’s picture

patchak - it'd involve checking out the entire CVS repository (DRUPAL-5 branch maybe?) and then using a recursive GREP... Its possible, but I'm not sure my ISP (or the D.O admins) would appreciate me checking out the entire repository ;-)

Dave Cohen’s picture

custom_url_rewrite is not a hook. So in any one drupal instance, it's only defined in one place. Very few modules need it, but for i18n and DFF there are good reasons. I pity the fool that has to use both of those modules together. (It will probably be me).

Note that the other patch I posted in the i18n thread might make my approach in #2 unnecessary. I haven't tested that patch in every case so I'm not really sure.

nicholasThompson’s picture

Category: support » bug
Priority: Normal » Critical
Status: Active » Postponed (maintainer needs more info)

Hi... I'm back for a bit to maintain and trim the queue down...

Item (1)... The auto-slash removal. Easy to fix - will make it an option which can be disabled.

Item (2)... Custom URL Rewriting. I dont know a lot about this. Could you explaing a little what it is and why DFF needs it?

Dave Cohen’s picture

You can learn more about custom_url_rewrite on http://api.drupal.org/api/function/custom_url_rewrite/5.

It's easy to understand how i18n uses it, so lets start there. Consider two URLs, one ends in en/node/42 and another fr/node/42. The english and french versions of content, specifically. Custom URL rewrite allows i18n to detect which language the user is requesting, then "rewrite" the path so that Drupal treats it as a request for node/42. The second important function is this... Suppose node/42 has a link to node/200. I18n has a chance to rewrite that link so that when it is sent to the browser it becomes en/node/200 or fr/node/200 depending on the language currently being viewed. That way once a user is viewing french content it stays french even when they follow links and submit forms.

DFF can support multiple facebook apps, so it uses custom_url_rewrite in a similar way. If the apps are known as 1 and 2, the paths would be fb_cb/1/node/42 and fb_cb/2/node/42. It helps DFF know exactly which application is receiving a request. At times, this is necessary for DFF to function properly. Other times its not strictly necessary, but serves as a sanity check.

nicholasThompson’s picture

Ahhh right! I see...

So for GR to work with this properly I need to check out i18n and FBB integrate with custom_url_rewrite and make sure the appropriate calls are made before a redirect.

nicholasThompson’s picture

Status: Postponed (maintainer needs more info) » Postponed

Feature (1) is added in 5.x-dev, however the custom_url_rewrite is in progress in other issues due to the i18n implications.

Marking as Postponed as I believe the i18n issue fixes SHOULD solve DFF at the same time... If not then we can re-open this thread at that point.

SocialNicheGuru’s picture

has any progress been made on this?

Thanks. I am one of the unlucky ones using global redirect and dff.

GreenReaper’s picture

For what it's worth, here's the two issues I ended up with:
* Global Redirect thought that the /fb_cp/xxxx/ page was the front page, but not referred to in the canonical fashion, and was redirecting circularly to /fp_cp/xxxx/ (line 101-108 of globalredirect.module)
* On working around that, Global Redirect thought it was not the deslashed path and failed on that (line 150-155)

For both I added the comparison "0 !== strpos($_REQUEST['q'], 'fb_cb/')" to the initial if. Hardly bulletproof and very specific, but it seems to work.

dparizek’s picture

I disagree - it is not an edge case because both Global Redirect and Drupal for Facebook are popular modules.

lubnax’s picture

subscribing

nicholasThompson’s picture

Issue tags: +Drupal for Facebook

The DRUPAL-6--1 has a custom_url_rewrite_outbound section in it now to improve compatibility between GR and i18n - does this effect DFF?

Dave Cohen’s picture

Not sure. It may effect canvas pages, when custom url rewriting is enabled (in 3.x branch, rewriting is not on unless explicitly enabled, which is recommended for canvas pages).

If a site enables on facebook connect but not canvas pages, it should no longer be an issue.

nicholasThompson’s picture

Dave - how would I go about testing that? Would I have to register a Facebook API App? Is there any "easy" way it could be integrated into a SimpleTest?

Dave Cohen’s picture

Well, I can tell you how modules/fb is expected to work and maybe you can devise a test with or without a facebook app.

In modules/fb, if you choose to use url rewriting you do so by including a bit of code in your settings.php (custom_url_rewrite_inbound() must be defined before drupal_init_path() is called, and therefore before modules are loaded). So for testing you would add this to your settings.php:

// change these paths depending on where modules/fb is installed.
include 'sites/all/modules/fb/fb_url_rewrite.inc'; // The url_rewrite-specific code.
include 'sites/all/modules/fb/fb_settings.inc'; // Other code needed to enable modules/fb.

Now, regardless of whether you have an app configured, you can test the expected behavior of other modules which need url rewriting. If they are broken because modules/fb has grabbed the custom url rewrite functions, well then there is a problem, but maybe not a bug. You see drupal by design expects only one set of url rewrite functions. And a savy site admin will know that to support two or more modules which need url rewriting, that person must define their own custom url rewrites, and in there code they can invoke whatever is needed to support multiple rewrites.

SocialNicheGuru’s picture

try using the module url_alter

Dave Cohen’s picture

Drupal for Facebook's url rewriting must be done before drupal_init_path is called, and therefore before modules are loaded. I do not expect it to ever be compatible with url_alter module.

Dave Reid’s picture

I thought we explicitly fixed that in fb.module for D6 or is this a D5 issue only with GR + FB?

Dave Cohen’s picture

This issue is marked 5.x-1.x, but the thread has led us into other territory.

Yes, there was an attempt to make the url rewriting work with url_alter. The methods are still named to be compatible with that module. However, it didn't work fully. One of the rewrite functions has to be defined in settings.php. By the time modules are loaded, it is too late. There is a comment in fb_url_rewrite.inc attempting to explain this.

For a time I thought I could do away with the need to do any rewriting. But I couldn't quite do it. In 3.x, using facebook's latest migrations, the rewriting is required if you want to support canvas pages.