File uploads
padUpload takes the file of one form field and stores it safely:
- its real type comes from its content - not from the type the browser claims, and not from its name - and is held against the types you allow,
image/*for any image; - a file over the size you allow,
'2M','500K'or bytes, is refused; - it is stored under a random name in
DATA/uploads/, with the extension of what it really is, never under the name the visitor's file had.
|
PHP fragments/file_uploads_1.php |
HTML fragments/file_uploads_1.pad |
Result |
|---|---|---|
|
|
No picture was sent yet. |
The answer is the record of the stored file - name (the visitor's own file name, for showing only), file (the path under DATA, for padFileGet), path, size, type and extension - or NULL when the field brought no file, or FALSE when the file was refused. padUploadError ( 'avatar' ) says why, and the {input} file field of the form shows it beside itself, in the words of its label.
A {form} holding a file field posts as multipart/form-data by itself; without that the browser sends only the file's name.
What is stored under DATA no address reaches. A page sends it back with padUploadSend ( $record ['file'], $record ['name'] ), which answers the file as the whole page and ends the request: its type read from its content again, a picture, a PDF or plain text shown, anything else - HTML, SVG, a script, which shown on the site's own address would run with its rights - downloaded; TRUE as its third argument downloads it in any case. A path out of DATA, or to no file, answers 404.