[Hpr] HPR Web Submission Form: Ready for first review by someone who knows what they're doing...

epicanis+hpr at dogphilosophy.net epicanis+hpr at dogphilosophy.net
Wed Apr 24 12:44:46 PDT 2013

I finally had time to sit down and finish getting the last bits of the first iteration of the Web-based HPR Episode Submission Form working and tested. So far it provides what I would consider "minimum useful functionality" plus one additional feature.

For me, "minimum useful functionality" means that it effectively provides to the HPR admins the same materials that are currently being submitted "by hand" to the ftp server. For HPR, this should make submissions more consistent to deal with. For submitters, you'd no longer need an FTP client nor need to worry about the correct format for the show notes file. 

The web form guides the submitter into providing the necessary and useful information and allows upload of the show audio file, and optionally an "audio summary" file (to be prepended to the show for people who didn't read the feed before copying the file to their media player and wandering off, so they can decide if they are interested or not) and/or a single file of "supplemental" files (presumably images, example files, etc referenced in the show notes, collected into a tarball or zip file or whatever)

Once uploaded, on the server side the script generates an obfuscated ID# for the submission, creates a save directory for it (as configured in the file) and saves the uploaded file(s) there, and creates a .txt file matching the format of the current show-notes file in the same directory. This provides a nice bundle of files equivalent to what the HPR admins are expecting from the FTP uploads right now for each episode, in a consistently-formatted way.

In addition, the script generates as much of an Atom <entry> as it can with the given information and saves it as well. (The script cannot know some of the information required for the final <entry> such as the HPR show#, the file sizes for the encoded files, and the date the show will hit the feed - the script sticks some filler text in those spaces that should be easy to find-and-replace with the correct information at release time).

The sample Atom feed file I mentioned in the last email was made with an <entry> directly generated from a test upload I did with the form (with the missing parts filled in by hand), and it is validated by the W3C online validator, so that part seems to be working. (If anyone is willing, I need to check that sample feed in as many "podcatchers" as possible. In particular, Atom allows multiple enclosures, meaning the current <entry> includes all of the media formats. I'm curious to verify that real-world "podcatcher" software is correctly handling that.)

Currently, it does only slghtly more validation than the current FTP uploads get before an admin looks at them. Unmodified HTML is only allowed in a couple of explicitly configured fields. Filenames and paths are all internally generated so there shouldn't be any opening for malicious overwriting, etc. The save directory is expected to be configured to be outside of the webserver root, so the uploaded files shouldn't even be visible to anyone limited to web server access (not that this should really be an issue in our case). 

I've uploaded copies of the two files that make up this system to the ftp server (ftp://hackerpublicradio.org ). "hprup.php" is the actual form. "takefile.php" is the script that accepts the uploads and processes the information.

To use them, both the web server and PHP will likely need their configurations updated to allow larger file uploads (the web server will need to be told how large of a chunk of POST data it should accept, and php.ini will need upload_max_filesize and post_max_size updated). The form in hprup.php should indicate what PHP is currently configured to accept as a maximum file upload size. Both files should work fine if renamed, so long as you update the form to indicate whatever you rename "takefile.php" to.

Anyway: if anybody here has time to look over them for any errors or potential problems I've missed, that would be helpful. I've only done enough testing so far to see that the system actually accepts data and files and saves the information the way I expected it to, so I haven't really started prodding it for holes much yet.

More information about the Hpr mailing list