With over l,000 gratuitous plugins, the WordPress Plugin Directory is the city mall for every WordPress user, and where yous'll find plugins covering all features and functionalities for your adjacent website. Nevertheless, chances are that you won't notice a plugin providing that exact feature expressly required by your client. Like it or not, you may have to launch your favorite text editor and beginning coding. But take you always considered the possibility to share your plugins with the whole WordPress community?

The main purpose of this mail service is to explore with you lot readers the benefits of distributing plugins through the WordPress.org repository. I will quickly summarize recommendations and best practices you are encouraged to follow, then I volition bulldoze you through the SVN key concepts you should know when you're planning to publish a plugin to the WordPress plugin directory.

  • Why the WordPress Plugin Directory?
  • What You lot Should Care Nearly
  • The Plugin Structure
  • Publishing to the WordPress Plugin Directory

Why the WordPress Plugin Directory?

The first reason to publish your plugin to the WordPress plugin directory is to have reward of a number of keen tools and services for gratuitous, such as plugin clarification, statistics, active installs, changelog, support forum, and more than. In addition, users are notified anytime a new version is available and tin can run the upgrade directly from the WordPress Plugins Screen. WordPress.org plugins have greater visibility in search engines, and you lot can exploit a powerful medium to promote your identity and improve your reputation as a developer.

If you lot aren't a nifty marketer or don't have time to market, the WordPress plugin directory tin can be a great way to get costless traffic and eyeballs on your plugin.

WordPress Plugin Directory
The WordPress Plugin Directory

Some other good reason for publishing a plugin is to contribute to the WordPress community. WordPress is free software, with a huge customs providing tons of themes and plugins for free. Publishing a WordPress plugin is the best way to requite thanks to all these awesome people who give abroad their work for free.

What You Should Care About

