Up to 50 percent off

Users are able to Publish directly without having Admin verify Post!

This topic contains 21 reply and 3 voices, and was last updated by Tareq Hasan 11 years ago
Viewing 15 Posts - 1 through 15 (of 21 total)
Author Posts
November 9, 2013 at 3:36 am 9872
Tareq Hasan I have had this error happen to me twice in the past day on 2 separate users' accounts. When a user creates a Post and clicks submit, that Post should be in Draft mode for the Admin to first verify before Publishing. I am unsure what happened, but in the past day 2 users' Posts have been Published immediately. How could that happen? In the "Post Settings" for this Form, I have "Pending Review" for the "Post Status". Any idea why this Publish immediately is happening? This is rather urgent that I fix this ;(
November 9, 2013 at 6:47 am 9876
Mahi Mahi

I think its plugin conflict. Is it happening for all or just 1/2 users? Check that your any other membership or user role permission plugin not playing a trick here?

November 9, 2013 at 7:11 pm 9901
paperweight paperweight

It’s happening for all the users. I use PMPro and the WPUF-PMPro bridge and those are operating fine I think. A few days ago all was fine, and then all of a sudden this problem started.

The only new plugin I added was SNAP (Social Networks Auto-Poster). I will experiment today with disabling that and see if it solves the issue.

November 12, 2013 at 6:12 am 9982
paperweight paperweight

No, I tested this a lot. The problem persists even when de-activating the other SNAP plugin. It also directly publishes the Post even if I set “Post Settings” to Draft or to Pending Review. Both Draft and Pending Review don’t seem to work because the Post is directly published.

Any other ideas on why this is happening? Is the “Post Settings” conflicting with maybe another function in the plugin? I doubt it, but could this be the case? I need to try to solve this asap. Any advice?

November 12, 2013 at 11:28 pm 9999
Tareq Hasan Tareq Hasan

It’s working fine here and I don’t see any reason why it’s behaving like this.

November 12, 2013 at 11:40 pm 10000
paperweight paperweight

Yes I agree it was working fine before, but now it doesn’t. Even when I create a new user it always immediately publishes a new Post. So I am trying to figure out what combination of things are making it do that. Is there a specific area of the code I should look to troubleshoot? Or is there something in the database I should check for? I appreciate your advice~

November 12, 2013 at 11:53 pm 10001
Tareq Hasan Tareq Hasan

For new posts, the post status is set at /class/frontend-form-post.php at line 212.

November 13, 2013 at 12:26 am 10002
paperweight paperweight

Yes Line 212 just grabs the settings, so that looks fine. I am really confused. I have deactivated all plugins except for Akismet, WPUF Pro, and PMPro and it still has this problem. Could it be something related to PMPro? I do not want to deactivate it since this is a live site, but you think that is related in any way?

Is there another way you suggest I should troubleshoot?

November 13, 2013 at 1:18 am 10003
Tareq Hasan Tareq Hasan

Are the users posting by buying a subscription pack? In that case, it doesn’t care about the settings. If the user has the ability to post, it’ll be publish by default.

November 13, 2013 at 1:40 am 10004
paperweight paperweight

Yes users are buying a subscription pack and then posting. Ahhhh, so is there a way to then fix or tweak this so the plugin uses the WPUF Pro settings and doesn’t publish automatically?

November 13, 2013 at 2:11 am 10005
Tareq Hasan Tareq Hasan

Find the handle_post_publish function in /class/subscription.php and replace with this:
[php]
function handle_post_publish( $order_id ) {
$post = self::post_by_orderid( $order_id );

if ( $post && $post->post_status != ‘publish’ ) {
$post_status = ‘publish’;
$form_id = get_post_meta( $post->ID, ‘_wpuf_form_id’, true );

if ( $form_id ) {
$form_settings = get_post_meta( $form_id, ‘wpuf_form_settings’, true );
$post_status = $form_settings[‘post_status’];
}

$update_post = array(
‘ID’ => $post->ID,
‘post_status’ => $post_status
);

wp_update_post( $update_post );
}
}
[/php]

It should reflect the forms post status setting.

November 13, 2013 at 2:13 am 10006
paperweight paperweight

Excellent, thank you Tareq! I will implement in the next 1-2 hours and let you know of any issues.

I see PMPro just issued a new release of their plugin and will upgrade in a few days if this fix works. Is there a way for you to include this fix in a plugin update for the WPUF-PMPro bridge?

November 13, 2013 at 2:15 am 10007
Tareq Hasan Tareq Hasan

This subscription post_status has always this issue and will ship with this fix in next versions.

November 13, 2013 at 2:26 am 10008
paperweight paperweight

cheers~ You guys rock!

November 13, 2013 at 2:46 am 10009
paperweight paperweight

Hi Tareq: ok I implemented the change but it still published immediately.

I changed this:

    function handle_post_publish( $order_id ) {
        $post = self::post_by_orderid( $order_id );

        if ( $post && $post->post_status != 'publish' ) {
            $update_post = array(
                'ID' => $post->ID,
                'post_status' => 'publish'
            );

            wp_update_post( $update_post );
        }
    }

To this:

function handle_post_publish( $order_id ) {
    $post = self::post_by_orderid( $order_id );
 
    if ( $post && $post->post_status != 'publish' ) {
        $post_status = 'publish';
        $form_id = get_post_meta( $post->ID, '_wpuf_form_id', true );
         
        if ( $form_id ) {
            $form_settings = get_post_meta( $form_id, 'wpuf_form_settings', true );
            $post_status = $form_settings['post_status'];
        }
         
        $update_post = array(
            'ID' => $post->ID,
            'post_status' => $post_status
        );
 
        wp_update_post( $update_post );
    }
}

Any other thoughts on how to fix this problem? Thanks for your help~

November 14, 2013 at 8:36 pm 10078
paperweight paperweight

Hi, any update on this? Should the code Tareq gave me fixed this specific issue? If so, did I just implement it incorrectly? Any thoughts on how to fix this?

Viewing 15 Posts - 1 through 15 (of 21 total)