Received via email on: 18.07.2023
Reviewed Version: v2.0.0
Review Comment:
Incorrect Stable Tag
In your readme, your 'Stable Tag' does not match the Plugin Version as indicated in your main plugin file.
ERROR: Stable tag shall not be trunk
wc-solana-pay.php - Version: 2.0.0
Your Stable Tag is meant to be the stable version of your plugin, not of WordPress. For your plugin to be properly downloaded from WordPress.org, those values need to be the same. If they're out of sync, your users won't get the right version of your code.
We recommend you use Semantic Versioning (aka SemVer) for managing versions:
Please note: While currently using the stable tag of trunk currently works in the Plugin Directory, it's not actually a supported or recommended method to indicate new versions and has been known to cause issues with automatic updates.
We ask you please properly use tags and increment them when you release new versions of your plugin, just like you update the plugin version in the main file. Having them match is the best way to be fully forward supporting.
Please use wp_enqueue commands
Your plugin is not correctly including JS and/or CSS. You should be using the built in functions for this:
Example(s) from your plugin:
wc-solana-pay/public/partials/public-place-order-button.php:39:<script type="text/javascript">
No publicly documented resource for your compressed content
In reviewing your plugin, we cannot find a non-compiled version of your javascript related source code.
In order to comply with our guidelines of human-readable code, we require you to include a link to the non-compressed, developer libraries you’ve included in your plugin. This may be in your source code, however we require you to also have it in your readme.
We strongly feel that one of the strengths of open source is the ability to review, observe, and adapt code. By maintaining a public directory of freely available code, we encourage and welcome future developers to engage with WordPress and push it forward.
That said, with the advent of larger and larger plugins using more complex libraries, people are making good use of build tools (such as composer or npm) to generate their distributed production code. In order to balance the need to keep plugin sizes smaller while still encouraging open source development, we require plugins to make the source code to any compressed files available to the public in an easy to find location, by documenting it in the readme.
For example, if you’ve made a Gutenberg plugin and used npm and webpack to compress and minify it, you must either include the source code within the published plugin or provide access to a public maintained source that can be reviewed, studied, and yes, forked.
We strongly recommend you include directions on the use of any build tools to encourage future developers.
Much related to sanitizing everything, all variables that are echoed need to be escaped when they're echoed, so it can't hijack users or (worse) admin screens. There are many esc_*() functions you can use to make sure you don't show people the wrong data, as well as some that will allow you to echo HTML safely.
At this time, we ask you escape all $-variables, options, and any sort of generated data when it is being echoed. That means you should not be escaping when you build a variable, but when you output it at the end. We call this 'escaping late.'
Besides protecting yourself from a possible XSS vulnerability, escaping late makes sure that you're keeping the future you safe. While today your code may be only outputted hardcoded content, that may not be true in the future. By taking the time to properly escape when you echo, you prevent a mistake in the future from becoming a critical security issue.
This remains true of options you've saved to the database. Even if you've properly sanitized when you saved, the tools for sanitizing and escaping aren't interchangeable. Sanitizing makes sure it's safe for processing and storing in the database. Escaping makes it safe to output.
Also keep in mind that sometimes a function is echoing when it should really be returning content instead. This is a common mistake when it comes to returning JSON encoded content. Very rarely is that actually something you should be echoing at all. Echoing is because it needs to be on the screen, read by a human. Returning (which is what you would do with an API) can be json encoded, though remember to sanitize when you save to that json object!
There are a number of options to secure all types of content (html, email, etc). Yes, even HTML needs to be properly escaped.
Remember: You must use the most appropriate functions for the context. There is pretty much an option for everything you could echo. Even echoing HTML safely.
Received via email on: 18.07.2023 Reviewed Version: v2.0.0 Review Comment:
Incorrect Stable Tag
In your readme, your 'Stable Tag' does not match the Plugin Version as indicated in your main plugin file.
ERROR: Stable tag shall not be trunk wc-solana-pay.php - Version: 2.0.0
Your Stable Tag is meant to be the stable version of your plugin, not of WordPress. For your plugin to be properly downloaded from WordPress.org, those values need to be the same. If they're out of sync, your users won't get the right version of your code.
We recommend you use Semantic Versioning (aka SemVer) for managing versions:
https://en.wikipedia.org/wiki/Software_versioning https://semver.org/
Please note: While currently using the stable tag of trunk currently works in the Plugin Directory, it's not actually a supported or recommended method to indicate new versions and has been known to cause issues with automatic updates.
We ask you please properly use tags and increment them when you release new versions of your plugin, just like you update the plugin version in the main file. Having them match is the best way to be fully forward supporting.
Please use wp_enqueue commands
Your plugin is not correctly including JS and/or CSS. You should be using the built in functions for this:
https://developer.wordpress.org/reference/functions/wp_enqueue_script/ https://developer.wordpress.org/reference/functions/wp_enqueue_style/
And remember you can use this function to add inline javascript:
https://developer.wordpress.org/reference/functions/wp_add_inline_script/
As of WordPress 5.7, you can pass attributes like async, nonce, and type by using new functions and filters:
https://make.wordpress.org/core/2021/02/23/introducing-script-attributes-related-functions-in-wordpress-5-7/
If you're trying to enqueue on the admin pages you'll want to use the admin enqueues
https://developer.wordpress.org/reference/hooks/admin_enqueue_scripts/ https://developer.wordpress.org/reference/hooks/admin_print_scripts/ https://developer.wordpress.org/reference/hooks/admin_print_styles/
Example(s) from your plugin:
wc-solana-pay/public/partials/public-place-order-button.php:39:<script type="text/javascript">
No publicly documented resource for your compressed content
In reviewing your plugin, we cannot find a non-compiled version of your javascript related source code.
In order to comply with our guidelines of human-readable code, we require you to include a link to the non-compressed, developer libraries you’ve included in your plugin. This may be in your source code, however we require you to also have it in your readme.
https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#4-code-must-be-mostly-human-readable
We strongly feel that one of the strengths of open source is the ability to review, observe, and adapt code. By maintaining a public directory of freely available code, we encourage and welcome future developers to engage with WordPress and push it forward.
That said, with the advent of larger and larger plugins using more complex libraries, people are making good use of build tools (such as composer or npm) to generate their distributed production code. In order to balance the need to keep plugin sizes smaller while still encouraging open source development, we require plugins to make the source code to any compressed files available to the public in an easy to find location, by documenting it in the readme.
For example, if you’ve made a Gutenberg plugin and used npm and webpack to compress and minify it, you must either include the source code within the published plugin or provide access to a public maintained source that can be reviewed, studied, and yes, forked.
We strongly recommend you include directions on the use of any build tools to encourage future developers.
wc-solana-pay/assets/script/wc_solana_pay-869b3859.js
Variables and options must be escaped when echo'd
Much related to sanitizing everything, all variables that are echoed need to be escaped when they're echoed, so it can't hijack users or (worse) admin screens. There are many esc_*() functions you can use to make sure you don't show people the wrong data, as well as some that will allow you to echo HTML safely.
At this time, we ask you escape all $-variables, options, and any sort of generated data when it is being echoed. That means you should not be escaping when you build a variable, but when you output it at the end. We call this 'escaping late.'
Besides protecting yourself from a possible XSS vulnerability, escaping late makes sure that you're keeping the future you safe. While today your code may be only outputted hardcoded content, that may not be true in the future. By taking the time to properly escape when you echo, you prevent a mistake in the future from becoming a critical security issue.
This remains true of options you've saved to the database. Even if you've properly sanitized when you saved, the tools for sanitizing and escaping aren't interchangeable. Sanitizing makes sure it's safe for processing and storing in the database. Escaping makes it safe to output.
Also keep in mind that sometimes a function is echoing when it should really be returning content instead. This is a common mistake when it comes to returning JSON encoded content. Very rarely is that actually something you should be echoing at all. Echoing is because it needs to be on the screen, read by a human. Returning (which is what you would do with an API) can be json encoded, though remember to sanitize when you save to that json object!
There are a number of options to secure all types of content (html, email, etc). Yes, even HTML needs to be properly escaped.
https://developer.wordpress.org/apis/security/escaping/
Remember: You must use the most appropriate functions for the context. There is pretty much an option for everything you could echo. Even echoing HTML safely.
Example(s) from your plugin:
wc-solana-pay/public/partials/public-place-order-button.php:40 <?php echo $script; // phpcs:ignore WordPress.Security.EscapeOutput.OutputNotEscaped ?>
-----> echo $script;
wc-solana-pay/admin/partials/admin-tokens-table.php:195 <?php echo $script; // phpcs:ignore WordPress.Security.EscapeOutput.OutputNotEscaped ?>
-----> echo $script;
wc-solana-pay/admin/partials/admin-tokens-table.php:185
-----> echo wc_help_tip($tip, true);
wc-solana-pay/admin/partials/admin-tokens-table.php:191 <?php echo $body; // phpcs:ignore WordPress.Security.EscapeOutput.OutputNotEscaped ?>
-----> echo $body;