I'd like to propose that we deploy and enable http://drupal.org/project/path_redirect on drupal.org.
Why we need this:
- The d.o redesign is going to reorganize a lot of pages and URLs, and we'd like to prevent linkrot.
- In general, when the documentation team reorganizes handbooks and aliases, it'd be nice to prevent linkrot
- Minor concrete example of this is the following handbook page: http://drupal.org/community-initiatives/git/feature-list -- When this page was first written, it was conceived of as a listing of all version control related features on d.o that we're going to have to touch as we migrate from CVS to Git. Now, it's really the working document for implementing "Phase 2" of the migration. The above URL was included in slides @ DCSF, but a vastly more sane URL would now be /community-initiatives/git/phase-2. I could just change it, but then all the links to the old will die, which sucks.
- We already have a bunch of code in drupalorg module to handle redirects in a hard-coded, hacky sort of way. See the redirects.module for details. Most of that module can and should die if we had a real solution to this problem.
- ...
Why path_redirect would be a good thing to deploy:
- Maintained by UberMaintainer (and security team member) DaveReid
- Has official D6 releases (sure, it's only beta, but Project* is only alpha, so what's the diff?)
- Already has a 7.x-1.x-dev snapshot and the #D7CX pledge
- 55th most used project on d.o according to http://drupal.org/project/usage
- ...
Comments
Comment #1
Bojhan commentedMakes sense - looking at the IA proposal almost all major pages will get a new structure, and linkrot is a pretty bad way to move to the new site.
Comment #2
dwwforgot to tag this...
Comment #3
damien tournoud commentedMajor +1 here. I think Dave was doing a security review or some other work to prepare the deployment on d.o.
Comment #4
killes@www.drop.org commentedWell, if the redesignmakes such big changes, then I guess we'll need this module..
Comment #5
dave reidHmm, I thought we had an issue already for this, but I can't find it anymore. :)
Short version of the module's current status is it's at the final stages of going through some major API changes, but I'm testing the hell out of them. So deploying on Drupal.org shouldn't be a problem now. I already have admin privs on drupal.org and a semi-infrastructure account so I can be available to help respond if anything happens.
Comment #6
dave reidBTW I've been using the 'needs redirect' issue tag for anything to be addressed after path_redirect is installed.
Comment #7
dwwBump: @Dave Reid: any news on a version you'd be happy with us deploying on d.o? ;)
Thanks!
-Derek
Comment #8
gregglesI think the stability and reliability of this module is fairly well known.
The bug list - http://drupal.org/project/issues/path_redirect?categories=bug - looks relatively trivial (mostly edge cases or end-user confusion that should really be support requests or problems with that pesky Pathauto module).
I think we can deploy the latest version of the module on drupal.org.
Comment #9
dwwIt's a lot nicer to be able to deploy official releases whenever possible. Any chance of that anytime soon? Even if it's just another beta...
Comment #10
dave reidGive me a sprint over the weekend... :)
Comment #11
dave reidMerging #644104: Enable path_redirect so core can link to stable documentation URLs into this issue. Just created the 6.x-1.0-beta7 release which should be the last beta before rc and 1.0. FYI the D7 version of path_redirect will be moving to the Redirect namespace.
Comment #12
dwwGiven that path_redirect 6.x-1.0-beta7 is out, I'm planning to deploy this Saturday (2010-08-21) morning (PDT). Among many other things, I need it to resolve #455922: Make the alphabetical list of projects not suck so much which is something I'm working on for the d.o redesign.
@killes: You've been warned... ;)
Comment #13
dwwFYI: deployed on scratch.d.o and working fine:
http://scratch.drupal.org/node/206666
Comment #14
dwwImported into bzr vendor and merged into the production (and redesign) d.o brz branches. Now deployed on d.o. Currently only full admins have permissions to do this. If we want to give site maintainers the power, we can just reopen this issue.
Working great, for example:
http://drupal.org/community-initiatives/git/feature-list
Yay!
-Derek
p.s. #889756: Let path_redirect handle redirects instead of more custom code if anyone's interested in cleaning up some cruft now that we have a better tool for the job...
Comment #15
dwwSorry for the noise, but tagging for the d.o redesign PM team... ;)
Comment #16
lisarex commentedPer convo w/ dww in IRC, reopening the issue to say I think it would be nice for site maintainers and docs team admins to be able to create a redirect without having to ask someone else and/or create an issue.
And btw, woohoo! This is great!
Comment #17
gerhard killesreiter commentedI htink that path_redirect should be used by the same roles that can currently create and edit aliases.
Comment #18
dwwThen that's how it's currently configured. Only "administrator" can create url aliases or administer url aliases. So, those are the only folks who can create redirects.
@lisarex: I guess that means your choices are:
A) Open a separate issue to debate expanding the roles that can create aliases and redirects.
B) Open an issue to try to get yourself into the full "administrator" role.
C) Create webmaster tickets requesting specific redirects and one of the full administrator users will have to create them. This probably sounds worse than it is -- especially among the redesign team, there are a lot of us with full powers. ;)