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
Needs review
1.0
Miscellaneous
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
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.