WordPress Plugin Development Tutorial Manual - Publishing Plugins to WordPress.org

WordPress.org offers a free hosting service for every developer who wants to develop plugins, through which we can:

Monitor the number of plugin downloads
Get plugin version usage statistics
Receive feedback and ratings from users
Support through free forums

WordPress.org also provides a WordPress Plugin API, for developers to monitor the plugin's statistics.

stake a claim

WordPress.org has a detailed plugin guide with examples and instructions, here are some of the most important aspects of it.

Plugin licenses may have to be combined with GNU General Public License v2 or higher, it is highly recommended to use the same license as WordPress - "GPLv2 or higher", if no license is specified for the plugin, the plugin's license may be considered compatible with GPLv2 or higher by default.
Plugins and developers must not do anything illegal, dishonest or morally offensive.
The Subversion repository provided can only be used for WordPress plugins, and the Plugin Catalog is a site that hosts and distributes plugins, and is not a public listing site.
Plugins may not embed external links (such as "Power by" links or advertisements) on public sites or call external services without explicit user permission and documentation.

Plugin Submission

We need to submit the plugin to the WordPress.org plugin repository by following 3 steps.

Register a valid, frequently used email address at WordPress.org, or if submitting a plugin on behalf of your company, sign up using your company's official email address.
Add plugins@wordpress.org to the whitelist of emails to ensure that emails sent by the plugin library can be received.
Submit the plugin, a brief description of the plugin functionality, and a complete, ready-to-go plugin.

Once the plugin is in the pending review queue, the WordPress plugin review team will review the plugin within 14 business days, and most issues can be avoided by following know guidelines. If an issue is found with the plugin, the review team will contact the developer with suggestions for improvement. Upon approval, the developer will receive an email with details on how to access the Subversion repository and then we can upload our plugin via SVN.

After uploading the plugin (and a description file) the plugin will appear in the plugin directory.

More information

Detailed plugin guide

Plug-in Catalog

The purpose of the WordPress Plugin Directory is to provide a space for all WordPress users, from techies to casual users, to download safe plugins that align with the goals of the WordPress project.

To that end, we wanted to make sure that we provided developers with a simple and transparent process for submitting plugins to the Plugin Catalog. As part of our ongoing efforts to make the plugin catalog inclusion process more transparent, we have created a list of developer guidelines. We strive to create a level playing field for all developers.

If you have any suggestions for improving the documentation or other related questions, please email plugins@wordpress.org and let us know.

Expectations of developers

All users with submission access and all users who officially support plugins are expected to follow the catalog guidelines. Violation of the rules may result in the removal of the plugin or plugin data (for previously endorsed plugins) from the catalog until the issue is resolved. Plugin data (such as user comments and code) may not be recoverable, depending on the nature of the violation and the results of peer review. Repeated violations may result in the removal of all of the author's plugins and the developer being banned from hosting plugins on WordPress.org.

Plugin developers are responsible for ensuring that their contact information on WordPress.org is up-to-date and accurate so that they receive all notifications from the plugin team. Contact information is not allowed to be forwarded to the support system's auto-responder emails, as this would result in the developer not being able to process the email in a timely manner.

All code in the catalog should be as secure as possible. Security is ultimately the responsibility of the plugin developer, and the plugin catalog enforces this whenever possible. If a plugin is found to have a security issue, it will be closed until the issue is resolved. In extreme cases, plugins may be updated by the WordPress security team and distributed for the safety of the general public.

Although we try to explain the guidelines in as much detail as possible, it is not possible to cover every situation. If you are unsure whether a plug-in may violate the guidelines, please contact us at plugins@wordpress.org for advice.

Plugin Catalog User's Guide

1, the plug-in must be compatible with the GNU General Public License v2

While any GPL compliant license is fine, it is highly recommended to use the same license as WordPress - "GPLv2 or higher". All code, data, images, etc. hosted in the WordPress.org plugin directory must be GPLv2 compliant. Included third-party libraries, code, images or otherwise, must be compatible. For a specific list of compatible licenses, please read the GPL Compatible License List on gnu.org.

2. Developers are responsible for the content and operation of their plug-ins.

