Support from Acquia helps fund testing for Drupal Acquia logo

Comments

acrollet’s picture

Status: Active » Needs review
FileSize
2.22 KB

Patch attached - I see this command as being very handy for doing quick & dirty imports for many redirects. Ate my own dogfood and used it to add about 100 redirects that I had in a CSV file. Here's a script example:

for i in `cat ~/Downloads/redirects_to_blog.csv`
do 
  source=$(echo $i|awk -F, '{print $3}')
  dest=$(echo $i|awk -F, '{print $4}')
  drush add-redirect "${source}" "${dest}" 302
done
AaronBauman’s picture

Status: Needs review » Reviewed & tested by the community

works as advertised, very straightforward patch, and very helpful; thanks.

moskito’s picture

Very useful. Patch still working. Should be committed.

mvc’s picture

i was just about to write this patch myself to import ~100 aliases. thanks, acrollet!

one tiny suggestion: make the default option 0, which will use whatever default redirection option is configured at admin/config/search/redirect/settings. trivial new patch attached.

AaronBauman’s picture

#4 works as advertised, still
RTBC++

This is the oldest RTBC issue in the queue.
Can we get it in, or at least reviewed by a maintainer?

greggles’s picture

Issue summary: View changes

In general I agree this is RTBC. I tested it out a bit and it worked to create redirects.

If I put on my super-picky-hat, here are things that could be improved:

1. The comment about redirect loops is not a sentence and not capitalized.
2. Several lines are longer than 80 characters
3. The error about redirect hash being in use doesn't have a comment (either both error conditions should have comments or neither should).
4. The $dest variable is an abbreviation that is not a word and it is not consistent with the module's code - throughout the module the "dest" is generally called a redirect

greggles’s picture

Attached patch addresses the nitpicking in #6. I actually kept the $dest variable (though renamed it to $destination) because otherwise there is a string variable $redirect and a newly created $redirect object clobbers it. I guess this is an example of procedural and OO code not mixing well.

Added docblock information for the function and used the optional $defaults second parameter to redirect_object_prepare instead of just overwriting the resulting object properties.

tannerjfco’s picture

Status: Reviewed & tested by the community » Needs work

Patch in #7 seems to break the "code" argument. Using the example command drush add-redirect 'node/1' 'http://google.com' 302
Adds the redirect, but redirect code is always the Default (301) regardless of what code is entered in the drush command for me.

Patch in #4 works as expected with the example command.

greggles’s picture

Perhaps it should be using status_code as the arry key instead of redirect_object_prepare?

greggles’s picture

Status: Needs work » Needs review
FileSize
2.5 KB

Yep, that's how it's used in redirect.admin.inc

tannerjfco’s picture

Status: Needs review » Reviewed & tested by the community

#10 works as expected for me!

Dave Reid’s picture

Status: Reviewed & tested by the community » Needs work
  1. +++ b/redirect.drush.inc
    @@ -19,11 +20,61 @@ function redirect_drush_command() {
    +    drush_set_error('redirect', t('You are attempting to redirect the page to itself. This would result in an infinite loop.'));
    

    Should use "return drush_set_error(...);" here.

  2. +++ b/redirect.drush.inc
    @@ -19,11 +20,61 @@ function redirect_drush_command() {
    +      drush_set_error('redirect', t('The source path %source is already being redirected to %redirect.', array('%source' => redirect_url($redirect->source, $redirect->source_options), '%redirect' => redirect_url($existing->redirect))));
    

    Same here.

  3. +++ b/redirect.drush.inc
    @@ -19,11 +20,61 @@ function redirect_drush_command() {
    +  if (!drush_get_error()) {
    

    Then there's no need for this. Simpilfied!

acrosman’s picture

An updated patch with the suggested improvements.

acrosman’s picture

Status: Needs work » Needs review
mvc’s picture

Status: Needs review » Reviewed & tested by the community

looks good here, acrosman

ivan_pinatti’s picture

Hi,

I used the patch #13 last week for ~70 redirects and worked like a charm. Do you guys have any expectation date to commit it?

One thing that I think that could be very useful, add a -f flag, so it can overwrite a existent redirect with a new one.

Thanks all.

Regards,

ivan_pinatti’s picture

joseph.olstad’s picture

looks promising, looking for a language parameter

joseph.olstad’s picture

Ok, here's a newer patch that supports the language parameter instead of just default "language_undefined"

language is needed especially for multilingual or bilingual sites when redirecting internal paths.

acrosman’s picture

Status: Reviewed & tested by the community » Needs review

I think a language code makes a lot of sense, but probably as an optional parameter at the end of the command. Seems likely that it's the least common use case compared to the other parameters.

mvc’s picture

I agree that the language parameter should be optional, and that the simplest way to do that would be to put it last.

Adding a -f flag would be nice but shouldn't block this patch.

jfhovinne’s picture

Updated patch with optional language and status code.

jfhovinne’s picture

Here is the previous patch with default language value fixed.

joseph.olstad’s picture

Status: Needs review » Reviewed & tested by the community

Nice work @jfhovinne ,

RTBC patch 23

pifagor’s picture

RTBC

alex_optim’s picture

Nice work. +1

pifagor’s picture

  • pifagor committed 501c22f on 7.x-2.x authored by jfhovinne
    Issue #1301594 by greggles, jfhovinne, mvc, acrosman, joseph.olstad,...

  • pifagor committed 99bc3f7 on 7.x-1.x
    Issue #1301594 by greggles, jfhovinne, mvc, acrosman, joseph.olstad,...
pifagor’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.