Plugin update error message

2 Views

I’m working on a client website where the framework requires a specific plugin version to work properly.

With the follow lines of code in my functions.php file, it stops the plugin from updating itself and displaying an update message to the admin user:

Read More
// Disable Cherry Plugin Updates
function filter_plugin_updates( $value ) {
    if(isset($value->response['cherry-plugin/cherry-plugin.php'])) {
        unset($value->response['cherry-plugin/cherry-plugin.php']);
    }
}

The code above works fine, however, it will sometimes throw a PHP error message when making certain changes from the WordPress backend menu, and doesn’t seem to be consistant on a specific change: 

"Fatal error: Cannot use object of type WP_Error as array in ../public_html/wp-content/plugins/cherry-plugin/admin/plugin-updater.php on line 63"

Viewing the above file, line 63 is: 

if ($response['response']['code']!='200') {
    return;
}

And the entire function it is within is: 

// Remote query, function return any data of xml file on server
function cherry_plugin_remote_query($atts){
    global $wp_version;

    $default = array(
                'remote_server' =>  CHERRY_PLUGIN_REMOTE_SERVER,
                'data_type' =>      '',//framework, plugin, notice, info (Or any channel in xml)
                'output_type' =>    'return'//return, echo, notice
            );
    extract(array_merge($default, $atts));
    if($data_type == 'framework' && defined('CHERRY_VER')){
        $current_version = CHERRY_VER;
    }else if($data_type == 'plugin'){
        $current_version = CHERRY_PLUGIN_VERSION;
    }else{
        $current_version = '';
    }

    $response = wp_remote_post( $remote_server, array(
            'body' => array('data_type' => $data_type,
                            'current_version' => $current_version,
                            'api-key' => md5(get_bloginfo('url'))),
            'user-agent' => 'WordPress/' . $wp_version . '; ' . get_bloginfo('url')
        )
    );

    if ($response['response']['code']!='200') {
        return;
    }
    $response = unserialize($response['body']);
    if($response==null){
        return;
    }

    switch ($output_type) {
        case 'notice':;
            if(!empty($response) && isset($response['action']) && !empty($response['notice_content'])){
                global $notice_attr;
                $notice_attr =array();
                if(isset($response['wrapper_id'])) $notice_attr['wrapper_id'] = $response['wrapper_id'] ;
                if(isset($response['wrapper_class'])) $notice_attr['wrapper_class'] = $response['wrapper_class'] ;
                if(isset($response['notice_content'])) $notice_attr['notice_content'] = $response['notice_content'] ;

                add_action($response['action'], 'cherry_call_function_add_notice');
                function cherry_call_function_add_notice(){
                    global $notice_attr;
                    echo cherry_add_notice($notice_attr);
                }
            }
        break;

        case 'echo':
            echo $response;
        break;

        default:
            return $response;
        break;
    }
}

How would I be able to stop the plugin from updating, displaying an update message to the admin user, as well as not throw any PHP errors?

Post Views: 2

Related posts

Leave a Reply

3 comments

  1. I know this is kind of a backwards way of doing it, but I suppose if you disable the possibility to upgrade the plugin, then you don’t need to worry about the plugin being overwritten.

    Change the plugin version number (in the plugins main file comment header) to something ridiculously high so it won’t recommend an upgrade to the user.

    I’ve had to do this for some unsupported plugins in the past when the second or third to last version of the plugin was the last operational version.

  2. As @gate_engineer already stated, your problem is a plain PHP problem where you are trying to access an Object as Array.

    To not only state that, but help you a bit further, the correct check for a proper response object is checking against the return value of wp_remote_retrieve_response_code() and wp_remote_retrieve_response_message():

    $response = wp_remote_request( array( /* args */ ) );
// or wp_remote_post()
// or wp_remote_get()
// or wp_remote_head()

if (
    200 !== wp_remote_retrieve_response_code( $response )
    OR 'OK' !== wp_remote_retrieve_response_message( $response )
    OR is_wp_error( $response )
)
    return $response->get_error_message();
    // ...or something more sophisticated using the returned remote API data.

    Another safety check would be to check the headers:

    $headers = wp_remote_retrieve_headers( $response );
// do some checks and fixes here like UTF-8 incompability fixes
// for e.g.
in_array( 'Content-Type', $headers )
AND 'utf-8' !== $headers['Content-Type']
    AND $result = utf8_encode( wp_remote_retrieve_body( $response ) );

    or/and if you know that there might be a custom header returned by the remote API, use it directly:

    'no-result' === wp_remote_retrieve_header( $response, 'custom-error-header' )
    AND print 'Response error!';

    Then just fetch your result. This will contain another check for is_wp_error() as well as it will check if the body is actually set. If it is an error or no body is here, it returns an empty string: ''.

    $result = wp_remote_retrieve_body( $response );
// Custom check:
if ( empty( $result ) )
    _e( 'Nothing returned from request.', 'your_textdomain' );

// Process your result:
echo $result['foo'];

  3. References:

    Stopping the Fatal Error:

    The error that you’re receiving above is due to the fact that wp_remote_post() returns a WP_Error object if a request to the remote web server failed. When the script executes the next expression on line 63:

    if ( $response['response']['code']!='200' )

    …PHP gets confused as to why you’re trying to access an object using the [] operator, and simply throws you a fatal error due to incorrect syntax. In this case, you would need to test before line 63 for a WP_Error object in $response, and deal with the failed request condition appropriately.