I have successfully used the EE3 FilePicker service in Ansel to create a button that selects a file. In my own JavaScript (ee()->cp->add_to_foot
), I use the following successfully to override the default callback (which appears to be for the file field?) and snag the file for my own purposes to resize it and add it to the Ansel field type:
$('.myButton').FilePicker({
callback: function(file, references) {
// do stuff with the file here
}
});
This seems to work fine. However, in another add-on I’ve been working on, I use the same method, create a button with the FilePicker service and then use my own callback method. For reasons that are unclear to me, my FilePicker method is being overridden by the default file field callback. There are only two ways I have found to make sure my callback is the one that runs, one is to use a timeout:
setTimeout(function() {
$('.myButton').FilePicker({
callback: function(file, references) {
// do stuff with the file here
}
});
}, 1000);
This is obviously not a reliable way to make sure my callback is the one run. But it does indicate that some JS is being loaded and run after mine in the sequence and overriding my callback. By setting a timeout, I am able to override it instead.
The other way is as follows:
$picker = ee('CP/FilePicker')->make()
$btn = $picker->getLink(lang('add_share_image'));
$btn->asThumbs();
$btn->enableUploads();
$btn = $btn->render();
$btn = str_replace(' filepicker', '', $btn);
As you can see, I’m stripping the filepicker class off the button being output. Whatever JS is hijacking my callback seems to bind to the filepicker
class. The button seems otherwise functional and non-the-worse for wear.
It is odd to me that this method has been working for Ansel but not my new add-on. It is entirely possible that my methods instantiating an Ansel field take just long enough that whatever is happening in EE to set the callback runs first than my Ansel field methods set the callback after that happens. Whereas on my new, simpler add-on that only has a little bit of JS it runs so quickly that it runs first and EE’s callback overrides it.
In any event, I need a way to ensure that my callback methods are the one that runs.
Derek indicated that it would be expected that the HTML generated with the FilePicker service would have a JS callback to run. Obviously, actually brining up the modal to chose a file is core behavior, but it is unclear to me how, as a add-on developer, the included callback methods for the file field would ever be relevant to me at all but I may be missing something. From my perspective, once a file has been chosen, the file should be handed over to me to do something with. I should run the callback.
I’m not sure I totally understand the issue here, but I’ll chime in with my 2 cents. I was trying to do the same thing and actually had a hell of a time getting a file field to work. Getting the initial selector buttons and stuff to render on the page was easy, but getting all the buttons to work was not straight forward, even with the callback documentation. After working with it a bit I feel like it is currently very overly complicated to get a file selector field to render in an add-on. I don’t feel like I need to be writing custom callbacks and such, it should just work for me. So, I made this: https://github.com/litzinger/file-field. 2 lines of code and it renders a file field with all the JS necessary to make it work. IMO this is how the output of the core code should work, it shouldn’t require as many steps as it currently does. The FilePicker service should create everything necessary to render a fully functional file field with a single method call. If I was using it wrong I’d love to get some direction on how to do it right.
TJ, the file name is added to a hidden field, so saving my form saves the selected image just like a normal file field on a publish page (assuming you save your POST data correctly).
I guess I can see the need for the custom callback if you have other actions to perform, but for the act of just picking a file and saving it, the service should be able to do that with a 1 liner… in an ideal world 😊
Granted, what we have in EE3 is miles beyond what was there in EE2, so I couldn’t complain too much, but I think more could be done.
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.