Pengalaman Pertama Ditolak ketika Submit Plugin WordPress


Malam sabtu kemarin (31-08-2018), saya mulai ngulik tentang pembuatan plugin di WordPress. Biar lebih paham, saya sengaja langsung bikin project sebuah plugin sederhana. Bisa dicek disini: https://github.com/azishapidin/woo-whatsapp. Saking sederhananya, kode dari plugin tsb pun hanya terdiri 100+ baris saja.

 

Tiga hari kemudian karena penasaran, saya langsung submit plugin buatan saya tsb ke Directory Plugin resmi WordPress. Setelah saya nunggu review dari pihak WordPress, akhirnya pagi ini dapat email review yang inti-nya masih ada beberapa issue di kode saya, yang bikin saya salut adalah mereka menjelaskan secara detail kepada saya kesalahan dan saran untuk memperbaiki kode-nya. Ini ilmu baru bagi saya, dan bisa jadi catatan buat temen-temen kalau nanti mau bikin Plugin WordPress.

 

Jadi rencana hari ini atau beberapa hari ke depan saya mau coba memperbaiki kode di plugin tsb berdasarkan email dari pihak WordPress. Berikut isi email-nya:

 

====================
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.org/plugins/wordpress-org/detailed-plugin-guidelines/You will not be able to submit another plugin while this one is being reviewed, so please read the email carefully. We know it can be long, but you must follow the directions at the end as not doing so will result in your review being delayed.## Generic function (and/or define) namesAll plugins must have unique function names, namespaces, defines, and classnames. 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 “Easy Custom Post Types” then you could use names like these:
function ecpt_save_post()
define( ‘ECPT_LICENSE’, true );
class ECPT_Admin{}
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:

function activatePlugin()
function waButton()

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

https://codex.wordpress.org/WordPress_Nonces

## 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.org/plugins/security/securing-input/

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’] );

===

 

Ada beberapa baris diawal dan diakhir yang saya hapus (pembuka dan penutup) biar enggak terlalu panjang, semoga bermanfaat.
Terima kasih atas kunjungannya 😀