Emailed Author: There are issues with your plugin code. Please read this ENTIRE email, address all listed issues, and reply to this email with your corrected code attached. It is required for you to read and reply to these emails, and failure to do so will result in significant delays with your plugin being accepted.
## Allowing Direct File Access to plugin files
Direct file access is when someone directly queries your file. This can be done by simply entering the complete path to the file in the URL bar of the browser but can also be done by doing a POST request directly to the file. For files that only contain a PHP class the risk of something funky happening when directly accessed is pretty small. For files that contain procedural code, functions and function calls, the chance of security risks is a lot bigger.
You can avoid this by putting this code at the top of all php files:
if ( ! defined( ‘ABSPATH’ ) ) exit; // Exit if accessed directly
## 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.
Example:
https://code.jquery.com/ui/1.12.0-rc.2/themes/smoothness/jquery-ui.css
## Forcing PHP Sessions on all pages
Using session_start() or ob_start() in your plugin without having it encapsulated in a function means that it will run on every single page load when your plugin is active. That means you’ve just broken caching for everyone because the way PHP Sessions work is they indicate the visitor using sessions is unique and should have a non-cached view of the website. This specifically breaks Varnish type caching.
Please remove this from your plugin, or put it only in the function that absolutely must have it.
## 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 myStartSession
function myEndSession
## Undocumented use of 3rd Party
Your plugin is calling a 3rd party system, but you neglected to explain this in your readme.
Plugins that send data to other servers, call js from other servers, and/or require passwords and APIs to function are required to have a full and complete readme so we can make sure you’re providing the users with all the information they need before they install your plugin. Our goal with this is to make sure everyone knows what they’re installing and what they need to do before they install it. No surprises.
This is especially important if your plugin is making calls back to your own servers. For the most part, we do not permit offloading of images or code, however in the case where you are providing a service (like Disqus or Kismet or Twitter), we permit it. The catch is you have to actually explain this to the layman in your read me, so they know where data is going.
You’re calling freegeoip.net – You MUST disclose this.
—-
Please make sure you’ve addressed ALL issues brought up in this email. When you’ve corrected your code, reply to this email with the updated code attached as a zip, or provide a link to the new code for us to review. If you have questions, concerns, or need clarification, please reply to this email and just ask us.
(While we have tried to make this review as exhaustive as possible we, like you, are humans and may have missed things. As such, we will re-review the ENTIRE plugin when you send it back to us. We appreciate your patience and understanding in this.)
