Prep for WordPress.org Release

[bd-viget]

List of issues found

Tested Up To Value is Out of Date, Invalid, or Missing

The tested up to value in your plugin is not set to the current version of WordPress. This means your plugin will not show up in searches, as we require plugins to be compatible and documented as tested up to the most recent version of WordPress.

Please update your readme to show that it is tested up to the most recent stable major version of WordPress. For example if WordPress said that version 99.3.2 was the current release, you would be able to set your value to 99.3 as that's the major release.

The following links will assist you in understanding WordPress's versioning and the latest version:

https://wordpress.org/download/
https://make.wordpress.org/core/handbook/about/release-cycle/version-numbering/

You cannot set it beyond the current version, as that will cause your plugin not to be available on searches. Also remember that WordPress has made late changes in releases, so claiming compatibility with an incomplete version is likely to land you in trouble.

From your readme file:

ERROR: Tested up to: "6.7.2" needs to be just the major version number. Example: Tested up: 6.7
ℹ️ Please, include only the major WordPress version, as the minor version is ignored.

Use wp_enqueue commands

Your plugin is not correctly including JS and/or CSS. You should be using the built in functions for this:

When including JavaScript code you can use:

• wp_register_script() and wp_enqueue_script() to add JavaScript code from a file.
• wp_add_inline_script() to add inline JavaScript code to previous declared scripts.

When including CSS you can use:

• wp_register_style() and wp_enqueue_style() to add CSS from a file.
• wp_add_inline_style() to add inline CSS to previously declared CSS.

Note that as of WordPress 6.3, you can easily pass attributes like defer or async: https://make.wordpress.org/core/2023/07/14/registering-scripts-with-async-and-defer-attributes-in-wordpress-6-3/

Also, as of WordPress 5.7, you can pass other attributes by using this 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:
src/classes/BreakpointVisibility.php:82 "<style>%s</style>\n",

Calling files remotely

Offloading images, js, css, and other scripts to your servers or any remote service (like Google, MaxCDN, jQuery.com etc) is disallowed. When you call remote data you introduce an unnecessary dependency on another site. If the file you're calling 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.

An exception to this rule is if your plugin is performing a service. We will permit this on a case by case basis. 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 external dependencies 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.

Example(s) from your plugin:

includes/parts-kit.php:141 'large'            => 'https://placehold.co/771x1024/EEE/31343C',
includes/parts-kit.php:135 'thumbnail'        => 'https://placehold.co/150x150/EEE/31343C',
includes/parts-kit.php:116 'url'         => 'https://placehold.co/600x400/EEE/31343C',
includes/parts-kit.php:138 'medium'           => 'https://placehold.co/226x300/EEE/31343C',
includes/parts-kit.php:117 'link'        => 'https://placehold.co/600x400/EEE/31343C',
includes/parts-kit.php:131 'icon'        => 'https://viget-wp-boilerplate.vgt.site/wp-includes/images/media/default.png',

Determine files and directories locations correctly

WordPress provides several functions for easily determining where a given file or directory lives.

We detected that the way your plugin references some files, directories and/or URLs may not work with all WordPress setups. This happens because there are hardcoded references or you are using the WordPress internal constants.

Let's improve it, please check out the following documentation:

https://developer.wordpress.org/plugins/plugin-basics/determining-plugin-and-content-directories/

It contains all the functions available to determine locations correctly.

Most common cases in plugins can be solved using the following functions:

• For where your plugin is located: plugin_dir_path() , plugin_dir_url() , plugins_url()
• For the uploads directory: wp_upload_dir() (Note: If you need to write files, please do so in a folder in the uploads directory, not in your plugin directories).

Example(s) from your plugin:
src/classes/BlockRegistration.php:221 wp_normalize_path( untrailingslashit( ABSPATH ) ),

Data Must be Sanitized, Escaped, and Validated

When you include POST/GET/REQUEST/FILE 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: Data that is input (either by a user or automatically) must be sanitized as soon as possible. This lessens the possibility of XSS vulnerabilities and MITM attacks where posted data is subverted.

VALIDATE: All data should be validated, no matter what. Even when you sanitize, remember that you don’t want someone putting in ‘dog’ when the only valid values are numbers.

