Add path redirection (aka integrate Path Redirect into core)

This really isn't something that would ever make it into core. It's not an "absolute must" so it's a non-starter really. After all, it's completely unnecessary for a new site, and often new sites would not bother with this either.

100% agree with harking

strongly agree, this functionality should be included into core

Since several people have requested this, I'm going to move the issue over to core and see how it is received.

If people like the idea, I'll roll the module as a patch for core.

just adding the link to the actual project page: http://drupal.org/project/path_redirect

My initial thought was that the new menu system should at least partly take care of this (AFAIK it allows you to define an "active" path alias for a path to which other aliases will redirect). Not sure wether it was actually done, though -- there was an issue about it, which I can't find right now.

@Frando, are you talking about the path alias interface issue at http://drupal.org/node/106094? I think there was discussion there of making an alias the "default" and then 301 redirecting any other paths to that main alias. This is nice for SEO to avoid duplicate content.

This would be a great and much-needed addition for the core 'product' and compliment path.module. It would probably actually live inside path.module as well. I would really love to drive this for Drupal 8 and also would like feedback from others on this.

Like it into core as well!

----------------------------
JGO | http://www.e2s.be
----------------------------

I am not sure if this is a good candidate to get into core. While I can see why something like Pathauto getting into core (mainly for automating internal link paths), I can't seem to find a good use case for Path Redirect (although I use it to redirect to external sites).

Maybe if we re-factored the entire Path stack so that Drupal could redirect paths anywhere and not just within DRUPAL_ROOT. I do think that Drupal should do certain basic tasks (and do them in a unified way). And I do think URL rewriting is one of those tasks.

Also, core is usually less "feature rich" than most things in contrib (just look at blog, poll, tracker and forum). I wouldn't want to see path_redirect make it into core, just to stagnate.

Maybe Dave can shed some light on why this would be a needed addition to core?

Most people use it for when you migrate a site to Drupal. You often have tons of links and need to redirect them properly. Right now this is mostly in the discussion phase, so its no means official that its being added. Realistically this would only be added if we truly had a frameworks and a product since path_redirect would fit in much better in the product. And its not really a module that needs to change a lot, so there's not much evolution that would benefit it from being in contrib.

Thanks Dave for the quick response.

My concerns are mainly two fold: Would it add more bloat to drupal and would it follow the 80/20 rule of admins actually using it.

While I don't have any serious objection to it being in core (since I use it myself), I just want to make sure what gets in core is actually useful and better served in core than contrib.

While I am no serious coder, I would like to see the redirection be segmented a bit. What I mean by this is that there should be a way to differentiate between internal and external links so that all links don't get passed through all the path_redirect functions. I just don't want to see path.module go from a tiny addition to every link getting run through tens of new functions.

This way redirecting code can live in something like includes/path.redirect.inc and only be called when needed.

bsherwood,

as everything on the world, also web sites tend to develop (and grow with time). In this proces you sooner or late (have to) change some paths. Also some content becomes obsolete, and sometimes it is much better to guide the visitor to a new content instead of just showing 404...

Imagine a site starting with one address, but with time you split it to more "virtual" web sites (different domains...) - for example when someone develops some software and dedicates "own sites" to each product. For sure there is a benefit for visitors to be automatically redirected to new locations, not just to see links and information about changes...

I believe every serious web site has a need for some redirections (for me mainly to maintain links independant of new versions of content, as a catalogue...). How to do that without redirects? I really don't want to crawl through all content just to look for obsolete links every time there is some change.

On the other hand, I don't use many modules that are in core, as aggregator, blog, contact, forum... I would prefer to have path redirects in core instead of forum for example (which I find more like WYSIWYG editors - I prefer to have a chioce among more highly developed external solutions, and to integrate the one which is more popular in my environment - and, users are more familiar with...).

For me, redirection is simply one of the main (core) functionalities of a web site management system (as Drupal is).

@LUTi,

I agree that redirection is important. I am just saying that drupal appeals to a wide audience of people and Path Redirect shouldn't just be added because it is a useful module. The drupal developers added CCK into D7 because the majority of drupal admins would download it as soon as they installed Drupal.

I also agree that there are a lot of core modules that don't get used by a lot of people, either because they don't need them or because they aren't powerful or flexible enough. That is why there our issues about removing them from core (mainly blog and poll)

I am also on board personally to have Path Redirect in core mainly because I do use it for certain sites. But just because I use and like Path Redirect, that doesn't mean it should be in core.

Now that Token is in D7, I would like to see the entire Path stack get refactored. This could include adding Pathauto as well as Path Redirect into core and redesigning the UI for all of them. Also some of what Path Redirect does overlaps with Pathauto so we could also clean up the code before we add them to core.

bsherwood,

I agree with you that just the fact that me (or, a majority of admins) use some module is and should not be a factor to make a decision about something be in core or not.

Therfore, I've tried to stress that a path handling should be a part of core, as it is all about to give site admin an organized environment within which he/she can publish some content in a way he/she likes. For me, the environment is a system which handles an address received in a right way (in terms to get the right content for it, being called or put together, and manage visitor rights about that). Sometimes this content simply doesn't exist (anymore), and also this has to be handled as site admin wants (not just being answered with an error) sometimes. To display the alternative content is for me as important as to display the right content in the right way. No info is sometimes just not acceptable...

Probably I was (am) not clear enough.

Of course it would be even better as you suggest - if some separate parts can be merged to do the job in a more efficient (better) way (less duplicate tasks or processing and maybe better interoperability...).

