I had a client, a large e-commerce shop running WooCommerce, come to us worn out. The custom plugins a previous agency had built were a constant source of trouble. WordPress or WooCommerce would update and something would break, the admin dashboard dragged, and there were security holes on top of that. All of it came back to code written without regard for the basic WordPress plugin standards.
My first move was the obvious one, and it is a common trap: hotfix each bug as it surfaced. Patch here, patch there. It stopped the bleeding for a while, then it stopped working as an approach. The individual bugs were not the problem. The foundation was. That code ignored the WordPress APIs, the coding standards and the conventions other developers rely on, and it had been written in a silo, detached from the ecosystem it was meant to extend.
What WordPress plugin standards actually buy you
This is where community work earns its keep, and a WordPress Contributor Day is a good example: those sessions produce tools, not just discussion. The “Plugin Check Plugin” is one of them. Run it against your plugin and it flags the common problems and shows you where you have drifted from the WordPress Coding Standards. That is not bureaucracy. It is the difference between code you can maintain and code that falls over on the next core update, and when it falls over it is your client’s site that goes down.
A plugin built properly is interoperable as well as functional. It coexists with other plugins and with the theme, it survives core updates, it goes through the WordPress API instead of around it, it sanitizes what it stores, and it does not slow the site down. Once a plugin is a pile of custom functions and raw database queries with no sanitizing or escaping, you are in for a rough time. I have seen some horrifying database calls over the years.
<?php
/**
* Plugin Name: BBioon Example Plugin
* Description: Demonstrates adhering to WordPress Plugin Standards.
* Version: 1.0.0
* Author: BBioon Team
* Text Domain: bbioon-example-plugin
*/
if ( ! defined( 'ABSPATH' ) ) {
exit; // Exit if accessed directly.
}
/**
* Register a custom post type using standard WordPress hooks.
*/
function bbioon_register_custom_post_type() {
$labels = array(
'name' => _x( 'Products', 'Post Type General Name', 'bbioon-example-plugin' ),
'singular_name' => _x( 'Product', 'Post Type Singular Name', 'bbioon-example-plugin' ),
'menu_name' => __( 'Products', 'bbioon-example-plugin' ),
);
$args = array(
'label' => __( 'Products', 'bbioon-example-plugin' ),
'description' => __( 'Custom post type for products', 'bbioon-example-plugin' ),
'labels' => $labels,
'supports' => array( 'title', 'editor', 'thumbnail' ),
'hierarchical' => false,
'public' => true,
'show_ui' => true,
'show_in_menu' => true,
'menu_position' => 5,
'show_in_admin_bar' => true,
'show_in_nav_menus' => true,
'can_export' => true,
'has_archive' => true,
'exclude_from_search' => false,
'publicly_queryable' => true,
'capability_type' => 'post',
'show_in_rest' => true,
);
register_post_type( 'bbioon_product', $args );
}
add_action( 'init', 'bbioon_register_custom_post_type' );
/**
* Sanitize and validate user input before saving.
* Example for a custom field in a meta box (not shown here).
* Always use appropriate sanitization functions.
*/
function bbioon_save_product_meta( $post_id ) {
if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) {
return;
}
if ( ! current_user_can( 'edit_post', $post_id ) ) {
return;
}
if ( isset( $_POST['bbioon_product_price'] ) ) {
$price = sanitize_text_field( $_POST['bbioon_product_price'] );
update_post_meta( $post_id, '_bbioon_product_price', $price );
}
}
add_action( 'save_post', 'bbioon_save_product_meta' );
?>The example is basic, but it shows a couple of the principles. Every function is prefixed with bbioon_, which is what stops it colliding with the next plugin that wants a function of the same name. It hooks in through add_action('init', ...); and add_action('save_post', ...);, which is how you extend WordPress rather than fight it. And it sanitizes the input and checks the user’s capability before writing meta, even for a single price field. Plenty of plugins skip both, which is how sites end up wide open.
What cutting corners costs
Skipping WordPress plugin standards is not free. You pay in development time, in debugging that never quite ends, in performance, and eventually in whether the client still trusts you. Writing to the standards from the first commit costs less than retrofitting them into a plugin that is already running a store, which is the position my client was in.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to work, drop my team a line. We have probably seen it before.
