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
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | interdiff-3212154-4-6.txt | 493 bytes | megachriz |
| #6 | node_clone-clone-files-3212154-6.patch | 3.37 KB | megachriz |
Comments
Comment #2
webservant316 commentedCross posted at filefield_paths https://www.drupal.org/project/filefield_paths/issues/3212156.
Don't know which module is the culprit.
Comment #3
webservant316 commentedComment #4
megachrizI think that I experienced the same issue, also using filefield_paths and also using the [node:nid] token. Though in my case I observed the following:
Step to reproduce
Now on both node 1 and node 2, the file's path is /sites/default/files/2/foo.jpg. Inspecting the nodes with the devel module revealed that both node 1 and node 2 were referencing the exact same file entity. From both, the file ID was 1.
So my conclusion is that when cloning a node, any files on that node aren't automatically cloned too.
I then disabled filefield_paths and I could produce the same behavior. Now both node 3 and 4 were referencing a file with ID 2. But maybe there it is perhaps less of an issue that a file entity is shared between two nodes? Because the file remains on node 3 when deleting it on node 4.
Patch
In the attached patch I added an option for cloning any files that are on a node too. I implemented it as a global setting, but other modules can use the API functions in case cloning files should only happen in specific situations. The added API functions are:
_clone_files(): loops through all fields of type 'file' and 'image' and clones all files on it._clone_files_for_field(): clones all files for one specific field._clone_file(): clones a single file.If I now redo the steps from the scenario above, the result is:
Comment #5
swms commentedI had the same problem as MegaChriz and the Patch in #4 works for me.
A good addition would be if the ALT/Titel fields of the image would also be cloned...
Comment #6
megachrizI 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 #7
megachrizComment #8
philsward commentedI'm going to say that #6 needs some work.
I honestly don't know if it works (yet) because I'm writing this after cloning a node and THEN finding the new "Clone Files" option added from the patch.
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 #9
megachrizCorrect. 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 #10
philsward commentedAgreed, however, how can we deal with the presence of fielfield_paths which I believe is the offending culprit for the majority of use-cases? That said... It is D7... Outside of ports to Backdrop or other forks, this doesn't really matter anymore. It would at least be nice to see it included in a final stable release though.