Block Form Access Based on Advanced User Authentication

Gravity Support Forums » Plugin Support » Gravity Forms

devEdge
Member

Hello,

I have a business directory website that allows a user to edit their business listing details (partially, at least). Each business listing (a custom post) is assigned the user as author. I use GF basically as a frontend editor, pulling in the post field values on the edit post form. Then, I've locked all these users out of the WordPress admin area. It's pretty cool actually...

Here's the problem though. GF, by default, is only capable of creating new posts - not editing existing posts. Thus, when the edit form is called with an invalid post to edit (or none at all), GF defaults to creating a new post rather than displaying an unauthorized message. I need to change that.

Is there a hook or filter I can use to add my own authentication logic and block the form when it is called? I was thinking the gform_pre_render filter might do the trick. Can I do my permissions check there and unset the form or something? Then echo an unauthorized message instead? How can I block the form from displaying (rendering at all actually)?

By the way... GF does not respect the publish_posts capability in WordPress.

Any thoughts?

Posted 11 years ago on Thursday July 4, 2013 | Permalink
devEdge
Member
Ok, I guess I asked the question too quickly. I was right about using the gform_pre_render filter. Here's basically what I did...
```
add_filter( "gform_pre_render", "block_user_render_form", 100, 1 );
function block_user_render_form( $form ) {
//Put your form ID instead of 6
if ( $form['id'] != 6 ) {
    return $form;
}
//test for authorization
if ( !$authorized ) {
   echo "<p>You are not authorized to do this.</p>";
   return null;
}
return $form;
}
```
The only caveat to returning a null form, is that GF will also output the following after the unauthorized message:
"Oops! We could not locate your form."

Which didn't bother me. But might for some...'

Cheers!
Posted 11 years ago on Thursday July 4, 2013 | Permalink

This topic has been resolved and has been closed to new replies.