Hi there,

I was troubleshooting an issue on one of my sites recently and realized that revisions were the culprit.

I had noticed that after attaching a file to a node (via the regular file field), that file never gets deleted from the server on my site. I remove it from the node, save that change, but I can see the file is still on the server.

This was causing major issues because it makes replacing files very difficult. When a user tries to attach a replacement/updated file, the file name has the "_0" or "_1" suffixed to it (since the original file is still on the server and that makes the name a duplicate). That means that the user then either has links pointing to the previous version of the file (which is still on the server, but is outdated) or the user would need to find all links to the file and edit each one to match the new file name/url. It's a total mess.

I really do understand why the decision would have been made for revisions to keep old files on the server (rather than just keeping versions of the node content), but if replacing files is impossible when revisions are enabled, could we consider implementing an option via configuration settings, per content type or maybe site-wide, to choose whether attached files are also versioned? I think it's important to be able to choose whether that behavior should extend to attached files since the "original file URL not matching the updated file" is not a problem versioned nodes have.

Does this make sense? Sometimes it's hard to explain things without showing... :-)

Otherwise, as it stands, it seems the options are:

  • have revisions enabled for your node content *and* make it so files could never be deleted from your server on the user end (which, again, makes file replacements difficult, since a newly attached file that's a replacement with the same name gets a different url ("_0" or "_1" suffixed at the end) and have to update all links to point to new file) OR
  • do not have revisions for files or node content.

It would be great to choose just to have revisioning on the node content and not attached files!

Comments

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Version: 7.x-dev » 8.x-dev

Feature requests need to be placed in the current developing version.

HongPong’s picture

HongPong CreditAttribution: HongPong commented

This is confusing to end users who expect files to disappear from the server when they are removed, if any 7.x contrib module would be available to get around this it would really help. (additionally it appears sites may delete files on cron rather than instantly.)
See related 6 & 7:
http://drupal.stackexchange.com/questions/47967/files-attached-to-nodes-...
http://stackoverflow.com/questions/8771001/deleting-a-file-from-a-node-i...
http://stackoverflow.com/questions/2101754/drupal-filefield-remove-file-...

ditcheva’s picture

ditcheva CreditAttribution: ditcheva commented

@HongPong, I've also been told that for some the issue is that the documents just get 'marked' for deletion, but are not actually deleted until a cron run. However, when revisions are enabled, the issue is that they do not get deleted at all.... ever. I have documents that are months/years old now on my site, that have been replaced, despite hourly cron runs. And again -- the biggest issue with this is the conflicting urls and the need to modify each pointing link to the new documents when you re-upload if you don't want your links to be pointing to the outdated version. :-((((

ditcheva’s picture

ditcheva CreditAttribution: ditcheva commented
Issue summary: View changes

Clarified language a little

afoster’s picture

afoster CreditAttribution: afoster commented

For anyone looking into this issue if you add the node's revision ID (vid) into the path of the uploaded files this fixed the problem in my project.

jelo’s picture

jelo CreditAttribution: jelo commented

This issue is related to this one: https://www.drupal.org/node/1999646

I actually proposed a different solution in the other thread that files belonging to revisions should by default be renamed and moved to a private file location. This would solve the issue reported by ditcheva with file name problems (which is one issue I have as well) plus the usability issue that users might accidentally use an updated file with a direct link, despite the current revision having a new file attached to it.

ditcheva’s picture

ditcheva CreditAttribution: ditcheva commented

I really like your approach, @jelo!

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

oknate’s picture

oknate
Location Greater New York City Area
CreditAttribution: oknate as a volunteer and commented
Version: 8.4.x-dev » 8.6.x-dev

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.