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.
## Calling file locations poorly
The way your plugin is referencing other files is not going to work with all setups of WordPress.
When you hardcode in paths, or assume that everyone has WordPress in the root of their domain, you cause anyone using ‘Giving WordPress it’s own directory’ (a VERY common setup) to break. In addition, WordPress allows users to change the name of wp-content, so you would break anyone who choses to do so.
Please review http://codex.wordpress.org/Determining_Plugin_and_Content_Directories and update your plugin accordingly. And don’t worry about supporting WordPress 2.x or lower. We don’t encourage it nor expect you to do so, so save yourself some time and energy.
This code is not needed:
// just making sure the constant is defined
if (!defined(‘WP_CONTENT_DIR’))
define(‘WP_CONTENT_DIR’, ABSPATH . ‘wp-content’);
## 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, if you were to use this, it would be a bad idea:
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 from your plugin:
if (!class_exists(‘Environment’)) {
class Environment {
and
if (!class_exists(‘WPPlugin’)) {
abstract class WPPlugin {
They LOOK smart, with the if-check. They’re not. They’ll just be likely to not run at all and your plugin will break.
define(‘ALLOW_INCLUDE’, true); – A bad define. Too generic.
## Not calling uninstall safely
Please secure your uninstall code. Please review the following links and make sure you’re not letting unauthorized users access the uninstall command, and that you’re allowing it to be called on an actual uninstall.
* https://developer.wordpress.org/reference/functions/register_uninstall_hook/
* https://developer.wordpress.org/plugins/the-basics/uninstall-methods/
Yours has this:
require_once(‘wp-plugin.php’);
function uninstall_options($ name) {
Not needed. Check for uninstall and then run 🙂
## Too Many Tags
Your plugin is using too many tags. We ask that users limit tags in their plugins to no more than 12, with some exceptions. Any time your plugin has a high number of tags, you’re seen as trying to game the system.
Remove any ‘common misspellings’ from your tag list (as they aren’t beneficial), as well as any duplicates. Duplicate words do not help your results in our search engine, as it only considers them once. As much as some people like to think, “tags” are not the same as “search terms” in our system, so including lots of them doesn’t really benefit you much.
If you’re looking to improve your search rankings, we suggest improving the parts of the readme intended for human beings to read. The short and long descriptions should be clear and useful. Addressing common problems in the “FAQ” section helps too. The entire contents of the readme file is considered for the search, and tags are really only a small part of that. Removing irrelevant pieces such as lists of languages (like links) or feature bullet points may help a lot as well, to reduce the overall length and to help eliminate irrelevant information about the plugin.
Make the readme for people, not for machines, and it will help you rank higher in the search results. People actually search for solutions to their problems, not simply for keywords.
## 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
—-
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.)
