DEV Community: Kushang Tailor

WordPress REST API Deep Dive: Custom Routes, Multiple Methods on One Endpoint, and Full CRUD

Kushang Tailor — Thu, 15 Oct 2026 12:19:57 +0000

🚪 Why the WP REST API Deserves Your Attention

Every WordPress site already ships with a front door for data. Open yourdomain.com/wp-json/ and you'll see a big JSON map of everything the site can do. That's the WordPress REST API.

It lets anything that speaks HTTP talk to WordPress: a React app, a mobile app, a Zapier flow, or another website. No admin screens, no page reloads. Just JSON in, JSON out.

In this article we'll go from "what is this thing?" to a complete, secure CRUD API for a custom Bookshelf, step by step.

By the end you'll know how to:

Register your own routes
Use GET, POST, PUT, PATCH and DELETE
Share one URL across several HTTP methods (the part that confuses almost everyone!)
Validate, sanitize and protect every request

Let's go. 🚀

🧠 Part 1: The WP REST API in Plain English

Think of the REST API as a restaurant:

Namespace → the restaurant name (bookshelf/v1)
Route → the menu item (/books)
Method → what you want to do with it (order, change, cancel)
Callback → the kitchen that does the work
Permission callback → the bouncer at the door 🕴️

A full URL looks like this:

https://example.com/wp-json/bookshelf/v1/books/42
                    └─ base ─┘└namespace┘└route┘└id┘

WordPress already gives you built-in endpoints under the wp/v2 namespace:

# Latest 5 posts
curl "https://example.com/wp-json/wp/v2/posts?per_page=5"

Those are great for posts, pages and users. But the moment you have your own data (books, bookings, tickets, whatever), you'll want custom routes.

🔤 HTTP methods at a glance

Method	Typical meaning	WP constant
`GET`	Read data	`WP_REST_Server::READABLE`
`POST`	Create data	`WP_REST_Server::CREATABLE`
`PUT` / `PATCH`	Update data	`WP_REST_Server::EDITABLE` (it also includes `POST`)
`DELETE`	Remove data	`WP_REST_Server::DELETABLE`
`ALLMETHODS`	Everything above	`WP_REST_Server::ALLMETHODS`

Two methods you didn't ask about but should know:

PATCH → a partial update ("only change the rating").
OPTIONS → WordPress answers automatically with your route's schema and allowed methods. You get it for free. 🎁

🧩 The four pieces of every endpoint

When you register a route, each handler has these keys:

