Please read this ENTIRE email, address all listed issues, and reply to this email with your corrected code attached (or linked). 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.
Also please remember in addition to code quality, security and functionality, we require all plugins adhere to our guidelines. If you have not yet, please read them:
All plugins must have unique function names, defines, and classnames. This prevents 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.
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 easycpts (from the first example).
Similarly, don't use _ (double underscores), wp , or _ (single underscore) as a prefix. Those are reserved for WordPress itself. You can use them inside your classes, but not as stand-alone function.
Please update your plugin to use more unique function and class names.
Some examples from your plugin:
define('PAYPAL_HERE_PLUGIN_DIR', dirname(FILE));
function angelleye_load_end_point()
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.
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.
Your autogenerated plugin slug was this: paypal-here-for-woocommerce
Since you don’t appear to legally represent that group, we need to change the plugin slug.
We recommend the following: woo-paypal-here
You also need to change the display name to not BEGIN with that term.
A rather lengthy explanation of why is included below, but the tl;dr is that we're no longer accepting plugins that begin with (or are in total) a trademarked product name or term as the name or slug of a plugin (ex: Facebook or google-maps-bathrooms). Nor are we accepting plugins that include the name of another plugin at the beginning of the name/slug (eg: contact-form-7-music), UNLESS you legally represent that service/plugin/theme/etc.
Please reply to this email with what slug you’d like. We’ll edit it slug for you.
You DO NOT need to edit your code for this. ALL we need is to be on the same page for the plugin slug :)
If you DO work for the company, reply to this email and tell us. We can fix your submission.
Here's the long stuff.
The slug for your plugin is generated based on the name you put in your main plugin file, with hyphens inserted in place of spaces. This means if you were to name your plugin "My Really Cool Cookie Jam" then your URL on WordPress.org would be http://wordpress.org/plugins/my-really-cool-cookie-jam
This becomes a larger issue when plugins use the names of other plugins in their own.
For example, if you have written an add-on plugin for WooCommerce, you may not name it "WooCommerce Improved Product Search" as that would generate the slug "woocommerce-improved-product-search" and that would conflict with the trademark of 'WooCommerce.' That said, it would be acceptable to submit the name "Woo Improved Product Search" which would use the slug "woo-improved-product-search" (woo not being trademarked you see).
As another example, if you have a plugin that integrates a service with a Easy Digital Downloads, you may call it "My Service Integration for Easy Digital Downloads", but you may not use "Easy Digital Downloads - My Service Integration". Alternately you could use 'EDD My Service Integration' and that too would be permitted.
Consider the example of Keurig. If you made an eco-friendly brew cup, you could market it "EcoBrew Pod for Keurig" but you could NOT attempt to market it as "Keurig EcoBrew Pod." The latter implies a direct relationship to Keurig and is actually against the law in some countries. In order to protect you, we need you to tread lightly with recognized brand names and trademarks. Always err on the side of caution, becuase if they come and tell us to close your plugin becuase you used their term FIRST in the display name, we have to do it :(
If you got all the way down here and forgot what to do next, just reply to this email and tell us what slug you’d like, or if you need to transfer the plugin to a different account. We can fix the plugin.
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 use gmail, you won’t be able to send a ZIP file if it contains any JS files (yes, we know it’s stupid, blame Google).
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.)