Remember in addition to code quality, security and functionality, we require all plugins adhere to our guidelines. If you have not yet, please read them:* https://developer.wordpress.or
define( ‘ECPT_LICENSE’, true );
namespace EasyCustomPostTypes;Don’t try to use two letter slugs anymore. We have over 60 THOUSAND plugins on WordPress.org alone, you’re going to run into conflicts.
Similarly, don’t use __ (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.
Remember: Good names are unique and distinct. This will help you and the next person in debugging, as well as prevent conflicts.
Some examples from your plugin:
## 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:
if ( ! defined( ‘ABSPATH’ ) ) exit; // Exit if accessed directly
## Not using Nonces and/or checking permissions
Please add a nonce to your POST calls to prevent unauthorized access.
Keep in mind, check_admin_referer alone is NOT bulletproof security. Do not rely on nonces for authorization purposes. Use current_user_can() in order to prevent users without the right permissions from accessing things.
## Please sanitize, escape, and validate your POST calls
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. This lessens the possibility of XSS vulnerabilities and MITM attacks where posted data is subverted.
VALIDATE: All data should be validated as much as possible. 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, 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.or
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 esc_html(), and so on.
Clean everything, check everything, escape everything, and never trust the users to always have input sane data.
Some examples from your plugin:
add_option( ‘woo_wa_phone_number’, $_POST[‘woo_wa_phone_number’] );