When I attach a file to a node via webfm, it appears on all translations of the node.

I would like to be able to have English attachments on the English node, French attachments on the French node etc.

What is the best way to do this?

Thanks!

Comments

robmilne’s picture

Status: Active » Postponed

I cannot say, nor do I have the time to investigate. I haven't worked on internationalization for a very long time (drupal 4.6). As always I solicit patches from people who can help out.

nhck’s picture

Status: Postponed » Closed (fixed)

This shouldn't happen with the latest version of i18n anymore.

Claude Cuvelier’s picture

Oh yes it does, I'm afraid. I am unable to link only French attachments to French nodes and only Dutch attachments to Dutch nodes... (I use i18n 6.x-1.7 and WebFM 6.x-2.12.) At first I thought it had something to do with translation synchronizing (Node type > Multilanguage options), but then I discovered that WebFM attachments aren't even among the synchronizable items in the list.
This is such a pity. I absolutely adore WebFM and its possibilities, but I must be able to keep Dutch and French attachments apart in my node translations.
Any ideas on how to achieve this using this great module will be much appreciated!

Claude Cuvelier’s picture

Category: support » bug
Status: Closed (fixed) » Active

(And therefore reopening this issue.)

cgmonroe’s picture

I haven't done a lot of I18n stuff... so I may be off base... I'm also assuming that you are doing real translation by a human and not psuedo translating via Google, et. al.

Isn't each translated node actually a separate node that I18n auto-redirects users to based on language preferences?

If so, you should be able to upload / attach different files to each translated node, since they have different node ids.

Hmm, now I'm wondering if these are different nodes or does Druapal so some sort of language revision magic to keep the same node id and have different text. If it is this, some help in understanding how Drupal is storing /determining what is display would help in seeing if this is possible.

Claude Cuvelier’s picture

Version: 6.x-2.10-rc3 » 6.x-2.12

Yes, every language version (translation) of a node has its individual node number.

I just found out that it appears to depend on when the WebFM attachments are made:

  • if the translated version of the node already exists, then all WebFM attachments made to any language version of the node will appear on all language versions;
  • however, if I make a new node, add the WebFM attachments immediately, and I create the translation afterwards, the translated version contains no attachments and I can attach other files to the translated version than to the original version.

Could anyone help to find out what may be causing this behaviour?

Thanks in advance!

Claude Cuvelier’s picture

Forget about my previous comment. My new "insight-of-the-hour" says that it has nothing to do with when the translations are made, but that the problem is caused by the synchronization settings in the multilanguage options (per content type). If I deselect all fields, I can choose other WebFM attachments per language version of the node. If one or more fields are selected, the WebFM attachments are synchronized between language versions. I will look a bit further into what fields exactly may be causing the problem.

nhck’s picture

Component: Documentation » User interface

Claude Cuvelier,
thank you for reporting this and helping to make webfm better. I came across this myself a couple of days ago, but didn't realize this was a bug. In my opinion we need our own "synchronization" check box - it should read "Synchronize Webfm Attachments". Has anyone done something like it before? I haven't yet been able to find some good documentation on this, but I definitely second this as a bug.

Thank you also for your in depth testing and narrowing this down.

Claude Cuvelier’s picture

Dear nhck,
Thank you for your reaction and for the great module (I absolutely love it).
As far as I can see, it doesn't matter which node field is selected. From the moment one node field is selected, the problem turns up.
It would be great if the module could provide for that possibility. I wasn't sure however if this should be treated as a bug or as a feature request, because there is a work-around: if I deselect all node fields in de "synchronize translations" tab, I can attach different language versions of files to different language versions of nodes.
Thanks again.

cgmonroe’s picture

I have to wonder "who's bug is it?" This really seems like it might be a bug in the code that synchronizes the translation content.

Is this part of I18N? Perhaps there may be some insight to this in the issues of that module? (Report back if you find any!). They may be able to let us know if there is a "hook" or other code that needs to be implemented in WebFM to keep this from happening.

FWIW, WebFM attachments are linked to a specific node id. When a node is loaded with WebFM attached files, they are added to the node object as the webfm_files property (e.g. $node->webfm_files). The "view" part of the equation is added in the nodeapi view case which just checks to see if there is a value in $node->webfm_files.

I suspect that the synchronize function is loading two nodes and then doing some games with their own nodeapi hook that merges two nodes together.

It seems to me that the bug is that the synchronize action should ONLY add field values that hare checked and they should not be adding unrelated node properties to the translated node.

nhck’s picture

Its our bug and I think I have found a simple fix. In my opinion we need to to unset $_POST['attachlist'] in hook_nodeapi after inserting/updating.
The reason is simple: Obviously on synchronizing fields the second node has to be updated as well thus hook_nodeapi is executed. Webfm overwrites the attachments made to the other node because we use $_POST.

This reveals a more serious problem: Why is $_POST used?!

nhck’s picture

Assigned: Unassigned » nhck
Priority: Normal » Major
nhck’s picture

Status: Active » Fixed

Hi there,

I think we have a fix for this in the dev version now. Thanks to all of you.

nhck

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

roball’s picture

Status: Closed (fixed) » Active

Is it possible that this change between releases 6.x-2.16-rc1 and 6.x-2.16 introduced #1361200: Roles with permission "view webfm attachments" can view attached files, but no longer actually download them? I observed it on a site which had I8N (core's "Locale" module) turned on.

roball’s picture

Version: 6.x-2.12 » 6.x-2.16-rc1
nhck’s picture

Status: Active » Closed (fixed)

Thanks roball for pointing this out, but I wouldn't think so. The situation is that the i18n sync module basically reruns the update hook with a different language setting - webfm is called by that hook - still having a certain file in the $POST-array, now attaching it to that node its being called by. The calling node however is just the copy of the original one in a different language. I have changed this in a way that unless its specifically requested through the i18nsync-settings the associated file is cleaned from the post array before rerunning the hook.

See here: http://drupalcode.org/project/webfm.git/commitdiff/af4c79583592690abc7f7...