Month: April 2021

This post is part of the ClassicPress Plugin Development series in which I am going to look at both best practice for developing plugins and how I approach some requirements as well as some of the functions I commonly use.

As with the readme.txt file, the main plugin file needs a header containing information related to the plugin. The bare minimum which is needed in the header is the plugin name:

/**
 * Plugin Name: {plugin name}
 */

The fields which can be used are:

• Plugin Name: The name of your plugin, which will be displayed in the Plugins list in the ClassicPress admin dashboard.
• Plugin URI: The unique home page of the plugin
• Description: A short description of the plugin which will be displayed in the Plugins section in the admin dashboard. It should be shorter than 140 characters.
• Version: The current version number of the plugin, such as 1.0.0 or 1.0.3.
• Requires at least: The lowest ClassicPress version that the plugin will work on.
• Requires PHP: The minimum required PHP version.
• Author: The name of the plugin author (separate multiple authors with commas).
• Author URI: The author’s website or profile on another website.
• License: The short name (slug) of the plugin’s license (e.g. GPLv2).
• License URI: A link to the full text of the license (e.g. https://www.gnu.org/licenses/gpl-2.0.html).
• Text Domain: The gettext text domain of the plugin. More information can be found in the Text Domain section of the How to Internationalize your Plugin page.
• Domain Path: The domain path tells ClassicPress where to find the translations.

The below example is what I use for my plugins:

/**
 * ------------------------------------------------------------------------------
 * Plugin Name: {plugin name}
 * Description: {short description}
 * Version: {version}
 * Author: {author}
 * Author URI: {author url}
 * Plugin URI: {plugin url}
 * Text Domain: {text domain}
 * Domain Path: {domain path}
 * ------------------------------------------------------------------------------
 * This is free software released under the terms of the General Public License,
 * version 2, or later. It is distributed WITHOUT ANY WARRANTY; without even the
 * implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Full
 * text of the license is available at https://www.gnu.org/licenses/gpl-2.0.html.
 * ------------------------------------------------------------------------------
 */

In the above example, the text in braces {} would be replaced with the required text.

This post is part of the ClassicPress Plugin Development series in which I am going to look at both best practice for developing plugins and how I approach some requirements as well as some of the functions I commonly use.

A ClassicPress plugin should have a readme.txt file. A readme file is where you “sell” your plugin, it’s features and benefits and why users would want to use it over the competition. Being clear and concise in your explanations will be of benefit.

This file explains what the plugin does, what features it has and is used to present this and other information to the users when they view the plugin details page through their ClassicPress site. This is an example of the plugin details for my SMTP plugin:

As you can see the user first sees the description, but there are a number of other tabs available as well, which are configured in the readme file which are created using a form of Markdown which allows the file to be human readable no matter how it is viewed (unlike HTML markup).

At the basic level, a plugin file does not need to contain much information. Below is an example of the template used by the Update Manager I use for updating my plugins (while the ClassicPress Directory is in development:

=== Plugin Name Here ===

Version:           1.0.0
Requires:          1.0.0
Download link:     https://

== Description ==

This text displays in the modal windows; it is required. Write something!

Continue reading “ClassicPress Plugin Development: Format of a Plugin readme.txt”