I don't think we are going to be able to make this decision now. I think the majority of this decision will be made once development on 8.x starts. We will clearly see if this module is needed/wanted in core if we get a ton of "+1 subscribes".

The Drupal team does an excellent job in refactoring code (Fields in 7.x can now be mapped to comments and users!), so I am sure that Path Redirect will definitely get an overhaul if included into core. Not only that, but Dave Reid is an active member in the community so this issue has some weight and authority behind it.

I also think that URL redirection is a pretty static problem to fix. It's not like the whole "views in core" issue. Views is constantly changing and adding new features so I would only want a flexible solution (like a Views API) to get into core. But that's a different issue all together.

I guess my only issue would be more code bloat. If PR gets into core, I would like to see it in it's own library (i.e path.redirect.inc) and only called on for certain tasks. This way we can include the code without making drupal slower. I am sure my issue is a not a huge problem, since the dev team does a great job of fixing those kinds of problems.

I am on board with PR getting into core, I just want to make sure everyone else agrees as well.

bsherwood,

I understand you. The difference is I am looking at the issue from strictly user's (site admin's) point of view, not developers / mainatiners...

For me, as said, nothing helps if I have a great site content, but visitors can not find it (in an easy way...). And, sooner or later, there is a situation when redirects come out as (the only, or the easiest / most comfortable) solution to get visitors where we want...

In terms of quality, a contributed module should never be better than a core component (module). Drupal maintainers probably know all the tricks and how to integrate something in an optimal way. As I see it, mainainers of contributed modules generally know what they need (would like to achieve), and then do their best - some with a great success (and, a lot of effort), some with less...

In terms of performance, if something is an optional core component, probably it shouldn't be much different as if it would be a contributed module, or? I see the major difference in who takes care for maintenance, and consequently how well integrated and up to date a component is. At the end, the site admin is always the one who (can) decide between some extra features (functionality) or (more or less noticeable) performance improvement (unless some component is not optional...).

The big benefit for me is also that core components are ready immediately when we have a new major version of Drupal, while contributed modules sometimes are quite behind (or, with some obsolete code which should be updated...). Drupal core components are also a sort of guarantee for us (that we will be able to upgrade a site without significant issues / a loss of functionality), while with contributed modules we never know (absolutely nothing bad about path redirect, this is absolutely a very general remark). There are some nice modules, where mainainer(s) suddenly are not available (so much / enough) anymore (due to the lack of time, interest or whatever...).

I think we are on the same page here. We both use this module and think it would do well in core. I also have this feeling that there will be a big push for getting Pathauto in core for 8.x. If Path Redirect makes the cut as well, I see a huge UI redesign in the making. So that would take care of the admin's perspective.

+1

Please explain an out of the box use case for including PR. It must be more than "it's useful".

If it's not turned on by default (i.e. in default.profile), why should it be included?

Can you make a case for making this part of menu functionality in a logical, clean way?

Why should out of the box use be the main criteria?

Like we do care about our site only when install the system, but not after, during its lifetime...

Sorry, out of the box is sort of short hand, since I've been talking for a while about "what should Drupal the product do". But yes, we do most care about first use experiences: it is still a module that can be installed afterwards, which makes it a great use case for a contrib module.

My opinions are in my previous posts - in short, I hate to get used to something (and, put some efforts to know something about), but find out later I have to switch to some alternative (as the first solution doesn't suit to all my needs...).

And, my concerns about contributed modules are mainly:
- what is the situation with those modules in development stages of Drupal (alpha, beta, rc...) - some manitainers wait for some maturity stage of Drupal core, while I'd like to test (and, prepare to move the site) before; furthermore, there are sometimes considerable delays before contributed modules are ported to new major versions (and, sometimes are quite buggy at the beginning...)
- what if maintainers suddenly don't take care about the contributed module anymore (whatever the reasons might be); this can create serious problems if the site depends on some module heavily (and, possibly prevent Drupal core updates until a new mantainer shows up)
- how well the contributed modules are integrated into the core (due to different reasons)

I believe a path redirections are very important feature, which sooner or later is needed by almost any web site. As such, I would have it in the core certaily before forum, poll, book etc. (I see them like at least 1 layer below those, which are a kind of applications...).

All of your arguments can be summarized as "I use this module a lot so I think it should be maintained more than other currently core modules that I don't care about". The best way for any contributed module to be maintained is ... by it being maintained. You can help by volunteering for none code tasks like helping manage the issue queue etc.

Your last sentence pretty much says it all "a very important feature which sooner or later is needed". That's exactly what contrib is for - add it when you need it.

There needs to be a fundamental, technical reason that *core* will be made better by the inclusion (e.g. rearchitecting paths somehow becomes better with the addition of this code), not just by checking off some more feature boxes. Let's just set it to postponed and focus on shipping D7 :P

Where might this idea stand in relation to D8 now?

Agreed with #25; is there a different take on things now that D7 is a mature product and D8 is upcoming?

Path Redirect and Global Redirect are being merged into Redirect
http://drupal.org/project/redirect

http://drupal.org/project/path_redirect
http://drupal.org/project/globalredirect

After the merge, i think it will be a great addition to core, like Pathauto
http://drupal.org/project/pathauto

Don't think it will be in time for D8 though. It has reached feature-freeze

Don't think it will be in time for D8 though. It has reached feature-freeze

Right. This goes in the "maybe next time" bucket now. :)

Not sure I agree with this going into core - especially the current implementation where redirects are looked up every bootstrap, but features can go into minor releases.

Hello All - the conversations are really good - was wondering what is the current development status of this?