Is anyone interested in this?

Sorry, but I'm horrible at making patch files, so I'm just going to post the function here. As always, please back up your files before you change anything.

In includes/path.inc, replace drupal_lookup_path() with this:

function drupal_lookup_path($action, $path = '') {
  static $mapsrc = array();
  static $mapdst = array();
  static $revmapsrc = array();
  static $revmapdst = array();
  static $count = NULL;

  if ($count === NULL) {
    $count = db_result(db_query('SELECT COUNT(pid) FROM {url_alias}'));
  }

  if ($action == 'wipe') {
    $mapsrc = array();
    $mapdst = array();
  }
  elseif ($count > 0 && $path != '') {
    if ($mapsrc == array()) {
      $query = "SELECT src, dst FROM {url_alias} ORDER BY CHAR_LENGTH(src) DESC";
      $resource = db_query($query);
      while ($result = db_fetch_array($resource)){
        $mapsrc[] = $result['src'];
        $mapdst[] = $result['dst'];
      }
      $revmapsrc = array_reverse($mapsrc, true);
      $revmapdst = array_reverse($mapdst, true);
    }
    if ($action == 'alias') {
      return str_replace($mapsrc, $mapdst, $path);
    }
    elseif ($action == 'source') {
      return str_replace($revmapdst, $revmapsrc, $path);
    }
  }

  return FALSE;
}

This worked fine in all my tests, but please let me know if you have any issues with it.

Please note that it is up to you not to create any naming conflicts. Think of it as a list of Drupal "reserved words". Don't make anything translate to "comment" or "reply" or "add" or any other word that normally occurs in the Path. It might create unexpected changes.

I have never used i18n, so I don't know if the two could be incorporated.

Good luck, and feedback (good and bad) is appreciated!

- Corey

I thought about just using htaccess, but then I realized that this would only work on links I create, but all system-created links ("node/35", etc.) would be unchanged.

By hacking the path module, all links are translated before being shown to the user as well. Therefore, if you replace the word "node" with "stuff", then you will never see the word "node" again in a link created with the l() function, which is just about every link you will see. "node/35" becomes "stuff/35". "node/35/edit" becomes "stuff/35/edit". You get the idea...

- Corey

Since my sites are small, this is not an issue, but I know it could be, especially with the next site I am building, so I have another solution.

Instead of hacking core, I am using killes' suggestion, in his comment below, of using the custom_url_rewrite() function.

Put this function into a new file, for example, named includes/custom_url_rewrite.inc. Here is the text of that file:

function custom_url_rewrite($action, $path, $original) {
  static $map = array();
  static $count = NULL;

  if ($count === NULL) {
    $count = db_result(db_query('SELECT COUNT(pid) FROM {url_alias}'));
  }

  if ($count > 0 && $path != '') {
    if (isset($map[$path])){
      $path = $map[$path];
    }
    else {
      $old = '';
      $new = $path;
      while ($old != $new){
        $old = $new;
        if ($action == 'alias') {
          $query = 'SELECT src AS pfrom, dst AS pto FROM {url_alias} WHERE LOCATE(src, "'.$new.'") ORDER BY CHAR_LENGTH(src) DESC';
        }
        else {
          $query = 'SELECT dst AS pfrom, src AS pto FROM {url_alias} WHERE LOCATE(dst, "'.$new.'") ORDER BY CHAR_LENGTH(src) ASC';
        }
        $resource = db_query($query);
        while ($result = db_fetch_array($resource)){
          $new = str_replace($result['pfrom'], $result['pto'], $new);
        }
      }
      if ($action == 'alias'){
        $map[$path] = $new;
      }
      else {
        $map[$new] = $path;
      }
      $path = $new;
    }
  }

  return $path;
}

You can leave off the ?> at the end of the file, but I had to include it here so that everything would show up appropriately.

Now, at the end of your settings.php file, add this:

require_once './includes/custom_url_rewrite.inc';

Your new URL renaming is now ready to roll!

Now for the gory details:

You CAN NOT put this into a module. I tried for 3 hours... The problem is that the URL is decoded *before* any modules are included, and since Drupal probably can't decode your new fancy URL's, it gives a lot of "Page Not Found" errors.

I got tired of adding aliases to my tables when I reached the 30,000 mark. Here's the long and the short of it:

1. There will be a longer load time, because you are doing more processing of the URL, etc.
2. I tested with around 30,000 aliases on the "admin/menu" page, because it contained 261 calls to the custom_url_rewrite() function (on my installation, that is).
   • Without the modification, the page loaded in .5~.6 seconds.
   • With the modification, the page loaded in .7~.8 seconds.
   • In short, it took about .2 seconds longer to make those 261 function calls with 30,000 records
