This issue has also been posted in the upload_path queue: #362544: D6 Problem on multilingual sites (interaction with i18nsync)

When using uploadpath set to [nid]/[yyyy]-[mm] on a multilingual Drupal setup I can upload a file to a node, however when I want to provide a translation of this node (hence creating a new node containing the translation) I can upload a file but I invariably get the following PHP error:

Fatal error: Cannot use object of type stdClass as array in C:\xampp\htdocs\sites\all\modules\uploadpath\uploadpath.module on line 36

This appears to be within uploadpath_nodeapi() but may emanate from the way i18n manages $node->files.

When looking in the error logs I eventually stumble across a duplicate warning in another module:

Duplicate entry '9-3' for key 1 query: INSERT INTO upload (fid, nid, vid, list, description, weight) VALUES (3, 7, 9, 1, 'dummyfilename_fr.pdf', 0) in C:\xampp\htdocs\sites\all\modules\i18n\i18nsync\i18nsync.module on line 128.

This in turn points to i18nsync_nodeapi() in the i18nsync module (which is part of i18n).

As I understand this, the i18nsync module tries to link the attachment to the same file identifier (fid = 3) which the database scheme apparently does not allow.

This is strange, since the "Synchronize translations" options in the "Workflow" settings of the Page content type have no tick next to "attachments". I am not sure which module is the culprit.

Could somebody shed some light on this issue and help in finding a fix?.

Thanks in advance!

Olivier

Comments

jose reyero’s picture

jose reyero commented
Status: Active » Closed (duplicate)
ShutterFreak’s picture

ShutterFreak commented

Which is the original issue this is a duplicate for?

courtney’s picture

courtney commented

Hi,

I'm seeing this exact same issue. When creating a new translation that has an attachment when the original language node also has an attachment, I get the duplicate entry error:

user warning: Duplicate entry '165-118' for key 1 query: INSERT INTO upload (fid, nid, vid, list, description, weight) VALUES (118, 159, 165, 1, 'Albania_Work Plan.pdf', 0) in /var/www/drupalrwi/sites/all/modules/i18n/i18nsync/i18nsync.module on line 194.

This is for:

Drupal 6.14
i18n 6.x-1.2
File attachments in our case are *not* configured to synchronize.

As well, I couldn't find where this was a duplicate? I don't believe this is related to 'upload path' since we do not have this module installed.

Thanks!
Courtney

courtney’s picture

courtney commented
Version: 6.x-1.0-beta6 » 6.x-1.2
Component: Code » Synchronization
Status: Closed (duplicate) » Active

Hi,

Just updated the Version, Component and status of this issue. I tested this again today on a fresh install of Drupal 6.14, with i18n 6.x-1.2. There are no other contributed modules installed, just core and i18n.

With i18n turned off, and the core locale and content translation modules turned on, I can create translations of the page content type and add attachments to each translation without any error.

As soon as i18nsynch is turned on (with nothing set to synchronize), when I add an attachment to a translation when the original node has an attachment, I get the error:

Duplicate entry '8-8' for key 1 query: INSERT INTO upload (fid, nid, vid, list, description, weight) VALUES (8, 8, 8, 1, 'mit.txt', 0) in /var/www/devsummit/sites/all/modules/i18n/i18nsync/i18nsync.module on line 194.

I looked at the code (starting with line 184) and don't see a way that it's even checking to see if file attachments are set to synchronize.

Thanks for any help you can provide!

-Courtney

jose reyero’s picture

jose reyero commented
Status: Active » Fixed

I've been reviewing the i18nsync files part and there were multiple issues with new files, all they should be fixed now:
- Checking for 'files' in fields list before synchronizing anythin.
- Correctly checking whether a file is new ($file->new)
- Reloading files before synchronizing so they get the right parameters (fid)

I think all of them had some part in this issue.

I haven't tried with upload_path though, so please confirm this is fixed, reopen if not.

courtney’s picture

courtney commented

Thanks! This is fixed for me in the Dec 1 6.x-1.x-dev version. We're not using upload_path, though, so haven't tested that.

Status: Fixed » Closed (fixed)

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