apedog

Yes. That fixed the notices. thanks ??

I think this ticket can be safely closed.

I’ve narrowed those warnings down to a remote dependency script (pre-3.x). So those errors probably originate there.

Those were just coincidences (and no stack trace)

Also, possible false-positive on jQuery.type is deprecated when running a script similar to this:

$(document).on("custom_event", function(event){
    console.log("Responding to event type " + event.type);
});

@anthoniusalfred

the manual update can still be performed by any users through the WP dashboard (Updates page, Plugins page and Themes page) as long as they have capabilities.

This is specifically what I use EUM for – to block the manual update option. Not per user, but per plugin. But I do understand that EUM is mainly a dashboard/UI. So maybe a programmatic solution is outside of this.

Thanks all for the info and time.

@ronalfy
Thank you for that link. Very comprehensive. I sort of knew the general idea of it, but it’s nice to have all the hooks explained in one spot. And in such depth. It was a good read. I didn’t know EUM does not use core’s auto-updates. I thought EUM would delegate a lot of the functionality to WP core, once auto-updates were introduced to core.

@vupdraft
Thank you for the reply. The hook auto_update_plugin blocks auto-updates. I’m actually wanting to manipulate the “Block” option. The option that completely prevents updates – manual updates as well. As far as I can tell, this option is not available through WP core’s auto-updates – only through EUM plugin. I started using EUM before auto-updates were introduced to WordPress. And I like the email notifications and logging of EUM better than what core provides so I’m not looking to switch to core. I only wish to disable manual “block/unblock” on select plugins (to prevent any admin accidentally ublocking-and-then-manually-updating through the dashboard UI).

I think I understand the idea that EUM is essentially a dashboard interface only – and not a programming API. My use case: EUM offers complete update blocking, that I need to “lock” for specific plugins on a client’s site (that uses EUM). Can this be achieved programmatically?

Thank you.
I just tested this and it works great.

well, an update with a message that plugin is no longer maintained/compatible would be more informative. but ok. good to know.

lol ok
(props for temperament ?? )

This is a simplified version of my code.
It’s just a function hooked on init
It runs once after a plugin has upgraded and set an option to true.
ie. it’s a maybe_upgrade routine running on first page load after a custom plugin has updated.

function my_redirection_create(){

   // some return early tests here.

    if ( class_exists( 'Red_Item' ) ){

        // require_once WP_PLUGIN_DIR . '/redirection/models/group.php';

        $details = [
            'url'         => 'source_url',
            'action_data' => [ 'url' => '/target/?my_param=' . $key ],
            'group_id'    => 2,
            'match_type'  => 'url',
            'action_type'  => 'url',
        ];
        $result = Red_Item::create( $details );
    }
}
add_action( 'init', 'my_redirection_create', 11 );

Thank you for that. Will have a look.

As for the fatal error when calling Red_Item::create() is this expected behaviour? Or am I doing something wrong? Or will this be fixed in future versions?

Fair enough ??

I thought it could be an easy fix. It’s all good.

post-scriptum:
I just saw the image you linked.

I had not realized the ‘Not Now’ button would dismiss the notice permanently. Most other plugins use the small gray-X ‘dismiss’ icon in the corner. So perhaps adding that would make things clearer for the user about the appropriate interactions.

But I’m guessing this might to lead to a lot more of your users not migrating at all. ‘Dismiss’ is easy.

Not really.
I don’t mind the plugin’s campaign to migrate to ‘Genesis Custom Blocks’. I get that this is the direction of the project. So dismissing the notice for a few weeks (requiring admin interaction) is neither here nor there. I’d like if I can simply make this change on my end without affecting the overall migration campaign on your end.

Your original suggestion of a programmatic disable hook add_filter( 'block_lab_display_migration', '__return_false' ); for the notice, is the most relevant for me until (if) I get a chance to play with the custom blocks again. At which point I can facilitate a safe migration. I don’t need the functionality of the migration page to be disabled. I just don’t want the client having to interact with these decisions/notices.

Personally, I’d love to see all the changes in ‘Genesis Custom Blocks’ back-ported to ‘Block-Labs’ but if that’s not happening – then eventually I’ll migrate as well. So as things stand now – I know I’ve used the API. I know the migration will break my blocks. The client does not know these thing – and doesn’t need to. I just want this consideration to be off their radar until next time I get to play with the code. And I’d like to be able to control this decision on my end without involving the campaign itself or the client.