Key	What it does
`methods`	Which HTTP verbs this handler accepts
`callback`	The function that does the work
`permission_callback`	Who is allowed in (required, WordPress warns you if it's missing)
`args`	The parameters, with `type`, `required`, `default`, `enum`, `minimum`, `maximum`, `sanitize_callback`, `validate_callback`

Your callback receives a WP_REST_Request and should return a WP_REST_Response (or a WP_Error when something goes wrong).

🛠️ Part 2: Creating Your First Custom Route

Routes are registered on the rest_api_init hook. Here's the smallest useful example:

add_action( 'rest_api_init', function () {
    register_rest_route(
        'bookshelf/v1',
        '/ping',
        array(
            'methods'             => WP_REST_Server::READABLE,
            'callback'            => function () {
                return rest_ensure_response( array( 'message' => 'pong' ) );
            },
            'permission_callback' => '__return_true', // Public on purpose.
        )
    );
} );

Visit /wp-json/bookshelf/v1/ping and you'll get {"message":"pong"}. 🎉

🔗 Dynamic routes with URL parameters

Need an ID in the URL? Use a regex capture group:

register_rest_route(
    'bookshelf/v1',
    '/books/(?P<id>\d+)',
    array( /* handlers go here */ )
);

Inside the callback, read it with $request->get_param( 'id' ). The \d+ also means /books/abc never reaches your code, so WordPress returns a 404 for you.

🏗️ A clean OOP structure

Since we're building a real API, let's keep it tidy. One class per job:

bookshelf/
├── bookshelf.php               ← Plugin bootstrap
└── includes/
    ├── class-plugin.php        ← Wires everything up
    ├── class-book-post-type.php ← Registers the "book" post type
    └── class-books-controller.php ← All REST logic lives here

For storage we'll use a private custom post type called book. This way we get trash, revisions and capabilities for free:

<?php
/**
 * Registers the Book post type.
 *
 * @package Bookshelf
 */

namespace Bookshelf;

defined( 'ABSPATH' ) || exit;

/**
 * Class Book_Post_Type
 */
class Book_Post_Type {

    /**
     * Hook into WordPress.
     *
     * @return void
     */
    public function register_hooks(): void {
        add_action( 'init', array( $this, 'register' ) );
    }

    /**
     * Register the post type (hidden from the default REST output).
     *
     * @return void
     */
    public function register(): void {
        register_post_type(
            'book',
            array(
                'label'        => __( 'Books', 'bookshelf' ),
                'public'       => false,
                'show_ui'      => true,
                'show_in_rest' => false, // We expose it with our own API.
                'supports'     => array( 'title' ),
            )
        );
    }
}

🔀 Part 3: Same Route, Different Methods

Here's the question I hear the most:

"If /books is used for both listing and creating, how does WordPress know which function to run?"

It looks at the HTTP method. The route is the address. The method is the intent. 📬

The trick is to pass an array of handlers to a single register_rest_route() call. Each handler declares its own methods, callback, permissions and args:

register_rest_route(
    'bookshelf/v1',
    '/books',
    array(
        // Handler 1: GET /books → list books.
        array(
            'methods'             => WP_REST_Server::READABLE,
            'callback'            => array( $this, 'get_items' ),
            'permission_callback' => '__return_true',
            'args'                => $this->get_collection_args(),
        ),
        // Handler 2: POST /books → create a book.
        array(
            'methods'             => WP_REST_Server::CREATABLE,
            'callback'            => array( $this, 'create_item' ),
            'permission_callback' => array( $this, 'can_create' ),
            'args'                => $this->get_write_args( true ),
        ),
    )
);

Same URL, two different jobs, two different bouncers. Notice that listing is public while creating needs a capability.

🔍 What WordPress does on each request

Matches the URL against every registered route (the regex).
Finds the handler whose methods contains the request's method.
Runs the permission_callback (fail → 401 or 403).
Validates and sanitizes args (fail → 400).
Finally runs your callback. ✅

⚠️ Gotchas worth remembering

Method not registered? If you send DELETE /books and no handler accepts it, you get a 404 rest_no_route. WordPress treats "route + method" as the unit.
Don't mix up the args. Each handler has its own args. Creating a book needs a required title, but listing a book needs optional page and per_page.
EDITABLE includes POST. If you use WP_REST_Server::EDITABLE on /books/{id}, then POST /books/5 will also update. It's handy, but it can surprise you. In this article I'll list PUT and PATCH explicitly.
One call is cleaner. Calling register_rest_route() twice for the same route merges the handlers, but keeping them together in one call makes the code much easier to read.

📚 Part 4: The Complete Bookshelf API

Here's the endpoint map we're building. Keep this table handy, we'll go through it top to bottom:

Method	Endpoint	Purpose
`POST`	`/wp-json/bookshelf/v1/books`	Create a book
`GET`	`/wp-json/bookshelf/v1/books`	List books with pagination
`GET`	`/wp-json/bookshelf/v1/books/{id}`	Retrieve one book
`PUT` / `PATCH`	`/wp-json/bookshelf/v1/books/{id}`	Update a book
`DELETE`	`/wp-json/bookshelf/v1/books/{id}`	Delete a book

🧱 The controller skeleton

All five handlers live in one class. First, the registration and the shared helpers:

<?php
/**
 * Books REST controller.
 *
 * @package Bookshelf
 */

namespace Bookshelf;

use WP_Error;
use WP_Post;
use WP_Query;
use WP_REST_Request;
use WP_REST_Response;
use WP_REST_Server;

defined( 'ABSPATH' ) || exit;

/**
 * Class Books_Controller
 */
class Books_Controller {

    const REST_NAMESPACE = 'bookshelf/v1';

    /**
     * Hook into WordPress.
     *
     * @return void
     */
    public function register_hooks(): void {
        add_action( 'rest_api_init', array( $this, 'register_routes' ) );
    }

    /**
     * Register the collection and single-item routes.
     *
     * @return void
     */
    public function register_routes(): void {
        // Collection route: /books.
        register_rest_route(
            self::REST_NAMESPACE,
            '/books',
            array(
                array(
                    'methods'             => WP_REST_Server::READABLE,
                    'callback'            => array( $this, 'get_items' ),
                    'permission_callback' => '__return_true',
                    'args'                => $this->get_collection_args(),
                ),
                array(
                    'methods'             => WP_REST_Server::CREATABLE,
                    'callback'            => array( $this, 'create_item' ),
                    'permission_callback' => array( $this, 'can_create' ),
                    'args'                => $this->get_write_args( true ),
                ),
            )
        );

        // Single-item route: /books/{id}.
        register_rest_route(
            self::REST_NAMESPACE,
            '/books/(?P<id>\d+)',
            array(
                array(
                    'methods'             => WP_REST_Server::READABLE,
                    'callback'            => array( $this, 'get_item' ),
                    'permission_callback' => '__return_true',
                ),
                array(
                    'methods'             => array( 'PUT', 'PATCH' ),
                    'callback'            => array( $this, 'update_item' ),
                    'permission_callback' => array( $this, 'can_modify' ),
                    'args'                => $this->get_write_args( false ),
                ),
                array(
                    'methods'             => WP_REST_Server::DELETABLE,
                    'callback'            => array( $this, 'delete_item' ),
                    'permission_callback' => array( $this, 'can_modify' ),
                    'args'                => array(
                        'force' => array(
                            'type'    => 'boolean',
                            'default' => false,
                        ),
                    ),
                ),
            )
        );
    }

    /**
     * Permission: can the current user create books?
     *
     * @return bool
     */
    public function can_create(): bool {
        return current_user_can( 'edit_posts' );
    }

    /**
     * Permission: can the current user edit or delete this specific book?
     *
     * @param WP_REST_Request $request Request object.
     * @return bool
     */
    public function can_modify( WP_REST_Request $request ): bool {
        return current_user_can( 'edit_post', absint( $request['id'] ) );
    }

And the argument definitions. This is where validation and sanitization happen before your callback even runs:

    /**
     * Args for the list endpoint.
     *
     * @return array
     */
    private function get_collection_args(): array {
        return array(
            'page'     => array(
                'type'              => 'integer',
                'default'           => 1,
                'minimum'           => 1,
                'sanitize_callback' => 'absint',
            ),
            'per_page' => array(
                'type'              => 'integer',
                'default'           => 10,
                'minimum'           => 1,
                'maximum'           => 50,
                'sanitize_callback' => 'absint',
            ),
            'search'   => array(
                'type'              => 'string',
                'sanitize_callback' => 'sanitize_text_field',
            ),
        );
    }

    /**
     * Args for create and update.
     *
     * @param bool $is_create Title is required only when creating.
     * @return array
     */
    private function get_write_args( bool $is_create ): array {
        return array(
            'title'  => array(
                'type'              => 'string',
                'required'          => $is_create,
                'minLength'         => 1,
                'sanitize_callback' => 'sanitize_text_field',
            ),
            'author' => array(
                'type'              => 'string',
                'sanitize_callback' => 'sanitize_text_field',
            ),
            'rating' => array(
                'type'              => 'integer',
                'minimum'           => 1,
                'maximum'           => 5,
                'sanitize_callback' => 'absint',
            ),
            'status' => array(
                'type' => 'string',
                'enum' => array( 'publish', 'draft' ),
            ),
        );
    }

Now the fun part. Each method gets its own mini-section: the code, a curl call, and the response.

💡 Testing tip: for write requests, create an Application Password (Users → Profile) and send it with curl -u "username:app-password". If you call the API from inside the browser, send the X-WP-Nonce header instead.

1️⃣ POST: Create a Book

    /**
     * POST /books
     *
     * @param WP_REST_Request $request Request object.
     * @return WP_REST_Response|WP_Error
     */
    public function create_item( WP_REST_Request $request ) {
        $post_id = wp_insert_post(
            wp_slash(
                array(
                    'post_type'   => 'book',
                    'post_title'  => $request['title'],
                    'post_status' => $request['status'] ?? 'publish',
                    'meta_input'  => array(
                        '_bookshelf_author' => $request['author'] ?? '',
                        '_bookshelf_rating' => $request['rating'] ?? 0,
                    ),
                )
            ),
            true
        );

        if ( is_wp_error( $post_id ) ) {
            return $post_id;
        }

        $response = new WP_REST_Response( $this->prepare_item( get_post( $post_id ) ), 201 );
        $response->header( 'Location', rest_url( self::REST_NAMESPACE . '/books/' . $post_id ) );

        return $response;
    }

Notice the 201 Created status and the Location header. It's the polite REST way to say "here's where your new thing lives."

Request

curl -X POST "https://example.com/wp-json/bookshelf/v1/books" \
  -u "kushang:xxxx xxxx xxxx xxxx" \
  -H "Content-Type: application/json" \
  -d '{"title":"Atomic Habits","author":"James Clear","rating":5}'

Response (201)

{
  "id": 42,
  "title": "Atomic Habits",
  "author": "James Clear",
  "rating": 5,
  "status": "publish",
  "link": "https://example.com/wp-json/bookshelf/v1/books/42"
}

Forget the title? You'll automatically get a 400 with rest_missing_callback_param. You didn't write a single if for that. 😎

2️⃣ GET: List Books (with Pagination)

    /**
     * GET /books
     *
     * @param WP_REST_Request $request Request object.
     * @return WP_REST_Response
     */
    public function get_items( WP_REST_Request $request ): WP_REST_Response {
        $query = new WP_Query(
            array(
                'post_type'      => 'book',
                'post_status'    => 'publish',
                'paged'          => $request['page'],
                'posts_per_page' => $request['per_page'],
                's'              => $request['search'] ?? '',
            )
        );

        $items = array_map( array( $this, 'prepare_item' ), $query->posts );

        $response = new WP_REST_Response( $items, 200 );
        $response->header( 'X-WP-Total', (int) $query->found_posts );
        $response->header( 'X-WP-TotalPages', (int) $query->max_num_pages );

        return $response;
    }

Pagination info goes in the headers, just like core endpoints do. Your JSON body stays a clean array.

Request

curl "https://example.com/wp-json/bookshelf/v1/books?page=1&per_page=2&search=habits"

Response (200, headers: X-WP-Total: 1, X-WP-TotalPages: 1)

[
  {
    "id": 42,
    "title": "Atomic Habits",
    "author": "James Clear",
    "rating": 5,
    "status": "publish",
    "link": "https://example.com/wp-json/bookshelf/v1/books/42"
  }
]

Try per_page=500 and you'll get a 400 back, thanks to maximum => 50. Always cap your list endpoints! 🛡️

3️⃣ GET: Retrieve One Book

We need a small helper that finds the book or returns a proper 404:

    /**
     * Fetch a book or return a 404 error.
     *
     * @param int $id Book ID.
     * @return WP_Post|WP_Error
     */
    private function get_book( int $id ) {
        $post = get_post( $id );

        if ( ! $post instanceof WP_Post || 'book' !== $post->post_type ) {
            return new WP_Error(
                'bookshelf_not_found',
                __( 'Book not found.', 'bookshelf' ),
                array( 'status' => 404 )
            );
        }

        return $post;
    }

    /**
     * GET /books/{id}
     *
     * @param WP_REST_Request $request Request object.
     * @return WP_REST_Response|WP_Error
     */
    public function get_item( WP_REST_Request $request ) {
        $book = $this->get_book( absint( $request['id'] ) );

        if ( is_wp_error( $book ) ) {
            return $book;
        }

        return new WP_REST_Response( $this->prepare_item( $book ), 200 );
    }

Request

curl "https://example.com/wp-json/bookshelf/v1/books/42"

Response (200) → the same single book object you saw above.

Missing book → 404:

{
  "code": "bookshelf_not_found",
  "message": "Book not found.",
  "data": { "status": 404 }
}

4️⃣ PUT / PATCH: Update a Book

    /**
     * PUT|PATCH /books/{id}
     *
     * Only the fields that were sent get updated.
     *
     * @param WP_REST_Request $request Request object.
     * @return WP_REST_Response|WP_Error
     */
    public function update_item( WP_REST_Request $request ) {
        $book = $this->get_book( absint( $request['id'] ) );

        if ( is_wp_error( $book ) ) {
            return $book;
        }

        $update = array( 'ID' => $book->ID );

        if ( $request->has_param( 'title' ) ) {
            $update['post_title'] = $request['title'];
        }

        if ( $request->has_param( 'status' ) ) {
            $update['post_status'] = $request['status'];
        }

        $result = wp_update_post( wp_slash( $update ), true );

        if ( is_wp_error( $result ) ) {
            return $result;
        }

        if ( $request->has_param( 'author' ) ) {
            update_post_meta( $book->ID, '_bookshelf_author', $request['author'] );
        }

        if ( $request->has_param( 'rating' ) ) {
            update_post_meta( $book->ID, '_bookshelf_rating', $request['rating'] );
        }

        return new WP_REST_Response( $this->prepare_item( get_post( $book->ID ) ), 200 );
    }

🧠 PUT vs PATCH: by the book, PUT replaces the whole resource and PATCH changes a few fields. WordPress core is relaxed here: both are treated as "update what I sent". I'm following core's habit, since it's friendlier for clients.

Request

curl -X PATCH "https://example.com/wp-json/bookshelf/v1/books/42" \
  -u "kushang:xxxx xxxx xxxx xxxx" \
  -H "Content-Type: application/json" \
  -d '{"rating":4}'

Response (200)

{
  "id": 42,
  "title": "Atomic Habits",
  "author": "James Clear",
  "rating": 4,
  "status": "publish",
  "link": "https://example.com/wp-json/bookshelf/v1/books/42"
}

5️⃣ DELETE: Remove a Book

    /**
     * DELETE /books/{id}
     *
     * Moves to trash by default. Pass force=true to delete permanently.
     *
     * @param WP_REST_Request $request Request object.
     * @return WP_REST_Response|WP_Error
     */
    public function delete_item( WP_REST_Request $request ) {
        $book = $this->get_book( absint( $request['id'] ) );

        if ( is_wp_error( $book ) ) {
            return $book;
        }

        $previous = $this->prepare_item( $book );
        $deleted  = wp_delete_post( $book->ID, (bool) $request['force'] );

        if ( ! $deleted ) {
            return new WP_Error(
                'bookshelf_delete_failed',
                __( 'The book could not be deleted.', 'bookshelf' ),
                array( 'status' => 500 )
            );
        }

        return new WP_REST_Response(
            array(
                'deleted'  => (bool) $request['force'],
                'previous' => $previous,
            ),
            200
        );
    }

Request

curl -X DELETE "https://example.com/wp-json/bookshelf/v1/books/42?force=true" \
  -u "kushang:xxxx xxxx xxxx xxxx"

Response (200)

{
  "deleted": true,
  "previous": { "id": 42, "title": "Atomic Habits", "...": "..." }
}

🎁 The Shared Formatter

One last helper so every endpoint returns the same shape. This is where we also escape the output we send out:

    /**
     * Turn a book post into a clean API array.
     *
     * @param WP_Post $post Book post.
     * @return array
     */
    private function prepare_item( WP_Post $post ): array {
        return array(
            'id'     => $post->ID,
            'title'  => $post->post_title,
            'author' => (string) get_post_meta( $post->ID, '_bookshelf_author', true ),
            'rating' => (int) get_post_meta( $post->ID, '_bookshelf_rating', true ),
            'status' => $post->post_status,
            'link'   => esc_url_raw( rest_url( self::REST_NAMESPACE . '/books/' . $post->ID ) ),
        );
    }
}

A quick note on escaping: JSON isn't HTML, so running esc_html() on API values would give clients double-encoded text like &. The rule of thumb is sanitize on the way in, escape at the place you render. Use esc_url_raw() for URLs, and let your front-end escape titles when it prints them.

🔐 Security Checklist (Pin This One)

✅ Always set permission_callback. Use __return_true only for data that's truly public, and say so in a comment.
✅ Validate with type, enum, minimum, maximum.
✅ Sanitize with sanitize_callback before saving.
✅ Check capabilities per item (edit_post) and not only globally.
✅ Cap per_page.
✅ Return a WP_Error with a proper status code and never die() or echo.
✅ Use wp_slash() when passing REST data to wp_insert_post() and wp_update_post().

🏁 Final Verdict

The WP REST API looks big at first, but once you see the pattern it's actually tiny:

One namespace → routes → an array of handlers → each handler = methods + callback + permissions + args.

The thing to take with you is Part 3. A route is just an address, and the HTTP method decides which handler answers. Once that clicks, GET /books and POST /books living side by side stops feeling like magic.

A few honest opinions after building this:

🧱 Use a controller class. A pile of closures works for demos, but a class keeps your routes testable and readable.
🛡️ Let args do the heavy lifting. Declarative validation means fewer if blocks and fewer bugs.
🔑 Treat permissions as a feature, not an afterthought. Most REST API security issues come from a lazy permission_callback.
📦 Version your namespace (/v1). Your future self will thank you when /v2 arrives.

Now it's your turn: take the Bookshelf, swap books for whatever your project needs (tasks, events, orders), and ship something. Got questions or a cooler example? Drop them in the comments, I read every one! 💬

WordPress 7.1 'Mary Lou': The Full Album, Track by Track 🎷

Kushang Tailor — Sat, 03 Oct 2026 03:32:37 +0000

It's late, but here is the full breakdown of all the features of WordPress 7.1, and it's worth exploring. 🙌

Yes, I know. WordPress 7.1 landed on August 19, 2026, and I'm showing up with the party snacks when everyone has already gone home. 😅

But here's the thing: most "what's new" posts were written before the release, from beta notes and roadmaps. Now that the dust has settled, we can look at what actually shipped, what quietly got cut, and what's worth your time.

And since I wanted to do this differently, I'm doing it the way WordPress itself named this release.

🎷 Why an album?

Every WordPress release is named after a jazz artist. This one is "Mary Lou", after the pianist, arranger and composer Mary Lou Williams. She started performing at six and moved through swing, bebop and sacred jazz. In the 1940s she turned her Harlem apartment into a nightly workshop where Monk, Dizzy Gillespie and Bud Powell traded ideas. The release team picked her for two words: reinvention and collaboration.

That's a surprisingly accurate summary of 7.1. So I'm treating it like a vinyl record: Side A, Side B, Side C, and a bonus track.

Drop the needle. 🎧

📀 The Tracklist

#	Track	What it is, in one line
1	Responsive Styles	Style blocks per screen size, no custom CSS
2	Interactive States	Hover, focus and active styles for buttons
3	Tabs	A new core Tabs block
4	Playlist	A new core audio Playlist block
5	The Small Design Stuff	Gradients, min-width, text shadow and more
6	Icon Block	Custom icon collections in the editor
7	The Omnibar	The admin bar now follows you everywhere
8	New Media Editor	One modal for crop, flip, rotate and metadata
9	Browser-Side Media	Image processing moves out of PHP
10	Media Library Upgrades	Infinite scroll, better galleries, resilient uploads
11	Notes Grew Up	Mentions, rich text, inline notes
12	Daily-Life Admin Fixes	Command palette, Identity, comment parents
13	Accessibility	46 accessibility tickets and new tooltip helpers
14	The Iframed Editor	The post editor is always iframed now
15	Developer Toolbox	Icon API, Abilities API, Design System, 20 new hooks
🎁	Bonus: Cut Tracks	What didn't make the album

🅰️ Side A: The Design Side

Where "I need custom CSS for that" starts to disappear.

🎵 Track 1: Responsive Styles

What changed: You can now define how a block looks at different screen sizes from inside the editor. You can do it in Global Styles (applies to every instance of a block) or in an individual block's settings. You can also preview each viewport as you work.

Why it matters: Making the heading smaller on mobile used to mean a media query in a stylesheet, or a page builder. Now it's a setting.

For theme authors: Block themes can define their own mobile and tablet breakpoints in theme.json, overriding the defaults for both responsive styles and block visibility. Your design system, your breakpoints.

💡 7.0 already had show/hide per device. 7.1 adds the actual styling per device on top of it. Responsive support started in 7.0 and is expanded here, so don't expect it to be 100% new.

🎵 Track 2: Interactive States

What changed: Button blocks can now have distinct styles for hover, focus and active states, straight from the editor's style controls. You can set them for one button or for all buttons via Global Styles.

Why it matters: "Make the button change color on hover" used to be one of the most common reasons to open a stylesheet. It's now a color picker.

For theme authors: theme.json gets pseudo-state styling too: hover, focus, focus-visible and active. Block-level support still varies by block, so test the blocks you rely on.

🎵 Track 3: Tabs Block (new!)

What changed: A core Tabs block that organizes content into tabbed panels. Tab titles are edited in place, and each panel can hold any blocks you like.

Why it matters: Tabs were always one of those "install a plugin for it" things. Now FAQ sections, pricing comparisons and "Overview / Specs / Reviews" layouts work with core only.

🎵 Track 4: Playlist Block (new!)

What changed: A core Playlist block bundles multiple audio tracks into a single player with a track list. There's an optional waveform that gives listeners a visual sense of each track while it plays.

Why it matters: Podcasters, musicians, course creators and anyone with a "listen to these 5 audio clips" page no longer needs a plugin. It also fits this release's jazz theme nicely. 🎶

🎵 Track 5: The Small Design Stuff

Short tracks, but you'll use them daily:

Background gradients + background images no longer fight each other. This now works across Group, Verse, Accordion, Pullquote, Post Content and Quote.
Minimum width joins the dimension controls, so elements stop collapsing on narrow screens without a media query.
Text shadow is available in Global Styles, so you set it once per block type.
Image block → "Mark as decorative." Purely ornamental images can be hidden from screen readers.
Custom HTML block supports editable nested blocks, which is handy for HTML pasted from AI tools.
Embed block: pasting a shortcode now produces a real Embed block instead of raw text.

🎵 Track 6: Icon Block + Custom Icon Collections

What changed: 7.0 started the SVG icon work. 7.1 makes it usable. There's a core Icon block backed by an icon library, and developers can register their own collections so custom icons appear throughout the editor next to the built-ins.

Why it matters: No more shipping an icon font or inlining a pile of SVGs just to get icons in the editor. (Developer details in Track 15.)

🅱️ Side B: The Workflow Side

Where the "collaboration" half of Mary Lou lives.

🎵 Track 7: The Omnibar

What changed: The WordPress admin bar now stays with you across the dashboard, the post editor and the Site Editor, plus some small visual polish.

Why it matters: Jumping from writing a post to editing your site design no longer feels like switching apps. You always know where you are, and the familiar tools stay in reach.

🎵 Track 8: The New Media Editor

What changed: A dedicated media editor modal replaces the old inline cropper. The familiar Crop button still opens it, but inside you get:

Freeform and aspect-ratio cropping
Horizontal and vertical flipping
Fine-grained and snap rotation
Metadata editing in the same workflow
Undo/redo while you edit

Why it matters: One focused place for "fix this image," instead of a cramped inline tool.

🎵 Track 9: Browser-Side Media Processing (the real headline) ⭐

If I had to pick one track from this album as the hit single, it's this one. And it's the quietest one.

The old way: You upload a photo, your server (via GD or ImageMagick) decodes it and generates every thumbnail size while you wait. That's why "increase your PHP memory limit" is the most common advice in WordPress land, and why big phone photos sometimes just fail.

The new way: The browser does the heavy lifting. Compression, resizing and thumbnail generation now happen client-side, using a WebAssembly build of libvips, before the file reaches your server.

What you get:

Less server load. No more hitting PHP memory limits or timeouts on big uploads.
Smaller files.
Modern formats: native support for AVIF, HEIC and HDR gain maps, which means the photos modern phones actually produce.
Opt-in GIF-to-video conversion, which usually gives much smaller files.
Resilient uploads: progress indicators and automatic retries when the connection drops.

Your existing settings still apply (like the big-image threshold and your output format preference), and the old server-side editor stays as a fallback for anything the browser can't handle.

A bonus I like: untrusted uploaded images get decoded inside the browser's sandbox first, instead of always being parsed by image libraries on your host. It doesn't remove the server path entirely, but the common case gets safer.

🎵 Track 10: Media Library Upgrades

Infinite scrolling in the Media Library grid by default. There's a per-user option to go back to pagination.
Better galleries. Galleries can pull in media already attached to a post, and the inserter shows an Attached images section for the current post.
Speculative loading defaults can now be set through environment variables or constants, so hosts and site owners can tune prefetching without writing a plugin.

🎵 Track 11: Notes Grew Up

Notes (the editorial commenting feature) got most of the collaboration love in this release:

Rich text: bold, italic, code and links inside notes
@mentions to loop in the right person (with email notifications in the final stretch)
Inline notes: leave a note on a specific piece of text, not just a whole block
Multiple conversations on the same block
Collapsible long notes to keep the margin tidy
Shareable revisions: hand someone a link to a specific revision for a second pair of eyes

⚠️ One honest note: real-time co-editing (the Google-Docs-style dream) is not in 7.1. More on that in the bonus track.

🎵 Track 12: Daily-Life Admin Fixes

Small things you'll notice by Tuesday:

Command palette (Ctrl/Cmd + K) groups results into Recent, matching and Suggestions, and remembers what you used.
The Site Editor respects your admin color scheme instead of a fixed dark background.
Identity section: site title, tagline and icon now live together.
Change a comment's parent from the Edit Comment screen. This was a long-standing annoyance.
"On This Day" dashboard widget (mentioned in several release roundups) surfaces old posts and comments from the same date in previous years.

🎵 Track 13: Accessibility

7.1 includes 46 accessibility-focused tickets. Highlights:

New wp_get_tooltip() and wp_get_toggletip() functions bring accessible tooltips to more of wp-admin, including post meta boxes and the login screen.
Better screen reader support in admin screens, with clearer labels and more predictable navigation in post list tables.
The new Tabs and Playlist blocks were built with accessibility in mind.

🅲 Side C: The Studio Notes (for developers)

Where we look at the mixing board.

🎵 Track 14: The Iframed Editor ⚠️

What changed: The post editor is now fully iframed for all themes, matching the Site Editor. The editing canvas runs separately from the admin UI, so admin styles stop leaking into your content, and viewport units and media queries target the canvas instead of the browser window.

Why it matters: It's mostly invisible, and layouts become more predictable. But it's also the change most likely to break something. Blocks still on Block API version 2 or lower need to move to version 3. WordPress publishes a block migration guide for this.

🧪 If you maintain custom blocks or older third-party ones, test on staging first.

🎵 Track 15: The Developer Toolbox

SVG Icon API is public. Register your own collections and icons with wp_register_icon_collection(), wp_register_icon() and wp_get_icon(), and use them across the editor. There's also a REST endpoint, so icon collections are queryable.
Abilities API (introduced in 6.9) gets a filterable execution lifecycle, custom validation and shared discovery, which helps with integrations and AI tooling.
New Design System for admin UIs: semantic design tokens (color, roundness, cursor styles) and a ThemeProvider React component, so custom admin screens feel at home in WordPress.
theme.json: responsive styling, custom breakpoints and pseudo-state styling (hover, focus, focus-visible, active).
DataViews / DataForm filters for the screens behind Pages, Templates, Parts and Patterns in the Site Editor.
Connectors screen adds username + application password authentication next to API keys.
Block Bindings extend to List Item blocks.
20 new hooks (19 filters and 1 action). Check the Field Guide for a cleaner extension point than your current workaround.
jQuery UI moves to 1.14.2. Dependency bumps like this break plugins quietly, so test anything that leans on jQuery UI widgets.

🎁 Bonus Track: The Cut Tracks (what didn't make it)

Every album has songs that got left on the studio floor:

Real-time collaboration: still not enabled. The Field Guide says it got extensive testing during the cycle, but it isn't in the final release while conflict handling is worked out.
Table of Contents block: it was on the roadmap, but it was pushed to a later release (7.2 per some coverage).
Guidelines (editorial rules and brand voice for AI tooling): not in 7.1.
React 19 upgrade: lands in the Gutenberg plugin first, Core later.
Hiding the Classic block: this was merged, then reverted in July. The Classic block stays in the inserter, so nothing changes if you still use it.

🎧 Liner Notes: Should You Update?

My honest take: 7.1 is a "finish what we started" release, not a reinvention. 7.0 brought the big AI foundation and the dashboard redesign. 7.1 polishes it and finally turns a lot of "I need custom CSS" moments into plain settings.

Some practical advice:

Back up first, and test that you can actually restore it. 💾
Update a staging copy and check your custom blocks (iframed editor!) and anything using jQuery UI.
Run the update from Dashboard → Updates, or with WP-CLI:

wp core update
wp core update-db   # especially on multisite

Go straight to the latest 7.1.x. Point releases have already shipped since August, including a security release, so don't stop at 7.1.0.

The release was a team effort: 800+ contributors, 170+ first-timers and 1,500+ enhancements and fixes, led by Anne McCarthy. Thank you to everyone who made it happen. 👏

🎤 Encore

If I had to pick my top three for everyday work:

🥇 Browser-side media, which fixes a 15-year-old pain quietly
🥈 Responsive + interactive styles, which means way less custom CSS
🥉 Notes with @mentions, a real step toward team editing

What's your favorite track on the album? Let me know in the comments. And if you've already moved to 7.1, tell me what broke (or what didn't). 👇

Sources and further reading:

Official announcement: WordPress 7.1 "Mary Lou"
Developer notes: WordPress 7.1 Field Guide
Release notes: Version 7.1 documentation

Copper CRM + WordPress: When Your Contact Form Finally Gets a Real Job 💼

Kushang Tailor — Thu, 01 Oct 2026 11:34:21 +0000

👋 Meet Copper CRM

Most CRMs feel like you need a weekend course before you can send your first email. Copper is different. It's built to live inside Google Workspace, so if your team already spends the day in Gmail, Calendar and Drive, Copper feels like a natural extension instead of yet another tab.

For WordPress developers, the interesting part is that Copper has a clean REST + JSON Developer API. You can create records, search, update, and subscribe to events. That means your WordPress forms don't have to end their life in an admin email inbox. They can land straight in a CRM, ready for follow-up.

In this article, we'll go through:

What Prospects and Contacts really are (and the naming trap 🪤)
Where tags, custom fields and webhooks live
A duplicate-entry gotcha I ran into
How to push Contact Us and Newsletter form entries to Copper using PHP

Let's go! 🚀

🧭 Contacts vs Prospects

Copper has two main "people-like" record types:

Prospects: someone who showed interest but isn't a real business relationship yet. Think "just filled the contact form."
Contacts: someone you're actually doing business with, or are ready to.

Copper's own help docs describe this flow nicely. You can start someone as a prospect while you check if they're a good fit, or skip that step and add them straight as a contact. When a prospect looks promising, you convert them. (Working with People)

⚠️ The Naming Trap (Read This Before You Write Code!)

Here's something that confused me at first. The Copper dashboard talks about Prospects and Contacts, but the developer documentation uses different words:

🔑 Prospects = leads in the developer API
🔑 Contacts = people in the developer API

So when you read the docs and see /leads, think "Prospects". When you see /people, think "Contacts". Copper also lets admins rename record types in settings, so your own account might use yet another label. Always map by endpoint, not by what the sidebar says.

Docs: Leads Overview · People Overview

📊 Quick Comparison

	Prospects (API: `leads`)	Contacts (API: `people`)
Meaning	Early-stage interest, not yet qualified	Real business relationship
Typical source	Contact form, enquiry, cold outreach	Newsletter signup, customers, qualified people
Duplicates	⚠️ Can store duplicates	✅ Doesn't store duplicate entries (more below)
Extra fields	Status, Customer Source	Contact Type
Company / pipeline link	Can't be related to Companies or Pipelines	Can be related to Companies and Opportunities
Moving forward	Can be converted to a Contact	Already the "final" form
Upsert endpoint	Yes, `PUT /leads/upsert`	Not listed in the docs, so check first, then create or update
Enabled by default?	No, you toggle Prospects on in settings	Yes

Sources: Copper: Customizing your account, Creating a Lead form, Convert a Lead API

🚨 The Duplicate Gotcha (My Real-World Finding)

This one cost me a bit of debugging time, so let me save you the trouble.

🔥 Highlight

While working with Copper CRM, I noticed that the Contacts (people) section does not store duplicate entries, but the Prospects (leads) section does.

What that means in practice:

Submit the same email to Contacts twice → you won't get two clean records. The second attempt is rejected or needs a different approach.
Submit the same email to Prospects twice → you can end up with two (or ten!) identical prospects. 😅

If your "Contact Us" form creates prospects with a plain POST /leads, every repeat visitor adds a new record. Your sales team will not thank you.

The fix: use the Upsert Lead endpoint. It checks for a match (name, email, or custom field), updates the record if it exists, and creates one if it doesn't. The docs say it's particularly useful to avoid duplicate leads. We'll use it in the code below.

Docs: UPSERT a Lead

🛠️ Tags, Custom Fields & Webhooks from the Dashboard

You can do a lot without writing any code. Here's where to look.

🏷️ Tags

Tags are flexible labels, like newsletter, website-lead, or wordpress. They're handy for things that don't deserve a full custom field. Tags are specific to each record type, and you can add, edit or delete them in settings. Good news for devs: you can also attach tags through the API when creating records.

⚠️ Heads up: if a tag is renamed or deleted in Settings, automations (and form actions) that referenced it won't apply it anymore.

Docs: Tags API

🧩 Custom Fields

Need to track "Budget", "Service Interest" or "Preferred Language"? That's what custom fields are for. In the dashboard, go to Settings → Manage Fields on Records, pick the record type (leads, people, companies, etc.) and add your field. Admins can also reorder, deactivate or reactivate fields from the same place. (Manage Field Settings)

For API usage, every custom field has a numeric custom_field_definition_id. You send values like this:

"custom_fields": [
  { "custom_field_definition_id": 100764, "value": "Hello" }
]

You can list your definitions via the API to find the IDs: List Custom Field Definitions · Custom Fields Overview

🔔 Webhooks

Webhooks flip the direction. Instead of you sending data to Copper, Copper pings your WordPress site when something happens (new lead, updated person, etc.). Great for syncing data back, notifying Slack, or kicking off a custom workflow.

On the developer side, you create a subscription with a target URL and the event you care about. Your endpoint receives a notification and processes it. (Pro tip: make your endpoint respond fast and handle repeated deliveries safely.)

Docs: Webhooks Overview · Create new subscription · Notification example

🔌 WordPress Forms → Copper (PHP Example)

Now the fun part. Imagine two forms on a WordPress site:

Form	Where it should go	Why
Contact Us	Prospects (`/leads`)	Unqualified enquiry, so it needs a sales check
Subscribe Newsletter	Contacts (`/people`)	Just an email and name, no sales follow-up needed

(This split is just an example. You can route either form to either place.)

🔐 Step 1: API Credentials

In Copper, generate an API key from your account settings. Every request needs three headers: X-PW-AccessToken, X-PW-Application (always developer_api) and X-PW-UserEmail. (Authentication docs)

Never hard-code secrets in plugin files. Put them in wp-config.php:

define( 'COPPER_API_KEY', 'your-api-key' );
define( 'COPPER_USER_EMAIL', 'you@yourcompany.com' );

🗂️ Step 2: File Structure (OOP style)

copper-forms/
├── copper-forms.php
└── includes/
    ├── class-client.php          // Talks to Copper
    ├── class-prospect-service.php // Leads
    ├── class-contact-service.php  // People
    └── class-form-handler.php     // Reads and sanitizes form data

🌐 Step 3: The API Client

One small class that knows how to talk to Copper. Everything else reuses it.

<?php
/**
 * Copper API client.
 *
 * @package CopperForms
 */

namespace CopperForms;

defined( 'ABSPATH' ) || exit;

/**
 * Class Client
 */
class Client {

    const BASE_URL = 'https://api.copper.com/developer_api/v1';

    /**
     * Send a request to Copper.
     *
     * @param string $method   HTTP method.
     * @param string $endpoint Endpoint, e.g. '/leads/upsert'.
     * @param array  $body     Request body.
     *
     * @return array|\WP_Error
     */
    public function request( $method, $endpoint, array $body = array() ) {
        $args = array(
            'method'  => $method,
            'timeout' => 5,
            'headers' => array(
                'X-PW-AccessToken' => COPPER_API_KEY,
                'X-PW-Application' => 'developer_api',
                'X-PW-UserEmail'   => COPPER_USER_EMAIL,
                'Content-Type'     => 'application/json',
            ),
        );

        if ( ! empty( $body ) ) {
            $args['body'] = wp_json_encode( $body );
        }

        $response = wp_remote_request( self::BASE_URL . $endpoint, $args );

        if ( is_wp_error( $response ) ) {
            return $response;
        }

        $code = (int) wp_remote_retrieve_response_code( $response );
        $data = json_decode( wp_remote_retrieve_body( $response ), true );

        if ( $code >= 400 ) {
            return new \WP_Error(
                'copper_api_error',
                'Copper API request failed.',
                array( 'status' => $code )
            );
        }

        return is_array( $data ) ? $data : array();
    }
}

🎯 Step 4: Contact Us → Prospect (Lead)

We use upsert matched on email, so repeat submissions update the same prospect instead of creating duplicates.

Docs: UPSERT a Lead · Create a New Lead

<?php
/**
 * Prospect (Lead) service.
 *
 * @package CopperForms
 */

namespace CopperForms;

defined( 'ABSPATH' ) || exit;

/**
 * Class Prospect_Service
 */
class Prospect_Service {

    /**
     * Client instance.
     *
     * @var Client
     */
    private $client;

    /**
     * Constructor.
     *
     * @param Client $client API client.
     */
    public function __construct( Client $client ) {
        $this->client = $client;
    }

    /**
     * Create or update a prospect from Contact Us data.
     *
     * @param array $data Sanitized form data.
     *
     * @return array|\WP_Error
     */
    public function upsert( array $data ) {
        $payload = array(
            'properties' => array(
                'name'    => $data['name'],
                'email'   => array(
                    'email'    => $data['email'],
                    'category' => 'work',
                ),
                'details' => $data['message'],
                'tags'    => array( 'website-contact-form' ),
            ),
            'match'      => array(
                'field_name'  => 'email',
                'field_value' => $data['email'],
            ),
        );

        return $this->client->request( 'PUT', '/leads/upsert', $payload );
    }
}

💌 Step 5: Newsletter → Contact (Person)

People has no upsert endpoint in the docs, so we do it manually: look up by email → update if found → create if not. This also protects us from the duplicate behaviour we talked about.

Docs: Fetch a Person by Email · Create a New Person · Update a Person

<?php
/**
 * Contact (Person) service.
 *
 * @package CopperForms
 */

namespace CopperForms;

defined( 'ABSPATH' ) || exit;

/**
 * Class Contact_Service
 */
class Contact_Service {

    /**
     * Client instance.
     *
     * @var Client
     */
    private $client;

    /**
     * Constructor.
     *
     * @param Client $client API client.
     */
    public function __construct( Client $client ) {
        $this->client = $client;
    }

    /**
     * Create or update a contact from newsletter data.
     *
     * @param array $data Sanitized form data.
     *
     * @return array|\WP_Error
     */
    public function save( array $data ) {
        $existing = $this->client->request(
            'POST',
            '/people/fetch_by_email',
            array( 'email' => $data['email'] )
        );

        // Found: update the existing person, keeping their current tags.
        if ( ! is_wp_error( $existing ) && ! empty( $existing['id'] ) ) {
            $old_tags = isset( $existing['tags'] ) ? (array) $existing['tags'] : array();
            $tags     = array_values( array_unique( array_merge( $old_tags, array( 'newsletter' ) ) ) );

            return $this->client->request(
                'PUT',
                '/people/' . absint( $existing['id'] ),
                array( 'tags' => $tags )
            );
        }

        // Not found (404) or lookup failed: try creating a new person.
        $payload = array(
            'name'   => $data['name'],
            'emails' => array(
                array(
                    'email'    => $data['email'],
                    'category' => 'work',
                ),
            ),
            'tags'   => array( 'newsletter' ),
        );

        return $this->client->request( 'POST', '/people', $payload );
    }
}

💡 Why merge tags manually? Sending tags on an update can replace the existing list, so we merge first and nothing gets wiped by accident.

🧼 Step 6: Form Handler (Validate, Sanitize, Escape)

This class receives both forms, checks the nonce, cleans the input and hands the data to the right service.

<?php
/**
 * Form handler.
 *
 * @package CopperForms
 */

namespace CopperForms;

defined( 'ABSPATH' ) || exit;

/**
 * Class Form_Handler
 */
class Form_Handler {

    /**
     * Prospect service.
     *
     * @var Prospect_Service
     */
    private $prospects;

    /**
     * Contact service.
     *
     * @var Contact_Service
     */
    private $contacts;

    /**
     * Constructor.
     *
     * @param Prospect_Service $prospects Prospect service.
     * @param Contact_Service  $contacts  Contact service.
     */
    public function __construct( Prospect_Service $prospects, Contact_Service $contacts ) {
        $this->prospects = $prospects;
        $this->contacts  = $contacts;
    }

    /**
     * Register hooks.
     *
     * @return void
     */
    public function register() {
        add_action( 'admin_post_nopriv_cf_contact_us', array( $this, 'handle_contact_us' ) );
        add_action( 'admin_post_cf_contact_us', array( $this, 'handle_contact_us' ) );
        add_action( 'admin_post_nopriv_cf_newsletter', array( $this, 'handle_newsletter' ) );
        add_action( 'admin_post_cf_newsletter', array( $this, 'handle_newsletter' ) );
    }

    /**
     * Handle the Contact Us form.
     *
     * @return void
     */
    public function handle_contact_us() {
        $this->verify_nonce( 'cf_contact_us' );

        $data = array(
            'name'    => isset( $_POST['name'] ) ? sanitize_text_field( wp_unslash( $_POST['name'] ) ) : '',
            'email'   => isset( $_POST['email'] ) ? sanitize_email( wp_unslash( $_POST['email'] ) ) : '',
            'message' => isset( $_POST['message'] ) ? sanitize_textarea_field( wp_unslash( $_POST['message'] ) ) : '',
        );

        if ( '' === $data['name'] || ! is_email( $data['email'] ) ) {
            $this->redirect( 'invalid' );
        }

        $result = $this->prospects->upsert( $data );

        $this->redirect( is_wp_error( $result ) ? 'error' : 'success' );
    }

    /**
     * Handle the Newsletter form.
     *
     * @return void
     */
    public function handle_newsletter() {
        $this->verify_nonce( 'cf_newsletter' );

        $data = array(
            'name'  => isset( $_POST['name'] ) ? sanitize_text_field( wp_unslash( $_POST['name'] ) ) : '',
            'email' => isset( $_POST['email'] ) ? sanitize_email( wp_unslash( $_POST['email'] ) ) : '',
        );

        if ( '' === $data['name'] || ! is_email( $data['email'] ) ) {
            $this->redirect( 'invalid' );
        }

        $result = $this->contacts->save( $data );

        $this->redirect( is_wp_error( $result ) ? 'error' : 'success' );
    }

    /**
     * Verify the nonce or stop.
     *
     * @param string $action Nonce action.
     *
     * @return void
     */
    private function verify_nonce( $action ) {
        $nonce = isset( $_POST['_wpnonce'] ) ? sanitize_text_field( wp_unslash( $_POST['_wpnonce'] ) ) : '';

        if ( ! wp_verify_nonce( $nonce, $action ) ) {
            wp_die( esc_html__( 'Security check failed.', 'copper-forms' ), '', array( 'response' => 403 ) );
        }
    }

    /**
     * Redirect back with a status.
     *
     * @param string $status Status key.
     *
     * @return void
     */
    private function redirect( $status ) {
        $back = wp_get_referer() ? wp_get_referer() : home_url( '/' );

        wp_safe_redirect( add_query_arg( 'cf_status', rawurlencode( $status ), esc_url_raw( $back ) ) );
        exit;
    }
}

🚦 Step 7: Bootstrap

<?php
/**
 * Plugin Name: Copper Forms
 * Description: Sends WordPress form entries to Copper CRM.
 * Version:     1.0.0
 * Text Domain: copper-forms
 *
 * @package CopperForms
 */

defined( 'ABSPATH' ) || exit;

require_once __DIR__ . '/includes/class-client.php';
require_once __DIR__ . '/includes/class-prospect-service.php';
require_once __DIR__ . '/includes/class-contact-service.php';
require_once __DIR__ . '/includes/class-form-handler.php';

add_action(
    'plugins_loaded',
    static function () {
        $client = new \CopperForms\Client();

        ( new \CopperForms\Form_Handler(
            new \CopperForms\Prospect_Service( $client ),
            new \CopperForms\Contact_Service( $client )
        ) )->register();
    }
);

On the front-end, each form posts to admin-post.php with a hidden action field (cf_contact_us or cf_newsletter) and a nonce from wp_nonce_field(). Since the form's output goes to the browser, remember to escape with esc_url() and esc_attr() there too. ✅

📝 A Few Notes Before Production

Don't block the visitor. For busy sites, push the Copper call to a background job (like WP-Cron or Action Scheduler) so a slow API call doesn't slow down the form.
Log errors, but never log your API key.
Custom fields: look up your custom_field_definition_id values first, then add them to the payloads.
Rate limits and bulk: if you import in bulk, check the Bulk Create People and Bulk Create Leads docs. Bulk requests are capped at 10 records.

🎬 Conclusion

Copper CRM is a friendly, Google-Workspace-first CRM, and its API makes it very pleasant to connect with WordPress. Quick recap:

Prospects = leads, Contacts = people in the developer docs. Map by endpoint, not by label.
Contacts don't store duplicates, Prospects do. Use the upsert endpoint for leads, and a "fetch by email first" check for people.
Tags, custom fields and webhooks give you a lot of power straight from the dashboard.
A small OOP structure (client + services + handler) keeps your integration clean, secure and easy to extend.

Once the basics work, you've got a solid pipeline from "someone typed in a form" to "sales team knows about it." 🎉

🔜 What's Next?

In the next article, we'll do the same thing with Elementor Forms: hooking into the form submission action and sending those entries to Copper as Prospects and Contacts. Stay tuned! 👀

If this helped, drop a ❤️ or a comment. I'd love to hear how you're using Copper with WordPress!

📚 Reference Links

Copper Developer API (Home)
Authentication
Leads Overview · UPSERT a Lead · Convert a Lead
People Overview · Fetch by Email
Tags · Custom Fields · Webhooks
Copper Help: Manage Field Settings

WordPress Performance From The Code Side — No Plugins Needed

Kushang Tailor — Tue, 08 Sep 2026 12:11:31 +0000

WordPress Performance From The Code Side — No Plugins Needed

Every WordPress site eventually hits the same wall: it gets slow, and the first instinct is to install a performance plugin. Then another one. Then a caching plugin to make the first two play nice. Before you know it, you've got five plugins fighting over the same wp_head hook and your site somehow got slower.

This article is about the other path — fixing performance from the code side. No plugin marketplace, no toggling forty checkboxes hoping one of them fixes your LCP score. Just a clear audit process, the right diagnostic tools, and code (yours or AI-assisted) that fixes exactly what's broken.

😎 Become a WordPress Core, JS, and CSS Expert

Just kidding.

A few years ago, that sentence would've been genuine advice — "go learn wp-includes inside out." Today, you don't need to be the person who's memorized every hook in class-wp-scripts.php. AI coding tools (Claude, Copilot, Codex — pick your favorite) already know that file better than most of us do. What you actually need is the ability to describe a performance problem accurately. That's the real skill now, and it's what the rest of this article is built around.

📋 Important Step: Audit Your Site First — Set Your Priorities

Before touching any code, know what's actually slow and which pages matter most. Don't try to fix everything at once — work top-down by priority.

List your page types and rank them by traffic/business value. Homepage and top landing pages = High priority. Category/archive pages = Medium. Low-traffic static pages = Low.
Run PageSpeed Insights on your Homepage first. This is almost always your highest-traffic entry point, so it sets the baseline.
Run it again on 2–3 of your top single post/product pages. These usually reveal template-specific issues (heavy featured images, embedded widgets, etc.) that the homepage doesn't show.
Note every red and orange metric (LCP, CLS, TBT, FCP) per page — don't just look at the overall score number.
Group the issues by type, not by page. You'll usually find the same 3–4 root causes (unused JS, oversized images, render-blocking CSS) repeating across pages.
Fix root causes, starting with whatever affects your High priority pages the most. One fix on a shared theme file often solves the same issue across ten pages at once. This turns "my site feels slow" into a short, ordered list of real problems — which is exactly what you need before writing (or prompting) any fix.

⚖️ Custom Code vs Plugins: Which One Should You Actually Use?

If you're not deeply technical, this table should help you decide where to start.

Factor	Performance Plugins	Custom Code
Setup time	Fast — install and configure	Slower — needs writing/testing
Site speed impact	Adds its own JS/CSS/DB overhead	Zero extra overhead, only does what you need
Flexibility	Limited to plugin's settings	Fully tailored to your exact bottleneck
Maintenance	Depends on plugin updates	You control the lifecycle
Risk of conflicts	High with multiple plugins	Low — no third-party hooks colliding
Best for	Quick wins, non-technical users, small sites	Long-term performance, custom themes, larger sites
Technical requirement	Low	Low-to-medium (thanks to AI, this gap is shrinking fast)

If your site is small and you need a quick win today, a well-chosen single plugin is fine. But if performance is an ongoing priority — especially on a custom theme or a client project — writing targeted code almost always wins, because it doesn't drag in features you'll never use.

🤖 Not Technical? Let AI Write the Fix — But Be Precise About the Problem

Here's the part that changes everything: you don't need to hand-write PHP or JS to get custom-code-level performance anymore. What you do need is to know exactly what's slow before you open that AI chat window. A vague prompt gets you a vague, possibly-wrong fix. A precise prompt gets you production-ready code. A few examples:

❌ Vague: "Make my WordPress site load faster"

✅ Precise — deferring a third-party widget:

"I have a third-party chat widget script loaded on my WordPress site via wp_enqueue_script(). It's render-blocking and hurting my LCP. I want it to load only when the user scrolls or clicks anywhere on the page — not on initial page load. Give me a PHP snippet to dequeue it from the normal flow, plus vanilla JS to load it on first user interaction (click, scroll, or touchstart), following WordPress coding standards."

✅ Precise — fixing layout shift from a hero image:

"My homepage hero image is causing a CLS score of 0.28 in PageSpeed Insights because it has no reserved space and loads late. It's set via get_the_post_thumbnail() in front-page.php. Give me the code to add explicit width/height attributes, mark it fetchpriority='high', and preload it in wp_head so it doesn't shift layout on load."

✅ Precise — trimming unused CSS on one template:

"Chrome DevTools Coverage tab shows my single-product.php template loads a 180KB CSS file but only uses about 20% of it. The file is enqueued theme-wide via functions.php. Give me a PHP approach using is_singular('product') to only load a smaller, page-specific stylesheet on that template instead of the global one."

✅ Precise — reducing database load from a widget:

"I have a 'Recent Reviews' widget on my WordPress sidebar running a custom WP_Query on every page load, and it's showing up as a slow query in Query Monitor. Give me a PHP snippet using the Transients API to cache the query result for one hour instead of hitting the database on every request."

Notice the pattern — every prompt names the exact element, the exact metric or tool reading, and the exact file or hook involved. That's the difference between code you can paste into production and code you'll spend an hour debugging.

🔍 Diagnose Before You Fix: PageSpeed Insights vs Lighthouse

Two tools, two different jobs:

Google PageSpeed Insights (PSI)
Runs both a lab test and pulls real-world field data from Chrome UX Report (CrUX) — meaning it shows how actual visitors experienced your site, not just a simulated run. Use this to see your real Core Web Vitals scores over the last 28 days, straight from Google's own dataset.

Lighthouse (Chrome DevTools)
A local, on-demand lab test that runs right in your browser. No real user data — just a controlled simulation under fixed network/CPU throttling. Use this while you're actively debugging, since you get instant before/after comparisons every time you make a change.

Quick rule of thumb: Use PSI to know if you have a problem and how real users are affected. Use Lighthouse to iterate while you fix it, since it's instant and doesn't wait on field data.

🕵️ Find Exactly What's Slow: Unused Code and Real Layout Shift

Before jumping into fixes, two Chrome DevTools tricks will point you straight at the problem instead of guessing.

Check unused JS and CSS per page

Open your page in Chrome, then open DevTools → More Tools → Coverage.
Click the reload button inside the Coverage panel to record a fresh page load.
You'll get a list of every JS and CSS file, with a red bar showing the percentage unused on that specific page.
Anything showing 70–90% unused is a strong candidate for either page-specific loading (is_page()/is_singular()) or removing entirely.

See real CLS and FCP under a slow connection

Open DevTools → Network tab, and set throttling to Slow 3G or Fast 4G.
Switch to the Performance tab, hit record, and reload the page with throttling still active.
Once the recording finishes, expand the Experience section — it shows the exact elements causing layout shift (CLS) and when your First Contentful Paint (FCP) actually happened.
This matters because on a fast office Wi-Fi, shifts often happen too quickly to notice. Slow network mimics real mobile users and exposes the actual elements causing jank — usually late-loading images, web fonts, or injected ads/widgets. Both of these give you a concrete list of file names and DOM elements — exactly what you need for the precise AI prompts above, or to fix by hand.

🛠️ Custom Ways to Improve WordPress Performance (No Plugin Required)

Here's the actual toolbox, ordered roughly by impact. Each one includes a minimal example — pick what applies to what your audit and DevTools checks turned up.

1. Defer or Async Non-Critical JavaScript

WordPress 6.3+ lets you set a loading strategy directly when registering a script, instead of relying on a plugin to inject defer.

wp_enqueue_script(
    'my-theme-slider',
    get_theme_file_uri( '/assets/js/slider.js' ),
    array(),
    '1.0.0',
    array( 'strategy' => 'defer', 'in_footer' => true )
);

2. Lazy-Load Third-Party Scripts on User Interaction

For things like chat widgets, review embeds, or social share scripts — don't load them until the user actually interacts with the page.

const loadOnInteraction = () => {
    const script = document.createElement( 'script' );
    script.src = 'https://example.com/widget.js';
    document.body.appendChild( script );
    events.forEach( ( evt ) => window.removeEventListener( evt, loadOnInteraction ) );
};
const events = [ 'click', 'scroll', 'touchstart' ];
events.forEach( ( evt ) => window.addEventListener( evt, loadOnInteraction, { once: true, passive: true } ) );

3. Prioritize Above-the-Fold Images, Lazy-Load the Rest

Not every image should be lazy-loaded — your hero/LCP image should load as fast as possible, while everything below the fold should wait.

<!-- Above the fold: preload + high priority + eager -->
<link rel="preload" as="image" href="hero.jpg" fetchpriority="high" />
<img src="hero.jpg" fetchpriority="high" loading="eager" alt="Hero image" />

<!-- Below the fold -->
<img src="footer-banner.jpg" loading="lazy" alt="Footer banner" />
<iframe src="video.html" loading="lazy"></iframe>

4. Lazy-Load Videos on User Interaction

Autoplaying or eagerly-embedded videos (YouTube embeds especially) are notorious for tanking LCP. Instead, show a lightweight thumbnail and only load the real player on click.

document.querySelectorAll( '.video-placeholder' ).forEach( ( el ) => {
    el.addEventListener( 'click', () => {
        const iframe = document.createElement( 'iframe' );
        iframe.src = el.dataset.videoSrc;
        el.replaceWith( iframe );
    }, { once: true } );
} );

This is exactly the pattern plugins like Viddefer automate — worth a look if you'd rather not maintain the logic yourself, but the core idea is simple enough to drop straight into your theme.

5. Extract and Enqueue Critical CSS (Medium Priority)

You don't have to hand-write critical CSS — tools like Critical or online generators (e.g., criticalcss.com) can extract it for you per page. Save the output as a small CSS file per template, then load it conditionally.

add_action( 'wp_enqueue_scripts', function () {
    if ( is_front_page() ) {
        wp_enqueue_style( 'critical-home', get_theme_file_uri( '/assets/css/critical-home.css' ), array(), '1.0.0' );
    } elseif ( is_singular( 'product' ) ) {
        wp_enqueue_style( 'critical-product', get_theme_file_uri( '/assets/css/critical-product.css' ), array(), '1.0.0' );
    }
} );

6. Load Page-Specific CSS Instead of One Global Stylesheet

If Coverage showed a large stylesheet with mostly unused rules on a given template, split it and load only what that page needs, using the same is_page()/is_singular() pattern as above.

7. Turn Off What You're Not Using

Emojis, embeds, RSD links, and the Windows Live Writer manifest all add head requests most sites never need.

remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_head', 'rsd_link' );
remove_action( 'wp_head', 'wlwmanifest_link' );
add_filter( 'embed_oembed_discover', '__return_false' );

8. Reduce Heartbeat API Frequency

The Heartbeat API polls the server every 15–60 seconds on admin screens (and sometimes the frontend). Slow it down instead of killing it entirely.

add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['interval'] = 60;
    return $settings;
} );

9. Cache Expensive Queries With Transients

If you're running a costly query (custom WP_Query, external API call, etc.), cache the result instead of hitting the database on every load. You can spot these slow queries using a debugging tool like Query Monitor — install it temporarily just to inspect, not as a permanent performance plugin.

$data = get_transient( 'my_expensive_query' );
if ( false === $data ) {
    $data = new WP_Query( array( 'posts_per_page' => 20 ) );
    set_transient( 'my_expensive_query', $data, HOUR_IN_SECONDS );
}

10. Trim Autoloaded Bloat (the Easy Way)

Plugins often set autoload => yes on options nobody reads on every page load, and over time this quietly slows down every request. You don't need raw SQL to find the offenders — Query Monitor (again, just as a diagnostic) has a dedicated panel showing your largest autoloaded options by size. Once you've spotted one that doesn't need to load on every request:

update_option( 'my_plugin_settings', $value, false ); // false = don't autoload

11. Enable Object Caching

If your host supports Redis or Memcached, a persistent object cache means repeated queries hit memory instead of MySQL — one of the biggest wins for dynamic sites, and it only requires a drop-in object-cache.php, not a bloated plugin.

12. Enable OPcache and Server-Level Compression

This one sits outside wp-content entirely, but it matters more than most plugin settings ever will: PHP OPcache (ask your host to confirm it's on) plus Gzip/Brotli compression at the server level compounds with everything above.

🎯 Conclusion

Performance plugins aren't evil — they're just a shortcut, and shortcuts come with trade-offs: extra weight, generic solutions, and settings you'll never fully understand. Writing (or AI-prompting) targeted code gets you the opposite: exactly the fix you need, nothing you don't.

The real shift isn't that coding got easier — it's that auditing and describing the problem precisely became the actual skill. Start with a priority-ordered audit, confirm the real bottleneck with PageSpeed Insights, Lighthouse, and the Coverage/Network tabs, then let code — written by you or generated with AI — do the rest.

A few related directions worth exploring next, if you want to go deeper:

Database query optimization and slow query logging
CDN + HTTP/2 (or HTTP/3) setup for static assets
Font-display strategies to kill layout shift from web fonts
Auditing and trimming unused core block CSS/JS in WordPress 6.x+

Donut Panic 🍩 — Building an Interactive CSS-Only Donut

Kushang Tailor — Tue, 11 Aug 2026 12:13:01 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

🍩 Inspiration

I write about WordPress plugins and PHP standards for a living, so when DEV dropped a "Comfort Food" theme for their Frontend Challenge, I didn't need to think twice about what to build. Not ramen, not pancakes — a donut. Specifically, the kind of donut that shows up on your desk right when a deploy breaks and somehow fixes everything.

The twist I gave myself: don't just draw a static donut. Let people build one — pick a glaze, pile on toppings, then serve it — and do almost all of it in CSS, with JavaScript kept firmly in the back seat where the challenge rules ask for it to stay.

That's how Donut Panic was born.

🎬 Demo

Pick a glaze, load it up with sprinkles, drizzle, or powdered sugar, then hit Serve and watch it animate off the plate.

🛠️ Journey

No JavaScript is driving the donut — `:has()` is

Here's the part I'm most excited to talk about: every visual change in Donut Panic — the glaze swap, the toppings appearing, the donut lifting off the prep station and landing on the plate — is driven by plain checkbox/radio inputs and the :has() selector. Something like .kitchen:has(#serve:checked) .donut lets a parent element react to the checked state of an input buried somewhere inside it, which means the "Serve" button, the topping toggles, and the glaze picker are all just styled <label>s wired to hidden inputs. No click handlers, no state management — the checkbox is the state.

JavaScript only shows up once, and it's not touching the art at all: it smooth-scrolls the stage into view on mobile after you hit Serve, because on a stacked mobile layout the donut can animate off-screen. That's the "sprinkle" of JS the challenge rules allow, used exactly the way it's meant to be — a UX nicety, not a rendering engine.

Building the donut from the inside out

The donut itself is layered rings, not a single flat shape:

A base dough circle with a radial gradient doing double duty as both color and simulated top-down lighting (highlight near one edge, shadow fading toward the rim).
A glaze layer sitting on top, clipped to a perfect circle via overflow: hidden on a wrapping .ring-clip, so drizzle and sprinkles can never spill past the donut's edge no matter how they're positioned.
A hole, punched through last with its own inset shadow so it always reads as depth rather than a flat cutout, even while the whole donut is mid-animation.
A shine layer, a diagonal white gradient that sweeps across the glaze on an infinite loop, which is what sells the "glossy glaze" feeling more than any single color choice does.

Making the glaze a real material change

Picking a glaze isn't a color swap — it's a full custom-property swap. Each glaze option (strawberry, chocolate, vanilla) redefines a whole cluster of variables — --glaze, --glaze-dark, --glaze-darker, --glaze-light — the moment its radio button is checked, using :has() again to scope the override to that one selected state. Because the gradient, the shine, and the shadow all reference those same variables, switching glazes updates lighting and depth together instead of just flattening the donut into a different hue.

Toppings as independently toggleable layers

Sprinkles, extra drizzle, and powdered sugar are each their own absolutely-positioned layer, faded in or out purely with opacity and scale transitions tied to their own checkbox. The sprinkles alone are two dozen individually placed spans, each carrying its own --t, --l, --r, and --c custom properties for position, rotation, and color, so they scatter across the donut face believably instead of repeating in an obvious pattern. Because every topping is decoupled from the glaze logic, you can mix and match freely — chocolate glaze with powdered sugar, strawberry with all three toppings at once — without any rule fighting another.

The "Serve" animation

Hitting Serve doesn't just reveal a new state — it moves the donut. The .donut element transitions its top, width, and transform properties with a bouncy cubic-bezier easing, so it visibly travels from the dashed-outline "prep station" down onto the plate, complete with a staggered pop-in for the glaze puddle, stray crumbs, and a handwritten napkin tag that reads "Enjoy Your Donut." The button label itself flips from "Serve the Donut" to "Served! Enjoy 🎉" using the same checked-state trick, and the topping menu visually locks (dimmed, grayscaled, pointer-events: none) so you can't keep editing a donut that's already left the kitchen.

What I'm proud of

Getting an entire multi-step interaction — pick a glaze, pick toppings, serve, watch it land, get locked out of editing — to run on nothing but :has(), custom properties, and transitions is the part I'm happiest with. It's proof that a lot of what we instinctively reach for JavaScript to do is really just state living in the DOM already, if you're willing to let a checkbox be the source of truth.

What's next

If I extend this past the challenge, I'd like to add more glaze and topping combinations, and maybe a "box of donuts" view that remembers everything you've built across a session — a good excuse to push :has() even further before I let JavaScript back in.

📄License

This project is open source, licensed under MIT. Fork it, remix it, build your own topping bar on top of it — just keep the license notice intact.

Happy Coding </>

AbilityGuard v1.1: I Gave My Abilities API Monitor a Memory (and a Voice)

Kushang Tailor — Wed, 05 Aug 2026 16:35:57 +0000

A few weeks back I published an article upon my latest AbilityGuard plugin so you could actually see what the WordPress Abilities API was doing on your site — which abilities were registered, which ones were risky, and what ran when nobody was watching.

That part worked. But pretty quickly I ran into a problem I should've seen coming: a monitor that only shows you the last 100 log entries and makes you stare at the screen isn't really monitoring anything. It's just a mirror. You still have to be looking at it at the exact moment something happens.

So v1.1 isn't a "few bug fixes" release. It's the release where AbilityGuard stopped being a dashboard and started being something closer to a watchdog — one that remembers, filters, exports, flags, and taps you on the shoulder when it needs to.

🧠 The Problem With a 100-Entry Memory

The original execution log was capped at a rolling 100 entries. Fine for a quick check. Useless for an actual audit trail. If you wanted to know what an ability did last Tuesday, and 150 executions had happened since, that data was just gone.

So the first thing I fixed in 1.1 was retention itself. You can now configure how many log entries AbilityGuard keeps — including unlimited retention if you want a permanent record. No more silently losing history because the log rotated while you weren't looking.

Of course, unlimited retention is only useful if you can actually find what you're looking for inside it. Which brings me to the next piece.

🔍 Filters That Don't Fight Each Other

The old filter set technically existed, but it wasn't built for real audit work. In v1.1 I rebuilt it as advanced execution log filters — status, trigger context, risk level, category, user ID, date range, and free-text search, all combinable.

The detail that actually took the most iteration wasn't adding filters, it was making them behave independently. Previously, selecting one filter could quietly narrow or reset another in a way that wasn't obvious. Now each filter selection stands on its own, so "show me destructive abilities triggered via REST by user 14 last week" actually returns what you'd expect, instead of a filter fighting itself behind the scenes.

Once you've built a filter combination you actually care about, you shouldn't have to rebuild it every time. So I added saved views — save a filter set once, reuse it from a dropdown. If you're doing weekly reviews, this alone probably saves you the most clicks.

And once you've filtered down to the exact slice of log you care about, you'll usually want to take it somewhere else — which is exactly what CSV export is for.

📤 Getting Data Out of the Admin Screen

Every filtered log view can now be exported to CSV directly from the current view. This wasn't a hard technical problem, but it mattered a lot — because plenty of AbilityGuard users aren't just checking a dashboard, they're pulling this data into a compliance report, a security review, or a spreadsheet someone else on the team is going to read.

👀 The Watchlist: Not All Abilities Deserve Equal Attention

Here's the thing about a site with the Abilities API active — you might have dozens of registered abilities, and realistically only a handful of them actually worry you. The ones marked destructive. The ones an AI agent could trigger unattended. The ones tied to user data.

v1.1 adds a sensitive ability watchlist so you can flag exactly those abilities for closer attention, instead of treating every entry in the inventory as equally important. It's a small feature on paper, but it's the one that changes how you actually use the plugin day to day — you stop scanning everything and start watching what matters.

And a watchlist that requires you to keep checking back is still passive. So the next two features exist to close that gap.

📧 Email Alerts and Scheduled Reports

This is the part that turns AbilityGuard from "something I check" into "something that tells me."

Email alerts fire for high-risk, failed, or watchlisted ability executions — so if something destructive runs, or something fails, or a watched ability triggers, you find out without opening wp-admin.
Scheduled reports send a daily or weekly summary of activity, so even if nothing alarming happened, you still get a pulse check in your inbox. Between the two, you get both ends of monitoring covered: immediate notice when something risky happens, and a steady rhythm of visibility even when nothing does.

🌐 Multisite Finally Gets Its Own Dashboard

If you're running a network, checking abilities site by site was never going to scale. v1.1 adds a Network Admin dashboard that shows per-site ability and log counts in one place, so a network admin can spot which site is generating unusual activity without switching contexts twenty times.

And while I was in the multisite code, I found (and fixed in the 1.1.1 patch) a bug where uninstall cleanup only ran on the main site instead of every site in the network. If you'd removed AbilityGuard from a multisite install, subsites were quietly keeping their data behind. That's fixed now — cleanup runs network-wide.

The 1.1.1 patch also brought the inventory detail popup in line with the execution log's detail modal, so the two feel like the same plugin instead of two screens that were designed a week apart.

🧩 What Didn't Change

No new abilities are logged that weren't logged before. AbilityGuard still only tracks Abilities API registrations and executions — not general WordPress admin actions like post edits or media uploads. That boundary was intentional in 1.0, and it's still intentional now. This release is about doing more with the data AbilityGuard already collects, not collecting more kinds of data.

Payload logging also stays privacy-conscious by default: output logging is still off unless you turn it on, same as before.

🛠️ Where This Goes Next

Retention, filters, exports, watchlist, alerts, reports, multisite — that's a lot for one point release, and it's the reason it took a few weeks instead of a few days. What's next is less about adding more surfaces and more about making the existing ones smarter — better risk scoring, and eventually, a Pro tier for teams that need more than a single site's worth of visibility. More on that when it's actually ready to talk about.

If you're running the Abilities API on your site — whether it's your own plugins registering abilities or third-party AI tools doing it for you — v1.1 is a straightforward update. No config migration, no breaking changes, just a plugin that remembers more and bothers you less.

You can grab it from the WordPress.org plugin page.

From a 10-Minute Nap to 300+ Installs: The Story of My 'Restrict WP Upload Type' Plugin

Kushang Tailor — Mon, 03 Aug 2026 12:13:58 +0000

📼 It Started With WordPress 4.7

I still remember the version number: WordPress 4.7. That's when I properly started my journey as a WordPress developer. Not as a "I read a tutorial and now I'm an expert" kind of start — more like a "I broke a client's site three times before lunch" kind of start.

Those were good years, honestly. I built a lot of sites. Small business sites, portfolio sites, e-commerce stores. But there was one problem that followed me across almost every single project, like a background process that never quits: the media library.

Sites would crash. Uploads would eat up server resources. And every now and then, out of nowhere — the dreaded white screen of death, right after someone in the client's team uploaded "just one more file."

🩹 The Debugging Loop I Knew Too Well

Every time this happened, I went into the same routine. Open the error logs, check the wp-content/uploads folder, check PHP memory limits, and dig line by line until I found the culprit.

And more often than not, the answer was almost embarrassingly simple:

A corrupt file that somehow made it through upload
A heavy media file nobody bothered to compress
Someone uploading a .exe or .zip disguised as an image — sometimes by mistake, sometimes not

None of these were WordPress core problems. They were upload hygiene problems. But WordPress, out of the box, doesn't really give site owners a simple way to say "only allow these file types, nothing else." So every time, I'd write a quick one-off fix for that one client, ship it, and move on. It solved the symptom. It never solved the actual disease.

Now, to be fair — the White Screen of Death isn't only caused by bad uploads. Over the years I've seen it come from all sorts of directions: a plugin conflict, a theme function throwing a fatal error, PHP memory limits being exhausted, a corrupted .htaccess file, or even a simple PHP version mismatch after a server update. Uploads were just the culprit I kept running into the most.

🚀 New Job, New Plugins, New Skills

Time moved on, and so did I. I switched companies, and with the new job came new opportunities — this time, actual plugin and theme development work, not just "fix this WordPress site" freelance gigs.

This is where I really understood how plugins and themes are built from the ground up. I started building plugins for clients and for in-house company websites, and eventually shipped my very first personal plugin on WordPress.org — Product Category.

That first release taught me a lot: how WordPress.org review works, how real users behave differently than you expect, and how a plugin is never really "done" — it just moves into its next version.

💤 The Idea That Came During a Nap

Here's the part of the story I still find funny. In early 2022, I was taking a short 10-minute nap — the kind where your brain refuses to fully switch off. And in that half-asleep state, old memories started resurfacing. Corrupt uploads. Wrong file extensions. Clients accidentally uploading a .zip where an image was supposed to go. Years of the same recurring headache, replaying like a highlight reel.

And then the thought hit me:

"What if there was one simple plugin where a site owner could just check which file types are allowed — and everything else gets blocked automatically?"

No more one-off fixes per client. No more custom snippets copy-pasted from an old project. Just one clean toggle-based settings screen.

That nap turned into a plan.

🧩 Planning Before a Single Line of Code

I didn't jump straight into the editor. I sat down and actually mapped out the plugin — what file types needed support, how the settings screen should look, how validation should happen both on the frontend and the server side (because client-side checks alone are basically decorative).

After the research phase, I started building. Following pure OOP structure, keeping things aligned with WordPress coding standards, and making sure every single input was properly sanitized, validated, and escaped — non-negotiables for me, then and now.

🐛 "It Worked Locally... So Why Is Production Rejecting Everything?"

After a solid months of development, the plugin was functionally complete. Time for testing.

I ran it on a few local environments first — smooth. Then I moved it to some live production sites for real-world testing, and that's when things got interesting: uploads stopped working entirely. Every single file, blocked. Media library, dead silent.

My first reaction was pure confusion — it worked perfectly on local, so why was production behaving like it had personally decided to reject every file on Earth?

I dug in. Checked hooks, checked filter priorities, checked MIME validation order. Eventually I traced it back to a plugin conflict — another plugin on those production sites was hooking into the same upload filters, and the two were essentially fighting over who gets the final say on what's "allowed."

So I went back in, added new compatibility functions, and reworked the restriction logic to play nicely with other plugins instead of assuming it owned the upload pipeline alone. Retested. This time — it worked like a charm.

🎉 Launch Day: April 2022

After that final round of verification, I published Restrict WP Upload Type on WordPress.org in April 2022.

If you check the plugin today, it does exactly what that half-asleep idea imagined:

Control over 97 file extensions and MIME types
A simple allow/block toggle for each format
A dedicated SVG security toggle, since SVGs need special handling
Real-time validation that blocks bad uploads before WordPress even shows its generic error
A global file size limit
Zero configuration complexity — install, check some boxes, done

⭐ What the Reviews Taught Me

Shipping the plugin wasn't the finish line — it was the starting line for actually listening. The plugin currently sits at a clean 5-star average across its reviews, and every one of them nudged the roadmap in a real direction.

One review praised how simple and effective the restriction logic was. Another user pointed out something I hadn't considered — they wanted the Restrict Files menu tucked inside the Media menu instead of sitting on its own, and asked for a clearer message telling users which plugin blocked their upload, so support requests wouldn't turn into a guessing game. Another review flagged a rough patch where settings weren't saving properly for one specific site.

I took all of it seriously. Over the following versions, I:

Moved the settings page under Media > Restrict Files, exactly as requested
Added a global max file size control
Made the blocked-upload message fully customizable, so site owners can explain exactly why a file was rejected
Improved validation so it runs before WordPress's generic security error even shows up
Added a settings search and enabled/disabled filters, since scrolling through 97 file types isn't fun for anyone
Tightened up nonce protection and added a proper uninstall cleanup routine

Four reviews might not sound like a lot on paper, but each one represented a real site, a real workflow, and a real reason to keep improving.

🔮 What's Next

The plugin has grown a lot since that April 2022 launch — from a one-page toggle screen to a proper settings experience with search, custom messaging, and file size controls. But I'm not done.

Next on the roadmap: deeper role-based restriction controls, so different user roles can have different upload permissions instead of one global rule for everyone — along with custom MIME type management and upload logs, so site owners get more visibility into who's uploading what.

It's a small plugin in the grand scheme of the WordPress ecosystem. But it came from a real, recurring frustration — and honestly, that 10-minute nap in early 2022 might be one of the more productive naps of my career.

If you manage WordPress media libraries and have ever stared at a white screen after someone uploaded "just one file," you can find Restrict WP Upload Type on WordPress.org.

🛡️ Building AbilityGuard: Monitoring the WordPress Abilities API in Production

Kushang Tailor — Thu, 30 Jul 2026 15:20:05 +0000

A few weeks ago I wrote about the WordPress Abilities API — what it is, why WordPress 6.9 shipped it, and what it means for how plugins will talk to each other and to AI agents going forward. That post was theory. This one is the part where theory meets a composer.json file and a stubborn bug at 1 AM.

This is the story of building AbilityGuard — a plugin that monitors Abilities API usage in production, so you actually know what's happening when abilities get registered, called, and (occasionally) abused.

👀 Why monitoring, and why now

Here's the thing about the Abilities API that got me nervous the first time I really understood it: it's a capability surface. Any plugin can register an ability. Any authorized caller — a human-triggered action, an automation, or increasingly, an AI agent — can invoke one. That's the whole point of the API, and it's genuinely exciting. But it also means your site now has a growing list of "things that can be done to it programmatically," and most WordPress admins have zero visibility into that list.

I've spent enough years debugging WordPress sites in production to know what happens when you can't see something: you find out about it during an incident, not before. Slow queries, rogue cron jobs, plugin conflicts — they all follow the same pattern. Nobody notices the small thing until the small thing becomes the outage.

So the idea for AbilityGuard was simple: give site owners a dashboard and a log for every ability registered on their site, every time one gets called, and by whom. Not another abstract "security scanner" — just honest, readable visibility into a part of WordPress that's brand new and mostly invisible right now.

🔌 Where I started: hooking into the registry, not fighting it

The Abilities API exposes a central registry (wp_get_ability_registry() under the hood, with helper functions layered on top). My first instinct was to intercept ability calls by wrapping core functions — and I killed that idea within the hour. Wrapping core functions is exactly the kind of thing that breaks on the next minor release and turns your plugin into the villain of someone else's changelog.

Instead, AbilityGuard hooks into the lifecycle events the API already exposes: registration, before-execution, and after-execution actions. That's the whole trick. I'm not intercepting anything — I'm listening. When an ability is registered, I capture its metadata (name, description, input/output schema, permission callback). When it's executed, I capture the caller context, the arguments passed, the execution time, and the result status.

That distinction — listening instead of wrapping — ended up shaping almost every architectural decision that followed.

🏗️ The architecture: keeping the pieces simple, so nothing breaks quietly

I could get technical here, but honestly, the idea behind the build is simple enough to explain without any code.

Think of AbilityGuard as three small, separate jobs living under one roof, and none of them stepping on each other's toes:

One part just watches. It sits quietly and notices whenever an ability is registered or run — it doesn't touch anything, doesn't change how the site behaves, it just pays attention.
One part writes it down. Whatever the first part notices gets recorded neatly — what happened, who triggered it, and how (through the website, a command line, an automated schedule, or regular code).
One part shows it to you. The inventory and execution log you see in your WordPress admin area is just a clean readout of what the other two parts already collected. Each of these pieces only knows how to do its own job and nothing else. The "watcher" doesn't know how logs get stored. The "writer" doesn't know how the admin screen looks. That separation sounds like a small detail, but it's the reason the plugin can stay light and predictable — if I ever need to change how something is displayed, I'm only touching the "display" piece, not the parts responsible for actually catching and recording the activity.

For a monitoring tool, that predictability matters more than clever code. A plugin whose entire job is to watch quietly in the background should never be the thing that causes a problem.

🔒 The part nobody wants to think about: sanitize, validate, escape — for data you don't control

This is where AbilityGuard gets a little more interesting than a typical CRUD plugin, because the "input" isn't a form field a human filled in — it's arbitrary arguments passed to an ability, possibly by an automated caller. I can't assume anything about shape or intent.

Every argument captured for logging goes through explicit validation against expected types before it's ever sanitized or stored — nothing gets written on faith. Output is escaped at render time, not at storage time, which is the rule I see broken most often in plugins I audit: people sanitize once on the way in and assume that protects them on the way out. It doesn't. Two different jobs, two different moments.

// LogRepository.php (simplified)
public function insert_event( array $event ): int {
    $sanitized = array(
        'ability_name' => sanitize_key( $event['ability_name'] ),
        'trigger_type' => sanitize_text_field( $event['trigger_type'] ), // rest, wp-cli, cron, php
        'status'       => in_array( $event['status'], array( 'success', 'failure', 'denied' ), true )
            ? $event['status']
            : 'unknown',
        'input'        => $this->logging_enabled( 'input' ) ? wp_json_encode( $event['input'] ) : null,
        'output'       => $this->logging_enabled( 'output' ) ? wp_json_encode( $event['output'] ) : null,
        'created_at'   => current_time( 'mysql', true ),
    );

    return (int) $this->wpdb->insert( $this->table_name, $sanitized );
}

Two decisions there came straight out of thinking about what an admin would actually want, and what they'd regret leaving on by accident. Input logging is configurable, and output logging is off by default, because ability responses can carry sensitive or genuinely large payloads and I'd rather someone opt in deliberately than discover a log table quietly filling up with data they didn't mean to store. On top of that, the log itself is a rolling window of the latest 100 execution entries rather than an ever-growing table — visibility without turning into its own storage liability. And none of it leaves the site: everything stays in a single custom table, {$wpdb->prefix}ability_guard_logs, with no data sent to an external service.

😮 What surprised me while building this

Two things I didn't expect going in.

First, how much discipline it took to not scope-creep into a general activity log. It would have been easy to also log post edits, media uploads, settings changes — the usual audit-log territory. I deliberately left all of that out. AbilityGuard only logs what runs through a registered ability's native execution hooks; if an action doesn't go through the Abilities API, AbilityGuard stays quiet about it. That restraint is the whole point — it's a focused lens on one new capability surface, not a replacement for a general audit log plugin.

Second, how much the "listener, not wrapper" decision simplified everything downstream. Because ExecutionListener only hooks into native ability execution hooks instead of patching internals, trigger context — REST, WP-CLI, cron, or plain PHP — falls out of the hook data for free. I didn't have to reconstruct how something ran; the API already tells me.

🚀 Where it goes next

The next thing on my list is extending AbilityGuard toward accessibility auditing — using the same "listen, don't wrap" pattern to flag abilities whose responses might affect assistive technology output. That's still early, but it feels like a natural second act for a plugin whose whole reason for existing is making the invisible visible.

If you're building on the Abilities API yourself — whether that's registering your own abilities or just trying to understand what's already running on your site — I'd genuinely like to hear what you're building. This corner of WordPress is still small enough that we're all figuring it out together.

🔗 AbilityGuard is live on WordPress.org: https://wordpress.org/plugins/ability-guard/

I Sold My PS5. A Very Big Step.

Kushang Tailor — Sat, 25 Jul 2026 12:09:17 +0000

I know from the title you're thinking, "What does a PS5 have to do with a big step?" But c'mon, we all know this — nobody hates PlayStation. Everyone loves it. Some people bought it on EMI, some paid full price without blinking, some just saved for months to finally get their hands on one. No matter the cost, everyone wants it in their living room.

And it's not like the timing was even good. Two massive upcoming games are lined up — GTA 6 and John Wick. Yeah, the games that gamers like me have been waiting for, refreshing trailers, checking release dates every other week. So selling my PS5 right now, right before all that? Trust me, it hurt more than it sounds.

But here's the thing about big steps — they're rarely the fun kind.

💸 The Real Reason

I wasn't proud of admitting this, but I'll say it plainly because that's the whole point of writing this: I was going through a financial crisis. Not the dramatic kind you see in movies, just the quiet, everyday kind — bills stacking up, income drying up, and that constant math running in your head every single day. You know the feeling. You open your banking app, do the mental subtraction, and close it again pretending you didn't just do that.

I'd been picking up Uber delivery shifts on my bike to fill the gaps, something I've written about before — You can check here. It helped, but it wasn't enough to cover everything. Some months you patch the hole. Other months the hole is just bigger than the patch you have.

So I sat there one evening, phone in hand, staring at my PS5 sitting quietly under the TV. It wasn't collecting dust — I loved that thing. But love doesn't pay bills, and I had to be honest with myself about what mattered more right now.

🎮 Making the Call

I'm not going to pretend this was some heroic, easy decision. It wasn't. I went back and forth for a couple of days. I even checked the resale price twice hoping it'd somehow answer the question for me. But at some point you just have to stop overthinking and act, because the tension of not deciding is worse than the decision itself.

I listed it. Priced it fair — not a giveaway, but not greedy either. Within a few days, I got a buyer. Someone genuinely excited to take it home, probably as pumped about GTA 6 as I was. There was a small, weird moment of handing it over — like saying bye to a good friend who's moving to another city. You're happy for them, a little sad for yourself.

🌤️ What Happened Next

Here's the part that actually matters: I got a genuinely good amount for it. Good enough that next month's tension just... vanished. That constant low-grade stress I'd been carrying for weeks? Gone, at least for a while.

And because of that breathing room, I did something I didn't expect — I temporarily stopped the Uber deliveries. Not because I don't need that income anymore, but because for the first time in a long time, I wasn't running on empty. I could actually sit, think, plan, and not just react to whatever bill showed up next.

✍️ Why I'm Writing This

Honestly? Because I think we don't talk about this stuff enough. Everyone posts the wins — the new gear, the new setup, the "look what I bought" content. Nobody really posts "I sold my PS5 because I needed the money." It feels a little embarrassing to admit, even now while typing this.

But I think that's exactly why it's worth sharing. Financial pressure isn't rare. It's not a personal failure. It's just life catching up sometimes, especially when you're juggling freelance income, gig work, and unpredictable months. Selling something you love isn't defeat — it's just a decision. A trade-off. You give up a want to protect your stability, and that's not weakness, that's just being an adult about it.

Will I buy a PS5 again someday? Probably, yeah. Maybe when GTA 6 actually drops and I've got some cushion built back up. But for now, I don't regret it. It did exactly what I needed it to do — it gave me one less thing to worry about, and that's worth more than any game right now.

Sometimes the "big step" isn't buying something new. Sometimes it's letting go of something you love, for the version of you that needs it more.

📸 One Last Look

Before I handed it over, I took one last photo. Felt a little silly doing it, honestly — like taking a picture with an old friend before they leave. But I'm glad I did. It's a small reminder of where I was, the decision I made, and why I made it. Not everything worth keeping has to stay in your living room.

The Bug I Fixed Nine Times Before I Finally Killed It For Good

Kushang Tailor — Mon, 20 Jul 2026 15:39:03 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

🎭 The Recurring Villain

If you've built WordPress sites long enough, you know this bug. It doesn't show up as an error in your console. It doesn't throw a fatal exception. It just quietly sits there, page after page, client after client — and it's called video bloat.

Nine years into web development, I lost count of how many times a client sent me a site with a message like "it's just... slow." And nine times out of ten, when I opened DevTools and checked the waterfall, the story was the same: three, four, sometimes ten embedded YouTube videos, each one dragging in its own iframe, its own set of scripts, its own chunk of megabytes — all loading the second the page rendered, whether the visitor scrolled past them or not.

One video embed alone can pull in 500KB–1MB+ before a user even presses play. Multiply that by a landing page stacked with testimonials, product demos, and a hero video, and you've got a page that fights your Core Web Vitals before it's even finished loading.

🔁 The Manual Fix (Every. Single. Time.)

For years, my solution was the same tedious ritual:

Find every video embed on the page.
Replace the iframe with a static thumbnail image.
Write a bit of custom JavaScript to swap the thumbnail for the real embed on click or scroll.
Repeat it for YouTube.
Repeat it again for Vimeo, because Vimeo's oEmbed API works differently.
Repeat it again for self-hosted <video> tags, because now you're dealing with <source> tags instead of iframes.
Test it across whatever page builder the client was using — Elementor, Divi, WPBakery, or straight-up Gutenberg blocks — because every one of them nests the video markup slightly differently. It worked. But it was never reusable. Every project meant writing the lazy-load script again, half from memory, half copy-pasted from my own old projects, tweaked just enough to fit the new theme's markup. It was the same bug, wearing a different site's clothes each time.

💡 The Moment It Clicked

The turning point wasn't one dramatic incident — it was the accumulation. After the fifth or sixth time writing near-identical vanilla JS to defer a YouTube iframe, I finally asked myself the obvious question: why am I solving this per-project instead of solving it once?

That's what pushed me to stop patching symptoms and build VidDefer — a plugin that treats video lazy-loading as a solved problem you should never have to think about again.

🛠️ How VidDefer Actually Fixes It

The core trick is that VidDefer doesn't care how or where your video got onto the page. Instead of hooking into specific page builders one by one (which is a losing battle — there's always a new builder), it uses PHP output buffering to intercept the final rendered HTML before it reaches the browser. Any YouTube iframe, Vimeo iframe, or self-hosted <video> tag gets swapped for a lightweight thumbnail-and-play-button placeholder — regardless of whether it came from Gutenberg, Elementor, Divi, WPBakery, or hand-written HTML in a Custom HTML block.

The real video only loads when a visitor actually clicks, or scrolls near it — saving hundreds of kilobytes on every page load where a video isn't watched (which, statistically, is most of the time).

A few details I was stubborn about while building it:

Zero configuration. Activate it, and it just works. No setup wizard required, though there's a settings screen if you want to tweak things.
No jQuery. Pure ES6, under 2KB gzipped. The whole point is performance — the fix itself shouldn't add weight.
Per-source handling done properly. YouTube thumbnails come straight from YouTube's public CDN (no API key needed). Vimeo thumbnails come through Vimeo's oEmbed endpoint and get cached locally via WordPress transients, so your server isn't pinging Vimeo on every single page load.
Accessibility wasn't optional. The placeholders are keyboard-navigable and follow WCAG 2.1, because a performance fix that breaks accessibility isn't a fix.
An escape hatch. Some videos — popups, lightboxes — shouldn't be touched. A simple no-lazy class tells VidDefer to leave them alone.

⚡ Before vs. After

Here's where I want to be upfront instead of hand-wavy: I'm not going to drop a flashy "300% faster!" screenshot in this post, because that number would either be fake or borrowed from a client site — and client performance data isn't mine to publish. Privacy first, always.

What I can tell you honestly: VidDefer just landed on WordPress.org. It's brand new. So instead of cherry-picking an old result, I'd rather show you real, verifiable numbers once they exist — a proper before/after on a demo site loaded with heavy video embeds, tested with actual Lighthouse and PageSpeed runs, out in the open where anyone can double-check it.

That's next on my list: building a public demo site stacked with YouTube, Vimeo, and self-hosted videos, and publishing the raw before/after report for everyone to see — no cherry-picking, no marketing spin. If you're curious, that follow-up post is coming.

What I can say with confidence today, from nine years of doing this fix by hand: every unloaded iframe is bytes and requests your browser simply never has to make. The math isn't controversial — deferring what the visitor hasn't asked to see yet is a straightforward win. I just want to show you that win with real data, not tell you about it.

🎓 What I Learned

The real lesson here wasn't about video embeds at all — it was about recognizing when you're solving the same bug over and over and calling it "just part of the job." If you find yourself writing a similar patch for the third or fourth time, that's not a coincidence. That's a signal that the fix belongs in a tool, not in your muscle memory.

For me personally, the fix that used to take an hour or two of custom scripting per project now takes the time it takes to click "Activate." That alone was worth building.

VidDefer is live on WordPress.org now, and every install is one fewer freelancer somewhere staying up late writing the same lazy-load script I used to write.

🔗 VidDefer – Deferred Video Embeds on WordPress.org

100+ Job Applications, 2 Months, Zero Offers — Why I Started Riding an Uber Delivery Bike

Kushang Tailor — Fri, 10 Jul 2026 14:18:11 +0000

Never break when your time is tough — just stay calm, stay active, and keep moving.

🎯 The Application That Broke Me

I stopped counting after 100.

I applied to every role that matched my resume, including:

WordPress Developer
Full-Stack Developer
Frontend Developer
Backend Developer
Business Development Executive - Entry Level
Project Manager - Entry Level
Junior React Native Developer
Senior WordPress Developer

Two months. Every relevant listing I could find. Custom cover letters for the ones that mattered. Follow-ups. LinkedIn messages to hiring managers who never wrote back.

Nothing worked out.

Not one offer. Barely a handful of interviews. A few "we'll get back to you" emails that never came back.

So a few weeks ago, I picked up a food and package delivery job on Uber, riding my own Hero Xtreme 125 through morning and evening traffic. I'm writing this because I think a lot of developers reading this are living some version of the same story right now, and nobody in our field likes to say it out loud. I do.

📊 The Market Isn't in Your Head — It's Actually This Bad

If job hunting in 2026 feels harder than it should, that's not you being unskilled or unlucky. The numbers back you up.

The time it takes to get a first job offer jumped from 57 days to 83 days in 2025 — almost a month and a half longer than before. Entry-level hiring at the biggest tech companies dropped 25% between 2023 and 2024, and it still hasn't bounced back. Software job postings are still down more than a third from pre-pandemic levels, and about 7% lower than they were just a year ago.

It's not just a "big tech" problem either. At one well-known Indian engineering institute, fewer than a quarter of a graduating class of 400 students had job offers just months before their course ended. Students there are calling it a "jobpocalypse." Tech layoffs crossed 150,000 in a single year not long ago, and even though the number has come down since, Q1 2026 alone saw close to 80,000 more tech workers lose their jobs.

Here's the part that hurts if you're early in your career: it's not spread evenly. Jobs for young software developers have dropped almost 20% from their late-2022 peak. Senior and specialist roles are actually growing at some companies — Google alone posted 62% more engineering openings in the first half of 2026 than a year earlier — but that growth sits at the top of the experience ladder, not at the entry point most of us are trying to get through.

So if you've sent 50, 80, 100+ applications and heard mostly silence — you're not the exception. You're the current normal.

⚡ What's Actually Causing This

Four things are happening at once, and it helps to name them instead of just feeling them.

1. AI is eating the "easy" tickets first. Company leaders aren't hiding it anymore. Microsoft's CEO has said AI now writes a real chunk of the code in some of their projects. Salesforce's CEO said his company hired zero new engineers in a recent year because AI tools closed that gap. The small, simple tasks that used to be a junior developer's way in — quick bug fixes, boilerplate features, basic integrations — are exactly what AI coding tools now handle well. That doesn't mean developers are useless, but it does remove a lot of the "starter" work companies used to hire freshers for.

2. Companies are still recovering from over-hiring in 2021-2022. A lot of today's layoffs trace back to companies that doubled their engineering teams during the cheap-money pandemic years and are now cutting that back. This has nothing to do with your skills. It's a hiring hangover that started years before you even applied.

3. Global conflicts are adding extra pressure on hiring budgets. With active wars and unrest going on in multiple regions right now, companies are dealing with higher energy costs, shakier supply chains, and more cautious investors. Reports through 2026 show business leaders openly saying this instability is a factor in tighter, slower hiring decisions — money is moving toward "safe" spends like cybersecurity and core AI infrastructure, and away from riskier hiring plans, especially at the entry level.

4. The bar for "entry-level" quietly moved higher. Companies don't just want a degree and a to-do-list app on your GitHub anymore. They want real, shipped work — actual projects, actual collaboration, actual production experience — squeezed into what used to be an entry-level ask. It's a classic trap: you need production experience to get hired, and you need to get hired to gain production experience.

None of this means the field is dying. Developer roles are still expected to grow well into the next decade, and plenty of companies are hiring hard for the right profile. But "the right profile" has shifted, and nobody warns you about that shift until you're three months deep into rejections.

🚀 What Skills Are Actually in Demand Right Now

Going through current hiring data and job posts, the same pattern keeps showing up:

Working with AI tools is no longer a bonus — it's expected. More than half of tech job posts now ask for AI/ML familiarity, and daily use of tools like GitHub Copilot, Cursor, Codex, or Claude Code is fast becoming a basic skill, not an impressive one.
Depth over "I can do everything." The generalist pitch is losing ground to developers with real, provable depth in one lane — cloud, DevOps, ML, security, or a specific ecosystem.
For WordPress specifically, the bar has moved well past "I can install a theme and turn on WooCommerce." Companies now want REST API and headless WordPress experience, React-based block development, clean OOP plugin architecture, solid Git habits, and comfort with the platform's built-in AI tooling. WordPress still runs over 40% of the web, so the demand is real — it's just concentrated on developers who've moved past template installs.
Proof over polish. A strong GitHub history, published articles, or real shipped projects now carry more weight than a clean resume, since most hires still come through referrals and visible work, not cold applications.

⚖️ My Skills vs. What's Actually Demanded

Here's where I had to be honest with myself instead of just angry at the market.

What I bring: I've built and shipped 4 WordPress plugins from scratch, following pure OOP architecture, WordPress VIP coding standards, and proper sanitization/escaping at every layer. I've built enterprise-level websites and web apps using React and Next.js, including headless WordPress setups where the frontend is fully decoupled from the CMS. Performance and security aren't an afterthought for me — I bake them into the build from day one, whether that's caching strategy, query optimization, or basic hardening against common attack vectors. I also actively use AI tools like Codex, Claude, and GitHub Copilot as part of my real workflow — not just to autocomplete a line, but to help scaffold plugins, debug tricky WordPress hooks, and speed up full web app builds. On top of that, I keep a solid, active GitHub history and write technical articles regularly, so my work is documented and public, not sitting in private repos nobody sees.

Where the gap actually is: the problem wasn't that I lacked AI fluency — I use these tools daily and build with them. The real gap was in how I was positioning myself. I was applying into the same volume-heavy, entry-level pool as everyone else, instead of clearly showing recruiters that I already work the way the market now expects: AI-assisted, specialization-focused, with real production and architecture experience behind me. My resume wasn't telling that story loudly enough.

That gap isn't a character flaw. It's a positioning problem, and it's fixable — just not in the two months I had bills to pay in the meantime.

🛵 Why I Joined Uber

I didn't join Uber because I gave up on development. I joined because rent, food, and basic responsibilities don't pause for a job market correction, and two months of zero income while sending applications into a void just isn't sustainable for anyone.

Delivery work on my own bike gave me something a regular part-time job couldn't: income starting almost right away, with zero disruption to my ability to keep applying, interviewing, and writing during the hours I wasn't riding. It's physically harder than sitting at a desk, and yes, some pride had to be swallowed. But a bridge is a bridge, and I'd rather ride one than fall through the gap it's covering.

✅ The Onboarding Process Was Refreshingly Simple

Compared to the black-hole application process I'd just been through, signing up to deliver was almost jarring in how simple it was:

No bond. No lock-in agreement of any kind.
No fixed shift hours — I choose when I ride, and I choose when I stop.
Document verification, a basic orientation, and I was live on the app within days, not weeks.
Full control to log off any time — no penalty for taking a day off for an interview or a writing deadline. That flexibility is exactly why it works as a bridge income source. I run two shifts a day — morning and evening — and build the rest of my day around job hunting and content work.

💰 The Actual Numbers: What My Hero Xtreme 125 Earns Me

Let's do this properly, because vague "I make decent money" claims don't help anyone else weighing this option.

My setup: a Hero Xtreme 125, petrol at roughly ₹100/liter, riding two shifts a day — morning and evening — spending roughly ₹100 in fuel per shift (about ₹200/day, close to 2 liters). I also take one full day off every week to rest, both for me and the bike.

Hours/day	Gross earning	Fuel cost	Net earning/day
6 hrs (standard)	₹700–800	~₹200	₹500–600
8 hrs (extended)	₹1,000+	~₹200–250	₹750–800+
10 hrs (long day)	~₹1,250–1,300	~₹280–300	~₹950–1,000
12 hrs (max stretch)	~₹1,450–1,550	~₹320–350	~₹1,100–1,200

Notice the per-hour rate drops a bit as the hours climb — that's normal, since the best surge-pricing windows (early morning and evening rush) get used up first, and the extra hours are usually slower, lower-paying stretches.

Scaling this out with a weekly off day built in — roughly 26 riding days a month:

Period	6 hrs/day	8 hrs/day	10 hrs/day	12 hrs/day
Monthly (net)	~₹14,300	~₹20,000–20,800	~₹25,350	~₹29,900–31,200
Yearly (net)	~₹1,71,600	~₹2,40,000–2,49,600	~₹3,04,200	~₹3,58,800–3,74,400

A quick mileage sanity check: the Xtreme 125 is rated over 60 kmpl on paper, but real-world, stop-start delivery riding usually brings that down to somewhere between 40 and 50 kmpl. At ₹100/liter, that's roughly ₹2–2.5 per km, which lines up closely with the ₹200/day I actually spend across two shifts covering around 80–100 km total.

Worth being upfront about the parts this table doesn't show: chain lubrication, oil changes, tyre wear, and regular servicing add up over months of daily riding. So the real net is a little lower than the fuel-only numbers suggest once you spread maintenance across the year. I'd set aside roughly ₹500–800 a month for that on top of fuel.

It's not developer-salary money. It's not meant to be. It's meant to keep the lights on while I fix the real problem — landing the next role.

💭 A Few Things I'd Add From My Side

A few honest thoughts that didn't fit neatly into the sections above but felt worth saying:

This isn't a failure story, it's a sequencing story. The job search didn't stop. It just stopped being the only thing paying the bills while it played out.
Writing kept me sane. Publishing articles and working on side projects during this stretch gave me something the job hunt alone couldn't — a sense of moving forward on days when applications went nowhere.
The stigma is the hardest part, not the job itself. Riding a delivery bike after years of writing production code messes with your head more than the physical work does. Worth saying plainly, because I suspect a lot of developers going through something similar feel that shame alone.
Flexibility is underrated as a survival tool. A gig with no bond and no fixed hours meant I never had to choose between an interview and a shift. That mattered more than the pay itself.
The market will turn — but not by waiting. Every report on this points the same way: demand for developers who can specialize and work fluently with AI tools is actually growing, even while generic entry-level postings shrink. The move isn't to give up on development. It's to close the gap between how you're positioned and what's currently getting hired.

🌱 Where This Leaves Me

I'm still applying. I'm still writing. I'm still building and the rest of my plugins work in whatever hours are left after two shifts on the bike. The Uber income isn't the destination — it's what's making sure I don't have to pause the actual goal while the market sorts itself out.

If you're in the same spot right now — sending applications into what feels like a void — you're not behind, and you're not broken. The data shows the market genuinely shifted under everyone's feet at the same time. The only real move is to keep adjusting how you show up, while keeping the lights on however you need to.

If this resonated with you, or you're going through something similar, I'd genuinely like to hear how you're handling it. Drop a comment.

Sources referenced: IEEE Spectrum, Rest of World, The Pragmatic Engineer's 2026 job market deep-dive, Final Round AI's 2026 software engineering market report, Second Talent's 2026 tech job market trends, SQ Magazine's layoff statistics roundup, Forbes' 2026 midyear geopolitical trends tracker, IDC's 2026 IT spending outlook, and current WordPress hiring guides from Wisemonk and Boundev.

Why I Stopped Trusting 'Just Embed the Video' and Built VidDefer Instead

Kushang Tailor — Tue, 07 Jul 2026 13:00:00 +0000

🎬 Why I Built VidDefer — And Why Your Video-Heavy WordPress Site Probably Needs It

Let me start with a confession: for years, I treated video embeds like they were "free." Drop a YouTube iframe into a post, hit publish, move on. No big deal, right?

Wrong. Dead wrong.

The moment I actually opened DevTools on a client site with 15+ embedded YouTube videos on a single landing page, I understood why the Core Web Vitals report looked like a crime scene. Every single embed was silently loading its own player, its own scripts, its own tracking pixels — before the visitor had even scrolled past the hero section.

That frustration is the entire origin story of VidDefer – Deferred Video Embeds, a plugin I just shipped to the WordPress.org repository.

This isn't a "top 10 performance tips" article. It's the story of a real problem, why existing solutions didn't fully cut it, and how VidDefer approaches it differently — plus an honest breakdown of who actually needs this plugin (spoiler: not everyone does).

💡 Where the Idea Actually Came From

I didn't wake up one day and decide "I should build a video lazy-load plugin." It came from a pattern I kept noticing across client projects:

A course platform with a video per lesson page.
A real estate site with property walkthrough videos on every listing.
A recipe blog embedding a YouTube tutorial in nearly every post.
A SaaS marketing site with a demo video stacked on top of three testimonial videos, all on the homepage. Every single one of these sites had the same complaint: "Our PageSpeed score is terrible, and we don't know why — we already optimized images and enabled caching."

The answer was almost always hiding in plain sight: multiple video iframes loading simultaneously on page load, each one pulling in third-party JavaScript before a visitor had shown any intent to actually watch anything.

Existing lazy-load plugins handled images beautifully. Videos were treated like an afterthought — usually just "lazy load the iframe attribute" without actually deferring the heavy scripts behind it. That gap is where VidDefer was born.

🎯 Why This Plugin? What Problem Does It Actually Solve?

Here's the technical reality most WordPress users don't realize: a standard YouTube or Vimeo embed doesn't just load a video. It loads:

The full embedded player iframe
YouTube/Vimeo's own JavaScript player framework
Analytics and tracking scripts bundled by the provider
Preconnect and font requests tied to the player UI All of this fires immediately on page load, whether or not the visitor ever intends to press play. Multiply that by every video on the page, and you've got a serious Largest Contentful Paint (LCP) and Total Blocking Time (TBT) problem — even if your images and fonts are perfectly optimized.

VidDefer solves this with a simple idea: show a lightweight thumbnail placeholder first, and only load the real player when the visitor clicks it (or scrolls to it, if you enable that mode). The visitor sees a legitimate, good-looking video preview instantly. The heavy player only loads on genuine interaction.

The result: pages that used to ship hundreds of kilobytes of unused video-player JavaScript on load now ship a tiny thumbnail image instead — until the user actually asks for the video.

🎥 Built Specifically for Video-Heavy Sites — Not Every Site Needs This

I want to be upfront about something most plugin marketing pages avoid saying: if your site has one video, buried at the bottom of one blog post, you probably don't need VidDefer. The performance gain there is marginal.

This plugin earns its place specifically on:

Course and membership sites with a video embedded on every lesson page
Real estate and travel sites using video walkthroughs across dozens of listings
SaaS and agency landing pages stacking demo videos, testimonial videos, and explainer videos together
Media and review blogs that embed a YouTube video in nearly every article
Portfolio and creative sites showcasing multiple embedded reels or showcases per page If your site falls into "video-heavy" territory — meaning multiple embeds per page, or video embeds across a large percentage of your total pages — that's exactly where VidDefer is designed to shine. On a content-light, video-light site, a general-purpose performance plugin will likely already cover you. VidDefer isn't trying to replace that; it's solving a narrower, deeper problem for sites where video embeds are the actual bottleneck.

🔍 The Real-World Problem, In Numbers

Here's a rough breakdown of what a single unoptimized YouTube embed typically drags along with it on load, compared to a deferred thumbnail placeholder:

A standard embedded iframe pulls in the player framework, related scripts, and thumbnail assets that can easily add several hundred kilobytes and multiple third-party requests — before playback even starts.
A deferred placeholder, by contrast, is just a compressed thumbnail image and a small play-button overlay, with the actual plugin script itself weighing in at under 2KB gzipped. Now multiply that by five, ten, or fifteen embeds on a single page — which is completely normal for course platforms or video-heavy blogs — and you can see why Core Web Vitals scores collapse on these page types specifically, even when everything else on the site is well-optimized.

⚙️ Which Third-Party Scripts Does VidDefer Actually Defer?

This is the part developers usually want to know, so let's get specific. On visitor interaction (click or scroll trigger, depending on your settings), VidDefer defers and then loads:

Video Source	What Gets Deferred	What Loads Only on Interaction
YouTube	The full YouTube iframe player + its embedded scripts	Real YouTube iframe player, pulling thumbnails from YouTube's public thumbnail CDN
Vimeo	The full Vimeo iframe player + its embedded scripts	Real Vimeo iframe player, with thumbnail/title metadata fetched via Vimeo's public oEmbed API and cached locally via WordPress transients
Self-hosted video	The `<video>` element and its associated MP4/WebM/OGV source loading	The actual video file, only once the visitor triggers playback

A few implementation details worth calling out for fellow developers:

Vimeo thumbnail/title data is fetched via a secure server-to-server request and then cached using WordPress transients, so your site only contacts Vimeo once per video, not on every page load.
YouTube thumbnails are pulled straight from YouTube's public thumbnail CDN — no API key required, no quota limits to worry about.
The plugin intercepts embeds using PHP output buffering, so it works regardless of whether the video was added via Gutenberg, Elementor, Divi, WPBakery, or hand-coded HTML.

📊 Without VidDefer vs. With VidDefer

Aspect	Without VidDefer	With VidDefer
Initial page load	Every embedded video loads its full iframe + scripts immediately	Only a lightweight thumbnail image loads initially
Third-party requests on load	Multiple requests per video (player framework, tracking, fonts)	Zero third-party requests until visitor interacts
JavaScript weight	Grows with every additional embedded video	Plugin adds under 2KB gzipped, regardless of video count
LCP / TBT impact	Degrades significantly on video-heavy pages	Minimal impact — thumbnails are lightweight and render fast
Visitor experience	Player controls appear before intent to watch is shown	Clean thumbnail + play button, feels intentional and fast
GDPR / privacy exposure	Third-party cookies/scripts may load before consent	No third-party connection made until visitor clicks play
Accessibility	Depends entirely on the embed provider's markup	WCAG 2.1 keyboard-accessible placeholders built in
Page builder compatibility	N/A	Works with Gutenberg, Elementor, Divi, and WPBakery via output buffering

🥊 Competitors vs. VidDefer

There are a handful of established performance plugins that touch video lazy loading as a side feature. Here's an honest, non-exaggerated comparison of where VidDefer differs:

General-purpose performance/caching plugins (the big all-in-one optimization suites): most of these treat video lazy loading as one small checkbox buried inside a much larger feature set focused on caching, minification, and image optimization. It works, but it's rarely built with video-specific controls like thumbnail quality, play-button styling, or per-video exclusion classes.
Dedicated "lazy load for videos" plugins: a few of these exist, but many are YouTube-only, require an API key, or haven't been updated in a while. Vimeo and self-hosted video support is often missing entirely.
Manually coding it yourself: totally possible if you're comfortable writing custom output-buffering logic and thumbnail-fetching code for three different video sources — but that's a real time investment for something that should be a five-minute plugin activation. VidDefer's niche is being video-first and multi-source from day one: YouTube, Vimeo, and self-hosted videos, all handled the same way, with zero configuration required to get the core benefit, and deeper customization available for anyone who wants it (thumbnail quality, play button style, colors, exclusions, GDPR overlay).

To be fair to the alternatives: if you only need basic image lazy loading and video is a minor part of your site, an all-in-one performance plugin is still a perfectly reasonable choice. VidDefer is for when video is the primary performance bottleneck, not a footnote.

➕ A Few Additional Things Worth Knowing

No API key required — YouTube thumbnails come from the public CDN, Vimeo data comes from the public oEmbed endpoint. Nothing to configure, nothing to break when a key expires.
Exclusion support — Add a no-lazy class to any video, iframe, or wrapping element to skip it entirely, useful for popups and lightboxes that need immediate access to the player.
YouTube Shorts are handled automatically, since they use the same embed format as standard YouTube videos.
Three play button styles and custom colors mean the placeholder doesn't have to look like an obvious plugin bolt-on — it can match your site's branding.
Built-in GDPR/privacy notice overlay is a nice side effect of the deferred-loading architecture: since no third-party connection happens until the click, you get a natural checkpoint to show a consent notice first.

🚀 Try It, Break It, Tell Me About It

If your site has more than a couple of embedded videos per page — especially across course content, listings, or media-heavy posts — I'd genuinely love for you to try VidDefer – Deferred Video Embeds and see what it does to your Core Web Vitals numbers.

It's version 1.0.0, freshly published, so bug reports and feature requests through the support forum are extremely welcome. If you've solved this problem a different way on your own sites, I'd love to hear that too — drop a comment below.