Symphony.

A new extension, "Field : Multilingual File Upload" is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

About

This is a multilingual version of the classic upload field. It works the same way as a single upload field, but supports multiple languages, the same way as Multilingual text. It offers on demand unique file names and outputs to Frontend the filename for current Frontend language code.

Download from Github.

Hi Vlad, thanks a lot for coding this field. I'm having some strange issues: in a production website it suddenly stopped working, no matter what file I try to upload, and even when I do not specify a file (the field is not required), it throws an error:

en: A file with the name already exists in /workspace/images. Please rename the file first, or choose another.

What is really odd is that it used to work, because I have successfully uploaded files until last week. I tried updating to the latest version of both the field and the fronted localization and even installed it locally on a 2.2.5 fresh install and still get that error.

while doing some debugging I have noticed that the $data array that the checkPostFieldData function receives is not a named array (here is a var dump of one of the two languages):

array(5) { [0]=> string(12) "IMG_0098.JPG" [1]=> string(10) "image/jpeg" [2]=> string(36) "/Applications/MAMP/tmp/php/phpu5nhRr" [3]=> int(0) [4]=> int(142482) } 

whereas normally a file upload field has an array with named keys:

array(5) { ["name"]=> string(13) "Immag0004.jpg" ["type"]=> string(10) "image/jpeg" ["tmp_name"]=> string(36) "/Applications/MAMP/tmp/php/phpnoK6W8" ["error"]=> int(0) ["size"]=> int(164220) }

so I believe that _getUniqueFilename function is not executed and also the checkPostFieldData of the parent object (the file field.upload class) throws the error while trying to retrieve the $data['name'] value.

am I missing something?

thanks a lot.

Ps. on a side note, in order to make the field work I had to comment line 22 of multilingual_upload.content.js (check if MultilingualField is already defined)

I'll look into it. It sounds oddly familiar. I know about the issue and I thought I fixed it.

Ps. on a side note, in order to make the field work I had to comment line 22 of multilingual_upload.content.js (check if MultilingualField is already defined)

A good samaritan helped me with the JS for all multilingual_* fields. These changes will eliminate the conflict with multilingual_field.

Stay tuned.

Thank man, for now I reverted to two separate fields, but left the multilanguage fields hidden in my sections (by commenting out the displayPublishPanel function), so as soon as we find a solution I'll put them back.

Please let me know if you need testing or help with anything!

Field : Multilingual File Upload updated to version 1.2 on 1st of February 2012

• Fixed a bug with array indexes.

@nanymor

Issue should be fixed now. I knew I saw it before. I fixed it in Multilingual Image Upload before.

Great Vlad, I will try it right away, thanks a lot for fixing it!

Hey Vlad, I tested the field and it works good. I have one question: In order to make it work I needed to include the frontend-localisation language class

require_once(EXTENSIONS . '/frontend_localisation/lib/class.FLang.php');

if I don't my frontend horribly throws:

Fatal error: Class 'FLang' not found in [...]/extensions/multilingual_upload_field/fields/field.multilingualupload.php on line 286

I don't know why that is not needed in your setup, but I'm curious because it's happening to me also with other extensions lately...

Also I added a couple fixes/features to the field while testing, so I will probably send you a pull request (when my friend and git-master Bauhouse will teach me how to do it since I'm a complete git-noob):

I added a checkbox in the settings for retrieving the reference lang file if no file in the current language is specified (like the multilingual text field does), fixed the unique file name generation (which I believe now is applied even if the option is disabled) and implemented the javascript fixes as suggested by the good samaritan

Thanks, @nanymor for the pull request. I'll review and integrate the changes.