It's required that all code be compatible with GPL to be included in our repository.

FancyBox v2 and up is not GPL compatible, as it has been licensed Creative Commons.

Please remove FancyBox and alter the plugin so it is not required. If you cannot alter the code, we suggest you find alternate code that is GPL compatible and use that instead. For more information on what types of licenses are compatible with GPL, please review the following links:

WordPress includes its own version of jquery and many other similar JS files, which have all been rigorously tested with WP and many of the most common plugins. In order to provide the best compatibility and experience for our users, we ask that you not package your own (especially not an older version) and instead use wp_enqueue_script() to pull in WordPress's version.

Please review http://codex.wordpress.org/Function_Reference/wp_enqueue_script and update your plugin accordingly. You need to both change your code to use our jquery as well as remove the unused files. Remember! Keeping unused files out of your plugins makes them smaller and less potentially vulnerable! if you have any jquery files included in your plugin that WP core has, just delete them.

Offloading jquery js, css, and other scripts to Google (or jquery.com or anywhere else frankly) is similarly disallowed for the same reasons, but also 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 your code doesn't work with the built-in versions of jquery, it's most likely a no conflict issue. If you can't guess, we -really- want you to use our JS files, and if you can't, we need to know why so we can fix things for everyone. If you're just including it because you want to support old versions of WP, or because you think they may not have jquery, please don't. If they don't have the default jquery, a lot more than your plugin will break. And if they're on older versions of WordPress, they need to upgrade, and we don't recommend you support anything except the most recent version of WP and one release back.

The primary issue with PHP's short tags is that PHP managed to choose a tag (<?) that was used by another syntax, XML.

With the option enabled, you weren't able to raw output the xml declaration without getting syntax errors:

<?xml version="1.0" encoding="UTF-8" ?>

This is a big issue when you consider how common XML parsing and management is.

While as of PHP 5.4, <?= ... ?> tags are supported everywhere, regardless of short tags settings. This should mean they're safe to use in portable code but that does mean there's then a dependency on PHP 5.4+. If you want to support pre-5.4 and can't guarantee short tags, you'll still need to use <?php echo ... ?>.

At this time, we ask that no plugin use PHP short tags, for sanity.

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.

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.

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.

WordPress includes its own version of jquery and many other similar JS files, which have all been rigorously tested with WP and many of the most common plugins. In order to provide the best compatibility and experience for our users, we ask that you not package your own (especially not an older version) and instead use wp_enqueue_script() to pull in WordPress's version.

Please review http://codex.wordpress.org/Function_Reference/wp_enqueue_script and update your plugin accordingly. You need to both change your code to use our jquery as well as remove the unused files. Remember! Keeping unused files out of your plugins makes them smaller and less potentially vulnerable! if you have any jquery files included in your plugin that WP core has, just delete them.

Offloading jquery js, css, and other scripts to Google (or jquery.com or anywhere else frankly) is similarly disallowed for the same reasons, but also 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 your code doesn't work with the built-in versions of jquery, it's most likely a no conflict issue. If you can't guess, we -really- want you to use our JS files, and if you can't, we need to know why so we can fix things for everyone. If you're just including it because you want to support old versions of WP, or because you think they may not have jquery, please don't. If they don't have the default jquery, a lot more than your plugin will break. And if they're on older versions of WordPress, they need to upgrade, and we don't recommend you support anything except the most recent version of WP and one release back.

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.

All instances where $_POST data is inserted into the database, or into a file, MUST be properly sanitized for security. This also holds true for $_REQUEST calls that are processed. In addition, by sanitizing your POST data, you will lessen the possibility of XSS vulnerabilities.
Using stripslashes is not enough, you need to use the Input Validation methods, or things similar, to protect your plugin. The ultimate goal is that you should ensure that invalid data is NEVER processed.