WordPress Plugin Development

• In uninstall.php, after checking that WP_UNINSTALL_PLUGIN is defined
• In the callback registered with register_deactivation_hook()
• In the callback registered with register_activation_hook(), so it runs on the next activation
• On admin_init, when the plugin notices its main file is missing

• settings_fields( 'myplugin' )
• do_settings_sections( 'myplugin-settings' )
• wp_nonce_field( 'myplugin' ) on its own
• register_setting( 'myplugin', 'myplugin_settings' )

add_shortcode( 'myplugin_price', 'myplugin_price_shortcode' );

function myplugin_price_shortcode( $atts ) {
	echo '<span class="price">£20</span>';
}

• The callback echoes its output instead of returning it
• The shortcode is registered outside the init action
• The callback does not call shortcode_atts()
• Shortcodes always render before the post content

• Removing a column that is no longer in the CREATE TABLE statement
• Adding a new column
• Adding a new index
• Creating the table on a site where it does not exist yet

add_action( 'wp_ajax_myplugin_confirm', 'myplugin_ajax_confirm' );

function myplugin_ajax_confirm() {
	check_ajax_referer( 'myplugin_confirm', 'nonce' );

	$id = absint( $_POST['booking_id'] ?? 0 );
	myplugin_set_booking_status( $id, 'confirmed' );

	wp_send_json_success();
}

• A capability check such as current_user_can( 'myplugin_manage_bookings' )
• A wp_ajax_nopriv_myplugin_confirm handler
• An is_admin() check
• Nothing: the nonce check already limits who can call it

Select all that apply.

• Each action is stored with its own status and log, so failed batches are visible and can be inspected
• It provides an admin screen and a WP-CLI command for inspecting and running the queue
• It runs actions without any PHP request or cron trigger
• It removes PHP time and memory limits for queued actions

• pre_set_site_transient_update_plugins
• plugins_api
• auto_update_plugin
• upgrader_process_complete

• PHP runs the render file on each request that displays the block
• The markup the editor saved into the post content
• The block’s JavaScript save function, run in the visitor’s browser

• Your plugin cannot be activated until WooCommerce is installed and active
• WordPress downloads and activates WooCommerce automatically when your plugin is activated
• WooCommerce is loaded before your plugin, but nothing else changes
• It is documentation only and WordPress ignores it

• Whichever copy loads first is used by both plugins, which can cause errors in the other
• Composer detects the clash and loads both versions side by side
• WordPress refuses to activate the second plugin
• PHP picks the newer version automatically

• On an early hook such as plugins_loaded, when the stored version option differs from the code’s version
• In the activation hook, because WordPress runs it after every update
• In uninstall.php, which runs before the new files are installed
• Only from a WP-CLI command that the site owner runs manually

• The log is read from the database and held in memory on every request, including pages that never use it
• Nothing, because options are only loaded when get_option() is called
• WordPress refuses to save options larger than 1 MB
• The log is stored in the object cache only and never reaches the database