Needs review
Project:
Path redirect
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
19 Jan 2009 at 19:09 UTC
Updated:
28 May 2014 at 13:14 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
mstef commentedOK i just went out and did it myself...
I'll show the added parts in path_redirect_init()
Line 39: (added $query_string)
Line 46: (added second IF statement)
Comment #2
jaydub commentedI've ended up needing to consider this option as well. I've attached my patch which uses a configurable value for what to do with a query string.
This patch is based off of the current stable release 5.x-1.2. I see that the latest code for 5 has some significant changes. I'll attempt to follow up with a patch against the -dev at a later time.
Comment #3
jaydub commentedand a patch against the latest dev snapshot
Comment #4
jaydub commentedComment #5
nickorr commentedJaydub,
Have you put the same patch into the v6 version yet? Do you know if there is any similar change that will work in v6?
Thanks,
Nick
Comment #6
jaydub commentedI thought I had posted a patch for d6 too but I guess I forgot. I will see if I can add a patch when I am at the office.
Comment #7
dave reidI will only work on feature requests for the Drupal 6 or 7 branches only.
Comment #8
mrfelton commentedHere is a D6 version, which seems to be working well so far.
EDIT: Please use the -p1 strip option with this patch.
Comment #9
gregglesI think this idea is generally very useful/important. I don't entirely understand the need for append vs. replace and think this could probably be a "yes/no" style option.
For anyone else on this thread who uses this feature, can you explain why it should be a choice? My proposal is that we should always append the information using the current system "// Values from the requested will override those specified in the redirect if they collide."
Comment #10
dave reidI would think the query string set in the redirect will always stay. The current query string on the page being redirected would be merged in. If I've set a redirect with specific query strings, I've probably meant for those to not be changed at all and not overwritten.
Comment #11
gregglesWell, I think that's why there are three options in the patch and perhaps room for a 4th option ;)
I don't really care: my use of this is for a situation without any options in the redirect and so the incoming querystring will always be used 100%. But I would like to get this committed and into a stable release, so I want to know what other people think.
Comment #12
gregglesHere's an updated patch simplified per discussion with Dave in irc.
I looked to write some simpletests for this, but the current tests are failing (poor excuse, I know).
Comment #13
dave reidYep, and excuse no more. Just a simple test case will do.
Comment #14
pobster commented+1 for this, has it been forgotten about? It's graceful and it works, I like it!
Pobster
Comment #15
gregglesNeeds tests.
Comment #16
pobster commentedAha, right... I'll write some tomorrow.
Thanks,
Pobster
Comment #17
pobster commentedApologies, tomorrow turned into the day after... Etc... Life often gets in the way of fulfilling promises...
Anyways, let me know your thoughts on this patch - it doesn't include the original patch from http://drupal.org/node/361150#comment-3270038 which will need to be applied first.
Pobster
Comment #18
gregglesI think needs review is the right status here.
I've combined them which fixes some offsets. And removing the needs tests tag since it's got tests.
Comment #20
gregglesSetting back to needs review so testbot will test my reroll patch.
Comment #21
pobster commentedJust to point out that *maybe* it would be nice to report the query parameters in the displayed message, I didn't bother but well... Just sayin'
$this->assertEqual($this->getUrl(), url($redirect, array('absolute' => TRUE) + $options), t('Redirected from %request to %redirect.', array('%request' => $request, '%redirect' => $redirect)));Maybe test if it's populated, implode it or
print_r($options, TRUE);dunno... Wasn't my intention to make it pretty, just make it work!Also, I did initially write a 'fail' test to show that it does fail if the setting is FALSE but I removed it as I didn't really think it that relevant. If you want me to put it back in - please give me a shout!
Pobster
edit: Also I'm sure it was obvious but I did purposefully set that status as I knew my patch would fail testing due to not having the original patch applied to it!
Comment #22
kim.peppersubscribing
Comment #23
pobster commentedHmmm any idea why testbot is taking so long?
We're successfully using this on the Economist site right now!
Thanks,
Pobster
Comment #24
asak commented+1 - works like a charm.
Comment #25
YK85 commented+1 subscribing
Comment #26
doublejosh commentedZoinks, I really really need this too!
Comment #27
doublejosh commentedApplied patch 361150 with full success.
Comment #28
gregglesReroll, still applies.
Comment #29
pobster commentedThe patch is missing the simpletest?
Pobster
Comment #30
gregglesSorry, I forgot about those. Care to re-roll?
Comment #31
pobster commentedYeah no worries, I'll do it tomorrow morning... Which... Is only about six hours from now... I should probably go to bed!
Thanks,
Pobster
Comment #32
doublejosh commentedReping about re-rolling.
I, for one, use this patch on production.
Comment #33
tangent commentedDoes the patch still need work? This issue is becoming ancient.
Comment #34
Anonymous (not verified) commentedplease commit!
Comment #35
Anonymous (not verified) commentedComment #37
gregglesIt doesn't apply, so needs a reroll before it can be committed.
Comment #38
shalompisteuo commentedI will try to reroll this following the instructions I found on this page https://drupal.org/patch/reroll.
Comment #40
shalompisteuo commentedComment #41
shalompisteuo commentedComment #42
gregglesthanks shalomPisteuo for the reroll. The patch in #40 is a bit larger than the one from #28. It looks like you added some code related to a test, which is great! It would be good to describe that change to help others know about it :)
Comment #43
shalompisteuo commentedWhere do you want me to put the description of the changes? In a code comment or here on this thread?
Comment #44
gregglesIn a comment here on this thread. I think the commenting in the patch is fine.
Comment #45
shalompisteuo commentedSure no problem. My contribution was only a re-roll per comment #28. The tests came from pobster in comment #17. The beautiful fix I believe came from greggles. I hope this helps to clarify the contribution. Any chance on getting this merged?