When I have an existing FileField configured with File Aliases, it works great for the most part. My problem is if I want to remove or delete a file from a FileField, the File Alias remains. If I subsequently upload a new file that is configured the same way to replace the old, the File Alias gets an ugly suffix like _0 or _1 appended to it.

It'd be great if when a file is removed from a FileField, the corresponding File Alias is also removed.

CommentFileSizeAuthor
#14 file_aliases-removal-841044-11.patch5.37 KBtommyk
#12 file_aliases-removal-841044-8.patch5.27 KBdanielphenry
#7 file_aliases-removal-841044-8.patch5.27 KBtommyk
#4 file_aliases.patch5.63 KBdanielphenry

Comments

SaxxIng’s picture

SaxxIng commented
Category: feature » bug

Same problem to me to. And I think this is a bug because the new alias doesn't point correctly to the file (page not found).
Hope to be helpful if someone needs more informations or tests (after a patch).
Saxx

alex.skrypnyk’s picture

alex.skrypnyk
he/him
Primary language English
Location Melbourne
commented

subscribe

danielphenry’s picture

danielphenry commented

Also Seeing this issue.

danielphenry’s picture

danielphenry commented
Status: Active » Needs review
StatusFileSize
new file_aliases.patch5.63 KB

So I'm new to this patch thing so may not be updating this properly but here is my proposed solution. The behavior is:
1. If you replace the file with one of the same name - the alias will be updated and appear the same from the outside.
2. If you upload a differently named file and no alias exists with that name a new alias will be created and the other deleted.
3. If you upload a differently named file and an alias already exists by that name (from a node or another file having already taken it) the alias will be appended with a number as was the original behavior.

This is based on the release version 1.1

tommyk’s picture

tommyk commented

I could not apply the patch because you need to create it relative(?) to the module directory. (I don't use a "contrib" directory on this site.) I believe the first line in the patch needs to say diff --git a/file_aliases.module b/file_aliases.module, etc.

I'm eager to try it out, though!

tommyk’s picture

tommyk commented
Status: Needs review » Needs work
tommyk’s picture

tommyk commented
Version: 6.x-1.1 » 6.x-1.x-dev
Status: Needs work » Needs review
StatusFileSize
new file_aliases-removal-841044-8.patch5.27 KB

I recreated the patch with Git against the master branch of 6.x.

I've tested scenario 1 from the list in comment #4 and it works as expected.

tommyk’s picture

tommyk commented

Removing a file and saving the node also successfully deletes the alias for the removed file.

nodiac’s picture

nodiac commented

The patch applies! It was awesome! This is at an LA Drupal meetup and we just learned how to apply patches.

tommyk’s picture

tommyk commented
Status: Needs review » Needs work

When using the patch I've noticed my logs filling up with:

Invalid argument supplied for foreach() in /…/sites/all/modules/file_aliases/file_aliases.module on line 161.

Offending section:

      // If the old ones can not be matched delete the old alias. If it does
      // match ignore.
      foreach ($old_files['#files'] as $old_file) {
        foreach($files['#files'] as $file) {
          if ($old_file['field']['filename'] == $file['field']['filename']) {
            $match = TRUE;
            break;
          }
        }
        if (!$match) {
          $path_old = 'filefield_paths/alias/' . $old_file['field']['fid'];
          $alias_old = drupal_get_path_alias($path_old);
          path_set_alias(NULL, $alias_old);
        }
      }
      break;

I don't understand enough to debug this, but maybe someone can help.

danielphenry’s picture

danielphenry commented
Status: Needs work » Needs review

Just add

if (isset($old_files) && isset($old_files['#files'])) {
// foreach statement
}

It will get rid of the notice. I had made the bad assumption that the files were always set.

danielphenry’s picture

danielphenry commented
StatusFileSize
new file_aliases-removal-841044-8.patch5.27 KB

Here is a patch file with a couple of checks in it to prevent warnings in the above mentioned code (comment #10)

tommyk’s picture

tommyk commented
Status: Needs review » Needs work

The last attached patch is the same file as the patch posted in comment #7. I'm not sure how that happened.

tommyk’s picture

tommyk commented
StatusFileSize
new file_aliases-removal-841044-11.patch5.37 KB

The attached patch is updated with the advice from #11.

Still not sure what happened with the patch from #12.

tommyk’s picture

tommyk commented
Status: Needs work » Needs review
tommyk’s picture

tommyk commented
Status: Needs review » Needs work

After some testing today, I have found that the patch in #14 breaks the "Display alias" functionality, where the file alias will be displayed instead of the file when the box is checked.

I don't know what part of the code affects that functionality, so I probably won't be much help on this issue at this point.

koshi’s picture

koshi commented

Version 7.x-1.x-dev is also affected by this bug. I think this module should have something like "Check integrity" button on the configuration page. It should find and remove broken (lost) aliases. You can obtain lost aliases if you delete nodes when this module is temporarily disabled. So we need a tool to fix everything when the module become enabled again.

neRok’s picture

neRok commented

I have made a patch to fix a bunch of issues with File Aliases module, including this issue, in the following issue.
#1896326: Combined patch for all known issues in D7 branch

Sorry- actually for D7, didnt notice.

webservant316’s picture

webservant316 commented

I installed the patch at #14 and I get the same error in #16 that 'display alias' stops working. However, worse the URL alias doesn't get removed if I use the delete file button or delete node button. So when attaching a file by the same name the URL alias module adds '_0' thinking the file is still there. The file is actually deleted but the alias remains. Lastly since the alias is still there but the file is not I get a WSOD when trying to access the alias path after the file is delete.

Others say above that this is working. Wonder what I am doing wrong?

webservant316’s picture

webservant316 commented

after studying the patch in #14 I am confused about two things....

1. How does this patch help to delete the unused aliases? It appears to try to reuse aliases, but the correct action in the case of deleting a node or deleting a node attachment is to delete the file and also delete the file alias. Where is the file alias getting deleted in those two cases? If the alias is deleted then then the url alias module will not add '_0' thinking that a file by the alias already exists.

2. Line 116 in the #14 patch adds a 'break;'. Seems like if this patch is properly applied that the following 22 lines in the case statement will never get executed. That cannot be right. Are these the lines responsible for displaying the aliases path to the file on the node?

Seems like the patch needs to add cases to 'delete' and 'update' in function 'file_aliases_nodeapi()'. In the case of 'delete' we need to 'delete' all the file aliases associated with the node. In the case of 'update' keep it simple and just delete and recreate all the file aliases associated with the node.

webservant316’s picture

webservant316 commented

This module could be very useful, but the problem in this issue is a show stopper for me. I will keep watching this queue to see if fixes are made. Since my need was simply to provide an alias in one very specific case I was able to create an .htaccess rewrite rule in 5 minutes versus debugging this module.

Here is the line of code I added to my Drupal .htaccess file....

RewriteRule ^(.*)/CCR$ /sites/default/files/userupload/homepage/$1/CCR.pdf [L,R=302]

The $1 is the 'username' that created a single 'homepage' node with a single file field attachment defined to put the attachment in the location above.

deciphered’s picture

deciphered commented
Issue summary: View changes
Status: Needs work » Closed (won't fix)

The Drupal 6 version of this module will not be receiving any more support.