It is the responsibility of the plugin developer to ensure that all files in the plugin conform to the plugin guidelines. It is prohibited to intentionally write code to circumvent the guidelines, or to fix code that is requested to be removed (see #9 Illegal/Dishonest Behavior). Before uploading to SVN, developers need to confirm the licenses of all included files, from the original source code to images and libraries. In addition, these resources must adhere to the terms of use of the third-party services and APIs they use. If the library license or API terms cannot be verified, they cannot be used.

3, must provide a stable version of the plugin from the WordPress plugin directory page

The only versions distributed by WordPress.org are plugins in the plugin catalog. Developers may develop code elsewhere, but users use plugins downloaded from the plugin catalog. Distributing code through alternate methods without keeping the code in the plugin repository up-to-date may result in the plugin being removed.

4. The code must be (mostly) readable.

Code in directories is not allowed to be obfuscated using obfuscation functions like p, a, c, k, e, r. It is not possible to hide code using methods such as uglify obfuscation or unclear naming (e.g. $ z12sdf813d). Unfortunately, many people use this method to try and hide malicious code such as backdoors or tracking. In addition, WordPress code is intended to be learned, edited and adapted by anyone. If the code is not readable, developers face unnecessary obstacles. Compressed code can be used, but uncompressed versions should also be included whenever possible. We recommend the following WordPress Core Coding StandardsThe

5. Trial versions are not allowed to be released

Plugins can and should not include features that are subject to restrictions or lockdowns that can only be provided through payments or upgrades. These features should not be disabled after a trial period or quota. Free features should also be included as is with paid features (see Guide 6: serviceware) and all code within the plugin should be fully available. We recommend hosting the plugin's add-ons outside of WordPress.org to exclude code that contains premium features. Plugins can promote other plugins in a way that is acceptable to the user (don't hijack the admin backend), they should not be overly prominent or intrusive.

6. Allow the provision of software as a service (SAAS)

Charge plugins provide services through the use of interfaces to third-party services (e.g., video hosting sites), even if they are paid services. The service itself must provide content functionality and describe the clearing in the Readme file submitted with the plugin, preferably linked to the terms of use of the service.

Disallowed services and features include:

It is not allowed to have a service that is only used to validate licenses or keys, while locally containing all functional aspects of the plugin.
Prohibit the removal of arbitrary code from plugins to create a service so that the service appears incorrectly to provide supplemental functionality.
Plugins should not be a storefront for a service. Plugins that act solely as a front-end for purchasing products from external systems are not allowed.

7. Plug-ins should not track users without their consent.

To protect user privacy, plugins should not access external servers to track users without their explicit and authorized consent. Documentation on how user data is collected and used should be included in the plugin's Readme file, preferably with an explicit privacy policy.

Some examples of prohibited tracking include:

Automatically collects user data without explicit confirmation from the user.
Intentionally misleading users to submit information as a requirement to use the plugin itself.
Not as a service when uninstalling images and scripts.
Use of external data (e.g., blacklists) without documented (or poorly documented) instructions.
Track the third-party advertising mechanisms used and/or viewed.

The exceptions to this policy are software-as-a-service, such as Twitter, the Amazon CDN plugin, or Akismet.Consent to these systems can be obtained by installing, activating, registering, and configuring plugins that utilize these services.

8. Plug-ins should not send executable code through third-party systems.

Loading code externally from a file service is allowed, but all communication must be as secure as possible. It is not allowed to execute external code in a plugin without acting as a service, for example:

Providing updates or otherwise installing plugins, themes or add-ons from servers other than WordPress.org
Install the advanced version of the same plugin
Third-party CDNs are called for reasons other than font inclusion; all non-service related JavaScript and CSS must be included locally.
Use of third-party services to manage regularly updated data lists, when not expressly permitted in the terms of use of the service.
Use iframe connection to manage pages; should use API to minimize security risks

It is permissible for a managed service to interact with and push software to a site, as long as the service handles the interaction on its own domain and not in a WordPress dashboard.

9. Developers and their plugins must not do anything illegal, dishonest or morally offensive.

While this is subjective and rather broad, its purpose is to prevent plugins, developers and companies from abusing the freedoms and rights of end users as well as other plugin developers. This includes (but is not limited to) the following examples:

Artificially manipulating search results through keyword stuffing, black hat SEO or other means
Offer to drive more traffic to sites that use the plugin
Compensating, misleading, pressuring, blackmailing or extorting comments or support from others
Implying that users must pay to unlock included features
Create an account to generate fake comments or support tickets (i.e. sockpuppeting)
Take plugins from other developers and present them as original work
Unauthorized use of a user's server or resources, such as part of a botnet or cryptomining
Violation of WordCamp Code of Conduct
Violation of Forum Guidelines
Harassing, threatening or abusive behavior towards any other WordPress community member
Falsification of personal information, intentional disguise of identity and sanctions for previous violations
Deliberate attempts to exploit loopholes in the guidelines

10, without explicitly requesting the user's permission, plug-ins may not be embedded in the public site of external links or contributions

