• Create a folder named plugin name in wp-content/plugins directory.
  • Inside it create a php file with same name as plugin name.
  • It should contain header which is used by wordpress to display meta information about it.
  • WordPress uses gettext via wrapper functions to make strings translatable.
  • A text domain uniquely identifies your plugin’s translations. Must match the plugin slug (folder or main file name).
/*
 * Plugin Name: My Plugin
 * Text Domain: my-plugin
 */

Domain Path

  • Defines where translation files live.
  • Defaults to the plugin folder.
  • If using a /languages directory, add to header:
/*
 * Domain Path: /languages
 */
  • __( 'Text', 'my-plugin' )
    • Returns a translated string.
  • _e( 'Text', 'my-plugin' )
    • Echoes the translated string.

Uninstall hook

  • Method 1:
register_uninstall_hook(
	__FILE__,
	'pluginprefix_function_to_run'
);
  • Method 2: To use this method you need to create an uninstall.php file inside the root folder of your plugin. This magic file is run automatically when the users deletes the plugin. /plugin-name/uninstall.php
  • If both are defined, uninstall.php will be used.
// 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" );

wpdb

  • This is WordPress’s global database object.
  • It’s an instance of the wpdb class.
  • You use it to safely interact with the WordPress database instead of using raw mysqli or PDO.
  • require Includes and loads a PHP file so its code can run.
  • use Imports a namespace or class so you can refer to it with a shorter name. use works after the code is loaded (so you still need require or autoloading).

shortcode

add_shortcode('wporg', 'wporg_shortcode');
function wporg_shortcode( $atts = [], $content = null) {
    // do something to $content
    // always return
    return $content;
}
  • [wporg] is your new shortcode. The use of the shortcode will trigger the wporg_shortcode callback function.

  • Actions allow you to add data or change how WordPress operates. Callback functions for Actions will run at a specific point in the execution of WordPress. Actions do not return anything back to the calling hook,(i.e., do_action() do not return anythin)

  • Filters give you the ability to change data during the execution of WordPress. Callback functions for Filters will accept a variable, modify it, and return it.

  • Multiple functions can be attached to same filter.

<?php
function add_world($text) {
    return $text . " world";
}
add_filter('my_text', 'add_world'); // No priority defined → defaults to 10

function add_exclamation($text) {
    return $text . "!";
}
add_filter('my_text', 'add_exclamation'); // No priority defined → defaults to 10

$text = "Hello";
$text = apply_filters('my_text', $text);

echo $text;
?>
  • One special action that applies to both hooks and filters is the ‘all’ action, which allows a function to be fired for all hooks and filters. See the source for apply_filters() in wp-includes/plugin.php:186-190.
  • $priority controls order:
    • Lower priority → runs earlier
    • Higher priority → runs later
<?php
add_action( 'all', function ( $hook ) { 
    error_log( $hook );
} );
  • If a file contains only PHP code, the closing tag ?> at the end of the file is optional, and in fact omitting it is recommended.
  • If you add a closing ?> at the end of a PHP file and there’s any extra whitespace or newlines after it, PHP might send that output to the browser.

pre_option_* filters

  • Any filter named pre_option_{$option} fires before WordPress queries the database for that option.

  • Example: pre_option_blogname fires before WordPress looks for the site title in wp_options.

  • alloptions fires right after WordPress loads the entire set of options that are marked as autoloaded from the database.

  • This is a memory optimization: instead of calling get_option() and querying the DB each time, autoloaded options are loaded in one query at the start of each request.

  • mu-plugins, aka Must-Use Plugins are plugins that are installed in a special folder called mu-plugins inside wp-content. These plugins are activated by default and won’t show up in the plugin’s list.

func_get_args()

function example() {
    $args = func_get_args();
    var_dump($args);
}

example(1, 'hello', true);

array(3) {
  [0]=> int(1)
  [1]=> string(5) "hello"
  [2]=> bool(true)
}

add_action('all', function() {
    $args = func_get_args();
    error_log(print_r($args, true));
}, 10, 15); // $accepted_args=15 defines upper limit of no. of args

In WordPress, post types are essentially different types of content that you can create and manage. By default, WordPress comes with a few built-in post types:

  1. Posts – Used for blog entries or news articles. They are typically listed in reverse chronological order.
  2. Pages – Used for static content like “About Us” or “Contact” pages.
  3. Attachments – These are media items like images, videos, or PDFs uploaded to the Media Library.
  4. Revisions – WordPress keeps a history of changes made to posts and pages. Each revision is stored as a separate post type internally.
  5. Navigation Menus – Represent menus created under Appearance → Menus.
  6. Custom CSS – Stores custom CSS added via the Customizer.
  7. Changesets – Used to store pending Customizer changes before they are published.