Adding {session} placeholder to ajax upload path ?

[lcollong]

Hi,

According to the tooltip and some threads, only some placeholders are available to specify the ajax uploaded files path ({$my->id}, {date}...) but element placeholder won't be interpreted.

It would be nice to be able to use the {$session->foo.bar} feature. One could set the session variable on form load for example or even using some calc element with ajax on. Depend when the files are saved during the form submit ?

Would it be hard to include it ? Safe enough ?

Thanks,

Laurent

 

[cheesegrits]

Might work. Give it a go.

The issue is that the file is uploaded and moved independently of form submission. As soon as you select the file, it uploads via AJAX, and gets moved to the destination folder at that point, not when the form is submitted. So even if you used your own AJAX mechanism to set a session variable, if they uploaded the file before filling out that element on the form ... it still wouldn't work. It'd be OK if you did it on load.

"One of these days" I'm going to look at modifying the way the AJAX upload works, so it only uploads to a temp dir during the AJAX upload, and moves the file to the destination during submission. Unfortunately, it's not going to be trivial. I looked at this a while back, and decided it was too much work.

-- hugh

 

[lcollong]

Did you commit some recent change ? On my less than 10 days old test drive it does not work. I don't see any recent commit on this. Am I wrong ?

Regarding the "timing", yes indeed. The variable has to be set before the form is loaded.
Our initial goal was to have images stored in something like /images/{rowid}/img.1.jpg
But we are facing several problems as the the rowid is not known in case of record creation.

Sounds like the only way to go will be to have a php script running onAfterProcess to rename things both in the file structure and in the related table based on the newly affected id....

Also, just tried to update fabrik using

wget --no-check-certificate https://github.com/Fabrik/fabrik/tarball/master -O - | tar -zx --strip-components 1


and got errors on Fabrik init :

Warning: require(/home/xxxxxxxx/libraries/fabrik/vendor/composer/../guzzlehttp/psr7/src/functions_include.php): failed to open stream: No such file or directory in /home/xxxxxxxxx/libraries/fabrik/vendor/composer/autoload_real.php on line 66

Warning: require(/home/xxxxxxxxxx/libraries/fabrik/vendor/composer/../guzzlehttp/psr7/src/functions_include.php): failed to open stream: No such file or directory in /home/xxxxxxxxxxxxxxxxx/libraries/fabrik/vendor/composer/autoload_real.php on line 66

Fatal error: require(): Failed opening required '/home/xxxxxxxxxxxxx/libraries/fabrik/vendor/composer/../guzzlehttp/psr7/src/functions_include.php' (include_path='.:/usr/local/php5.6/lib/php') in /home/xxxxxxxxxxxxxx/libraries/fabrik/vendor/composer/autoload_real.php on line 66

 

[cheesegrits]

Hmmm, yes, I'm in the middle of updating the Composer vendor library. Aaaaand ... oops ... try again.

https://github.com/Fabrik/fabrik/commit/976ce1a90c40cae556c2ba91ad94b98c6f23bae0

For some reason not all of the new Composer libs included by the AWS lib got committed first time round.

Unfortunately, in order to get the upload element Amazon S3 storage adapter working properly again, I've had to rewrite it to use the new official Amazon SDK, installed with Composer, which adds about 7MB of library files (even though the S3 API is only a tiny part, it needs the whole thing plus all dependencies).

-- hugh

 

[cheesegrits]

You'd have the same problem with {rowid} even if you weren't using AJAX, as file uploading even for regular uploads is done prior to processing and storing the data. It's kind of a chicken and egg thing. We don't want to process and save the form data if the file couldn't be uploaded, as a problem uploading / moving the data needs to fail the submission. But it'd be nice to be able to use the newly created rowid in the location.

It's something I've been meaning to address for a long time, but it's not very high on the priority list atm. One of those things that'll probably only happen if someone needs it bad enough to fund development. It just isn't an issue for enough people to justify me spending days on it on spec.

-- hugh