All "Powered By" or credit displays and links included in the code must be optional and not displayed on the user's front-end page by default. The user must have the option to choose the credit link, not put in the terms of use that forces the credit link to be displayed or in order to work. If the code is generated in a service rather than a plugin, allow the service to mark up its output as they see fit.

11, plug-ins should not hijack the management dashboard

Users like plugins to be used like part of WordPress, rather than confusing themselves with a self-contained interface.

Escalation tips, notifications and alerts must be used with limited caution or only on the plugin's settings page. Any site-wide notifications or embedded dashboard widgets can disappear on their own or allow users to close them when the issue is resolved. Error messages and alerts must contain information on how to resolve the situation and remove themselves upon completion.

Advertising on WordPress dashboards should be avoided, they are usually ineffective. Users rarely visit the dashboard, and when they do, they are trying to solve a problem. Making a plugin more difficult to use is usually not well-received, and we recommend moderation when placing ads in it. Remember: referrals are not allowed to be tracked through these ads (see guideline 7), and most third-party systems do not allow back-end advertising. Abuse of the guidelines for ad systems can result in developers reporting upstream.

Developers are welcome and encouraged to include links to their own websites or social networks, as well as local (including within plugins) links to enhance the experience.

12. Public pages on WordPress.org (Readme files) cannot contain spam promotional information.

Public-facing pages (including self-referential and translated documents) must not contain spammy promotional information. Spammy promotional behavior includes (but is not limited to) unnecessary affiliate links, competitor plugin tags, more than 12 tags in total, black hat SEO and keyword stuffing.

Links to directly desired products, such as plugins using desired themes or other plugins, are moderately allowed. Similarly, related products can be used in tags, but not competitors' tags. If a plugin is a WooCommerce extension, the tag "woocommerce" can be used. However, if the plugin is an Akismet replacement, it may not use that field as a tag.

Readme files are written for people, not robots.

In all cases, promotional links must be publicly available and must link directly to the service in question, not redirect or spoof URLs.

13. The plugin must use the default WordPress library.

WordPress includes many useful libraries such as jQuery, Atom Lib, SimplePie, PHPMailer, PHPass and many more. For security and stability reasons, plugins should not include other versions of these libraries in their code. Instead, plugins must use the versions of these libraries that are packaged with WordPress.

For all the JavaScript libraries included in WordPress, see Default scripts and registrations included with WordPress.

14. Frequent submission of plug-ins should be avoided.

The SVN repository is a release repository, not a development repository, and all commits, code or readme files will trigger the regeneration of the zip file associated with the plugin. So only code that is ready to be deployed (that is, a stable, beta or RC release) should be pushed to SVN. It is highly recommended to include descriptive and informational messages in every commit. Frequent "garbage" commit messages, such as "update" or "cleanup", make it difficult for others to follow the changes. Multiple quick commits that only tweak small aspects of the plugin (including the Readme) put unnecessary strain on the system and can be seen as molesting the list of recent updates.

The exception to this is when updating the Readme file is just to indicate support for the latest version of WordPress, which can be submitted.

15, each new version of the plug-in version number must be incremented

Users will only be alerted to updates when the plugin version is increased. The readme.txt of the trunk must always reflect the current version of the plugin. For more information on tagging, read SVN's notes on Tagging and how readme.txt works.

16. The full plug-in must be provided at the time of submission.

All plugins are checked before approval, that's why zip files are needed. Names cannot be "reserved" for future use or to protect the brand (see #17: Respecting the Brand). Other developers may use unused directory names of approved plugins.

17, plug-ins must respect trademarks, copyrights and project names

The use of trademarks or other items as the sole or initial rights to a plugin slug is prohibited unless proof of legal ownership/representation can be established. For example, the WordPress Foundation has registered the word "WordPress" and it is illegal to use "wordpress" in a domain name. This policy extends to plugin slugs, and we will not allow one slug to begin the term of another product.

For example, only Super Sandbox employees may use "super-sandbox" or its branding in "Super Sandbox Dancing Sloths" or other arrangements. Non-Super Sandbox employees should use formats such as "Dancing Sloths for Superbox" to avoid potentially misleading users into believing that the plugin was developed by Super Sandbox. Similarly, if you do not represent the "MellowYellowSandbox.js" project, it is not appropriate to use it as the name of the plugin.

It is recommended to use the original branding as it not only helps to avoid confusion but is also more memorable for the user.

18. We reserve the right to maintain the plug-in catalog to the best of our ability.

Our intention is to enforce these guidelines in as fair a manner as possible. We do this to ensure overall plugin quality and user safety. To that end, we reserve the following rights:

...keep these guidelines up to date.
...disable or remove any plugins from the catalog, even if the reason is not explicitly stated.
...granting exceptions and allowing developers time to fix problems, even security-related ones.
...removing developer access to the plugin in favor of new, active developers.
...changes to the plugin for public safety without the developer's consent

