Option to disable migrate to Genesis Custom Blocks

  • Resolved apedog

    (@apedog)


    4 years, 1 month ago

    I have block labs installed on a client’s website. And a theme that uses the block-labs API.
    I’d like to avoid a situation where the plugin is migrated through the client’s actions – and the blocks stop working. Changing the custom code using the blocks-lab API is not feasible ATM.

    Also, separate issue – you might want to polyfill the block-labs functions and hooks in genesis so as to avoid any breakage. Wrapped in a function_exists etc. so as to render my above concern moot.

    Thank you.

Viewing 9 replies - 1 through 9 (of 9 total)
  • Plugin Author Ryan Kienstra

    (@ryankienstra)

    Hi @apedog,
    Thanks, that’s an interesting idea.

    Does the client have install_plugins and edit_others_posts permissions? Otherwise, they shouldn’t see the migration UI:

    https://github.com/getblocklab/block-lab/blob/1ae868ed6edb6eca082b0ef5e9a1b3ce74ec86c9/php/admin/migration/class-submenu.php#L130

    Thread Starter apedog

    (@apedog)

    They have full admin caps. Same as me. It’s their website. I just work on it – and had time to test on a staging site that migrating will break the blocks.

    I tried writing a quick polyfill, but once I realized that was going to take more than 15 minutes, I abandoned that idea. Tho I guess for someone who knows all the hooks in need of polyfilling it should take less time than that.

    ps. On an unrelated note, I like the branding on ‘block-labs’ a lot better than ‘Genesis custom blocks’. It’s a lot clearer what the plugin is (stand-alone) and what the plugin does (make new blocks). As well as the block-y icon (very accessible and indicative of the functionality in the admin menu). I’m pretty sure there are reasons for abandoning the old brand – but it was really good. Even for an uninitiated user, the functionality of the plugin was obvious just from the brand. It’s not an issue for me but I figured I’d share my thoughts here anyway.

    Plugin Author Ryan Kienstra

    (@ryankienstra)

    Hi @apedog,
    Sure, that makes sense.

    Were you thinking of something like:

    
add_filter( 'block_lab_display_migration', '__return_false' );

    That would prevent the migration UI from displaying, and the notice to migrate.

    ps. On an unrelated note, I like the branding on ‘block-labs’ a lot better than ‘Genesis custom blocks’.

    Good points. Unfortunately it’s a little late to change the name of the plugin, but I think your points are right.

    Thread Starter apedog

    (@apedog)

    Yes, please.
    That filter hook is exactly right.

    Thank you.

    Plugin Author Ryan Kienstra

    (@ryankienstra)

    Hi @apedog,
    This will prevent the Block Lab > Migrate page from displaying:

    
// Remove the submenu Block Lab > Migrate.
add_action(
	'admin_menu',
	static function() {
		remove_submenu_page(
			'edit.php?post_type=block_lab',
			'block-lab-migration'
		);

		remove_all_actions( 'block_lab_page_block-lab-migration' );
	}
);

    1. Would your client be able to click ‘Not Now’ on the migration notice? That snippet above won’t hide the notice. But even if they do click ‘Migrate’ in the notice, the migration page won’t display.

    Otherwise, if you have access to your client’s credentials, maybe you could click it for them.

    https://cldup.com/RA6vEO-1T6.png

    2. If we do deploy a new version of Block Lab with that filter block_lab_display_migration, when would that help you? For example, if we don’t deploy it for 3 weeks, would it still be helpful?

    Thanks for your patience.

    Thread Starter apedog

    (@apedog)

    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.

    Thread Starter apedog

    (@apedog)

    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.

    Plugin Author Ryan Kienstra

    (@ryankienstra)

    Hi @apedog,
    Sure, it’s definitely a hassle to migrate, I’d think the same thing.

    Is there a timeline in which adding the filter to Block Lab would help you? For example, if we deployed a new version of BL with the filter in 3-4 weeks, would that help? (Though not pledging a timeline yet)

    Thread Starter apedog

    (@apedog)

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

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Option to disable migrate to Genesis Custom Blocks’ is closed to new replies.