Contrib.social

Removing file_field files from a cloned node changes the field_field path with a token [node:nid] stored in the original node

Open on Drupal.org →
Created on 4 May 2021, over 3 years ago
Updated 31 January 2023, almost 2 years ago

The problem observed was the filefield_paths in cloned nodes would randomly lose connection with the files they were supposed to point to. So we concluded there was some funky interaction between the modules node_clone and filefield_paths. We use the token [node:nid] in our filefield_path definition. So we thought we solved the problem whenever we cloned a node we always performed a SAVE or SAVE-AND-CONTINUE so that filefield_paths would have an opportunity to have access to the cloned node ID. When you first clone a node the node ID in the URL is the source node, not the cloned node.

However, that little trick of CLONE then immediately SAVE is not working. The problem runs deeper and maybe multi-factored.

This is the latest major problem demonstrated.

1. Create a node with a file field type and define a filefield_path which uses the [node:nid] token. GOOD.

2. Clone the node. GOOD.

3. Observe that the cloned filefield_paths are currently pointing back to the source node. OKAY I GUESS. Though what would happen if we deleted the files at this point? Seems like it would delete the files from the source node. That would be bad which is why we always SAVE before doing anything after a CLONE.

4. So save the node. GOOD.

5. Observe that the cloned filefield_path is now pointing to a path with the cloned [node:nid]. GOOD.

6. Now remove the file from the cloned node. GOOD.

7. Observe that the filefield_path in the source node has changed and is now actually pointing to the cloned [node:nid]. BAD. Wild. How does that happen?

This is a major problem for us. Hoping for quick help.

Jeff

🐛 Bug report
Status

Needs review

Version

1.0

Component

Miscellaneous

Created by

🇺🇸United States webservant316

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    🇳🇱Netherlands megachriz

    I ran in this problem again for an other D7 site lately and noticed that I had written a patch for it before! Lovely.

    But this time I also ran into a similar issue as @swms, though in my case it was about the "Display" field specifically.

    Hopefully this new patch fixes the issue better.

  • Comment almost 2 years ago →
    🇳🇱Netherlands megachriz
  • Comment 3 months ago →
    🇺🇸United States philsward

    I'm going to say that #6 needs some work.

    I honestly don't know if it works (yet) because I'm writing this AFTER finding the new Clone Files option.

    But...

    If the patch is applied and the option is set to No (the default option after applying the patch), presumably, the patch doesn't address the initial shortcomings of the core of the issue.

    If a node is cloned for example and has images, the images are "moved" from the original to the clone on saving the clone.

    If the original node is then edited and saved, all of the images "move" from the clone back to the original.

    Ideally, the option of "No" should take into consideration any files and then erase all references to those files on clone save instead of carrying them over to the clone for the two nodes to then play tug-of-war on which one get's to house the images.

    I'm using filefield_paths with "active updating" turned on which might be part of the problem of the tug-of-war, however the cloning needs to do a better job of dealing with existing files at the basis.

    Unfortunately this probably won't get a proper fix given the EoL of D7, but these comments might help if node_clone gets ported to Backdrop or YAD7 or another startup flavor after the EoL in 2025.

  • Comment 3 months ago →
    🇳🇱Netherlands megachriz

    If the patch is applied and the option is set to No (the default option after applying the patch), presumably, the patch doesn't address the initial shortcomings of the core of the issue.

    Correct. It makes sure that the default behavior is that files are not copied. Only when [node:nid] (or an other node specific value) is used, you may want to clone the files too. If I'm correct, the [node:nid] token is only available when Filefield Paths is installed. So this issue only becomes a 'bug' when a particular other module is installed. Therefore I think that cloning files should be optional and off by default.

  • Comment about 1 month ago →
    🇺🇸United States philsward

    Therefore I think that cloning files should be optional and off by default.

    Agreed, however, how can we deal with the presence of fielfield_paths which I believe is the offending culprit for the majority of use-cases?

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024