In return, we are committed to utilizing these rights as much as possible for end users and developers.

Planning Plugin

You've written the next plugin that rivals Hello Dolly in popularity and you want the WordPress world to know and use him, what do you do?

1. As many tests as possible

With any luck, your plugin will be used by a lot of people in a variety of situations and hosting environments, make sure the plugin has been tested as much as possible, that the tests cover a wide range of situations, and that users don't get frustrated using it.

2. Choose a good name

The name of the plugin should reflect the uniqueness of you and the plugin, and when choosing a name, make sure it doesn't infringe on a trademark or conflict with other product names. For example, if you don't work for Facebook, you shouldn't name your plugin "Facebook's Dancing Squirrels", naming it "Dancing Squirrels for Facebook" would be better, coming up with a good name is not an easy task, so take your time, the plugin website won't be able to change it after submission, but the display name can be changed at any time.

3、Write excellent code

The README.text file is the best place to start, as this file is the standard reference point for all plugins, make sure it is included in that file:

Briefly describe what the plugin actually does, if the plugin has a lot of functionality, splitting it into two plugins might be a little better.
Installation instructions, especially if you need to specialize the configuration, and if the user needs to register for the service, make sure that the registration link is given.
Guidance on how to access support and what kind of support you can and cannot offer.

4. Release the first version on WordPress.org

The WordPress.org Plugin Directory is the easiest way for potential users to download and install plugins, and after publishing your plugin to the WordPress.org Plugin Directory, your plugin is available for users to download or update with a few clicks.

Before releasing just one version, you need to register an account with the plugin directory. After the plugin has been reviewed, you will be granted access to the Subversion repository, and the WordPress.org website provides excellent documentation to help you complete your first Subversion commit.

5. Embrace open source

Open source is one of the greatest ideas of our time because of the ability to collaborate across borders. By encouraging people to contribute, you can make it possible for others to love your code as much as you do, and here are a few great places to open up your source code.

Github Getting other people involved in your project is easy. Other developers and users can easily submit bug fixes or reports, feature requests and brand new code contributions.
Bitbucket is an alternative to something like Github.
The WordPress.org plugin directory provides and requires you to use Subversion.

6. Listen to your users

You'll often find that users use your code more often than you think, which is valuable feedback. Publishing your code through WordPress.org means that your plugin automatically gets a support forum. Using it, you can subscribe to receive post updates via email and respond promptly to your users who love your plugin as much as you do.

Automattic's Happy Engineer - Andrew Spittle has two posts about providing good support "Avoiding Easy" and "The Speed of Support." Jetpack also has an article on How to Write a Good Bug Report The article.

7、Push the new version regularly

The best plugins are the ones that continue to be more visible and iterative over time, offering small improvements with each update without making users wait too hard. Remember that constant updating leads to "update fatigue" and users will stop updating when they get tired, it's important to keep an appropriate frequency of updates, not too many and not too few.

8. Stick to the job

As in other aspects of life, the best things come from good patience and hard work.

Using Subversion

We'll describe some of the basics of using Subversion here.start using, swing, and Label ReleaseThe

This documentation is not a complete and reliable description of using SVN, it's more of a quick start on publishing plugins on WordPress.org, for more comprehensive documentation, see the SVN book.

For more information, see the following documents:

nomenclature

If you are new to using Subversion, you need to understand a few terms first, so let's take a look at how Subversion works and introduce a few terms.

All files will be kind of stored in an SVN repository on our server, where anyone can copy your plugin files to the local machine, however, as the plugin author, only you have the permission to commit the code. This means that you can make changes to files, add new files and delete files on your local machine, and upload those changes to the SVN central server. This process checks for updates to the code repository as well as information displayed in the WordPress.org plugin directory.

Subversion keeps track of all code changes so that you can view all old and new versions when you need to. To handle remembering each individual version, you can tell Subversion to tag certain repositories for reference, and tags are great for labeling different versions of plugins.

SVN Catalog

The SVN repository contains the following directories:

/assets/
/branches/
/tags/
/trunk/

Assets holds the Plugin Usage Screenshots, Plugin Banner Images, and Plugin Icons.
All development work is done on the trunk catalog to do so.
Plugin releases are saved in the tags Catalog.
Code branches are saved in the branches Catalog.

In the event that you develop your plugin elsewhere (e.g. in a Git repository), we also recommend that you keep your trunk folder synchronized with your code for SVN comparisons.

How to use

The following instructions will walk you through some of the basics of using SVN.

Start a brand new plugin

