WordPress Plugin Development Basics: Hooks, Paths, and Best Practices

Once you have set up your main plugin file and header, understanding core WordPress lifecycle events, file path management, and coding standards is essential for building scalable and maintainable plugins.

1. Plugin Activation and Deactivation Hooks #

WordPress provides dedicated hooks to run custom code when a user enables or disables your plugin:

• Activation Hook (register_activation_hook): Executed immediately when the plugin is activated. Use this hook to initialize default settings, create custom database tables, or register custom post types (e.g., registering a book post type).

register_activation_hook(
	__FILE__,
	'pluginprefix_function_to_run'
);

• Deactivation Hook (register_deactivation_hook): Triggered when the plugin is deactivated. This is used for temporary cleanup, such as unregistering custom post types or clearing scheduled tasks, without deleting user data.

register_deactivation_hook(
	__FILE__,
	'pluginprefix_function_to_run'
);

2. Essential Plugin Best Practices #

To prevent conflicts with WordPress core, themes, or other third-party plugins, adhere to these fundamental practices:

• Collision Avoidance: Ensure function names, class names, constants, and database options do not overlap with existing WordPress identifiers.
• Prefixing: Always prepend a unique prefix (e.g., myplugin_) to all your custom constants, global functions, settings keys, and PHP namespaces.

3. Dynamic Directory and Path Helper Functions #

Hardcoding file paths or URLs can cause breakage when migrating sites or changing server environments. WordPress provides built-in helper functions to safely reference files:

• plugins_url(): Generates the full web URL to files within your plugin directory, ideal for enqueueing front-end CSS stylesheets and JavaScript scripts.
• plugin_dir_path(): Retrieves the absolute server file-system path to your plugin folder, used when requiring or including secondary PHP files.
• plugin_dir_url(): Returns the web URL path leading directly to your plugin directory.

4. Proper Data Cleanup with uninstall.php #

When a user deletes a plugin from the WordPress admin dashboard, leaving orphan database tables and options behind creates clutter.

• Deactivation vs. Uninstallation: Deactivation is temporary, so user data should remain intact. Uninstallation (deleting the plugin) should perform a complete data cleanup.
• Using uninstall.php: For complex plugins, create an uninstall.php file in your plugin root directory. WordPress automatically executes this file when the plugin is permanently deleted, allowing you to cleanly drop custom database tables and delete plugin options.

// if uninstall.php is not called by WordPress, die
if ( ! defined( 'WP_UNINSTALL_PLUGIN' ) ) {
    die;
}

$option_name = 'wporg_option';

delete_option( $option_name );

// for site options in Multisite
delete_site_option( $option_name );

// drop a custom database table
global $wpdb;
$wpdb->query( "DROP TABLE IF EXISTS {$wpdb->prefix}mytable" );

5. Plugin Licensing #

Include a standard LICENSE file (such as GPL v2 or later) in your plugin root directory to comply with WordPress open-source guidelines.

• Official Documenation