0

I am using the fieldfield_path module to create a redirect for my files as they come in during a migration (this is so that I can give an original path in the migration, and create a redirect, allowing me to redirect at the apache level from the old url to a new one, but also have extra information in the path that wasn't available from the old site path. The fieldfield path file path is set to publication_documents/pub/[node:field_doc_type_book]/[node:nid] for my book content type public files field.

When I look at my migration messages I see the following message:

Creating redirect from 
private://publication_documents/pub/old/1565/filename.pdf to    
private://publication_documents/pub/book/37544/filename.pdf

Which is what I would expect, the nodeid of the node the file is attached to is 37544. Unfortunately when I actually visit /system/files/publication_documents/pub/old/1565/filename.pdf I get redirected to system/files/publication_documents/pub/book/149678/filename.pdf

Which is a page not found error page. It is a mystery where the number 149678 came from, but I can confirm that the redirect happening is the one actually stored in the redirect table. I've looked through all of the node and revision ids, file ids, etc. that I could think of as possibly being the source of this mystery integer, but have had no luck so far. I removed all the migrated data and ran the migration again, but the integer on the redirect is still the same.

What might be happening? Why is drupal telling me it is creating one redirect, but actually creating another? I suspect it is actually creating the one it is telling me about, but then replacing it with another, but so far, I don't have any information to prove either theory.

I am using the media module, and wonder if that is somehow messing things up. I also have pathauto active.

1 Answer 1

0

It turned out that what was happening is that the old redirects were never being deleted when I rolled back my migrations. When I did a reimport, the source for the redirect already existed so new ones weren't being created. To solve this I implemented hook_node_delete as follows (I need to delete redirects to system/files/publication_documents/{either int or pub}/{the value of a field}/{node id}) :

function MYMODULE_node_delete($node){
    // Delete alias.
    $nid = $node->nid;

    $type = $node->{'field_doc_type_' . $node->type}[LANGUAGE_NONE][0]['value'];
    foreach (array('pub', 'int') as $status) {
        redirect_delete_by_path('system/files/publication_documents/' . $status . '/' . $type . '/' . $nid);
    }
}

This works when the redirects have been created with the current $nid, but this wasn't true for any of the existing redirects in the system, so I wrote remove_redirects.php:

<?php
redirect_delete_by_path('system');

and then I rolled back my entire migration and ran drush scr remove_redirects

This cleared out the existing redirects, so I can run the migration again, and future rollbacks will get rid of the redirects too.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.