You just need to add the existing plugin files to the new SVN repository.

To do this, you need to first create a local directory on your machine to hold a copy of your SVN repository:

$mkdir my-local-dir

Then, check out the plugin repository for the build

$svn co https://plugins.svn.wordpress.org/your-plugin-name my-local-dir
> A my-local-dir/trunk
> A my-local-dir/branches
> A my-local-dir/tags
> Checked out revision 11325.

As shown in the code above, Subversion has added all the directories from the British SVN repository to the local copy ("A" for add).

To add your code, open the my-local-dir Folder:$cd my-local-dir

Now you can add code to the trunk directory in any way you like. Once added, you must let Subversion know that you want to add these files to the central code repository.

my-local-dir/$svn add trunk/*
> A trunk/my-plugin.php
> A trunk/readme.txt

[c-alert type=danger content=Don't put the main plugin file in a subfolder of trunk, e.g. /trunk/my-plugin/my-plugin.php, this will break the download. You can use subfolders to contain plugin files. /]

After adding the files, we will commit and push the changes to the central plugin repository.

my-local-dir/$svn ci -m 'Adding first version of my plugin'
> Adding trunk/my-plugin.php
> Adding trunk/readme.txt
> Transmitting file data .
> Committed revision 11326.

It needs to contain submission information for all tags.

If the commit fails due to "Disallowed Access" and you know you have committed access, add your username and password to the commit command.

Edit a file that exists in the code repository

Let's say you've committed the code with the plugin repository and now you need to make some changes. First, go to your local repository and make sure the local code is up to date.

$cd my-local-dir/
my-local-dir/$ svn up
> At revision 11326.

In the example above, the local code is up to date. If there are changes in the central repository, they will be downloaded and merged into your local copy.

Now you can use any editor you like to edit the files that need to be changed.

If you are not using an SVN GUI tool such as SubVersion or Coda, it is still possible to check and see the differences between the local copy and the central repository after making changes. First we check the status of the local copy:

my-local-dir/$ svn stat
> M trunk/my-plugin.php

The above command tells us that our local trunk/my-plugin.php is not the same as the one we downloaded from the central repository ("M" stands for "modify").

Let's take a look at what exactly has changed in that file so we can check to make sure everything is correct.

my-local-dir/$ svn diff
> * What comes out is essentially the result of a
* standard `diff -u` between your local copy and the
* original copy you downloaded.

If everything looks okay, we can commit the code to the central code repository.

my-local-dir/$ svn ci -m fancy new feature: now you can foo *and* bar at the same time
> Sending trunk/my-plugin.php
> Transmitting file data .
> Committed revision 11327.

Done!

Marking a new version

Each time a plugin is released, we should tag the code for that version. Doing so allows users to easily access the latest or earlier version, and also allows you to easily track code changes and have the WordPress.org plugin directory specify which version of the plugin users should be allowed to download.

First, copy your copy of the code into a subdirectory of the tags/ directory. For compatibility with the WordPress plugin repository, the new subdirectory should look like a version number, e.g., 2.0.1.3 would be a good choice, and good, cool, hotness would be a bad idea.

We can use svn cp instead of the regular cp to take advantage of SVN's features.

my-local-dir/$svn cp trunk tags/2.0
> A tags/2.0

Now it is possible to submit code to the plugin repository as before.

my-local-dir/$ svn ci -m tagging version 2.0
> Adding tags/2.0
> Adding tags/2.0/my-plugin.php
> Adding tags/2.0/readme.txt
> Committed revision 11328.

Alternatively, you can use HTTP URLs to replicate and save bandwidth:

my-local-dir/$svn cp https://plugins.svn.wordpress.org/your-plugin-name/trunk https://plugins.svn.wordpress.org/your-plugin-name/ tags/2.0

This will perform the copy remotely instead of copying everything locally and uploading it. This is a good option if you have a larger plugin.

Don't forget to update the Stable Tag field in trunk/readme.txt after tagging a new version!

Congratulations! You've updated your code!

More information

Plugin Developer FAQ

Submissions and comments

How do I submit my plugin?

Go to the Add page and upload your zip file.

What happened after the submission?

You will receive an automated email with information about the submission and then someone will manually review your code. If we find no issues with the plugin in terms of security, documentation or presentation, the plugin will be approved. If issues are found, you will receive an email with details of what you need to fix.

What is the URL of the plugin?

When you submit a plugin, you get an automated email telling you what the plugin's Slug will be.The Slug is generated based on the name of the plugin in the main plugin file (the plugin header file). If you set your plugin name: Boaty McBoatface, then your URL will be https://wordpress.org/plugins/boaty-mcboatface and your Slug will be boaty-mcboatface. If there is a plugin with a name that already exists, then you'll get a warning when you get a warning when submitting.

After the plugin is approved, it will not be able to be renamed. Please choose wisely.

Why do I get a different slug than the one I submitted?

Sometimes we notice spelling errors and fix them for you. Other times, there's an obvious problem with the name you've chosen that won't work. For example, if you submit "WooCommerceTango Salsa Add-on" your Slug will default to woocommerce-tango-salsa-add-on If you don't work for WooCommerce, we'll change it for you to woo-tango-salsa-add-on , but if your zip file is named woo-tango-salsa, or if you use intentionally spelled class names, then we might use it.

Basically, we'll fix things we think are bad for you, and if we're not sure, we'll let you know via email. For obvious errors, we'll help you fix the problem.

How long does it take for a plugin to be approved

There is no official average time as no two plugins are the same, if your plugin has a very small amount of code and all the code is correct, it should be approved within seven days. If your plugin has any code issues, it should also be approved soon after as long as you fix them in time. Either way, you will receive an email from plugins@wordpress.org, so please add it to your email whitelist and wait patiently for our response.

If I have a problem with my plugin, how long do I have to fix it?

As long as it takes, there is no time requirement.

Why is my plugin rejected after 6 months?

If you haven't responded to our review within 6 months, we may reject it in order to keep your request in the pending queue below 1000. We won't reject if you've replied, even if only once, or told us to tell us that you're writing code.

Do I need to innovate my submission after fixing the plugin?

No, just respond to emails, even after a year.

I have 10 plugins, can I submit them all at once?

No. You can only insert one plugin at a time into the review queue. Since all plugins get an initial review within 7 days, this should not be a hardship.

What are the specific things I should and avoid doing?

We've compiled some very obvious dos and don'ts, all of which are listed in our guidelines. Most of them can be summarized as "don't be a spammer", but touch on the things that people do the most:

Excluding readme.txt files when acting as a service
Plugin not tested with WP_DEBUG mode
Includes customized versions of the JavaScript libraries bundled with WordPress.
Unnecessary external resources are called
Added a "Powered By" link.
Tracking Users

Again, this is a brief overview. Please read the guide, the full list is very detailed.

Which plugins are not accepted by the plugin repository?

We do not accept plugins that do nothing, break the law or encourage bad behavior. This includes black hat SEO spammers, content tweakers, hate plugins, etc. A plugin should be something that directly benefits the user. It shouldn't require the user to edit files, it should just work out of the box. We also don't accept 100% copying of other people's work or plugins that copy features found in WordPress core. Basically, your plugin should do something new, or in a new way, or solve a specific problem.

Can I change the name of my plugin?

Yes and no, you can change the display name, but once the plugin is approved, the slug (i.e. the part of the plugin URL that belongs to you) cannot be changed. This is why we have warned about this several times.

To change the display name, edit the main plugin file and change the value of "Plugin Name:" to the new name. You may also want to edit your header file in your readme.txt

Are there any names that are not allowed to be used

Vulgar or offensive plugin names (Display Name or Slug) will not be allowed.

Are there any names that can't be used in the slug

Yes! In addition to the vulgarity mentioned above, we have the following restrictions:

In extreme cases, plugins must not use "WordPress" or "Plugin" in their slugs.
Cannot use version number in plugin Slug
Due to system limitations, only slugs containing English letters and Arabic numerals can be used.
Plugins may not begin with a trademarked term or the name of a specific project/library/tool unless submitted by an official representative

We encourage everyone to be creative and come up with unique names. As of March 2017, we will autocorrect any plugins with unacceptable names. If the best name is in question, we will contact you to make sure.

Can I use WordPress or plugins in my display name?

Yes, but very much not recommended, it's pointless and redundant.

I made a mistake and submitted a plugin with the wrong name. How can I fix it?

At the time of submission, you should have received an email allowing you to contact us. Reply directly or email plugins@wordpress.org explaining the situation, we can correct the plugin before we approve it Slug, we can fix the problem before we approve the plugin so we can always help you correct the error, if not we will tell you what needs to be done, we try to correct spelling errors before we approve but sometimes we also make mistakes afterward.

I already have a plugin, but I want to redo it! I'm just submitting it again, right?

No, instead you should rewrite the existing plugin. Make it a major version release. We can't rename plugins or transfer users, so new users won't inherit any existing users, comments, support themes, ratings, downloads, favorites, etc. Basically, you would leave all existing users out in the cold, which is basically what this means.

Using SVN Repositories

Where should I put the file?

Place your code files directly in the trunk/ directory of the repository. Whenever you release a new version, tag that version by copying the current trunk version to a new subdirectory of the tags/ directory.

Make sure you update trunk/readme.txt to reflect the new stable tag.

Images of self-describing files (e.g. screenshots, plugin titles and plugin icons) belong to the Assets/ directory in the SVN checkout root (which you may need to create). This would be the same as Tags/ and Trunk/, for example.

Can I put files in a subdirectory of /trunk?

No, this will disable the zip generation tool and result in not being able to generate in your zip plugin package.

If the plugin is complex and has many files, you can organize them into subdirectories, but the readme.txt file and the root plugin file should be placed directly in the trunk/ directory.

How should I name my labels (a.k.a. versions)

Your Subversion tags should look like version numbers. Specifically, they should only contain numbers and periods. 2.8.4 is a good tag, and neato releaso is a bad tag. It's a bit rigid, isn't it? Yes, this helps with handling and disambiguation, and we recommend that you use the semantic version to track plugin releases.

How many tags should I keep in SVN?

As little as possible. Very few people in the plugin repository need your old code. Remember that SVN for plugin repositories is not suitable for version control. You can use Github for version control if you need to. the SVN should have your current version, but it doesn't need to keep sub-versions of previous versions. It's better just for the last one or two of them.

Can I include an external SVN in the plugin?

No, sorry. You can add SVN externals to your code repository, but they will not be added to the downloadable zip file.

Your WordPress.org page

Where does the WordPress.org plugin directory get its data?

Based on the information you specify in the plugin file and readme.txt file, as well as information from the Subversion SVN repository. Read more about how readme.txt works.

You should also make full use of the plugin header description in the main plugin file. These will define the WordPress.org hosting page as well as the username of the WordPress admin display. It is recommended to use these headers to fully document your plugin.

Can I specify which version of a plugin should be used by the WordPress.org plugin directory?

Yes, specified by specifying the Stable Tag field in the readme.txt file in the trunk directory.

What should I write in the plugin's changelog?

An update log is a log or record of all or significant changes made to your plugin, including a record of changes, such as bug fixes, new features, etc. If you need help formatting the update log, we recommend keeping the update log as this is the format used by many products.

How many versions should I keep in the plugin's changelog?

Always keep major versions in the changelog, e.g. if your current version is 3.9.1 then you need to keep the 3.9 changelog, older versions should be removed or merged into changelog.txt, this will allow users to access these changelogs while keeping the plugin's Readme file lean. At most, keep the latest version and one major version of the changelog in the readme file. The plugin's changelog.text won't show up in the WordPress plugin directory, but that's okay, most users just need to know the latest information.

How do I include a video on the plugin's description page?

For YouTube and Vimeo videos, simply paste the video link into your description. Please note that the video must be set to allow embedding.

For videos hosted by the WordPress.com VideoPress service, use the wpvideo shortcode. The shortcode can also be used for YouTube and Vimeo if desired, just as it is used in WordPress.

How long does it take for the plugin catalog to reflect my changes

WordPress.org is updated every few minutes, however, depending on the size of the update queue, changes may take longer, so please contact us at least 6 hours in advance.

How do I make a cool Banner for my plugin?

You can make your own plugin titles by uploading properly named files to the assets folder.

How to add a one icon to my plugin

You can make your own plugin icons by uploading properly named files to the assets folder.

Support Forum

How do I get notified of updates to forum posts?

Go to https://wordpress.org/support/plugin/YOURPLUGIN and scroll down to the bottom of the list of posts. There you will see the option for RSS links, as well as the option to sign up for emails.

Click on the subscribe link in your email, or use the RSS link in your favorite reader.

How do I get notifications for all plugins?

If you're tracking the WordPress forums, https://wordpress.org/support/view/plugin-committer/YOURID lists all the support requests and comments for your submitted plugin. Not a code submitter and just listed as an author? Use https://wordpress.org/support/view/plugin-contributor/YOURID

Those are just RSS links. If you need to subscribe to email, go to https://profiles.wordpress.org/YOURID/profile/notifications/并输入要通过电子邮件发送的项目.

How do I add a support account for my plugin?

You can add support representatives to your plugin. Support reps can mark forum threads as resolved or assigned (same as plugin authors and contributors), but do not have permission to submit plugin code.

The UI for managing plugin support reps can be found in the advanced view of the plugin page next to Manage Submitters. Once someone has been added as a support rep, they will get the plugin supporter flag when replying to a plugin support topic or comment.

Close plug-in

How do I turn off my plugin?

If you ask for your plugin to be removed, after passing the request, your plugin will be permanently disabled and cannot be restored unless you can provide a valid reason.

Send an email to plugins@wordpress.org with an account email that has submission access and links to your plugin. If your email is not the person with submission access to the plugin, the system will ask you to send the email using another email.

What happens when my plugin is closed?

When the plugin is closed, the plugin's current URL is redirected to the plugin's home directory and will not be generated again. Everyone will no longer be able to download the plugin through the website or install it through the WordPress backend. the SVN repository will remain accessible, allowing others to download and distribute code on a directory-by-directory basis.

Why is my plugin closed?

It could be because the plugin violated guidelines, had behavioral or security issues. In any case, you should receive an email from plugins@wordpress.org to tell you why the plugin was removed.

Why are other people's plugins being turned off?

We don't publicize why we shut down plugins to anyone except plugin developers and WordPress core developers. Don't bother asking. It's for security reasons. If we publicize why we shut down a plugin, everyone will know the vulnerability. If we choose not to say "it's for security", then every time we say 'we can't tell you', the world will know it's for security. Basically, it makes everyone less secure.

Can I get someone else's plugin disabled?

If you report a security issue or guideline violation in a plugin at plugins@wordpress.org, we will review the report and take appropriate action. In most cases, this involves shutting down a plugin.

Someone has posted a copy of my plugin, what should I do?

Provide a link to the stolen plugin via email at plugins@wordpress.org, or a link where you can download the stolen version of the plugin. We will compare the two files, as well as all of our code history, to determine if the plugin is indeed stolen or just an unapproved offshoot. Keep in mind that if you license your plugin under the GPLv2 or higher, it is perfectly fine to distribute your work as long as the copyright remains intact and you are credited with the information.

Can I send a security report?

Email plugins@wordpress.org and describe the problem clearly and concisely. Be sure to explain how you verified that this is a vulnerability (a link to a list of plugins on a site like secunia.com is perfect). If you provide a link to the report, please don't delete it! We'll pass it directly to the plugin's developer.

Can I get a bounty for finding a bug in a plugin?

We are not affiliated with any bug reward programs, so we do not submit your reports, etc. to them. The only one we work on is hackerone.com/automattic, which is a bug related to the Automattic property. Everything else is on its own, don't ask us to submit things.

Do you offer help or CVE?

No, we can't help at the moment.

My plugin was turned off, can I turn it back on?

It may be possible. If we turn off your plugin for security reasons, after resolving the issue, reply to the email and in most cases we will turn the plugin back on. If the plugin was shut down using a violation of the guidelines, it depends on the severity and nature of the violation. For example, repeat violators are less likely to reopen the plugin relative to first time violators.

Plugin Owner

How do I give other people access to my plugin?

If you want to add the user as a submitter, which is what gives them access to the update code, you can open the https://wordpress.org/plugins/YOURPLUGIN/advanced page and add their username as a submitter. If you want to show them as authors, you need to add their usernames to the readme.txt file.

How do I remove other people's access from my plugin?

Anyone with commit access can do this. Go to https://wordpress.org/plugins/YOURPLUGIN/advanced Hover over their ID and a delete link will appear, click on it.

How do I take over an abandoned plugin?

We will advise users to discard plugins that are no longer being developed. We ask that you first try to contact the original developer so they can add you as a plugin submitter. In some cases, this is not possible, and that's when you can start fixing the plugin. Make sure it is coding standard compliant, secure, and includes itself inside the copyright information. Then you can contact us to adopt your plugin.

We don't guarantee you'll get anyone's plugin.

Is the request to offer to buy my plugin legal?

Many developers receive unsolicited emails or offers to purchase their plugins. We have found that the vast majority of these are fraudulent and do not recommend you follow up. While legitimate offers do come in, they are usually from official companies associated with the plugin, or from a well-established plugin company. Don't trust offers that start with "We're reaching out to the WordPress community at ......" or "We're looking to acquire existing WordPress plugins... ..." emails that begin with. Such purchases often damage the reputation of the plugin (and the original developer) by engaging in sleazy tactics (such as tracking users or other serious violations of the guidelines).

If you choose to sell your plugin (or give it to someone else), please make sure the new owner understands all the guidelines of the repository. If they violate our terms, the plugin will be removed and we may not refund depending on the extent of the violation. Whoever owns the rights to submit the plugin should be responsible for their users. Spamming, inserting tracking data and adding spam features are the fastest ways to break your plugin.

We advocate only giving your plugins to people you personally review and trust to take responsibility for your code and users.

What happens if the plugin developer dies?

When a developer is determined to be dead, they are removed from their plugin to prevent unethical access and harm to users. If they are the only developer, then the plugin may be shut down. All attempts are made to locate their friends and colleagues to provide them with an opportunity to claim the code first, and if no one does, the plugin will be shut down.