ESCAPE: Data that is output must be escaped properly when it is echo'd, 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.

To help you with this, WordPress comes with a number of sanitization and escaping functions. You can read about those here:

• https://developer.wordpress.org/apis/security/sanitizing/
• https://developer.wordpress.org/apis/security/escaping/

Remember: You must use the most appropriate functions for the context. If you’re sanitizing email, use sanitize_email(), if you’re outputting HTML, use wp_kses_post(), and so on.

An easy mantra here is this:

Sanitize early
Escape Late
Always Validate

Clean everything, check everything, escape everything, and never trust the users to always have input sane data. After all, users come from all walks of life.

Example(s) from your plugin:

src/classes/Settings.php:119 return str_replace( 'acf/', '', $rule['value'] );
# ↳ This was found inside a foreach loop in the line 113 iterating over $group
# ↳ This was found inside a foreach loop in the line 113 iterating over $group

✔️ You can check this using Plugin Check.

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:
src/classes/BlockIcons.php:296 $this->editor_css()

✔️ You can check this using Plugin Check.

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. We need you to update your plugin to use more unique and distinct names.

A good way to do this is with a prefix. For example, if your plugin is called "Viget Blocks Toolkit" then you could use names like these:

• function vigeblto_save_post(){ ... }
• class VIGEBLTO_Admin { ... }
• update_option( 'vigeblto_settings', $settings );
• define( 'VIGEBLTO_PLUGIN_DIR', plugin_dir_path( FILE ) );
• global $vigeblto_options;
• namespace viget\vigetblockstoolkit;

Disclaimer: These are just examples that may have been self-generated from your plugin name, we trust you can find better options. If you have a good alternative, please use it instead, this is just an example.

Don't try to use two (2) or three (3) letter prefixes anymore. We host nearly 100-thousand plugins on WordPress.org alone. There are tens of thousands more outside our servers. Believe us, you’re going to run into conflicts.

You also need to avoid the use of __ (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 remember, if you're using _n() or __() for translation, that's fine. We're only talking about functions you've created for your plugin, not the core functions from WordPress. In fact, those core features are why you need to not use those prefixes in your own plugin! You don't want to break WordPress for your users.

Related to this, using if (!function_exists('NAME')) { around all your functions and classes sounds like a great idea until you realize the fatal flaw. If something else has a function with the same name and their code loads first, your plugin will break. Using if-exists should be reserved for shared libraries only.

Remember: Good prefix names are unique and distinct to your plugin. This will help you and the next person in debugging, as well as prevent conflicts.

Analysis result:

# This plugin is using the prefix "viget_blockstoolkit" for 2 element(s).
# This plugin is using the prefix "vgtbt" for 27 element(s).
# This plugin is using the prefix "get" for 7 element(s).

# Cannot use "block" as a prefix.
includes/helpers.php:31 function block_attrs
# Cannot use "get" as a prefix.
includes/helpers.php:119 function get_block_id
includes/helpers.php:147 function get_block_class
includes/helpers.php:224 function get_block_from_blocks
includes/helpers.php:251 function get_block_fields
includes/helpers.php:299 function get_field_property
includes/helpers.php:427 function get_core_classes
includes/helpers.php:458 function get_core_styles
# Cannot use "is" as a prefix.
includes/helpers.php:393 function is_acf_saving_field

# Looks like there are elements not using common prefixes.
includes/helpers.php:345 function inner_blocks
includes/helpers.php:372 function print_admin_message

Allowing Direct File Access to plugin files

Direct file access occurs when someone directly queries a PHP file. This can be done by entering the complete path to the file in the browser's URL bar or by sending a POST request directly to the file.

For files that only contain class or function definitions, the risk of something funky happening when accessed directly is minimal. However, for files that contain executable code (e.g., function calls, class instance creation, class method calls, or inclusion of other PHP files), the risk of security issues is hard to predict because it depends on the specific case, but it can exist and it can be high.

You can easily prevent this by adding the following code at the top of all PHP files that could potentially execute code if accessed directly:
if ( ! defined( 'ABSPATH' ) ) exit; // Exit if accessed directly

Example(s) from your plugin:
includes/parts-kit.php:10
views/jsx.php:10
viget-blocks-toolkit.php:20
views/default.php:11