WordPress Repository Guidelines

Common mistakes WordPress plugin developers make:

## Calling images and files remotely

Offloading content to your own server is disallowed.
https://www.example.com.com/wp/plugins/test.php

Please include all the files needed for your plugin locally.

## Generic function (and/or define) names

All plugins should have unique function names, defines, and classnames. This will prevent your plugin from conflicting with other plugins or themes.
For example, if your plugin is called “Easy Custom Post Types”, then you might prefix your functions with ecpt_{your function name here}. Similarly a define of LICENSE would be better done as ECPT_LICENSE. You can use namespaces instead, however make sure that those also are unique. A namespace or class of ‘MyPlugin’ is NOT actually all that unique, you see.

This extends to anything in a define. For example …
define( ‘PLUGIN_PATH’, plugins_url( __FILE__ ) );
That define is a global, so PLUGIN_PATH could conflict with a number of other things.

Don’t try to use two letter slugs anymore. As of 2016, all the good ones are taken. Instead consider easy_cpts_ (from the first example).
Similarly, don’t use __ to prefix, as the double underscore should be reserved for WordPress itself.
Please update your plugin to use more unique names.

Some Examples:
function filter_inserted_comment
function remove_html_link_tag_from_comment_author_link

## Without correct headers, a plugin will fail to be activated and updated properly, and can (and usually will) cause issues with other plugins.

In addition, putting plugin headers on any file other than the main plugin file will cause issues on uninstall and activation.
Please review https://developer.wordpress.org/plugins/the-basics/header-requirements/ and update your plugin accordingly, putting the headers in only the main file.

## Calling files remotely

Offloading images, js, css, cgi, and other scripts to Google (or jquery.com or anywhere else frankly) is disallowed because you’re introducing an unnecessary dependency on another site.  If the file you’re trying to use isn’t a part of WordPress Core, then you should include it -locally- in your plugin, not remotely. If the file IS included in WordPress core, please call that instead.

The one exception to this rule is if your plugin is performing a service. We will permit this on a case by case basis, however since this can be confusing, we have some examples of what are not permitted:

* Offloading jquery CSS files to Google – You should include the CSS in your plugin.
* Inserting an iframe with a help doc – A link, or including the docs in your plugin is preferred.
* Calling images from your own domain – They should be included in your plugin.

Here are some examples of what we would permit:

* Calling font families from Google or their approved CDN (if GPL compatible)
* API calls back to your server to process possible spam comments (like Akismet)
* Offloading comments to your own servers (like Disqus)
* oEmbed calls to a service provider (like Twitter or YouTube)

Please remove this dependency from your plugin and, if possible, include all files within the plugin (that is not called remotely). If instead you feel you ARE providing a service, please re-write your readme.txt in a manner that explains the service, the servers being called, and if any account is needed to connect.
Examples:
maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js
/maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap.min.css

## Generic function (and/or define) names

All plugins should have unique function names, defines, and classnames. This will prevent your plugin from conflicting with other plugins or themes.
For example, if your plugin is called “Easy Custom Post Types”, then you might prefix your functions with ecpt_{your function name here}. Similarly a define of LICENSE would be better done as ECPT_LICENSE. You can use namespaces instead, however make sure that those also are unique. A namespace or class of ‘MyPlugin’ is NOT actually all that unique, you see.

This extends to anything in a define. For example …
define( ‘PLUGIN_PATH’, plugins_url( __FILE__ ) );
That define is a global, so PLUGIN_PATH could conflict with a number of other things.
Don’t try to use two letter slugs anymore. As of 2016, all the good ones are taken. Instead consider easy_cpts_ (from the first example).
Similarly, don’t use __ to prefix, as the double underscore should be reserved for WordPress itself.

## Please sanitize, escape, and validate your POST calls

When you include POST/GET/REQUEST calls in your plugin, it’s important to sanitize, validate, and escape them. The goal here is to prevent a user from accidentally sending trash data through the system, as well as protecting them from potential security issues.

SANITIZE: All instances where generated content is inserted into the database, or into a file, or being otherwise processed by WordPress, the data MUST be properly sanitized for security. By sanitizing your POST data when used to make action calls or URL redirects, you will lessen the possibility of XSS vulnerabilities. You should never have a raw data inserted into the database, even by a update function, and even with a prepare() call.

VALIDATE: In addition to sanitization, you should validate all your calls. If a $_POST call should only be a number, ensure it’s an int() before you pass it through anything. Even if you’re sanitizing or using WordPress functions to ensure things are safe, we ask you please validate for sanity’s sake. Any time you are adding data to the database, it should be the right data.

ESCAPE: Similarly, when you’re outputting data, make sure to escape it properly, so it can’t hijack admin screens. There are many esc_*() functions you can use to make sure you don’t show people the wrong data.

In all cases, using stripslashes or strip_tags is not enough. You need to use the most appropriate method associated with the type of content you’re processing. Check that a URL is a URL and don’t just be lazy and use sanitize_text please. The ultimate goal is that you should ensure that invalid and unsafe data is NEVER processed or displayed. Clean everything, check everything, escape everything, and never trust the users to always have input sane data.

Please review this document and update your code accordingly: http://codex.wordpress.org/Validating_Sanitizing_and_Escaping_User_Data

Example:
$action = trim($_POST[‘action’]);
$post_id = trim($_POST[‘post_id’]);

## Please use wp_enqueue commands

Your plugin is using <style> and/or <link> tags to insert CSS/JS
You should be using the built in functions for this:

https://codex.wordpress.org/Function_Reference/wp_enqueue_script
https://codex.wordpress.org/Function_Reference/wp_enqueue_style

If you’re trying to enqueue on the admin pages you’ll want to use the admin enqueues

https://codex.wordpress.org/Plugin_API/Action_Reference/admin_enqueue_scripts
https://codex.wordpress.org/Plugin_API/Action_Reference/admin_print_scripts
https://codex.wordpress.org/Plugin_API/Action_Reference/admin_print_styles