Mention the Match Redirect module on project page / documentation

Not really at all at this point. There's been a long standing issue in Path redirect for this but no one has gotten it right and I think those types of redirects are much better suited for the server-level redirects. It feels like it's a hard thing to get right. I'll leave this postponed for now.

i also would love to see this option.

Kind-of agreeing with Dave Reid on this point. While it would be awesome to do regex-based redirects (even as simple as a wildcard redirect), something like this is better suited for the Apache level...

Of course, I think if someone had a separate module (or wanted to write up something better for an 'advanced' redirect), a lot could be done to help people with the writing of said regex redirects - for instance, moving all paths in one directory level to another, or removing .html from any query string within a certain path... etc.

Documentation in this area is very cryptic for those of us without voodoo regex powers and a deep understanding of mod_rewrite.

Basic support for wildcards + specific url alias overrides would be fantastic.

Often when a new site is deployed, the old site needs to have 301 Redirects added to maintain link equity (Google Juice).

Typically this is done with mod_rewrite, but that's more challenging to do in a Drupal Multisite environment and requires filesystem access.

Giving Drupal the ability to do wildcard-based path redirects (with asterisks only, in typical Drupal form, no fancy regexes) would solve this for the 90% use case.

Subscribing.

I agree.

Subscribing.

Subscribing

Subscribing. Just simple path/* wildcards alone would be awesome.

+

My case for why a wildcard would be useful. I have a site I moved from D6->D7. On the D6 site I had the calendar module that created hundreds of pages, on the D6 site this has been replaced and those URL's no longer exist. For months now I have been getting search engines pounding no longer existent pages like these ones.

ex.
page not found calendar-for-groups/2012-09-15/1093
page not found calendar-for-groups/2011-W09/77
page not found calendar-for-groups/2011-W27/77
page not found calendar-for-groups/2012-06-29/1093

I get thousands of these request every week and I would love to be able to redirect calendar-for-groups/* to the new events page.

Here is my first attempt to add a wildcard functionality (file attached). As much as I've tested it on my site, it seems to work as expected. Any feedback is welcome, in particular code improvements... ;-)

A general rule is that a wildcard character in source can "replace" 0 or more characters in URL string (the shortest match possible). If there are wildcards in redirect, they are replaced with the same pattern matching source wildcards (i.e. the first wildcard match in source replaces the first wildcard in redirect and so on...).

If there are more matching redirects, the one where wildcards replace the smallest number of characters is chosen (for example, /test_* and /test_*/* are both matching /test_1/x, but the second one is selected as a better match, considering the wildcard in first redirect replaces 3 characters - '1/x', and both wildcards together in second redirect replace "just" 2 characters - '1' and 'x'). This algorythm is very basic and can (should) probably be improved somewhere in the future...

If both source and redirect queries are empty, a 'Retain query string through redirect.' option is respected. If there is just a source query, this option is neglected, as we may expect to handle queries with wildcards in case of need (so, if there is no redirect query, we guess that we simply don't want a query to be retained...).

The attached patch didn't show up, probably a problem with the patch's name.

You're right, sorry. What about that one?

Doesn't work as well... Arrrgh. Next try... ;-)

Finally... :-)

I'm still really opposed to this idea in Redirect itself. We should have a good enough API that it should be possible to make a separate Redirect wildcard module because it will need a separate listing page and form for creating the redirects since it doesn't really need all the validation that is currently done. If there are blockers in the API to prevent this from happening I'll gladly look at those, but this module tries to keep things simple and let other modules do complex stuff.

Marking back as postponed pending any API changes required.

