Edit Post VS Custom Form

4 Views

I have a blog which relies heavily on user generated content.

I would like my users to be able to create posts, but the posts must only have specific fields:

Read More
  • title
  • content
  • an attached image
  • two metadata fields (latitude, longitude from Google Maps)
  • tags (only pre-existing tags)

Is it better to:

a) give users access to the Edit Post screen and style it differently (Is this possible?)
or
b) develop a custom page/ form to submit the post?

So far, I have opted for the second option (code below), but I am unsure of whether I am going about it the right way. 

if (isset($_POST['photo-title']) && !empty($_FILES) ) { 

    // The user submitted the form.

    // Create the post object.
    $post = array(

         // Forget the lack of validation for now ;)

         'post_title' => $_POST['photo-title'],
         'post_content' => $_POST['photo-description'],
         'post_status' => 'publish',
         'post_type' => 'post',
         'post_author' => $user_ID,
         'post_category' => array(5)
      );

    // Insert the post into the database.
    $post_id = wp_insert_post( $post );

    // If the post was successful
    if ($post_id) {

        // Add metadata for the photo
        add_post_meta($post_id, 'ob_latitude', $_POST['latitude']);
        add_post_meta($post_id, 'ob_longitude', $_POST['longitude']);
    }


    // Handle the photo upload.
    $attach_id = media_handle_upload('photo', $post_id );
}
Post Views: 4

Related posts

Leave a Reply

1 comment

  1. You are way on the safer and less effort involved side if having them access the admin interface is an option.

    In that case you could implement a custom post type for your needs, disable most of the ‘support’ flags when registering it, and add your own metabox to support latitude and longitude, as well.

    With some extra plugins (like Members or any other one that’s capable of editing roles and capabilities) you can even assign permissions to only edit that post type to these users that should be able to.

    All this is pretty well documented on the Codex and relatively easy to do.

    If you go for the front-end form option, you’re basically left with digging through the code and trying to re-implement it on the front-end, which isn’t such a bad thing for your learning experience, but it will take you way longer.

    Update: Developing post form on the front-end.

    First up, i’d still recommend creating a separate custom post-type. It allows you to more easily separate your user input from the rest of your content and above mentioned flexibility in assigning specific capabilities.

    Where to find things

    What i’d do to get started is have a good look at the following files, make sure you understand what’s going on:

    • wp-admin/post.php – particularly the part that processes the actions
    • wp-admin/includes/post.php – particularly edit_post() and wp_write_post()
    • wp-admin/edit-form-advanced.php – good to understand the relation between UI and the actions it triggers

    Since you want to allow uploads as well, you’ll also need to learn about the media side of things:

    • wp-admin/includes/media.php – particularly media_handle_upload(), media_upload_form_handler() and media_upload_form()
    • wp-admin/includes/file.php – make sure you understand wp_handle_upload()
    • wp-admin/includes/image.php – at least good to have a look to know what happens to your attachments on upload, and you’ll have to include this, of course

    How to go about it

    Your best starting point is making a copy of wp-admin/post.php and stripping everything but what you need to save the post. Try to get rid of as many unnecessary dependencies as you can, but keep the function calls involved in saving the post.

    Remember that the more you keep using core WP functions and the more high-level they are, the more you’ll stay compatible across different versions and the more sanity checks you get for free.

    Then have a look at wp-admin/edit-form-advanced.php and it’s dependencies with the aim of determining what you may need for your UI and how you can provide that while using as much WP code as possible. At the same time have a look at the comment_form() function for inspiration on front-end form implementation.

    A part of all that will be understanding the nonce-mechanism (which isn’t that complex, really).

    Make sure your post stuff works first…that is that your user can create and possibly edit/delete their posts and that you get all the data stored properly.

    Then add your meta data UI and store that, too. When doing so, try to use hooks. For instance, if you use WP functions to store the posts to the db, the save_post hook will be run. Use it to store your meta data. This is because the more you do this kind of stuff the easier it will be to accommodate changes in WP down the track or even change the way you do things, your self. Using hooks implicitly modularizes your functionality.

    After all that works, implement the upload form and the upload processing script. The media functions take a little to really get a hang of, i find. This is due to a lot of them being entangled in the AJAX driven admin side Media Thickbox. However, once you figured how to split the crop from the crap, you’ll only need to make a few calls to get your media uploads running.

    Use the function Bainternet provided in his answer to this question.

    Finally, make sure you provide good user feedback for each and every operation. Naturally, this is way more important on the front-end than on the admin side, so make sure you let your users know what’s going on. Again, try to understand how WP handles that itself (it uses two different mechanisms to get messages across from one page to the next).

    Form Example

    Finally, here’s an example of a post and upload form i wrote for a Photo Contest plugin i’m gonna release sometime soon, hopefully. The plugin doesn’t use regular attachments, though, but creates it’s own attachment-like post-type for them, so this is a bit more involved than your case. And it also uses the cookie based commenter identification mechanisms as it’s eventually open for users who aren’t log in. All this you probably won’t need, however, it may be good to look at for inspiration, anyways (except that you’d want to re-use media_upload_form(), probably).