WordPress Plugins » Tag: fb - Recent Postshttps://wordpress.org/plugins/tags/fb
WordPress Plugins » Tag: fb - Recent Postsen-USSun, 02 Aug 2015 21:34:59 +0000http://bbpress.org/?v=1.1Login Page Designerhttps://wordpress.org/plugins/login-page-designer/#post-84562
Mon, 13 Jul 2015 18:47:01 +0000Ipstenu (Mika Epstein)84562@http://wordpress.org/plugins/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 your plugin being rejected.

## 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.

## 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.

Including wp-config.php, wp-blog-header.php, wp-load.php, or pretty much any other WordPress core file that you have to call directly via an include is not a good idea and we cannot approve a plugin that does so unless it has a very good reason to load the file(s). It is prone to failure since not all WordPress installs have the exact same file structure.

Usually plugins will include wp-config.php or wp-load.php in order to gain access to core WordPress functions, but there are much better ways to do this. It's best if you tie your processing functions (the ones that need but don't have access to core functions) into an action hook, such as "init" or "admin_init".

If you're trying to use it because you need to access WordPress functions outside of WordPress, we'd actually much rather you didn't do that at all. Your plugin should be inside WordPress, only accessible to people who are logged in and authorized, if it needs that kind of access. Your plugin's pages should be called via the dashboard like all the other settings panels, and in that way, they'll always have access to WordPress functions.

----

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.

We do not permit plugins to phone home for license validation unless the plugin is providing a service that cannot be completed on the user's server.

For example, a plugin like Akismet is processing spam on their own servers, and passing the data back to the users via an API. This is a service.

On the other hand, a plugin that simply validates a license and 'unlocks' functionality that's already in the plugin is not a service.

This is explained in more detail in our guidelines (http://wordpress.org/plugins/about/guidelines/) under "Serviceware"
Please remove the license check from your plugin. Alternately, you may provide more information as to how you are providing a service. Remember. The service needs to be running from an external server.

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.

A readme.txt is needed so your plugin will display correctly in our repository, but also 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 Akismet or Twitter), we permit it. The catch is you have to actually explain this to the layman in your readme, so they know where data is going.

Your readme MUST validate per http://wordpress.org/plugins/about/validator/ or we will reject it. Keep in mind, we don't want to see a readme.MD. Among other things, the formatting for markup is different, and the filetype isn't read by our system.

Please send a link so the completed plugin can be downloaded. Alternately you can reply to this and send a .zip file. Note: We would like you to send the whole plugin, not just the readme, as we will re-review your entire code as a whole.

As this is for a new plugin request, please reply within seven days of this email or we will reject your plugin.

A readme.txt is needed so your plugin will display correctly in our repository, but also 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 Akismet or Twitter), we permit it. The catch is you have to actually explain this to the layman in your readme, so they know where data is going.

Your readme MUST validate per http://wordpress.org/plugins/about/validator/ or we will reject it. Keep in mind, we don't want to see a readme.MD. Among other things, the formatting for markup is different, and the filetype isn't read by our system.

Please send a link so the completed plugin can be downloaded. Alternately you can reply to this and send a .zip file. Note: We would like you to send the whole plugin, not just the readme, as we will re-review your entire code as a whole.

As this is for a new plugin request, please reply within seven days of this email or we will reject your plugin.