when you are creating a node... the nid is not known. because drupal doesn't asign you a node until you press save. ok. I can udnerstand it... but when you are editing a node. the node id is in the URI. "/node/xx/edit" Maybe we could use that to upload the files directly to the final folder and not use a temporal folder when editing nodes.
Comments
Comment #1
decipheredWhile you're right, you're also wrong :)
You're right in the case that you're using a token that can't be changed while editing, but what if you are using the [title] token and you change the title of the node during an edit?
While it would be nice to know all the token values so as to not have to use temporary files, this way just works.
Cheers,
Deciphered.
Comment #2
hedac commentedI see... That's why I used nid instead of title. because nid can't change. I guess that would be valid only for nid.
If I use title, what happens with the previously uploaded images? would they move to the new folder also and the previous title folder deleted?
If not.. I don't have a problem using nid, but one limitation is when inserting uploaded images in the textarea. I sometimes use IMCE to insert an imagefield image into the textarea... but I can't insert it before saving the post and images are moved into final directory.
so This idea comes to my mind.... is it possible to change the textarea $content and replace all the paths "files/[nid]" strings (or whatever the path would be) with the final path when saving the post?
Comment #3
decipheredCurrently if you change the source of one of the tokens being used in FileField Paths ([title]) it will only upload the new files to the new location.
A new feature was just introduced into the latest dev build called 'Retroactive changes', which moves and/or renames previously uploaded files to the current FileField Paths settings. This was introduced primarily for people who wanted to re-sort already uploaded files when changing FileField Paths settings or if they where uploaded before installing FileField Paths, but it should also move files if the token source has been modified.
This, however, is just an assumption and has not been tested in any way whatsoever.
You also have to understand that at the current stage, the function processes every single node of the content type you initiate the Retroactive changes on.
I do, however, see the benefit of adding an altered version of that functionality to do what you have mentioned, but my major concerns about the functionality is that it will likely break links, and will require a lot more testing before it should really be used. Edit: #373094: Retroactive like behavior when changing token source
As for the IMCE issue, there is already some functionality in FileField Paths that checks the Body and Teaser fields for references to the unprocessed URLs and corrects them. I have not tested this functionality for a large amount of time as it generally doesn't come up in my use case. It does not, however, process CCK fields.
If this does not appear to be working correctly, I would suggest you create another Issue and I will do what I can to fix/improve it.
Comment #4
hedac commentedThank you very much
it is great the body and teaser check for references to unprocessed URLs.
I've tested it today... it is not working for me.
the text code (using fckeditor) is .../%5Bnid%5D/... not .../[nid]/... maybe that's why it is not detected to replace
Comment #5
decipheredIssue moved to #373735: Replacement of unprocessed URL in Body fails with FCKEditor.
Try to keep separate issues... separate :)