Let custom_url_rewrite_outbound() operate on base_url

Please don't set your own patches ready to be committed. All patches need community review, and *especially* when they're touching a function that's used basically everywhere.

Could you clarify what we need to do to test this?

this would be very useful for serving static content from a different domain like files.example.com, for example.

I have use-cases for this as well, over in the Domain Access module.

In some cases, I need to force $absolute values to be attached to URLs -- for example, when searching content from multiple domains, the links need to go to sites where access rules allow the nodes to be viewed.

In 5.x, I had provided a hook_url_alter() patch to provide this functionality, and have tried to backport custom_url_rewrite_outbound() since learning of the function.

http://drupal.org/node/210248

However, custom_url_rewrite_outbound() fires too late in the url() function for me to make any modification to the $options['absolute'] parameter.

This patch addresses that need, however, I think it introduces the potential to leave $base unset if the IF check for (!empty($path) && $path != '') returns FALSE.

Perhaps we should move the custom_url_rewrite_outbound() sequence instead?

For reference, my approach was to run the rewrite hook at the very top of the url() function.

http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/domain/patc...

With regard to $base, I may have read the code incorrectly.

I like this new patch, since it is exactly what I was going to propose.

The patch works, and you can rewrite $options['base_url'] and set $options['absolute'] = TRUE in order to force links to go to different hosts. It also preserves url aliases.

There are, of course, performance implications, but that is a trade-off for added functionality for sites that choose to implement the function. I have not done extensive performance testing.

Marking RTBC because I'd like to get input from core committers.

This is an API change for the custom rewriter too late for 6.x.

The argument is that this is a bugfix, since the original feature did not consider all use cases.

I will reset this issue once. If it is rejected as too late in the release cycle, then I accept that it is a feature for 7.x.

If it does not go in to 6.x, I will be releasing this patch (or something like it) as part of the Domain Access module.

Well, the patch is also an API change in that it removes the possibility to modify $options['prefix'], although it is supposed to be modifiable from the function. Let's try to not break APIs when you are advocating a patch as a bug fix. :)

works perfectly. the only thing i did not test is interaction with locale. hopefully gabor can verify that.

here is the function i used to test (note base url change at bottom). i will change the docs accordingly once this goes in.

function custom_url_rewrite_outbound(&$path, &$options, $original_path) {
  global $user;

    // Change all 'node' to 'article'.
    if (preg_match('|^node(/.*)|', $path, $matches)) {
      $path = 'article'. $matches[1];
    }
    // Create a path called 'e' which lands the user on her profile edit page.
    if ($path == 'user/'. $user->uid .'/edit') {
      $path = 'e';
    }
    
    $options['base_url'] = 'http://cnn.com';
    $options['absolute'] = true;
}

Well, this patch also fixes URL encoding of the path prefix when we are on the front page, which makes it all consistent with the path handler case, so committed, thanks.

Attached is a backport for Drupal 5, if anyone needs it.