Download the PHP package thetwopct/wp-org-submission-rules without Composer
On this page you can find all versions of the php package thetwopct/wp-org-submission-rules. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package wp-org-submission-rules
WordPress.org-specific plugin review code sniffs
When submitting a plugin to the WordPress.org repo, there are several checks that the plugin review team apply to your plugin, but which are not fully covered by WordPress Coding Standards or included in the Plugin Check (PCP) plugin.
This sniff ruleset tries to bring attention to and fix some of the checks that are missed.
This is an additional ruleset you can add to PHPCSStandards PHP_CodeSniffer. PHP CodeSniffer tokenizes PHP files and detects violations of a defined set of coding standards, and also corrects coding standard violations. PHP_CodeSniffer is an essential development tool that ensures your code remains clean and consistent.
If you use these sniffs and indeed PHP_CodeSniffer I would urge you to donate something to the project as without funding it will go away and all our code will be worse off.
Install
The sniffs have been released on to Packagist, so installation should be as simple as running:
You can then check that the ruleset (WPOrgSubmissionRules) is now installed:
You can then add it to your custom .phpcs.xml file to include in your sniffs:
or access the standard directly from the command line as per other standards:
or to run over your whole code:
One of the rules looks for unique names of variables, and you can add a prefix in your custom rules:
What the sniffs detect:
Here are some of the review issues from WordPress.org that these sniffs try to make sure you avoid:
1) Use wp_enqueue commands
Any inline CSS or JS is flagged via <script> or <style> tags.
Sniff: WPOrgSubmissionRules.ForbiddenTags.ForbiddenInlineTags
2) Generic function/class/define/namespace/option names
All plugins must have unique function names, namespaces, defines, class and option names. This prevents your plugin from conflicting with other plugins or themes. WordPress.org expect your plugin to use unique and distinct names.
Sniff: WPOrgSubmissionRules.Naming.UniqueName
3) Options and Transients must be prefixed
This is really important because the options are stored in a shared location and under the name you have set. If two plugins use the same name for options, they will find an interesting conflict when trying to read information introduced by the other plugin.
Sniff: WPOrgSubmissionRules.Naming.UniqueName
4) Internationalization: Don't use variables or defines as text, context or text domain parameters
In order to make a string translatable in your plugin you are using a set of special functions. These functions collectively are known as "gettext". There is a dedicated team in the WordPress community to translate and help other translating strings of WordPress core, plugins and themes to other languages.
To make them be able to translate this plugin, please do not use variables or function calls for the text, context or text domain parameters of any gettext function, all of them NEED to be strings. Note that the translation parser reads the code without executing it, so it won't be able to read anything that is not a string within these functions.
Sniff: WPOrgSubmissionRules.Internationalization.TranslationFunctionStringLiteral
5) Prefix length requirements
WordPress.org requires prefixes to be at least 4 characters long. The sniff detects short prefixes by extracting the part before the first underscore (this is dumb, but we need to play by their rules):
ABC_For_ACF→ prefix isABC(3 chars, too short ❌)abcfacf_save_post→ prefix isabcfacf(8 chars, OK ✅)
Sniff: WPOrgSubmissionRules.Naming.PrefixLength
6) Reserved prefixes (wp, , __)
WordPress reserves certain prefixes for core functionality:
wp_- Reserved for WordPress core_(single underscore) - Reserved for WordPress internal use__(double underscore at start) - Reserved for magic methods
Sniff: WPOrgSubmissionRules.Naming.PrefixLength
7) Security: Nonce checks required
Any usage of $_POST, $_GET, or $_REQUEST must be accompanied by proper nonce verification using:
wp_verify_nonce()check_ajax_referer()check_admin_referer()
Also warns about using these superglobals outside of functions (performance issue).
Sniff: WPOrgSubmissionRules.Security.NonceCheck
8) Anti-pattern: function_exists() wrapper
Using if (!function_exists('name')) { function name() {...} } is an anti-pattern. If another plugin has a function with the same name and loads first, your plugin will silently fail. Use unique prefixes instead.
Sniff: WPOrgSubmissionRules.Naming.FunctionExistsWrapper
Active development
This package is under constant development and will be updated to reflect new checks that the Plugin Team review process throws at us. If you have feedback on these sniffs and want us to add new custom sniffs, please open an issue. This file can be found in our GitHub repo.
