custom_url_rewrite is not a hook. By defining it, you prevent sites from defining their own behavior for this function.

Attached patch will not break existing sites, but will make it possible to override domain's url rewrites as needed.

domain_custom_rewrite.diff812 bytesDave Cohen


agentrickard’s picture

Status:Active» Needs work

I don't think 'steals' is correct. It implements the function, which 99% of site do not use.

This is a well-documented issue. Most sites do not use custom_url_rewrite_outbound(). Using that function requires that you add custom code to your site, so we can safely assume that people using the function will understand the error.

Section 3 of INSTALL_QUICKSTART.txt: (there is also a note in 4.5 of INSTALL.txt)

3. Check for existing custom_url_rewrite_outbound().

    custom_url_rewrite_outbound() is a special function that you
    can add to settings.php to alter how Drupal writes links to content.
    If your site already uses this function -- it is not in core -- then
    you will receive a PHP fatal error. This is because Domain Access
    uses a version of this function as well.
    If you encounter this conflict, you need to merge the logic of the
    two functions into a single function.

The patch may prevent an unexpected error, but it doesn't work, because what we need to do in those cases is merge the two functions.

Is there a way to make domain_url_rewrite_outbound() run and then call the other function? (Or vice versa?) Even so, I don't think that will work, since the business logic of the function probably needs examining in all cases.

Dave Cohen’s picture

i18n and Drupal for Facebook also implement these functions. In both, there is logic similar to whats in the patch.

Here's an example of custom url rewrites which is possible with the patch I supplied, but not possible without it. This would be in someone's settings.php, for example...

* Both Drupal for Facebook and domain module use the custom_url_rewrite feature.  We have to define our own functions which call the others in the proper order.
* Note our version of domain module must be patched to support this.
function custom_url_rewrite_inbound(&$result, $path, $path_language) {
  // Call fb module first
  if (function_exists('fb_settings_url_rewrite_inbound')) {
    fb_settings_url_rewrite_inbound($result, $path, $path_language);
  if (function_exists('domain_url_rewrite_inbound')) {
    domain_url_rewrite_inbound($result, $path, $path_language);
function custom_url_rewrite_outbound(&$path, &$options, $original_path) {
  // call fb module last
  if (function_exists('domain_url_rewrite_outbound')) {
    domain_url_rewrite_outbound($path, $options, $original_path);
  if (function_exists('fb_settings_url_rewrite_outbound')) {
    fb_settings_url_rewrite_outbound($path, $options, $original_path);

Sure, the custom url rewrite function leave something to be desired. And there are patches to make them hooks instead of single functions. But in my opinion a module should be written in a way that makes it easy for people to build their sites. Is your idea is that if someone needs a customized url rewrite, they should change the logic in sites/all/modules/domain/ Sounds like a big headache if you ever make a change to that same file.

agentrickard’s picture

Yeah, that explanation makes sense. This really isn't something we've had to deal with.

Can you write that into the patch as some documentation?

agentrickard’s picture

Status:Needs work» Fixed

Committed to HEAD. Needs documentation.

Opening new issue. #450998: Document use of domain_url_rewrite_outbound()

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

agentrickard’s picture

This has been fixed in 5.x as well, though it is of less concern there.