WordPress Plugin Boilerplate

Use the == Installation == section to provide step-by-step instructions for users to set up your plugin. This typically includes uploading files to the correct directory and activating the plugin via the WordPress dashboard.

== Installation ==

1. Upload `plugin-name.php` to the `/wp-content/plugins/` directory
1. Activate the plugin through the 'Plugins' menu in WordPress
1. Place `<?php do_action('plugin_name_hook'); ?>` in your templates

To display screenshots in the WordPress.org plugin repository, use the == Screenshots == section. Reference images named screenshot-1.(png|jpg|jpeg|gif), screenshot-2.(png|jpg|jpeg|gif), etc.

WordPress looks for these in the /assets directory or the directory containing the stable readme.txt. Files in the /assets directory take precedence.

To use the boilerplate, install the plugin-name directory directly into your WordPress plugins folder. Because the boilerplate is a generic foundation, you must rename the directory and its internal identifiers to match your specific plugin name.

For example, if your plugin is named example-me, perform the following renames:

• Rename the directory plugin-name to example-me.
• Change the PHP function/variable style plugin_name to example_me.
• Change the slug style plugin-name to example-me.
• Change the Class name Plugin_Name to Example_Me.
• Change the constant style PLUGIN_NAME_ to EXAMPLE_ME_.

Once renamed, the plugin is safe to activate, though it will have no functionality until you add your own code.

The boilerplate uses a strict file organization scheme. When adding your own classes or third-party libraries, place them in the appropriate directory based on their scope:

• plugin-name/includes: For functionality shared between the WordPress admin area and the public-facing site.
• plugin-name/admin: For all admin-specific functionality.
• plugin-name/public: For all public-facing (front-end) functionality.

Keep users informed of changes and necessary updates using these sections:

• == Changelog ==: List version changes. List versions from most recent at the top to oldest at the bottom.
• == Upgrade Notice ==: Provide reasons for upgrading (e.g., security fixes). Keep these under 300 characters.

== Changelog ==

= 1.0 =
* A change since the previous version.
* Another change.

== Upgrade Notice ==

= 1.0 =
This version fixes a security related bug. Upgrade immediately.

The boilerplate includes a .pot file as a starting point for internationalization. It uses a central variable to store the text domain. To generate translatable files, it is recommended to use one of the following tools:

• Poedit
• makepot
• i18n

You can provide two levels of description in your readme.txt:

1. Short Description: Located immediately below the header. It must be no more than 150 characters and contains no markup.
2. Long Description: Located under the == Description == section. This supports Markdown and has no character limit.

The top of your readme.txt file must contain a specific header block used by WordPress.org to display plugin metadata. Ensure you include the following fields:

• Contributors: A comma-separated list of WordPress.org usernames.
• Tags: A comma-separated list of tags for plugin discovery.
• Requires at least: The minimum WordPress version required.
• Tested up to: The highest WordPress version you have verified the plugin against.
• Stable tag: The Subversion tag of your latest stable version (e.g., 4.3) or trunk.
• License: The license type (e.g., GPLv2 or later).

=== Plugin Name ===
Contributors: (this should be a list of wordpress.org userid's)
Donate link: http://example.com/
Tags: comments, spam
Requires at least: 3.0.1
Tested up to: 3.4
Stable tag: 4.3
License: GPLv2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html