automator_before_blocks_init

Description

Usage

add_action( 'automator_before_blocks_init', 'your_function_name', 10, 1 );

Examples

add_action( 'automator_before_blocks_init', 'my_custom_automator_block_registration', 10, 0 );

/**
 * Registers a custom block for Automator before the core blocks are initialized.
 *
 * This function demonstrates how to add a new block definition to the Automator
 * block registry before the default ones are loaded.
 */
function my_custom_automator_block_registration() {
    // Assume you have a custom block class or file path.
    // For demonstration, let's use a hypothetical path.
    $custom_block_path = '/path/to/your/custom-blocks/MyCustomBlock.php';

    // You might want to check if the file exists before attempting to register.
    if ( file_exists( $custom_block_path ) ) {
        // The automator_before_blocks_init hook doesn't directly pass a variable
        // to add to. Instead, you'd typically use a global or a different mechanism
        // to add your block class to the registry if the core Automator class
        // provided a public method or filter for this purpose.
        //
        // However, if the 'Blocks' array in the source context is intended to be
        // directly modified by hooks (which is less common for 'action' hooks
        // without parameters), you'd need to access it. Let's assume a hypothetical
        // scenario where Automator makes its $classes variable accessible or has
        // a specific way to register blocks here.
        //
        // For a more realistic scenario, consider if Automator has a dedicated
        // function or class method to register new blocks that is meant to be
        // called from hooks like this.
        //
        // If the intent is to add your block class to the $classes array being
        // built in the gutenberg_block_classes method, that would typically
        // be done via a filter on $classes, not an action without parameters.

        // Since this is an action hook without parameters, the common approach
        // is to rely on other mechanisms Automator provides for block registration
        // or to manipulate global state if explicitly designed for it.

        // Example: If Automator provided a function like:
        // automator_register_block( 'MyCustomBlock', $custom_block_path );
        //
        // Then you would call it here:
        // if ( function_exists( 'automator_register_block' ) ) {
        //     automator_register_block( 'MyCustomBlock', $custom_block_path );
        // }

        // Without a specific registration function provided by Automator for this
        // hook, we can only illustrate the hook usage. The core logic would
        // depend on how Automator expects custom blocks to be added.
        //
        // For demonstration purposes, let's assume a hypothetical scenario where
        // Automator's internal $classes array is globally accessible or can be
        // modified by a helper function. This is NOT typical WordPress best practice
        // for actions without parameters, but fits the context of modifying a private
        // class property indirectly.

        // If Automator provided a public static method like:
        // Automator_Load::add_block_definition( 'MyCustomBlock', $custom_block_path );
        //
        // Then it would look like this:
        // if ( class_exists( 'Automator_Load' ) && method_exists( 'Automator_Load', 'add_block_definition' ) ) {
        //     Automator_Load::add_block_definition( 'MyCustomBlock', $custom_block_path );
        // }

        // As the original hook is `automator_before_blocks_init`, and it's an action
        // without parameters, the most likely scenario is that any custom block
        // registration logic would be handled by calling a specific Automator
        // API function or method designed for this purpose.
        //
        // For this example, we'll simulate adding a block definition, assuming
        // Automator has a way to do this that's triggered by this hook.
        // In a real plugin, you would replace this with the actual Automator API call.

        // Let's assume there's a global array or a helper function to add blocks.
        // This is a placeholder for actual block registration.
        error_log( 'Custom Automator block registration logic executed for: ' . $custom_block_path );
    }
}

Placement

This code should be placed in the functions.php file of your active theme, a custom plugin, or using a code snippets plugin.

Source Code

src/class-automator-load.php:716

public function gutenberg_block_classes( $classes = array() ) {

		do_action( 'automator_before_blocks_init' );

		$classes['Blocks'] = UA_ABSPATH . 'src/core/blocks/class-blocks.php';

		do_action( 'automator_after_blocks_init' );

		return $classes;
	}

Related Hooks

• automator_after_activity_stream_init — fires_nearby
• automator_after_automator_post_types_init — fires_nearby
• automator_after_blocks_init — fires_nearby
• automator_before_activity_stream_init — fires_nearby
• automator_before_automator_post_types_init — fires_nearby
• automator_after_blocks_init — paired_after