Small change to InputfieldFile.js to facilitate front-end HTML5 uploads

[adrian]

Maybe I am going about this the wrong way, but I wanted to make use of the admin image upload features for a front-end form.

The only way I could think of to achieve this was to modify InputfieldFile.js like this:

//var postUrl = $form.attr('action');
var postUrl = '/admin/page/edit/?id=' + $('#Inputfield_id').val();
 

That, together with:

<p id="PageIDIndicator" class="">'.$page->id.'</p>
 

lets everything work as expected. 

I haven't tested thoroughly yet, but I don't think this breaks anything. Of course you can see that my admin is at "admin", rather than the default "processwire". Not sure the easiest way to get this path from within InputfieldFile.js 

There is very likely a better way to do this, but since I want my form action to post to itself, but have the xhr open the page/edit?id= link, I am not sure what it is I guess I could set the action of the form so that it works for the image upload and then override the action for the actual form onsubmit, but that seems hackish too.

Thanks for any suggestions.

[Soma]

I think PW has the config js outputed in head where also the admin path is. I created frontend form example which work with all fields also image upload. Will look for it later maybe its something different.

[Soma]

Maybe this example will help you? http://processwire.com/talk/topic/2089-create-simple-forms-using-api/?p=21226

[adrian]

Thanks Soma,

I changed that modified line to: 

var postUrl = config.urls.admin + 'page/edit/?id=' + $('#Inputfield_id').val();
 

which take cares of variable locations for the admin in different PW installs. 

However, I am not sure if this was all you were hoping I got from that link. I had a look over your example front-end form it is very close to what I am using. However I can't see how your example would work with the HTML5 uploader. 

This code at the end of InputfieldFile.js requires the presence of an element with the #PageIDIndicator, which I don't see in your form code. 

    if (window.File && window.FileList && window.FileReader && $("#PageIDIndicator").size() > 0) {
        InitHTML5();
    } else {
        InitOldSchool();
    }
 

Is there something in your code that I am missing that gets around this requirement?

Can you think of a way that I can avoid the need to edit the postURL in the InputfieldFile.js file?

[Soma]

Yes you're right. The file upload doesn't work for the reason you found out in InputfieldFile.js.

My code example works also with the change you proposed to get the page edit admin url. What I do is add this code to the form too to render a hidden id field.

$form = $modules->get("InputfieldForm");
$form->method = 'post';
$form->action = "./";

$field = $modules->get("InputfieldHidden");
$field->attr("name","id");
$field->value = $editpage->id;
$form->add($field);
 

Together with your change it now works. I think that change would be ok to make that it can be used in such cases. 

I'm not sure if I back then haven't really tried fiel uploads but I thought it was working. Maybe some changes in core or my memory is dusty.

Either way and apart from all that, just because you can doesn't mean you should - regarding all the details and security should be first priority when moving backend functionality to front end. It's not planned/meant to be used like this originally but surely possible if you include all files and configs. But I'm thinking depending on how and where and for what reason you implement it you should be careful and only let really trusted users have access anway. Even myself am not aware of what could go wrong, but I'm sure Ryan could speak a word on that subject.

I'm not sure what you're building and it seems to me you're rebuilding the backend on front-end. Without knowing any details and I'm sure you got your reasons, why not just use the backend admin? Or what doesn't the backend provide that you want to create editing on front-end?

I'm also curious to hear what Ryan thinks about all this.

[adrian]

Hi Soma - thanks for the thoughtful post. I agree that just because you should doesn't mean you should

In this case of what I am working on right now - it is an interactive educational website/app that allows students to enter various parameters, generate graphs and maps, and then produce summary pages reporting on their findings, that will become part of the site content. Things really do need to be done via the front end, not just for aesthetics and user experience, but also because of requirements to perform various unit conversions etc before storing in the DB.

I actually nearly went with your iframe/modal=1 approach, but it still wasn't clean enough for my needs in this case.

Just to clarify - there is no data input/upload allowed on the front-end by guest users, and all registered users must be manually registered, so hopefully things are ok from a security standpoint, even if I don't fully understand all those issues in PW just yet.

I have created similar types of sites before, but never with an off the rack CMS - I have always built my own to fit the exact needs of the project because I never thought there was anything out there that could do what I wanted without mountains of hacking. When I found PW I thought it was time to give it a try. To be honest at some times it has felt like a bit of a struggle, but hopefully it will be worth it in the end. In some cases it has cost me lots of time, but I know it has saved me lots of time too, and the learning process will be invaluable for future sites.

I have some other data heavy sites which I still think will never be a good fit for PW (at least not completely - I think a hybrid approach might work well - content in PW and data in separate tables with custom queries).

I have a couple of much simpler projects coming up very shortly where all the content will be developed by the clients. I am really looking forward to using PW on these and hopefully I'll be back in the realms of 'normal' PW usage and might be able to start helping out here, instead of just asking all the questions

Ryan - would definitely love to hear your thoughts.

PS Antti and Ryan - do you think we could make that change to the postUrl variable in InputfieldFile.js?

[ryan]

Ryan - would definitely love to hear your thoughts.

I think what you are doing with this stuff is fine so long as you understand all the security considerations (and it sounds like you do). This is not unlike what Form Builder is doing. But something like files do require even more consideration. For instance, on a front-end file upload, usually I'd want the uploaded files going into a quarantine area (only accessible by passthru script) rather than web accessible directory. That's why I ultimately made a custom Inputfield type for file uploads in Form Builder, rather than using InputfieldFile. So at least for front-end files, I do think it's better not to use InputfieldFile. Though it sounds like your users are still trusted (not anonymous) so it may be okay in your case... only you can decide. 

PS Antti and Ryan - do you think we could make that change to the postUrl variable in InputfieldFile.js?

It's Monday and I'm having a little trouble waking up, so I don't completely follow yet. Currently we pull the postUrl from the form's action attribute. It sounds like you want it to be hard-coded instead? I don't think we could do that just because it would prevent other admin processes from using the InputfieldFile (though, I don't think any others use it at present). But since this is dynamically set via the form's action attribute, I think it's probably best to set it that way? An alternative is that you could copy that InputfieldFIle.js file out of it's current location, change it how you need it, and have your JS output function use your version rather than PW's.