Bear in heed that a greater visibility could ruin your reputation if your plugins are desperately coded, if you do non regularly update them, or if you do not provide a quick and efficient support (definitely, if you don't act as a trusted developer). Here are some central concepts to pivot up.

Coding

At that place is a lot to say about coding, and you lot'll find a lot of useful readings out there. Merely if you're a WordPress developer, the Codex is your Bible, and y'all should read the Plugin Guidelines before you start coding. Hither is my personal list of primal concepts:

  • Keep your code human readable. This allows other developers to understand what your plugin does, to peradventure help you find bugs, and to develop their own plugins on your code. In guild to boost collaboration between developers, the WordPress Codex provides the WordPress Coding Standards, which is a sum of best practices for any WordPress developer.
  • Always annotate your code. Inline documentation is a great resource you should never underestimate. It allows anyone to speedily sympathise what a function does, which arguments are accepted, which variable returns, etc. In the comments, y'all tin add links, script versions, and other descriptions that tin can come in handy anytime your script is going to be edited by yous or anyone else.
    And I similar to say that WordPress people are a learning customs, and abiding the Inline Documentation Standards is a great fashion to let people learn what yous already know.
  • Prefer WordPress functions instead of PHP functions when possible. WordPress functions allow you to build secure and efficient code. Peculiarly when you need to get data from the database, API functions salvage you from building complex queries, that could nigh probably be less secure than the built-in WordPress queries. At that place are a lot of corking developers behind the core, and they are doing a fantastic task we can take advantage of.

Features

Even if you won't go paid for your work, you should consider your plugins like products to sell. You are not required to be a marketing specialist: you just have to know that your plugin should be some way unique and/or distinguishable from like plugins. Give your plugin a memorable and meaningful proper noun, and unique features that will make people say "I need information technology!". And, if your plugin provides features that are already covered by other plugins, focus on accessibility and ease of utilize to give users a value-added making a articulate departure betwixt your production and its competitors.

Support

Each plugin distributed through the Plugin Directory has a specific forum where users volition contact yous for aid. Provide clear answers to user questions, and help them troubleshooting their bug. Quick and appropriate replies will be crucial in edifice your reputation as a trusted developer. Take into business relationship any topic, and grab any piece of information that could help you lot improve your plugin.

Updates

Regularly update your plugin, pushing small changes when needed, simply exercise non exceed. As well many updates can disappoint your users.

Licensing

WordPress is released under GNU General Public Licence V2 and nearly plugins are released under the same GPL license. Actually, it'southward not strictly required to release the plugin nether the same license, every bit any compatible license is admitted. Anyway, GPLv2 is recommended (read more near GPL licensing).

In guild to provide a working instance for this mail service, the plugin we dissected in four Handy WordPress Media Library Hacks has been published to the Directory. Download the ExIF Viewer and open its files in your text editor, and so go back to this post and dive into the plugin structure.

The Plugin Construction

Your plugin will be stored in the WordPress.org SVN repository. Anyone will be able to check out a re-create, merely only the author will have the privileges to check in. Once you've published a plugin, you can add new files, and edit or delete existing files on your local machine, then upload these changes to the server. All changes are tracked by the subversion, so that you'll be able to get back to quondam versions or revisions afterwards.
The SVN repositories provide four default folders:

          /assets/ /branches/ /tags/ /trunk/        
  • Screenshots, headers and icons go in assets
  • trunk is the directory where you'll put the plugin files
  • Divergent branches of lawmaking get in branches
  • Plugin releases volition be stored in tags

Each plugin must be provided of at to the lowest degree two files: the readme.txt file and the primary PHP script. Optionally, you can add together a number of images (assets) to exist displayed on the plugin'south page.

Plugin Assets

Assets are plugin headers, icons and screenshots. Plugin headers are the JPG or PNG images you can see at the summit of a plugin page. File names depend on image width and height. Currently, the post-obit name/dimensions are immune:

  • Regular: banner-772×250.(jpg|png)
  • Retina: banner-1544×500.(jpg|png)

Icons are squared images with the post-obit names/dimensions:.

  • icon-128×128.(jpg|png)
  • icon-256×256.(jpg|png)
  • icon.svg

You should not specify the SVG dimensions in the file name, equally these images tin can be scaled at any size. If you employ SVGs, you must provide a PNG icon every bit a fallback.

Screenshots are images displayed in the plugin page content. PNG and JPEG formats are immune, and the file name must be lowercase and respect the following structure:

  • screenshot-one.(jpg|png)
  • screenshot-2.(jpg|png)

For each screenshot, you should provide a description in the readme file. All these graphics should be added to the avails binder in your plugin's local directory (more than on How Your Plugin Assets Work).

Akismet page
Appealing and consistent assets make a great plugin page

The Readme.txt File

You should provide your plugin with a readme.txt file and advisable headers in the main script.
Get-go, you need a readme.txt file with the post-obit information:

  • Plugin name
  • Contributors: (a list of wordpress.org userid's)
  • Donate link: http://example.com/
  • Tags: (plugin tags)
  • Requires at least: (WordPress version)
  • Tested up to: (WordPress version)
  • Stable tag: (plugin version)
  • License: GPLv2 or later (or compatible)
  • License URI: https://www.gnu.org/licenses/gpl-2.0.html
  • Description
  • Installation
  • Screenshots
  • Changelog

The Screenshots section allows you to add together a description for whatsoever prototype y'all'd want to include to the plugin page. WordPress.org provides the plugin readme file standard template, which will assist you build your readme file. Moreover, yous tin can employ the Readme Validator to check if your file is correct.

Readme Validator
The Readme Validator outputs notes and warnings on readme files

The Plugin Header Comment

The header comment tells WordPress that a file is a plugin.
If you're not going to publish your plugin, the only required field is the plugin name. Conversely, if y'all're planning to publish the plugin, the more information you add, the better. Here is a listing of available fields:

  • Plugin Proper name: (required) your plugin's proper noun must be unique. Before publishing, search the Plugin Directory for plugins with the same name
  • Plugin URI: the home page of the plugin
  • Description: a one-line plugin description (less than 140 characters)
  • Version: the current plugin version (must be college of the previous version)
  • Author: i or more author names, separated by commas
  • Writer URI: the author's home page
  • License: the slug of the plugin's licence (i.e. GPL2)
  • License URI: the link to the full text of the license (i.e. https://www.gnu.org/licenses/gpl-2.0.html)
  • Text Domain: the text domain of the plugin
  • Domain Path: where to find the translation files (see How to Internationalize Your Plugin)

Here is the header comment of ane of the most popular WordPress plugins:

          <?php /**  * @package Akismet  */ /* Plugin Proper noun: Akismet Anti-Spam Plugin URI: https://akismet.com/ Description: Used by millions, Akismet is quite possibly the best mode in the world to <potent>protect your weblog from spam</stiff>. It keeps your site protected even while you slumber. To get started: activate the Akismet plugin and then go to your Akismet Settings page to set up up your API key. Version: 3.3.ii Author: Automattic Author URI: https://automattic.com/wordpress-plugins/ License: GPLv2 or later on Text Domain: akismet */        

Publishing to the WordPress Plugin Directory

When prepare, sign-up and submit your plugin.

Subscribe At present

Add your plugin
The offset plugin release has to be uploaded for a transmission review

The plugin will be manually reviewed past the WordPress.org staff. This process could take between one and ten days. If any issues are found, you lot'll receive an e-mail explaining what'due south wrong and what y'all should do to prepare errors.

Awaiting for approval
The revision process could take upwards to x days

Once the plugin has been approved, yous will receive an email letting you know that you have admission to the SVN repository.

Approval email
An e-mail volition inform yous that the plugin has been approved

At this moment, the plugin is not available for download, but yous tin upload, edit and delete files via command line (or whatever SVN client). The image beneath shows the current plugin folio.

Approved plugin page
The plugin folio is active, just the plugin is not available for download

Upload the Plugin

Our first task is to upload the plugin files to the SVN repository, but first we need a local folder where nosotros will store the plugin files:

          $ mkdir localdir        

Now nosotros can check-out the pre-build repository:

          $ svn co https://plugins.svn.wordpress.org/plugin-proper name path/to/localdir        

We'll get the following response:

          > A    plugin-proper noun/branches > A    plugin-name/tags > A    plugin-name/trunk > Checked out revision 99999999.        

A means that the folders have been added from the central repository to the local binder.
The next step is to add files to the local /trunk binder and upload them to the repository:

          localdir/$ svn add trunk/*        

Yous'll exist required to authenticate yourself. Once logged in, you'll go the following response:

          > A    trunk/my-plugin.php > A    trunk/readme.txt        

Annotation: do not put the master plugin file in a subfolder of trunk, because this volition intermission downloads.

At present check in the changes back to the repository:

          localdir/$ svn ci -thousand 'Kickoff plugin version'        

And here is the concluding response:

          > Adding body/my-plugin.php > Adding trunk/readme.txt > Transmitting file data . > Committed revision 9999999.        
ExIF Viewer structure
The file structure of the ExIF Viewer local copy

Post-obit, we have to add together the plugin avails:

          localdir/$ svn add assets/*        

And so cheque in the changes over again:

          localdir/$ svn ci -m 'Assets upload'        

And that'southward it! Jump to your plugin'southward page, and showtime promoting your piece of work!

ExIF Viewer plugin page
The final folio of the ExIF Viewer plugin

Publish a new release

Before you publish the adjacent release, you must think to update the Stable Tag field in trunk/readme.txt file and the Version number in the plugin header comment. When the new release is ready for publishing, copy your files to a subfolder of /tags and set the subfolder'southward name to the version number (i.e. i.0.i):

          localdir/$ svn cp body tags/i.0.1 > A tags/1.0.i        

Then check in the changes:

          localdir/$ svn ci -m "tagging version 1.0.one" > Adding         tags/1.0.ane > Adding         tags/i.0.1/my-plugin.php > Adding         tags/1.0.1/readme.txt > Committed revision 999999.        

And that'due south it! The new version is online.

Edit a file

Occasionally, yous may need to make modest changes that do non require a new release. Offset, update the local re-create of the repository:

          localdir/$ svn up > At revision 999999.        

Then edit the files and check for changes:

          localdir$ svn stat > M       trunk/readme.txt        

M ways that those files have been modified.
Following, yous can see what has changed between the two versions:

          localdir$ svn unequal        

Finally, ckeck in the changes to the central repository:

          localdir$ svn ci -m "pocket-sized changes" > Sending trunk/readme.txt > Transmitting file data . > Committed revision 999999.        

Summary

Whether y'all decide to publish a light version of a commercial plugin, or you publish the plugin to contribute to the customs, the WordPress.org Directory is the all-time place to distribute your piece of work. It gives you a broad exposure and provides a number of professional tools for distributing and promoting your plugins.

If you feel similar your sales and marketing skills aren't potent enough, brand certain to check out Bridget Willard'southward "How To Market Your Plugin" to acquire more about how to get better at selling your plugins.

And then, have you ever considered this opportunity? Share your experience with us below.


Salvage time, costs and maximize site performance with:

  • Instant help from WordPress hosting experts, 24/vii.
  • Cloudflare Enterprise integration.
  • Global audience reach with 29 information centers worldwide.
  • Optimization with our built-in Application Functioning Monitoring.

All of that and much more, in one plan with no long-term contracts, assisted migrations, and a 30-day-money-dorsum-guarantee. Check out our plans or talk to sales to notice the plan that's right for you.