These sorts of wildcard redirects can always be handled by a simple custom module. In this case you are looking for any request at /path/* and redirecting to one page. This is trivial with a simple hook_menu implementation.

foo.module

function foo_menu() {
  $items['calendar-for-groups/%'] = array(
    'title' => 'wildcard redirect',
    'page callback' => 'foo_wildcard_redirect',
    'access callback' => TRUE,
    'type' => MENU_CALLBACK,
  );

  return $items;
}

function foo_wildcard_redirect() {
  drupal_goto('events');
}

As proposed in #18 works fine.
But if your doing this because Google has a long index of non existent pages, then you probably want this to be 301 instead of 302 which is default of drupal_goto()

So foo_wildcard_redirect() would be:

function foo_wildcard_redirect() {
  drupal_goto('events', array('query'=>array()), $http_response_code = 301);
}

I second this feature request. We are currently migrating a very large site to Drupal. It would be nice for the site owners to be able to add their own wildcard paths, that way the onus is not on the sysadmin to updated htaccess or the apache config file. One specific use case is that their old server used to have tilde user pages (www.example.com/~foo), they want to be able to redirect those pages to another server (www.bar.com/~foo).

Perhaps we can create a new module, maybe called Redirect Match? That way the user can choose whether to enable this module or not. Is anyone interested in helping me maintain this module?

I'd also really like to see this feature implemented in this module.

yes this would be a really handy feature for this module!! need it badly :)

http://drupal.org/project/redirect_match

Scratch that last comment, turns out that redirect_match does nothing at all. Bizarre.

I've created a patch based on comment #18, which works for me and is really simple. Users can create wildcard redirects such as 'test/*' by using the 'Add redirect' interface. The only thing to mention here is that this approach requires you to clear cache before your new wildcard redirect will work (since it uses hook_menu). I tried to use entity_load_multiple without an EntityFieldQuery, but couldn't figure out how to do a 'source LIKE' property condition. We can change that later, but this should work for now.

Re: #25 — The patch applies cleanly and appears to work, but I'm not sure if using hook_menu() is the best way forward. Any solution to this should, at the very least, try to make use of Redirect's own API.

Really, what is needed is some way of doing a full preg_replace on paths as per mod_rewrite. It's really annoying that there's no way of implementing rewrites outside of .htaccess as Drush nukes it when updating core -- simply giving Redirect the ability to accept regex would open up a whole new best practice (I.e., users would then never need to add rewrite rules to .htaccess).

I'm so annoyed about this (I opened this Drupal.SE question ages ago and almost started an identical question today when I ran into this problem again) that I'm considering writing a separate module that does nothing but manage custom mod_rewrite rules. That said, I'd vastly prefer this functionality to be part of Redirect.

Maintainers — any thoughts?

It turns out my fix doesn't work for multiple level wildcard paths, here is an example:

mysite.com/wildcard/*

• mysite.com/wildcard/this-works-fine
• mysite.com/wildcard/this/does/not/work

I have updated my patch so it does not send it directly to drupal_goto, it now uses a redirect handler function.

As far as the redirect API is concerned, I'd be glad to use it. I did use redirect_load_multiple, but also needed to do an EntityFieldQuery since redirect_load_multiple currently does not allow redirects to be loaded by using a 'source like' query.

Alright,

If i redirect
FROM: courses TO: http://someothersite/courses
FROM: people/profiles TO: http://someothersite/people/profiles
then under what circumstances do I not want
FROM: courses/all-other-subpaths TO: http://someothersite/courses/all-other-subpaths
as well?

There is no such circumstance that I can think of.
I want and expect the subpaths to be redirected, (and if there is such a circumstance, then there can be a checkbox in "Advanced options" to toggle redirecting subpaths).

The users mental model is that a path is like a folder. Paths are hierarchical.
When a user creates a redirect for a path, of course they think that everything from that point down in the hierarchy also gets redirected.

Having to set up redirects for each and every subpath, is often impossible due to the dynamic nature of the content.
I absolutely cannot use apache redirects for this because with thousands of sites. It is not manageable.
This module exist solely so that the average user can make redirects without needing to get the sysadmin to put in apache redirects. It should handle common use cases.

It looks like the common case for using wildcards is for redirecting subpaths. Redirecting them by default is a sane default.
Full wildcards and regular expressions and that whole complex mess might appeal to some minortiy of people, but I cannot believe that subpaths are not redirected by default.

I just took a quick look at some redirects that have been set up on our sites.
I can't find a single case where it would hurt to redirect subpaths by default as well.
If you don't have subpaths, you are fine, as nothing would change. If you do have them you want them redirected as well.

The beauty of this approach is that there is no need for any wildcards at all.
You make your redirect exactly as you do now and the "wildcards" (i.e. subpaths) just work out of the box.

A similar problem exist in core (d7 at least) url aliases where if you alias node/22 to research and you expect research/edit to take you to node/22/edit but it does not. Same goes for people/7 aliased to people/joe-smith. You would expect people/joe-smith/publications to take you to people/7/publications, but it does not. It is such obvious behaviour... but that's for a whole another rant.

... end rant

EDIT:

Reading the source code for redirect.module, I found a module that does fixes this for url aliases (BTW, ordinary users have no idea what the difference between a path alias and a redirect is, and why should they? Especially with global redirect enabled)
Anyway, so what's the best apporach? a subpath_redirect module?

I've tried patch provided in #27 but doesn't work in my case.

I have old para-metrical urls that I have to redirect to new drupal urls, for example:

mysite.com/old_page.php?param1=6&param2=4&param3=5
mysite.com/old_page.php?param1=3&param2=2&param3=5
mysite.com/old_page.php?param1=2&param2=1&param3=5

All the above have to be redirected to the SAME node like:

mysite.com/category/item1

I've tried wildcards in this way:

mysite.com/old_page.php?param1=*&param2=*&param3=5

But it doesn't work.

Can patch in #27 manage such situations?

Thank you very much for helping me

@MXT:

It looks like you only need to redirect one page and you can ignore the parameters in the URL.
I'm not sure why you wouldn't just add a regular redirect from mysite.com/old_page.php to mysite.com/category/item1
Is there a reason this approach doesn't work?

The wildcards are really just for redirecting entire paths (such as mysite.com/subdir/another-path/*).

Hi zhuber, thank you for your answer:

I'm not sure why you wouldn't just add a regular redirect from mysite.com/old_page.php to mysite.com/category/item1
Is there a reason this approach doesn't work?

The reason is that last param "param3" takes the "old node" id to show the "old node" itself, and the same "old node" cab be reached from different "situations", for example:

• mysite.com/old_page.php?param1=6&param2=4&param3=5 -> shows old node "pizza" from "worldwide" (param2)
• mysite.com/old_page.php?param1=3&param2=2&param3=5 -> shows always old node "pizza", but from "italy" (param2)
• mysite.com/old_page.php?param1=2&param2=1&param3=5 -> shows always old node "pizza", but from an archive (param1)

And all of the above, for SEO reasons, have to be redirected to new drupal URL: mysite.com/category/pizza

And:

• mysite.com/old_page.php?param1=6&param2=4&param3=8 -> shows old node "spaghetti" from "worldwide" (param2)
• mysite.com/old_page.php?param1=3&param2=2&param3=8 -> shows always old node "spaghetti", but from "italy" (param2)
• mysite.com/old_page.php?param1=2&param2=1&param3=8 -> shows always old node "spaghetti", but from an archive (param1)

And this time the above have to be redirected to mysite.com/category/spaghetti

I hope I was more clear this time...

Thank you

I too need this functionality as the previous site on the domain was a wordpress site, and while we've kept some of the same articles, they have different URL's and I need to bulk redirect entire sections.

#31 - sounds like you have a custom template file (old_page.php) - you should be able to write in your own redirects with php in that file.

Any chance we can get my patch tested? It was added over 3 months ago and seems to work fine for me. Not even sure if it still valid with any changes to dev, but I'd like to get this committed to the module.

zhuber, I would really like to see this functionality in the module but unfortunately your patch from #27 patched fine but it's not working for me.

Here's why .htaccess is not really an option for me:

• Drupal has its own .htaccess
• multi-site setup
• .htaccess syntax sucks

@Kasper and others: this module may be what you're looking for: https://drupal.org/sandbox/biff45452/2071259.

It came out of the sandbox and seems to be working fine: https://www.drupal.org/project/match_redirect

Now that there's a separate module that provides this functionality, lets change this to a documentation task to mention the new module in the documentation and on the project page.

Project has been added to https://www.drupal.org/project/redirect

Sorry Dave if I re-open this issue, but I don't find this fix in any 7.x branches.
Is it an oversight?

EDIT
After better reading the project page, I've seen it!

Best regards.