From http://drupal.org/node/1420700#comment-5575506

Also with Active updating - when u edit node in English - it's save as node 101, now when u edit the same node in German language it's saves as 102 (it's correct cause different languages are saved as a new node) but it copy all images from 101 to 102 and u can't properly see node 101 as a user.

When a node is a translation, it should COPY images to new folder only.

 

My response from http://drupal.org/node/1420700#comment-5577070

As for the translation issue, I'm not entirely certain how to approach that, I don't think it's FFPs responsibility to copy the file, if anything that should/could possibly be handled by one of the many translation based modules. However what FFP should do I can't say for certain. Quite possibly I could include the 'Active updating' checkbox on the Entity itself so that it could be checked/unchecked as necessary.

Comments

batigol’s picture

I would like to hear other ideas from File Path users. Actually fixing this behavior is crucial in multilingual sites (especially if you want file order).

batigol’s picture

Without active updating, everything works quite well - you can't use [node:title] token cause when you update node title, path to file won't change, but simply [node:nid] works fine ([node:language] is quite useful too, for i18n sites).

Again, the way File Paths works now (WITHOUT active updating and WITH [node:nid] as a folder): If you have node in EN (nid-100 for example) and you add some files to it, when translating to FR (nid-101) with SAME files (without adding new files to translation) File Paths won't create a new folder (cause it uses all files from previously created node, nid-100). However when you add some new images or change those you have used in EN node, File Paths will create new folder (nid-101) and put there ONLY new or modified (replaced) files.

This is dangerous behavior for some other modules, like colorbox... Cause even in FR language node (nid-101) links inside node are connected with other node folder (nid-100). It could be disorienting.

The good thing is when you delete the first (EN nid-100) node, File Paths keeps it's folder with all files used by translated node (FR, nid-101). The bad thing is, it leave empty folders (when you delete both nodes).

I'm sure @Deciphered experience is unquestioned and with other ppl advices it will be 'fixed' (basic functionality of this module is preserve). As I said before I would like to hear other ppl opinion in this particular case. There is almost 25 thousands sites using this module. I think it's one of basic drupal modules you will use on almost every major site. So please give us feedback how you are seeing File Paths working.

I think that copying all files from basic folder to translated node folder would fix this problem. Deleting default language node would not impact translated one, and vice versa. Active updating change file path in drupal database. In file_usage table item appear twice so maybe in file_menage table it should appear twice too with proper path off course.

Deciphered’s picture

Again, I disagree with the 'copying all files' approach, that is not for File (Field) Paths to deal with but for a module that focuses on Field management on translated entities. However neither do I think File (Field) Paths should be dealing with the second node at all, if it is it means that it's getting the incorrect data passed to it during hook_entity_update().

I will try to get some time to run some tests and see what I can come up with.

kerios83’s picture

I see you guys tested this module thoroughly. I don't have much to add besides 'Active Update' need some love. Copying files need twice as much disc space so actually pointing all images and files to one folder is a good thing. If english language is your default, all images should be stored in english nodes, and only if you delete it, they should be moved to translated one. This however could impact other modules usability so it need some tests. They simply should get image path AFTER Pathauto/Transliteration/ File Paths modules do made changes on it.

By the way, very good work on beta3 but I receive this message:

Notice: Trying to get property of non-object in views_handler_field_user_picture->render() (line 63 of C:\xampp\htdocs\drupal\sites\all\modules\views\modules\user\views_handler_field_user_picture.inc).

all the time.

Deciphered’s picture

Hi kerios83,

Thanks for your input.

As for your error meesage, can you open a new issue with the details and specifics on your setup so I can attempt to reproduce and fix the issue?

Cheers,
Deciphered.

kerios83’s picture

edited. If somebody feel aggrieved I'm sorry. I was referring to above error I got with File Paths (to not take it too seriously cause of... other issue :) not @batigol opinion.

Deciphered’s picture

@kerios83, you made an issue, there's no need to hiajck this issue, it's quite frankly disgraceful behaviour and completely uncalled for. I suggest you delete your post and apologise to @batigol.

Anonymous’s picture

Issue summary: View changes

[node:original:nid] and... you'll have all files belonging to the original file (when translating the original one). If you put new images in the translation, then it's like a new node (nid is from the translated node, and it copies the images into that new nid).

But... yeah... this is way too daunting. First, nid is not available, only after saving the create node.
There is no automated check if file is new or duplicated from original.
There is no transition from original node's files into translated node files (plus, not duplicating...)

But... this needs thinking... file management on multilingual is way daunting.

kerios83’s picture

Heh try to add marketplace on top of it and it's a disaster :)

Anyway I'm starting a new project so i guess i will test all modules again and see if something got an improvement!

Deciphered’s picture

Status: Active » Closed (works as designed)

I'm inclined to go with my original gut feeling that this is not an issue for File (Field) Paths to deal with, especially given @nmpribeiro's suggestion.