Weekly update – January 10, 2020

[ryan]

I hope you all have had a good start to 2020! Last week's release of the new master ProcessWire version 3.0.148 has gone smoothly, and if you haven't yet upgraded, it's a good time to do so. This week I've been working to finish up the new front-end file upload field called InputfieldFrontendFile, which is part of the LoginRegisterPro module package. I've released beta version 1 of that module in the LoginRegisterPro support board in the downloads topic, so it's ready for download now, as is a new version of LoginRegisterPro to accompany it. Today, I've written up a lot about this module, as well as posted a few screenshots here: 

Front-end file uploads with InputfieldFrontendFile module

I've also got some ProcessWire core updates in progress this week for the dev branch, but this week has gone by so quickly I think I'll have to save those for next week. Thanks for reading and have a great weekend!

[teppo]

Quote

The frontend file Inputfield requires LoginRegisterPro (v3+) and can only be used on the Profile form (not the Registration form).

Out of curiosity, how tight is the coupling between this inputfield and LoginRegisterPro / a specific form in it? ?

I'm working on a project that will require front-end uploads. It's not a huge deal – I can handle that in other ways as well – but just wondering if I could possibly use this new inputfield for those. These uploads would have nothing to do with the LoginRegisterPro module specifically, but I might still find good use for it on this particular project.

[dotnetic]

@teppo for front-end uploads you could also take a look at this example 

which utilizes TusPHP (resumable uploads) and Uppy (a nice uploader widget)

[ryan]

Quote

Out of curiosity, how tight is the coupling between this inputfield and LoginRegisterPro / a specific form in it?

@teppo (and @Robin S who had a similar question): There is coupling from LoginRegisterPro to InputfieldFrontendFile, but there isn't any from InputfieldFrontendFile to LoginRegisterPro. So I think InputfieldFrontendFile can be used for other cases outside of LoginRegisterPro. But for the moment, I've been focused just on the LoginRegisterPro use case, so haven't tried to use it for other things yet. 

The main thing is that for ajax file uploads to work, the system creating and rendering the form behind it (whether ProcessPageEdit, LoginRegisterPro, ProcessProfile, ListerPro, ProcessUser, etc.) needs to recognize an ajax request for a specific field and pass control to it, rather than doing the usual form rendering or processing. Afterwards it also needs to intercept the result and provide an ajax response (like JSON). LoginRegisterPro does this exactly the same way that ProcessPageEdit does (looking for specific HTTP headers), so unless I've forgotten anything, InputfieldFrontendFile would work in PW's admin page editors too. 

InputfieldFrontendFile also uses Pagefiles/Pageimages objects as its value attribute (just like InputfieldFile or InputfieldImage). That's because in ProcessWire, any file has to have an "owner" that can manage files, and of course Page objects (via a dedicated PagefilesManager instance) are what do that in PW, and Pagefiles/Pageimages objects are 1-to-1 with a Page. So that's where the real coupling is, to a Page, and to a Files field (or Images field), rather than to LoginRegisterPro. It's a good fit here because LoginRegisterPro works with User objects, which are just another type of Page. 

What InputfieldFrontendFile can't replace is something like the file upload field in FormBuilder. In that case, the form entries are the "owners", and they are entirely different from Pages and have their own protected file storage and delivery system. Also an entry isn't allowed to exist till a form is submitted, so ajax file uploads wouldn't work there, except potentially on a paginated form after the first pagination.