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.
## Bad Code
define('DATABASE_TYPE', 'auto');
define('DATABASE_HOST', 'localhost');
define('DATABASE_USER', '');
define('DATABASE_PASS', '');
define('DATABASE_NAME', '*');
This has multiple issues. Why is it even there? Why aren't you just letting WP handle that?
## 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 run_cwis()
define('ROOT_PATH', dirname(__FILE__));
define('SCAN_PATH', dirname(dirname(dirname(ROOT_PATH))));
define('WORK_PATH', ROOT_PATH . DIRECTORY_SEPARATOR . 'cwis-scan');
define('INCLUDES_DIR', 'CWIS-INCLUDES');
define('INCLUDES_PATH', WORK_PATH . DIRECTORY_SEPARATOR . INCLUDES_DIR);
Those defines are all GLOBAL and could break all manner of things.
Pretty much everything in /cwis-scan/cwis-defines.php needs to be renamed uniquely.
If those are intended to be in shared libraries, please detect IF the code is already included and not re-include it, as doing so will cause conflicts if two people call the same defines and functions.
## 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.
Example:
// Absolute path to the root directory
define('ROOT_PATH', dirname(__FILE__));
// Absolute path to the scan directory
define('SCAN_PATH', dirname(dirname(dirname(ROOT_PATH))));
// Absolute path to the working directory
define('WORK_PATH', ROOT_PATH . DIRECTORY_SEPARATOR . 'cwis-scan');
That is all rather pointless.
You're using it here:
// Include scanner "bootstrap" file
require_once(WORK_PATH . DIRECTORY_SEPARATOR . 'cwis-bootstrap.php');
Which can actually JUST be this:
// Include scanner "bootstrap" file
require_once( 'cwis-bootstrap.php' );
If you needed the path, you'd use plugin_dir_path
## 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.
The whole cwis-template.php file is doing this.
## 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
The whole cwis-template.php file is doing this. Is there a reason you're not just outputting this on wp-admin, where you'd have access to everythign WP?
## Asks users to edit/writes to plugin
We cannot accept a plugin that forces (or tells) users to edit the plugin files in order to function, or saves data in the plugin folder.
Plugin folders are deleted when upgraded, so using them to store any data is problematic.
Please change your plugin to save those files outside of the plugins folder (in wp-content/pluginname perhaps or wp-content/uploads/pluginname - which would make it work well with multisite, making sure you read http://codex.wordpress.org/Determining_Plugin_and_Content_Directories to understand where the folders are and how best to call them), or if possible, save data to the wp_options tables.
----
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.)