3. On other pages, with only 40 or 50 links (function calls), the time difference was negligible (again, with 30,000 URL aliases).
4. It seems that the number of links on the page is of more importance than the number of URL aliases. When testing with only a few thousand aliases, I was getting similar time differences on the "admin/menu" page.
5. This function was written to use caching, to streamline identical requests, which happens A LOT more than I thought it did.

Any comments/suggestions? I am looking for ways to make this better. I will be implementing this on my own site when I get it finished... (if ever!) :o/

- Corey

Didn't know about that function, but it suddenly made a lot of things easier.

I'm always learning... ;o)

- Corey

Why would your code have 18 million aliases? Wow, that's a lot!!!

I think I see what you're saying, but you're still stuck with the problem of having to have an additional 1 million aliases (one for each user).

My solution uses pattern substitution, and does not stop at the backslash character (a feature). Therefore, if you want to alias "de/" to "I_AM_AN_ALIAS", then "node/14" becomes "noI_AM_AN_ALIAS14", and Drupal understands it perfectly (although it might look a little strange to the user).

The reason that I give this example is because, if you alias "64" as "James", then when a person is trying to view "node/64", then they will see "node/James", regardless of whether or not James is involved. :o) That is why, in the current system (helped out by the pathauto module), "user/64" is aliased as "James", so that only the user page requests are aliased. (I know that you are probably fully aware of this, but I include it just in case there are some that are unclear as to the nature of this modification.) I know that your method would deal with this in a different manner, but, with the current method, it still only requires a few SQL queries (usually only 2) to substitute everything in the URL.

OK, I guess I need to stop rambling and get to the point:

I am afraid that the tree based aliasing would actually increase server load, because one would need to load the hierarchy, and then do the substitution for each "leaf" (recursively) in the url, resulting in significantly higher computation times and sql calls. Obviously I haven't built the code and tested it, but it would be my first concern.

What It all boils down to is that, in both designs, there must still be an alias for each option. The difference is that the tree design has a higher overhead of computation in terms of organization. MYSQL is fast in searching through rows of data, but if there is additional overhead of PHP having to pull from the database, understand the data, then go back to the database, etc., then I think it will impact the performance negatively.

Please forgive me if I misunderstood your approach.

One of the features of my approach is that it is beneficial for language translation of a site. Consider the urls "node/add", "admin/block/add", and "admin/access/rules/add". In each of these, the current method could replace "add" with whatever alias the author would like. In the hierarchial design, it would be necessary to create many aliases (one under "node" in the first level, one under "block" in the second level, and one under "rules" in the third level).

Here's an additional thought for you: I'm working on .htaccess to allow the url to be re-mapped so that not only clean urls work, but so that james.example.com becomes www.example.com/user/james, and james.example.com/edit becomes www.example.com/user/james/edit, etc. I think this would look very professional! The hard part is that custom_url_rewrite() does not include example.com or anything before it...

- Corey

Sorry to post this separately, but my previous comment was getting a little long, and this is really a separate issue.

Why are you creating a separate "custom address" module, when all it is is a simple userid lookup? You could do that all from the comfort of the custom_url_function(), and never have to add another path alias. The only reason it currently relies on the url_alias table is because that is what would be most beneficial for the majority of users.

- Corey

Hey James,

Sorry it's been so long. Work is more hectic than ever, and I haven't been able to do much coding lately.

I looked through your function, and have a few concerns.

First, loading an entire array of $greedy_aliases even once will kill a site once it gets too big. This is how the url aliases used to work, until sites with many aliases started choking on that single bit of code. In your situation, if you're expecting to grow to 1 million users, then that means that, for each page call, 1 million user aliases will be loaded into that function.

The second concern is that, once $greedy_aliases is loaded, it is only used in the first part of the function. To me, it almost does not seem worth the potential resource consumption (think 1 million user aliases) when it is only used for a tue/false test. I could be wrong, though. Have you been able to benchmark the two methods?

Now, for my idea of how your implementation could work:

First of all, checking for an asterisk is too time consuming, for php or mysql. If there were a way to store that option (whether or not to use pattern matching) in the database as a simple true/false value for each alias so that it would not have to be computed each time, then that would be a better solution. If this were a feature modification for core, then this could be added as a checkbox beside each url alias, and stored in a new database column (call it "pattern_match", for example). SQL queries could then test whether each alias is intended to be used in pattern matching, and then use the "LIKE" syntax only if needed.

The problem with this is that it is getting into modifying core files, a procedure which obviously should be avoided.

I want this to work, because I believe it would have a positive effect on site presentation. I'm just not sure that I can get the performance cost down enough to make it practical.

The other thought is that most websites using this would want just about every alias to be pattern matched, since most aliases are for content and user info.

Still thinking...

- Corey