matt_fw

The block is registered with an invalid name in wp-content/plugins/megamenu/integration/block/location/block.php , note the __DIR__ . /build line:

function maxmegamenu_location_block_init() {
	register_block_type(
		__DIR__ . '/build',
		array(
			'attributes' => array(
				'location' => array(
					'type'  => 'string'
				)
			),
			'render_callback' => 'maxmegamenu_render_callback',
		)
	);

	$locations = array_merge(
		array( "" => __('Select a location', 'megamenu') ),
		get_registered_nav_menus()
	);

	wp_localize_script( 'maxmegamenu-location-editor-script', 'max_mega_menu_locations', $locations );
}

You use __DIR__/build as the block name. It evaluates to something like /var/www/acme.com/wp-content/plugins/megamenu/integration/block/location/build , which is invalid, it should be <vendor>/<block>. Here are examples of block names used by other plugins:

• core/archives
• woocommerce/all-reviews
• woocommerce/featured-category
• yoast-seo/siblings

WP_Block_Type_Registry::register() requires block names to match regex '/^[a-z0-9-]+\/[a-z0-9-]+$/'

@rohit Thank you for the reply, it’s great to see updates and to know that you are working on the solution. I appreciate the effort to provide a workaround, but please allow me to point out why it’s not a good solution.

First, some users might click on buttons right after a page is visible (especially power users). User experience will be inconsistent, for some users the workaround is going to work, for some, it won’t.

Divi popup event handlers might not have been run yet after 1000 ms – it heavily depends o a particular page. The proposed workaround would assign event handlers only for them to be possibly removed after a while.

Lastly, users – even if they’re developers – might have no control over when event handlers are attached if the event handlers are attached by other plugins/themes (in my case – Divi itself).

Actually, you call wp_cache_flush() in every function.