Нужен розработчик плагинов на вордпрес

Есть некоторие баги и нужно их исправить в плагине а то плагин не хотят принимать

We are a group of volunteers who help you identify common issues so that you can make your plugin more secure, compatible, reliable and compliant with the guidelines.

There are issues with your plugin code preventing it from being approved immediately. We have pended your submission in order to help you correct all issues so that it may be approved and published.

We ask you read this email in its entirety, address all listed issues, and reply to this email after uploading a corrected version of your code. Failure to do so will result in your review being delayed or even rejected.

We know this email can be long, but we kindly ask you to be meticulous in fixing the issues we mention so that we can make the best use of our volunteer time and get your plugin approved as soon as possible.

Remember that in addition to code quality, security and functionality, we require all plugins to adhere to our guidelines. If you have not yet, please read them: https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

Finally, should you at any time wish to alter your permalink (aka the plugin slug), you must explicitly tell us what you want it to be. Just changing the display name is not sufficient, and we require to you clearly state your desired permalink. Remember, permalinks cannot be altered after approval.

Be aware that you will not be able to submit another plugin while this one is being reviewed.

## Incomplete Readme

Your readme is either missing or incomplete.

In some cases, such as for first plugins, ones with dependencies, or plugins that call external services, we require you to provide a complete readme. This means your readme has to have headers as well as a proper description and documentation as to how it works and how one can use it.

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 to other servers. You are expected to provide users with all the information they need before they install your plugin.

Your readme also must validate per https://wordpress.org/plugins/about/validator/ or we will reject it. Keep in mind, we don't want to see a readme.MD. While they can work, a readme.txt file will always be given priority, and not all of the markdown will work as expected.

We ask you please create your readme one based on this: https://wordpress.org/plugins/readme.txt

Analysis result:

ERROR: Plugin Name not 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.0.1 was the current release, you would be able to set your value to 99.0 or 99.0.1, as 99.0.1 would be considered a minor 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: 5.8 < 6.5

## No GPL-compatible license declared

It is necessary to declare the license of this plugin. You can do this using the fields available both in the plugin readme and in the plugin headers.

Remember that all code, data, and images — anything stored in the plugin directory hosted on WordPress.org — must comply with the GPL or a GPL-Compatible license. Included third-party libraries, code, images, or otherwise, must be also compatible

For a specific list of compatible licenses, please read the GPL-Compatible license list on gnu.org.

The license declared on this plugin is either no present or it's not GPL compatible:

ERROR: License declaration not found on index.php

Please check the header requirements in order to correctly declare the license of the plugin: https://developer.wordpress.org/plugins/plugin-basics/header-requirements/

It is necessary to configure the "License: " field in the plugin header with a valid, GPL-compliant license name.

## The main file of the plugin has a name that does not follow the convention.

We expect the main plugin file (the file containing the plugin headers) to have the same name as the plugin folder, which is also the same name as the slug / permalink of the plugin.

For example, if your plugin slug is ecpt-social-manager we expect your main plugin filename to be ecpt-social-manager.php

Note that using some common names as the filename for the main plugin file can lead to issues in some configurations.

Please check out our tips on how to structure files and folders in a plugin.

The main file of this plugin is named index.php

## Not permitted files

A plugin typically consists of files related to the plugin functionality (php, js, css, txt, md) and maybe some multimedia files (png, svg, jpg) and / or data files (json, xml).

We have detected files that are not among of the files normally found in a plugin, are they necessary? If not, then those won't be allowed.

Example(s) from your plugin:

24_00-10-11_Archive/dist/admin/screen-min.jpg:Zone.Identifier

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

