Skip to:

Proposed method for file attachments and uploads

  • charliestout


    File uploads and attachments: like many others, I am highly interested in such a plugin. While I agree with the intent of the developers to keep bbPress light and awesome (which it is,) it certainly seems a shame to have to abandon bbPress because it does not provide for file uploads.

    It’s my understanding that each post is given a unique identifier, visible as a URL parameter: id=38 for post 38, id=39 for post 39, etc.

    Functionally, it seems a matter of creating an /uploads folder, and using a PHP upload/file management script to create a folder with the same name of the post ID in the /uploads folder.

    I think one could add some PHP code in the topic page loop to parse the /uploads folder for folders whose names match the numbers of the post id’s displayed on that page, if-then display links to any files contained within those folders, if-not, then don’t.

    Do I have the technical know-how to pull this off? Of course not. I barely got the forums installed and avatar plugin running on my server. But others lurking here with any PHP ninja skills might be able to.

    Of course, there might be horrendous security risks that I’m not thinking of with this method. And the PHP code that scans the uploads folder for foldernames that match post id’s might ridiculously slow down the forums, as it constantly scans the filesystem instead of performing a quick database lookup.

    But it might be a good start. Between all of us here in these forums, I am confident that we’ll eventually stumble across this much-needed functionality. Necessity is a mother…

Viewing 11 replies - 26 through 36 (of 36 total)
  • @ _ck_

    I think all languages place the file extension on the right of the filename.



    Progress is excellent, way ahead of schedule, should have a public demo Saturday night (24 hours or so).

    Working on a auto-thumbnail method now for image uploads.

    I’ve come up with some extra security features like the files are not directly publicly accessible (stored in non-webroot directory) so they never get fed through the parsers and cannot be executed (ie. .php .html .asp) even if someone manages to trick a file extension or mime somehow. The only downside to this is that the files must be “dumped” through PHP (readfile) which will keep the PHP session open longer but unless you are serving multi-megabyte files at high traffic rates, this should not be a big issue (optionally you can make the files directly accessible off the web if this is critical issue).

    As a bonus the above method makes hotlinking impossible as you can set attachments as accessible to logged-in members only.

    Piping things through PHP will be slower (but potentially more secure).

    Oh, and the file size may be limited by the memory limits in PHP that way too. Not the file upload size limits, but the memory allocation limits set in the PHP INI file.

    This stuff will come out in the wash once it is released and in the hands of users though.



    Yes there used to be a limit with readfile/passthru but supposedly fixed in newer PHP and even the old limit was 2mb which is fairly high anyway. Also there is some debate that flushing output and making sure compression/output buffers are turned off avoids the limit. We’ll find out as more people test it.

    I’ll have a version up for testing in 12 hours or so.



    fel64: No, there’s been hooks for the post form for as long as I can remember.

    Unfortunately that’s only for new posts. For editing existing posts there is absolutely no way to affect the template without editing it. There’s no hooks for edit_form() or any of it’s sub-functions or the template loader (the loader does the include AFTER the hook so nothing can be placed afterwards. I requested some hooks many month ago but they may have been missed (or ignored). This plugin will require (one, simple) edit of the edit-post.php template.

    (In theory it could be done via the bb_get_footer but that’s really messy and the footer hook is AFTER the footer has been rendered).



    An early beta is now available for review:

    @ _ck_

    Which ticket was he hook request in. I’ll see if I can do something about it sooner rather than later.

    I’m also happy to do a new release to get those changes more readily available for this plugin.



    The ticket was months back, I’d have to search.

    It’s fairly simple in theory though, why not mimic the existing hook structure for new posts to match editing existing posts:

    pre_post_form -> pre_edit_form

    post_form -> edit_form

    post_post_form -> post_edit_form

    I recall a ticket where mdawaffe was hesitant to put hooks in the templates.

    Would you require hooks in the templates?



    I agree with not doing the actions in the templates – that was a mistake WordPress did for awhile eh? The hooks can go inside function edit_form in the core, no?

    Just for clarification, because this one is important, do_action('post_edit_form') should go AFTER the </form> is closed.

    do_action('pre_edit_form') should be before the <form

    and do_action('edit_form') should be inside the form.

    If all the post_form’s are actions, so should be the edit_forms. I don’t think any are filters, wouldn’t make sense…?

    This will help other plugins like my Signatures too.

    Less template edits needed, makes it easier for users.

    Of course I still have to support some 0.8.3 people so it’s going to be awhile before this solves all problems but at least newer installs can benefit.

Viewing 11 replies - 26 through 36 (of 36 total)
  • You must be logged in to reply to this topic.
Skip to toolbar