WordPress Plugin Development: A Guide to Creating a Base Plugin for WordPress.org

The WordPress.org Plugin Directory is a treasure trove of plugins, often the first stop for WordPress users seeking enhanced site functionality. This directory also presents significant opportunities for developers, but adherence to specific guidelines is crucial. A well-structured base plugin simplifies the development process.

Key Considerations:

• The WordPress.org Plugin Directory demands adherence to specific guidelines for plugin creation and submission. This includes proper file and directory structuring, comprehensive README.txt instructions, and compliance with WordPress coding standards.
• The assets directory houses essential plugin visuals: screenshots, a banner image, and an icon. While not mandatory, these assets significantly boost user engagement.
• Maintaining a clear trunk and tags directory structure is vital for version control. The trunk serves as the active development directory. Upon release, code is copied to a version-specific directory within tags. Users download from these versioned directories, not the trunk.
• Internationalization is key. Translate all displayed strings to support non-English speakers. This involves creating a .pot file containing translated string versions.

Base Plugin Structure:

Every plugin destined for the WordPress.org directory requires these files and directories:

<code>--plugin-name
    --assets
        -screenshot-n.png
        -icon-256x256.png
        -banner-772x250.png
    --trunk
        --admin
            --css
            --js
            --inc
            -admin.php
        --public
            --css
            --js
            --inc
            -public.php
        --inc
            -activation.php
            -deactivation.php
        --languages
            -plugin-name.pot
        -plugin-name.php
        -uninstall.php
        -README.txt
    --tags      </code>

Let's examine each component's function and required code.

Assets Directory:

This folder holds plugin images: screenshots, a banner, and an icon. Multiple screenshots (png, jpg, jpeg, or gif) showcasing the latest version are recommended. The icon should be 256x256 pixels, and the banner 772x250 pixels. While optional, these visuals enhance plugin visibility.

Trunk and Tags Directories:

The trunk directory is your workspace. For releases, copy the trunk contents to a new version directory within tags (e.g., tags/1.0, tags/2.0). Users download from these version directories, not the trunk.

README.txt File:

This file is paramount; it's the primary information source displayed on WordPress.org. It should clearly explain the plugin's purpose and usage, even if seemingly obvious. Use Markdown formatting. The Stable tag in the trunk's README.txt must point to the latest version directory in tags.

Example README.txt Content (Markdown):

<code>--plugin-name
    --assets
        -screenshot-n.png
        -icon-256x256.png
        -banner-772x250.png
    --trunk
        --admin
            --css
            --js
            --inc
            -admin.php
        --public
            --css
            --js
            --inc
            -public.php
        --inc
            -activation.php
            -deactivation.php
        --languages
            -plugin-name.pot
        -plugin-name.php
        -uninstall.php
        -README.txt
    --tags      </code>

plugin-name.pot File:

Create a .pot file for internationalization. Use load_plugin_textdomain() in plugin-name.php:

=== Plugin Name ===
Contributors: developer1, developer2
Donate link: http://example.com/
Tags: tag1, tag2, tag3
Requires at least: 3.0.1
Tested up to: 3.4
Stable tag: 2.0
License: GPLv2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html

Short description (under 150 characters).

== Description ==

Detailed plugin description.

== Installation ==

Installation instructions.

... (FAQs, Screenshots, Changelog, Upgrade Notice)

Activation and Deactivation Files (inc/activation.php, inc/deactivation.php):

These files contain code executed upon plugin activation and deactivation, respectively. Use register_activation_hook() and register_deactivation_hook() in plugin-name.php:

load_plugin_textdomain("plugin-name", false, basename(dirname(__FILE__)), "/languages");

uninstall.php:

This file runs when the plugin is deleted. Include a check to prevent manual execution:

register_activation_hook(__FILE__, 'plugin_activated');
register_deactivation_hook(__FILE__, 'plugin_deactivated');

Admin and Public Directories:

admin/admin.php contains admin-specific functionality, while public/public.php houses public-facing features.

Publishing Your Plugin:

Your plugin becomes an SVN repository on WordPress.org. After approval, use SVN to manage changes and releases.

Further Resources:

Consult the WordPress.org Plugin Directory FAQ, use a README.txt validator, and consider using a README.txt generator.

This detailed guide provides a solid foundation for developing and submitting your WordPress plugin to the WordPress.org directory. Remember to always adhere to their guidelines and best practices.

The above is the detailed content of Developing for the WordPress.org Plugin Directory. For more information, please follow other related articles on the PHP Chinese website!