24_00-10-11_Archive/dist/views/widgets/mail.view.php:5  ...</title><style>img{border:none;-ms-interpolation-mode:bicubic;max-width:100%}body{background-color:#f6f6f6;font-family:sans-serif;-webkit-font-smoothing:antialiased;font-size:14px;line-height:1.4;marg... 

## Don't Force Set PHP Limits Globally

While many plugins can need optimal settings for PHP, we ask you please not set them as global defaults.

Having defines like ini_set('memory_limit', '-1'); run globally (like on init or in the __construct() part of your code) means you'll be running that for everything on the site, which may cause your users to fall out of compliance with any limits or restrictions on their host.

If you must use those, you need to limit them specifically to only the exact functions that require them.

Example(s) from your plugin:

24_00-10-11_Archive/dist/rein/monitor/Scan.php:84 set_time_limit(0);

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

24_00-10-11_Archive/dist/rein/monitor/DashboardForm.php:39 foreach($_POST['ids'] as $id) { $id = intval($id); if($id < 1) return; // incorrect param value  $this->_ids[] = $id; }
24_00-10-11_Archive/dist/rein/monitor/DashboardController.php:20 $form->load(isset($_POST) ? $_POST : []);

## Processing the whole input

We strongly recommend you never attempt to process the whole $_POST/$_REQUEST/$_GET stack. This makes your plugin slower as you're needlessly cycling through data you don't need. Instead, you should only be attempting to process the items within that are required for your plugin to function.

Example(s) from your plugin:

24_00-10-11_Archive/dist/rein/monitor/DashboardController.php:20 $form->load(isset($_POST) ? $_POST : []);

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

24_00-10-11_Archive/dist/views/widgets/table-top.view.php:7 <span>Last Scan: <?php echo date('F j, Y g:i A', intval($table->scan->datetime)) ?></span>

## Allowing Direct File Access to plugin files

Direct file access is when someone directly queries your file. This can be done by simply entering the complete path to the file in the URL bar of the browser but can also be done by doing a POST request directly to the file. For files that only contain a PHP class the risk of something funky happening when directly accessed is pretty small. For files that contain procedural code, functions and function calls, the chance of security risks is a lot bigger.

You can avoid this by putting this 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:

24_00-10-11_Archive/dist/views/dashboard/index.view.php:3 
24_00-10-11_Archive/dist/views/widgets/mail.view.php:3 
24_00-10-11_Archive/dist/views/dashboard/help.view.php:2 
24_00-10-11_Archive/dist/views/widgets/table-top.view.php:1 

## Unsafe SQL calls

When making database calls, it's highly important to protect your code from SQL injection vulnerabilities. You need to update your code to use wpdb calls and prepare() with your queries to protect them.

Please review the following:

• https://developer.wordpress.org/reference/classes/wpdb/#protect-queries-against-sql-injection-attacks
• https://codex.wordpress.org/Data_Validation#Database
• https://make.wordpress.org/core/2012/12/12/php-warning-missing-argument-2-for-wpdb-prepare/
• https://ottopress.com/2013/better-know-a-vulnerability-sql-injection/

Example(s) from your plugin:

24_00-10-11_Archive/dist/rein/common/Table.php:144 $sql = sprintf("SELECT * FROM `%s`", static::tableName());
24_00-10-11_Archive/dist/rein/common/Table.php:188 $sql.= " OFFSET $offset";
24_00-10-11_Archive/dist/rein/common/Table.php:184 $sql.= " LIMIT $limit";
24_00-10-11_Archive/dist/rein/common/Table.php:174 $sql.= sprintf(" order by `%s` %s", $attribute, $direction);
24_00-10-11_Archive/dist/rein/common/Table.php:166 $sql.= sprintf(" order by `%s` %s", static::primaryKey(), $order);
24_00-10-11_Archive/dist/rein/common/Table.php:156 $sql.= static::prepareSqlCondition($name, $value);
24_00-10-11_Archive/dist/rein/common/Table.php:153 $sql.= static::prepareSqlCondition($name, $value, '');
24_00-10-11_Archive/dist/rein/common/Table.php:149 $sql.= ' WHERE ';
24_00-10-11_Archive/dist/rein/common/Table.php:192 $rows = $wpdb->get_results($sql, 'ARRAY_A');
# The SQL query needs to be included in a wpdb::prepare($query, $args) function.
# Remember that you will need to include placeholders for each variable within the query and include their calls in the second parameter of wpdb::prepare().
# You cannot add variables like "$limit" directly to the SQL query. You need to use wpdb::prepare.
# Remember that using wpdb::prepare($query, $args) you will need to include placeholders for each variable within the query and include the variables in the second parameter.
# You cannot add variables like "$offset" directly to the SQL query. You need to use wpdb::prepare.


24_00-10-11_Archive/dist/rein/monitor/Scan.php:72 return $wpdb->get_var(sprintf('SELECT COUNT(1) FROM %s', static::tableName())) > 0 ? false : true;
# The SQL query needs to be included in a wpdb::prepare($query, $args) function.
# Remember that you will need to include placeholders for each variable within the query and include their calls in the second parameter of wpdb::prepare().

... out of a total of 5 incidences.