DEV Community: MD Hemal Akhand

Uploaded first part of my typescript tutorial. See here: https://dev.to/mdhemalakhand1999/master-typescript-part-01-452g

MD Hemal Akhand — Mon, 22 Jun 2026 01:13:24 +0000

MD Hemal Akhand

Jun 22

Master TypeScript — Part 01

#typescript #javascript

8 min read

Master TypeScript — Part 01

MD Hemal Akhand — Mon, 22 Jun 2026 01:09:16 +0000

TypeScript checks your JavaScript before it runs. Wrong data types show as errors while you code, not when users hit your app.

Syntax: let name: type = value — a named box that must hold that type.

Core Types

A type answers: what kind of value is this?

String — text.

let message: string = "Hello, TypeScript!";

Number — whole or decimal.

let age: number = 30;
let pi: number = 3.14159;

Boolean — only true or false.

let isAuthenticated: boolean = true;
let hasPermission: boolean = false;

Array — list of one kind. string[] or Array<boolean>.

let numbers: number[] = [1, 2, 3, 4, 5];
let names: string[] = ["Alice", "Bob", "Charlie"];
let flags: Array<boolean> = [true, false, true];

Tuple — fixed order per slot. Wrong order = error.

let user: [number, string, boolean];
user = [1, "Alice", true];
// user = ["Alice", 1, true]; // Error

Enum — named choices instead of magic numbers.

enum Role { Admin, User, Guest }
let role: Role = Role.Admin;

enum Status { Active = 1, Inactive = 0, Suspended = -1 }
let accountStatus: Status = Status.Active;

Final code:

let message: string = "Hello, TypeScript!";
let age: number = 30;
let pi: number = 3.14159;
let isAuthenticated: boolean = true;
let hasPermission: boolean = false;

let numbers: number[] = [1, 2, 3, 4, 5];
let names: string[] = ["Alice", "Bob", "Charlie"];
let flags: Array<boolean> = [true, false, true];

let user: [number, string, boolean];
user = [1, "Alice", true];
// user = ["Alice", 1, true]; // Error: order doesn't match

enum Role { Admin, User, Guest }
let role: Role = Role.Admin;

enum Status { Active = 1, Inactive = 0, Suspended = -1 }
let accountStatus: Status = Status.Active;

Arrays

An array holds multiple values. type[] means every item is that type.

String array:

let fruits: string[] = ["Apple", "Banana", "Cherry"];

Number array:

let scores: number[] = [90, 85, 78];

Boolean array:

let isAvailable: boolean[] = [true, false, true];

Array of objects — each item has the same shape:

let users: { id: number; name: string; active: boolean }[] = [
  { id: 1, name: "Alice", active: true },
  { id: 2, name: "Bob", active: false },
];

Mixed array — uses any[], turns off type checking. Avoid when you can.

let mixed: any[] = ["Text", 42, true];

Final code:

let fruits: string[] = ["Apple", "Banana", "Cherry"];
let scores: number[] = [90, 85, 78];
let isAvailable: boolean[] = [true, false, true];

let users: { id: number; name: string; active: boolean }[] = [
  { id: 1, name: "Alice", active: true },
  { id: 2, name: "Bob", active: false },
];

let mixed: any[] = ["Text", 42, true];

Objects

An object groups related fields. Access with dot: car.brand.

Simple object:

let car: { brand: string; model: string; year: number } = {
  brand: "Tesla", model: "Model S", year: 2023,
};

Nested object — object inside object:

let employee: {
  id: number; name: string; position: string;
  contact: { email: string; phone: string };
} = {
  id: 101, name: "John Doe", position: "Software Engineer",
  contact: { email: "john.doe@example.com", phone: "123-456-7890" },
};

Optional field — ? means the field may be missing:

let product: { id: number; name: string; price?: number } = {
  id: 1, name: "Laptop",
};

Final code:

let car: { brand: string; model: string; year: number } = {
  brand: "Tesla", model: "Model S", year: 2023,
};

let employee: {
  id: number; name: string; position: string;
  contact: { email: string; phone: string };
} = {
  id: 101, name: "John Doe", position: "Software Engineer",
  contact: { email: "john.doe@example.com", phone: "123-456-7890" },
};

let product: { id: number; name: string; price?: number } = {
  id: 1, name: "Laptop",
};

Functions

A function runs reusable steps. Type the inputs and the return value.

Basic function — two numbers in, one number out:

function add(a: number, b: number): number {
  return a + b;
}

Optional parameter — ? means you can skip it:

function greet(name: string, message?: string): string {
  return message ? `${message}, ${name}!` : `Hello, ${name}!`;
}

Default value — used when the argument is not passed:

function calculateDiscount(price: number, discount: number = 10): number {
  return price - (price * discount) / 100;
}

Return an object:

function createUser(id: number, name: string): { id: number; name: string; active: boolean } {
  return { id, name, active: true };
}

Arrow function — short syntax with =>:

const multiply = (a: number, b: number): number => a * b;

Return undefined when nothing is found:

let employees: { id: number; name: string; role: string }[] = [
  { id: 1, name: "Alice", role: "Developer" },
  { id: 2, name: "Bob", role: "Manager" },
];

function findEmployeeById(id: number): { id: number; name: string; role: string } | undefined {
  return employees.find((employee) => employee.id === id);
}

Final code:

function add(a: number, b: number): number { return a + b; }

function greet(name: string, message?: string): string {
  return message ? `${message}, ${name}!` : `Hello, ${name}!`;
}

function calculateDiscount(price: number, discount: number = 10): number {
  return price - (price * discount) / 100;
}

function createUser(id: number, name: string): { id: number; name: string; active: boolean } {
  return { id, name, active: true };
}

const multiply = (a: number, b: number): number => a * b;

let employees: { id: number; name: string; role: string }[] = [
  { id: 1, name: "Alice", role: "Developer" },
  { id: 2, name: "Bob", role: "Manager" },
];

function findEmployeeById(id: number): { id: number; name: string; role: string } | undefined {
  return employees.find((employee) => employee.id === id);
}

Type Inference

TypeScript infers types from values — you write less, stay safe.

Object inference — types are detected from the value:

const userInfo = { id: 1, name: 'MD Hemal Akhand', age: 25, verified: true };

typeof — reuse an object's shape as a type:

function printUser(input: typeof userInfo) {
  console.log(input.name);
}

Inside a function — destructured fields are inferred too:

function validateForm(formData: { email: string; age: number; isAdmin: boolean }) {
  const { email, age, isAdmin } = formData;
  return email.includes('@') && age < 18;
}

Final code:

const userInfo = { id: 1, name: 'MD Hemal Akhand', age: 25, verified: true };

function printUser(input: typeof userInfo) {
  console.log(input.name);
}

function validateForm(formData: { email: string; age: number; isAdmin: boolean }) {
  const { email, age, isAdmin } = formData;
  return email.includes('@') && age < 18;
}

Type Aliases

A type alias names a shape once and reuses it.

Simple alias:

type name = string;
type ID = string | number;

Use the alias:

function printID(id: ID) { console.log(`Your id is: ${id}`); }
printID(123);
printID('123');

Object alias:

type User = { id: ID; firstName: string; lastName: string; skills: string[] };

Return type on function:

function createUser(firstName: string, lastName: string): User {
  return { id: crypto.randomUUID(), firstName, lastName, skills: [] };
}

satisfies — checks shape without forcing return type:

function createUser2(firstName: string, lastName: string) {
  return { id: crypto.randomUUID(), firstName, lastName, skills: [] } satisfies User;
}

as — forces a type. Skips checks. Not recommended.

function createUser3(firstName: string, lastName: string) {
  return { id: crypto.randomUUID(), firstName, lastName } as User;
}

Indexed access — pull nested types from a type:

type UserTwo = {
  id: ID; firstName: string; lastName: string; skills: string[];
  address: { street: string; city: string; country: string;
    coordinats: { lat: number; long: number } };
};

type Address = UserTwo['address'];
type Skill = UserTwo['skills'][number];

Callback types — keep data types and function types separate:

type CB = () => void;
type CB2 = (arg1: string, arg2: number) => string;

Final code:

type name = string;
type ID = string | number;

function printID(id: ID) { console.log(`Your id is: ${id}`); }
printID(123);
printID('123');

type User = { id: ID; firstName: string; lastName: string; skills: string[] };

function createUser(firstName: string, lastName: string): User {
  return { id: crypto.randomUUID(), firstName, lastName, skills: [] };
}

function createUser2(firstName: string, lastName: string) {
  return { id: crypto.randomUUID(), firstName, lastName, skills: [] } satisfies User;
}

function createUser3(firstName: string, lastName: string) {
  return { id: crypto.randomUUID(), firstName, lastName } as User; // not recommended
}

type UserTwo = {
  id: ID; firstName: string; lastName: string; skills: string[];
  address: { street: string; city: string; country: string;
    coordinats: { lat: number; long: number } };
};

type Address = UserTwo['address'];
type Coordinats = UserTwo['address']['coordinats'];
type CoordinatsTwo = Address['coordinats'];
type Skill = UserTwo['skills'][number];

type CB = () => void;
type CB2 = (arg1: string, arg2: number) => string;

function printAddress(addr: Address) { console.log(addr.country); }
function testCB(cb: CB) { cb(); }
function testCB2(cb: CB2) { cb('hemal', 27); }

Union Types

A union means this OR that — string | number.

Union alias:

type MyID = string | number;

Discriminated union — shared role field narrows the type in if:

type Admin = { id: MyID; role: 'admin'; fullControl: true };
type Manager = { id: MyID; role: 'manager' };
type MyUser = Admin | Manager;

function doSomething(user: MyUser) {
  if (user.role === 'admin') console.log(`Full control: ${user.fullControl}`);
  else console.log('Role: ' + user.role);
}

typeof narrows primitive unions:

function formatValue(value: string | number): string {
  if (typeof value === 'string') return value.toUpperCase();
  return value.toFixed(2);
}

Success or error response:

type ErrorResponse = { error: true; message: string };
type SuccessResponse = { error: false; data: string };
type APIResponse = ErrorResponse | SuccessResponse;

function handleResponse(response: APIResponse) {
  if (response.error) console.log(response.message);
  else console.log(response.data);
}

Final code:

type MyID = string | number;

type Admin = { id: MyID; role: 'admin'; fullControl: true };
type Manager = { id: MyID; role: 'manager' };
type MyUser = Admin | Manager;

function doSomething(user: MyUser) {
  if (user.role === 'admin') console.log(`Full control: ${user.fullControl}`);
  else console.log('Role: ' + user.role);
}

function formatValue(value: string | number): string {
  if (typeof value === 'string') return value.toUpperCase();
  return value.toFixed(2);
}
console.log(formatValue(30));
console.log(formatValue('My Name'));

type ErrorResponse = { error: true; message: string };
type SuccessResponse = { error: false; data: string };
type APIResponse = ErrorResponse | SuccessResponse;

function handleResponse(response: APIResponse) {
  if (response.error) console.log(response.message);
  else console.log(response.data);
}

Intersection Types

An intersection means this AND that — merge types with &.

Person + role fields:

type Person = { id: ID; name: string; age: number };
type Employee = Person & { role: 'employee'; salary: number };
type Customer = Person & { role: 'customer'; balance: number };

Use the merged type:

const newCustomer: Customer = {
  id: 1, name: 'hemal', age: 27, role: 'customer', balance: 30,
};

Shared base + extra props (common in UI components):

type BaseProps = { id: number; className?: string };
type buttonProps = BaseProps & { label: string; onCLick: () => void };
type inputBox = BaseProps & { value: string; onChange: () => void; placeholder: string };

Final code:

type Person = { id: ID; name: string; age: number };
type Employee = Person & { role: 'employee'; salary: number };
type Customer = Person & { role: 'customer'; balance: number };

const newCustomer: Customer = {
  id: 1, name: 'hemal', age: 27, role: 'customer', balance: 30,
};

type BaseProps = { id: number; className?: string };
type buttonProps = BaseProps & { label: string; onCLick: () => void };
type inputBox = BaseProps & { value: string; onChange: () => void; placeholder: string };

Generics

Generics use a type placeholder T — one pattern, many types.

Generic function — same input type in, same type out:

function functionName<T>(value: T): T {
  console.log(value, typeof value);
  return value;
}
functionName<number>(30);
functionName('30');

Merge two objects:

function mergeObject<T, U>(arg1: T, arg2: U): T & U {
  return { ...arg1, ...arg2 };
}

const mergeObj = mergeObject({ a: 1 }, { b: 2 });
const mergeObj2 = mergeObject({ name: 'Hemal', age: 27 }, { birthday: 1999 });

Generic type — box that holds any type:

type MystryBox<T> = { value: T };
const numberBox: MystryBox<number> = { value: 123 };

API wrapper — same response shape, different data:

type ApiResponse<T> = { data: T; status: number; message: string };

async function fetchUser(): Promise<ApiResponse<UserGenericsType>> {
  const response = await fetch('https://www.example.com/users');
  const data = await response.json();
  return { data, status: response?.status, message: response?.statusText };
}

One fetch function for any endpoint:

const fetchData = async <T>(url: string): Promise<ApiResponse<T>> => {
  const response = await fetch(url);
  const data = await response.json();
  return { data, status: response?.status, message: response?.statusText };
};

Final code:

function functionName<T>(value: T): T {
  console.log(value, typeof value);
  return value;
}
functionName<number>(30);
functionName('30');

function mergeObject<T, U>(arg1: T, arg2: U): T & U {
  return { ...arg1, ...arg2 };
}

function mergeObject2<T, U>(arg1: T, arg2: U) {
  return { ...arg1, ...arg2 };
}

const mergeObj = mergeObject({ a: 1 }, { b: 2 });
const mergeObj2 = mergeObject({ name: 'Hemal', age: 27 }, { birthday: 1999 });

type MystryBox<T> = { value: T };
const numberBox: MystryBox<number> = { value: 123 };

type UserGenericsType = { id: ID; firstName: string; lastName: string; skills: string[] };
const userBox: MystryBox<UserGenericsType | null> = { value: null };
if (userBox.value) console.log(userBox.value.firstName);

type ApiResponse<T> = { data: T; status: number; message: string };

type Product = { id: string | number; name: string; price: number; discount: number };

async function fetchUser(): Promise<ApiResponse<UserGenericsType>> {
  const response = await fetch('https://www.example.com/users');
  const data = await response.json();
  return { data, status: response?.status, message: response?.statusText };
}

async function syncProduct(): Promise<ApiResponse<Product>> {
  const response = await fetch('https://www.example.com/products');
  const data = await response.json();
  return { data, status: response?.status, message: response?.statusText };
}

async function main() {
  const user = await fetchUser();
  console.log(user.data.lastName);
  const product = await syncProduct();
  console.log(product.data.name);
}

const fetchData = async <T>(url: string): Promise<ApiResponse<T>> => {
  const response = await fetch(url);
  const data = await response.json();
  return { data, status: response?.status, message: response?.statusText };
};

async function main2() {
  const userData = await fetchData<User>('https://www.example.com/users');
  const productData = await fetchData<Product>('https://www.example.com/products');
}

What You Learned

Core types, arrays, objects, functions
Type inference, type aliases, unions, intersections, generics

Type each example. Break them on purpose. Read the errors. Fix them.

Part 02 covers advanced type tools next.

OOP - Make Your Code More Scalable

MD Hemal Akhand — Sun, 14 Jun 2026 07:22:42 +0000

Have you ever opened a Project and found one giant PHP file with 2,000 lines?

Functions everywhere. Global variables. No clear structure. And every time you add a feature, something else breaks.

You are not alone.

Most developers know what a class is. Far fewer know how to design classes that stay clean as a project grows.

There is a real difference between:

Using OOP syntax — writing class MyPlugin { }
Thinking in OOP design — knowing when to split, inject, and abstract

This post closes that gap.

TL;DR — what you will learn

Method chaining — chain calls on one line by returning $this
Dependency injection — pass objects in from outside; stop hiding new inside business logic
SRP — one class, one reason to change
OCP — extend with new classes, do not rewrite stable code
LSP — subtypes must be swappable without breaking callers
ISP — small interfaces; no forced empty methods
DIP — high-level code depends on interfaces, not concrete classes

No Laravel required. No framework magic. Just PHP that fits inside WordPress.

Why OOP matters in WordPress

WordPress grew up procedural. Functions in the global namespace. Hooks everywhere. That still works — and for small plugins, it is often the right choice.

But when a plugin grows, procedural code tends to:

Mix business logic with WordPress hooks in the same function
Repeat database calls because nothing is shared cleanly
Break in unexpected places when you change one feature

Object-oriented design does not replace WordPress hooks. It organizes what happens inside those hooks.

The goal is simple:

Each class does one job
Dependencies are passed in, not hidden inside
New features are added by extending — not by rewriting the same file

That is what we build toward in this guide.

Part 1: Method chaining

What is it?

Method chaining means every setter (and sometimes getter) returns $this — the same object — so you can call the next method immediately on one line.

It reads like a sentence instead of a list of separate steps.

Without chaining:

$student = new Student("Alex Rivera", 22, 101);
$student->setName("Jordan Lee");
$student->setAge(24);
$student->displayName();
$student->displaySeparator();
$student->displayRoll();

With chaining:

$student = new Student("Alex Rivera", 22, 101);
$student->setName("Jordan Lee")
        ->setAge(24)
        ->displayName()
        ->displaySeparator()
        ->displayRoll()
        ->displaySeparator()
        ->displayAge();
// Output: Jordan Lee, 101, 24

The secret: return $this

class Student {
    private $name, $age, $roll;

    public function setName($name) {
        $this->name = $name;
        return $this;   // ← enables chaining
    }

    public function setAge($age) {
        $this->age = $age;
        return $this;
    }

    public function displayName() {
        echo $this->name;
        return $this;
    }

    public function displaySeparator() {
        echo ", ";
        return $this;
    }
}

What is happening?

Each method updates or displays a property
Instead of returning nothing, each method returns $this
PHP lets you call the next method on that returned object immediately

Why it matters in WordPress: Settings APIs, form builders, and custom query wrappers all read cleaner with chaining. Admin UI code becomes easier to scan.

Note: Chaining is a style choice, not a rule. Use it where readability improves.

Part 2: Dependency injection

What is it?

Instead of a class creating its own helper objects internally, you pass (inject) the object it needs from the outside.

Think of hiring a contractor. You do not build the plumbing yourself. You call a plumber and hand them the job.

Bad — tight coupling:

class StudentDisplay {
    public function show() {
        $student = new StudentRecord("Alex", 22, 101); // hard-coded inside
        $student->displayName();
    }
}

StudentDisplay is locked to StudentRecord. You cannot swap it for a database-backed student or a test fake without rewriting the class.

Good — dependency injection:

interface StudentData {
    public function displayName();
    public function displayAge();
}

class StudentRecord implements StudentData {
    private $name, $age;

    public function __construct($name, $age) {
        $this->name = $name;
        $this->age = $age;
    }

    public function displayName() {
        echo "Student Name: " . $this->name;
    }

    public function displayAge() {
        echo "Student Age: " . $this->age;
    }
}

class StudentDisplay {
    public function show(StudentData $student) {
        $student->displayName();
        echo "<br/>";
        $student->displayAge();
    }
}

// Object created outside, passed in:
$student = new StudentRecord("Alex Rivera", 22);
$display = new StudentDisplay();
$display->show($student);

What is happening?

StudentData is an interface — a contract
StudentRecord implements that contract
StudentDisplay only knows the interface, not the concrete class
You create the student outside and pass it in — that pass is dependency injection

Two ways to inject:

Constructor injection (most common):

class OrderNotifier {
    private $mailer;

    public function __construct(MailerInterface $mailer) {
        $this->mailer = $mailer;
    }

    public function notify($order) {
        $this->mailer->send($order->getEmail(), "Order confirmed");
    }
}

Method injection (when dependency is only needed for one action):

class ReportGenerator {
    public function generate(ExporterInterface $exporter) {
        $exporter->export($this->buildReport());
    }
}

Why WordPress developers should care:

Testability — pass a fake mailer in tests instead of sending real emails
Flexibility — swap StudentRecord for DatabaseStudent without touching StudentDisplay
Cleaner plugins — AJAX handlers, admin screens, and repositories stay decoupled

Part 3: SOLID principles (all five)

SOLID is five design rules from Robert C. Martin (“Uncle Bob”). Together they answer one question:

How do I structure code so that adding features does not break everything?

S — Single Responsibility Principle (SRP)

Rule: A class should have only one reason to change.

Not “one method.” Not “small class.” One reason to change.

Bad — god class:

class SchoolSystem {
    public function countSchools() {}
    public function countTeachers() {}
    public function countStudents() {}
    public function sendParentEmails() {}
    public function syncToCRM() {}
}

Better — one class per responsibility:

interface CountableEntity {
    public function displayCount();
}

class SchoolCounter implements CountableEntity {
    public function displayCount() { echo "Schools: 30"; }
}

class TeacherCounter implements CountableEntity {
    public function displayCount() { echo "Teachers: 50"; }
}

class StudentCounter implements CountableEntity {
    public function displayCount() { echo "Students: 120"; }
}

class CountReporter {
    public function report(CountableEntity $entity) {
        $entity->displayCount();
    }
}

WordPress analogy: Do not put “save post meta,” “send notification email,” and “sync to CRM” in one hook callback. Split them into three classes.

O — Open/Closed Principle (OCP)

Rule: Open for extension, closed for modification.

Add new behavior by adding new classes — not by editing the same if/else block every sprint.

Without OCP:

function handleExam($role) {
    if ($role === 'teacher') {
        echo "Teacher manages exam";
    } elseif ($role === 'student') {
        echo "Student views exam";
    }
    // New role = edit this function again
}

With OCP:

interface ExamHandler {
    public function handleExam();
}

class TeacherExamHandler implements ExamHandler {
    public function handleExam() { echo "Teacher manages exam"; }
}

class StudentExamHandler implements ExamHandler {
    public function handleExam() { echo "Student views exam"; }
}

class ExamCoordinator {
    public function run(ExamHandler $handler) {
        $handler->handleExam();
    }
}
// New parent role? Add ParentExamHandler — never touch ExamCoordinator.

WordPress connection: Payment gateways, shipping methods, and export formats are classic OCP cases.

L — Liskov Substitution Principle (LSP)

Rule: If class B implements interface A, you must be able to swap B for any other implementation of A without breaking the program.

interface FeeManager {
    public function manageFees();
    public function manageCharges();
}

class School implements FeeManager {
    public function manageFees() { echo "School fee: $500"; }
    public function manageCharges() { echo "School exam charge: $60"; }
}

class Hospital implements FeeManager {
    public function manageFees() { echo "Hospital fee: $1,200"; }
    public function manageCharges() { echo "Lab charge: $80"; }
}

class BillingService {
    public function processFees(FeeManager $entity) {
        $entity->manageFees();
        echo "<br/>";
        $entity->manageCharges();
    }
}

$billing = new BillingService();
$billing->processFees(new School());    // works
$billing->processFees(new Hospital());  // also works

Warning sign: If a subclass overrides a method and throws “not supported” for half the callers, you probably violated LSP.

I — Interface Segregation Principle (ISP)

Rule: Do not force a class to implement methods it will never use.

Bad — fat interface:

interface OrganizationManager {
    public function studentCount();
    public function teacherCount();
    public function hospitalCount();
    public function doctorCount();
    public function universityRanking();
}

A school class would be forced to implement hospitalCount() — empty stub or fake data.

Better — segregated interfaces:

interface SchoolStats {
    public function studentCount();
    public function teacherAttendance();
    public function teacherCount();
}

interface HospitalStats {
    public function hospitalCount();
    public function doctorAttendance();
    public function doctorCount();
}

class SchoolDashboard implements SchoolStats {
    public function studentCount() { echo "Students: 120"; }
    public function teacherAttendance() { echo "Teacher attendance: 95%"; }
    public function teacherCount() { echo "Teachers: 30"; }
}

WordPress analogy: Split a 20-method PluginInterface into Activatable, SettingsPage, RestEndpoint — implement only what you need.

D — Dependency Inversion Principle (DIP)

Rule: High-level code should depend on abstractions (interfaces), not concrete classes.

Without DIP:

class AttendanceReport {
    public function run() {
        $teacher = new TeacherAttendance(); // locked to one class
        $teacher->record();
    }
}

With DIP:

interface AttendanceRecorder {
    public function record();
}

class TeacherAttendance implements AttendanceRecorder {
    public function record() { echo "Teacher attendance recorded"; }
}

class StudentAttendance implements AttendanceRecorder {
    public function record() { echo "Student attendance recorded"; }
}

class AttendanceReport {
    public function run(AttendanceRecorder $recorder) {
        $recorder->record();
    }
}

$report = new AttendanceReport();
$report->run(new StudentAttendance());

AttendanceReport never mentions TeacherAttendance or StudentAttendance by name. It only knows the AttendanceRecorder interface. That is dependency inversion.

Putting it all together

Idea	One-line meaning
Method chaining	Return `$this` to chain calls on one line
Dependency injection	Pass objects in from outside the class
SRP	One class, one reason to change
OCP	Extend with new classes, do not modify stable code
LSP	Subtypes must be swappable without breaking callers
ISP	Small interfaces — no forced unused methods
DIP	High-level code depends on interfaces, not concrete classes

You do not need all seven on day one.

Start here:

Week 1 → Split one god function into two classes (SRP)
Week 2 → Pass dependencies via constructor instead of new inside (DI + DIP)
Week 3 → Extract an interface before your next if/else role check (OCP)

Small steps. Big payoff over six months.

Common mistakes (and how to fix them)

“I use classes, so I do OOP” — A 2,000-line Plugin_Main with 40 methods is still a god object. Split by responsibility.
Editing the same file for every new feature — If every new payment method means editing checkout.php, apply OCP — add a class instead.
Giant interfaces — If half your implementing classes have empty methods, apply ISP — break the interface apart.
new ClassName() hidden inside business logic — If you cannot test without a real database, apply DI — inject a repository interface.
Learning theory without writing code — Pick one hook in your plugin. Extract one class. Pass one dependency. That single refactor teaches more than reading ten articles.

From small plugin to scalable plugin

You do not need 50 classes on day one. A 200-line plugin with three focused classes is already a win.

As you grow, mature plugins typically add:

PSR-4 autoloading via Composer
Namespaces to avoid class name collisions
A thin bootstrap class that wires hooks on plugins_loaded
Interfaces for anything you might swap (mailer, storage, payment)
PHPUnit tests with mocked dependencies

The design thinking stays the same. Only the packaging gets more professional.

Final thoughts

Being an OOP developer is easy. Designing systems with clear responsibility boundaries is not.

The difference shows up six months later — when you add a feature and nothing else breaks. When a junior developer can read your class in five minutes. When you can write a test without booting all of WordPress.

Start small today:

Pick one function in your plugin that does too much
Extract one responsibility into its own class
Pass its dependency through the constructor
Define an interface if you might swap the implementation later

That is SRP, DI, and DIP in one afternoon.

Method chaining is the readable syntax. SOLID is the architecture underneath. WordPress hooks are still how you plug into the CMS.

You do not have to choose between “WordPress way” and “proper OOP.” You combine them.

That is how OOP stops being syntax and starts being design.

No More Load On WordPress! Try Ajax Today!

MD Hemal Akhand — Sat, 13 Jun 2026 01:27:48 +0000

You build a WordPress form. It should save without reloading the page.

You click Send. Nothing happens.

Or the Network tab shows admin-ajax.php returning a single character: 0.

If that sounds familiar, you are not alone. After six years of building WordPress themes, plugins, and WooCommerce projects, I keep seeing the same pattern on client sites. The JavaScript looks fine. The PHP looks fine. But the request never reaches the callback — or it reaches the wrong hook — or the response is not JSON at all.

Most of the time, the problem is not JavaScript skill. It is not understanding how WordPress routes background requests.

This article walks through everything: what AJAX is in WordPress, how admin-ajax.php works, security with nonces, enqueueing scripts, frontend vs admin, JSON responses, debugging, and when to use REST instead. Copy the examples into your own plugin and change the prefixes.

What is AJAX in WordPress?

AJAX lets the browser talk to the server in the background without refreshing the page.

Real examples you have seen:

Submit a settings form and show "Saved!" instantly
Load more blog posts when someone clicks a button
Update a cart count in the header
Save a contact form without leaving the page

WordPress does not ask you to invent a custom API endpoint for every plugin. It gives you one built-in router:

/wp-admin/admin-ajax.php

You register an action name in PHP. JavaScript sends that same action in every POST request. WordPress connects the two — similar to add_action(), but triggered from the browser instead of a page load.

The one rule that breaks most projects

Every AJAX request must include:

action=your_action_name

WordPress reads that value and fires a hook:

wp_ajax_{action} — logged-in users only
wp_ajax_nopriv_{action} — logged-out visitors

If you register wp_ajax_send_form_data in PHP but JavaScript sends send-form-data, nothing runs.

If you only register wp_ajax_ but test while logged out on the public site, nothing runs.

If you forget the action key entirely, WordPress returns 0.

That is normal WordPress behavior. Once you expect it, debugging gets much faster.

The full request loop

Here is what happens on a working setup:

User clicks Submit on a form
JavaScript calls preventDefault() so the page does not reload
JavaScript POSTs to admin-ajax.php with action, nonce, and your fields
WordPress fires wp_ajax_{action} or wp_ajax_nopriv_{action}
Your PHP callback runs, verifies the nonce, sanitizes input
PHP returns JSON via wp_send_json_success() or wp_send_json_error()
JavaScript reads response.success and updates the UI

If any step in that chain is wrong, the feature feels "broken" even when half the code is correct.

Part 1: Your first AJAX handler

Start with the smallest possible example: a logged-in admin request with no nonce yet (we add security in Part 2).

add_action( 'wp_ajax_send_form_data', 'myplugin_send_form_data_callback' );

function myplugin_send_form_data_callback() {
    wp_send_json_success(
        array(
            'message' => 'Hello from WordPress AJAX!',
        )
    );
}

What to notice:

The action name is send_form_data — prefix it with your plugin name in real projects (myplugin_send_form_data) so you never collide with other plugins
JavaScript must send exactly action: 'send_form_data'
wp_send_json_success() prints JSON and stops execution — you do not need die() after it

Send the request from JavaScript inside wp-admin:

jQuery.ajax({
    method: 'POST',
    url: ajaxurl,
    data: {
        action: 'send_form_data',
    },
}).done(function (response) {
    console.log(response.data.message);
});

Important detail: the global ajaxurl variable exists automatically in the WordPress admin area. It does not exist on the public frontend. For frontend forms, use wp_localize_script() — covered in Part 3.

Part 2: Secure AJAX with nonces

AJAX endpoints are public URLs. Anyone can send a POST request if they guess your action name.

For any operation that saves, deletes, or changes data, verify a nonce — a short-lived token WordPress generates to prove the request came from your site.

Step 1 — Create the nonce and pass it to JavaScript

wp_localize_script(
    'myplugin-admin-js',
    'my_ajax_obj',
    array(
        'ajax_url' => admin_url( 'admin-ajax.php' ),
        'nonce'    => wp_create_nonce( 'myplugin-ajax' ),
    )
);

This creates a global JavaScript object my_ajax_obj with two values your script needs: the AJAX URL and the nonce string.

The script handle 'myplugin-admin-js' must match the handle you used in wp_enqueue_script().

The string 'myplugin-ajax' is your nonce action name — use the same string when verifying.

Step 2 — Send the nonce from JavaScript

data: {
    action: 'send_form_data',
    nonce: my_ajax_obj.nonce,
    user_name: 'Hemal',
}

Step 3 — Verify in PHP before doing anything else

function myplugin_send_form_data_callback() {

    if ( ! isset( $_POST['nonce'] ) ) {
        wp_send_json_error(
            array(
                'message' => 'Nonce is missing.',
            )
        );
    }

    $nonce = sanitize_text_field( wp_unslash( $_POST['nonce'] ) );

    if ( ! wp_verify_nonce( $nonce, 'myplugin-ajax' ) ) {
        wp_send_json_error(
            array(
                'message' => 'Security check failed.',
            )
        );
    }

    $name = sanitize_text_field( wp_unslash( $_POST['user_name'] ?? '' ) );

    wp_send_json_success(
        array(
            'message' => 'Success!',
            'name'    => $name,
        )
    );
}

Without a nonce, anyone on the internet can spam your endpoint. With a nonce, only requests that include a valid token from your enqueued script will pass verification.

Part 3: Enqueue scripts and pass data correctly

If your form lives on a custom admin page, you must load your JavaScript on that screen and pass the AJAX URL yourself.

add_action( 'admin_enqueue_scripts', 'myplugin_load_admin_scripts' );

function myplugin_load_admin_scripts() {

    wp_enqueue_script(
        'myplugin-admin-js',
        plugin_dir_url( __FILE__ ) . 'assets/js/admin.js',
        array( 'jquery' ),
        '1.0.0',
        true
    );

    wp_localize_script(
        'myplugin-admin-js',
        'my_ajax_obj',
        array(
            'ajax_url' => admin_url( 'admin-ajax.php' ),
            'nonce'    => wp_create_nonce( 'myplugin-ajax' ),
        )
    );
}

What each part does:

Part	Purpose
`admin_enqueue_scripts`	Loads assets only in wp-admin
`'myplugin-admin-js'`	Script handle — must match in `wp_localize_script`
`array( 'jquery' )`	Loads jQuery before your script
`true` at the end	Loads script in footer (after DOM exists)
`wp_localize_script`	Exposes `my_ajax_obj.ajax_url` and `my_ajax_obj.nonce` to JS
`admin_url( 'admin-ajax.php' )`	Full URL — works on local, staging, and subfolder installs

Never hard-code /wp-admin/admin-ajax.php. Always use admin_url().

Part 4: Put the pieces together

A clean plugin splits responsibilities:

Assets class — enqueue JS, pass nonce and URL
Admin page — render the HTML form
Ajax class — register wp_ajax_* hooks and callbacks

On the JavaScript side:

(function ($) {
    $(document).ready(function () {

        $('.myplugin-ajax-form').on('submit', function (event) {
            event.preventDefault();

            var $form = $(this);

            $.ajax({
                method: 'POST',
                url: my_ajax_obj.ajax_url,
                data: {
                    action: 'send_form_data',
                    nonce: my_ajax_obj.nonce,
                    user_name: $form.find('[name="user_name"]').val(),
                },
            }).done(function (response) {
                if (response.success) {
                    alert(response.data.message);
                } else {
                    alert(response.data.message || 'Request failed.');
                }
            });

        });

    });
})(jQuery);

When the user clicks Send:

Normal form submit is blocked
POST goes to admin-ajax.php
WordPress reads action=send_form_data
Hook wp_ajax_send_form_data fires
PHP verifies nonce and returns JSON
JavaScript shows the result

That is the entire system. Nothing hidden.

Part 5: JSON responses — success and error

Use WordPress helpers. Do not echo random text and call die() — it breaks JSON parsing in JavaScript.

Success:

wp_send_json_success(
    array(
        'message' => 'Saved!',
        'id'      => 123,
    )
);

Error:

wp_send_json_error(
    array(
        'message' => 'Something went wrong.',
    ),
    400
);

JavaScript receives:

{
    "success": true,
    "data": {
        "message": "Saved!",
        "id": 123
    }
}

Always check response.success before reading response.data.

Always sanitize before save:

$name  = sanitize_text_field( wp_unslash( $_POST['user_name'] ?? '' ) );
$email = sanitize_email( wp_unslash( $_POST['email'] ?? '' ) );
$id    = absint( $_POST['item_id'] ?? 0 );

Part 6: Frontend AJAX for logged-out users

Public contact forms need the nopriv hook.

add_action( 'wp_ajax_send_form_data', 'myplugin_send_form_data_callback' );
add_action( 'wp_ajax_nopriv_send_form_data', 'myplugin_send_form_data_callback' );

Hook	When it runs
`wp_ajax_{action}`	User is logged in
`wp_ajax_nopriv_{action}`	User is not logged in

This is the most common "works for me, broken for clients" bug. You test as admin. Real visitors are logged out.

For admin-only actions (delete post, save settings), skip nopriv and add current_user_can() inside the callback instead.

Part 7: Enqueue on the frontend

Admin uses admin_enqueue_scripts. The public site uses wp_enqueue_scripts:

add_action( 'wp_enqueue_scripts', 'myplugin_load_public_scripts' );

function myplugin_load_public_scripts() {

    wp_enqueue_script(
        'myplugin-public-js',
        plugin_dir_url( __FILE__ ) . 'assets/js/public.js',
        array( 'jquery' ),
        '1.0.0',
        true
    );

    wp_localize_script(
        'myplugin-public-js',
        'my_ajax_obj',
        array(
            'ajax_url' => admin_url( 'admin-ajax.php' ),
            'nonce'    => wp_create_nonce( 'myplugin-ajax' ),
        )
    );
}

Same pattern. Different hook. If the script is not enqueued on the page where your form appears, the JavaScript never runs — even if PHP is perfect.

Part 8: Using fetch() instead of jQuery

WordPress does not care which library you use. It cares about POST, action, and nonce.

document.querySelector('.myplugin-ajax-form')?.addEventListener('submit', async function (event) {

    event.preventDefault();

    var form = event.target;
    var formData = new FormData();

    formData.append('action', 'send_form_data');
    formData.append('nonce', my_ajax_obj.nonce);
    formData.append('user_name', form.querySelector('[name="user_name"]').value);

    var response = await fetch(my_ajax_obj.ajax_url, {
        method: 'POST',
        body: formData,
        credentials: 'same-origin',
    });

    var json = await response.json();

    if (json.success) {
        alert(json.data.message);
    } else {
        alert(json.data.message || 'Request failed.');
    }

});

Part 9: admin-ajax.php vs REST API

WordPress offers two async patterns:

admin-ajax.php

URL: /wp-admin/admin-ajax.php
Register with add_action( 'wp_ajax_*' )
Best for classic plugins, wp-admin UI, small forms

REST API

URL: /wp-json/your-namespace/v1/your-route
Register with register_rest_route()
Best for headless sites, Gutenberg blocks, mobile apps

For most theme and plugin work inside WordPress admin, admin-ajax.php is still the fastest path. Move to REST when you need standard HTTP routes, external consumers, or block editor integration.

Part 10: Debugging when AJAX fails

Check these in order before guessing:

Action name — identical string in PHP hook and JavaScript action field?
Network tab — open DevTools, find admin-ajax.php, read the response body
Logged out? — did you register wp_ajax_nopriv_?
Script loaded? — is wp_enqueue_script running on this exact page?
Nonce — created, passed to JS, sent back, verified with same action string?

Common responses:

Response	Meaning
`0`	Action not registered or callback not found
`-1`	Nonce failed or permission denied
JSON with `"success": false`	Callback ran but returned an error
Empty or HTML	PHP error, or you used `echo` instead of JSON helpers

Temporary logging in PHP:

error_log( print_r( $_POST, true ) );

Enable WP_DEBUG_LOG in wp-config.php and read wp-content/debug.log.

Quick reference

I want to…	Use
Handle logged-in AJAX	`add_action( 'wp_ajax_{action}', 'callback' )`
Handle logged-out AJAX	`add_action( 'wp_ajax_nopriv_{action}', 'callback' )`
Pass URL + nonce to JS	`wp_localize_script()`
Return success JSON	`wp_send_json_success( $data )`
Return error JSON	`wp_send_json_error( $data )`
Verify token	`wp_verify_nonce( $nonce, 'action-name' )`
AJAX router URL	`admin_url( 'admin-ajax.php' )`

Common mistakes

Missing action in JavaScript — WordPress returns 0
Mismatched action names between PHP and JS
Forgetting wp_ajax_nopriv_ on public forms
No nonce on write operations
Using echo instead of wp_send_json_*
Hard-coding /wp-admin/admin-ajax.php
Not sanitizing $_POST
Scheduling script on wrong hook or wrong admin page

Checklist before shipping

Action name is unique and prefixed (myplugin_send_form_data)
wp_ajax_ registered (and wp_ajax_nopriv_ if public)
Nonce created, passed to JS, verified in PHP
Input sanitized, output escaped
wp_send_json_success / wp_send_json_error used
Script enqueued on the correct hook and page
Tested logged in and logged out
Network tab checked for 0, -1, or 500 errors

What you can build with this

Once the loop is clear, many features become straightforward:

Live search and filters
Infinite scroll / load more
Theme option panels that save instantly
Newsletter and contact forms
Admin dashboards that refresh without reload
WooCommerce-style cart updates

Same WordPress hook thinking — triggered from JavaScript.

Medium — full walkthrough with additional examples:

https://medium.com/@hemal.akanda.39/no-refresh-in-wordpress-by-ajax-4942c5e80bd2

Substack — same topic in plain English, no code:

https://substack.com/@mdhemalakhand/note/p-201821073

What I am building now

After years of WordPress client work, I am building AppsLaunch — branded Android and iPhone apps for local service businesses from one dashboard.

How it works:

Create your company and add logo, colors, services, and products
Customers browse in the app and send inquiries — leads land in your dashboard inbox
Build signed Android and iPhone apps from the cloud and publish to Google Play and the App Store
Each business gets its own app name and store listing — not a generic builder brand

Plans from $30/month. No per-lead fees on paid plans.

https://applaunch.teamzlab.com/

Final thought

WordPress AJAX is four ideas on every project:

Register the action in PHP
Send the same action name from JavaScript
Secure the request with nonces and sanitization
Return clean JSON

Once you see that loop, no-refresh forms stop feeling like magic and start feeling like normal WordPress development.

Stripe Subscriptions in a SaaS (Step-by-Step With Code)

MD Hemal Akhand — Fri, 12 Jun 2026 04:00:37 +0000

Have you ever added a “Subscribe” button to your SaaS — and then realized payments and user accounts are two completely different problems?

The user pays on Stripe.

Your app still thinks they’re on the free plan.

The webhook fires twice.

A guest buys from your landing page but has no login.

Sound familiar?

This happens on almost every subscription SaaS. The fix is not “one magic Stripe button.” It is a clear flow: checkout → webhook → database → dashboard.

This article walks through that flow step by step, with code you can adapt for your own Next.js project.

No confusion. No guessing. Just clear steps.

Security note: Every API key, webhook secret, URL, and route in this article is made up for learning. Use your own values from the Stripe Dashboard. Never publish your real credentials, webhook endpoints, database table names from production, or internal file paths in a public post — that gives attackers a head start.

What you’re building (the big picture)

In simple words:

User clicks Subscribe → Stripe Payment Link opens
User pays → Stripe sends a webhook to your server
Your server saves the subscription in Postgres
Dashboard shows plan, renewal date, cancel button

Here’s the full flow (paths below are examples only — name yours however you like):

User clicks "Subscribe"
        ↓
Stripe Payment Link (hosted checkout)
        ↓
Payment succeeds
        ↓
Stripe redirects to your success page (?session_id=...)
        ↓
Webhook: checkout.session.completed (runs in parallel)
        ↓
Create or find user in your database
        ↓
Save subscription row
        ↓
User lands on billing dashboard

Important: Stripe is the source of truth for billing. Your database is a mirror kept in sync by webhooks.

Part 1: Set up Stripe (Dashboard)

Before writing code, create your products in Stripe.

Step 1 — Create products and prices

In Stripe Dashboard → Products:

Product	Monthly price	Yearly price
Starter	$19/month	$190/year
Pro	$49/month	$490/year
Business	$99/month	$990/year

Each price gets a Price ID like price_1ExampleStarterMonthly01. Save these — you’ll map them in code later.

Step 2 — Create Payment Links

For most SaaS apps, Payment Links are simpler than building a custom checkout form.

Why?

Stripe hosts the checkout page (PCI compliance handled for you)
Works for landing page and logged-in dashboard
No frontend card form to maintain

Create one Payment Link per plan + interval (6 links for 3 plans × monthly/yearly).

Configure each link:

Mode: Subscription
Success URL: https://YOUR-DOMAIN.com/billing/success?session_id={CHECKOUT_SESSION_ID}
Local dev: http://localhost:3000/billing/success?session_id={CHECKOUT_SESSION_ID}

Stripe will give you URLs like:

https://buy.stripe.com/test_XXXXXXXXXXXX

Copy those into a private config file in your repo (not in a blog post).

Step 3 — Get your API keys

From Developers → API keys:

# Test mode (local development)
STRIPE_TEST_SECRET_KEY=sk_test_XXXXXXXXXXXXXXXXXXXXXXXX
STRIPE_TEST_WEBHOOK_SECRET=whsec_XXXXXXXXXXXXXXXXXXXXXXXX

# Live mode (production)
STRIPE_SECRET_KEY=sk_live_XXXXXXXXXXXXXXXXXXXXXXXX
STRIPE_WEBHOOK_SECRET=whsec_XXXXXXXXXXXXXXXXXXXXXXXX

# Toggle test vs live in the app
NEXT_PUBLIC_STRIPE_TEST_MODE=true

Never commit real keys to Git. Use .env.local and your host’s secret environment variables only.

Part 2: Database tables

Your app needs to remember who subscribed to what. A typical setup uses three tables.

`users` — link account to Stripe customer

ALTER TABLE users ADD COLUMN stripe_customer_id TEXT UNIQUE;

`subscriptions` — subscription history

CREATE TABLE subscriptions (
    id TEXT PRIMARY KEY,
    user_id TEXT NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    stripe_subscription_id TEXT NOT NULL UNIQUE,
    stripe_customer_id TEXT NOT NULL,
    stripe_price_id TEXT,
    plan_id TEXT NOT NULL,
    billing_interval TEXT NOT NULL,
    status TEXT NOT NULL,
    current_period_start TIMESTAMPTZ NOT NULL,
    current_period_end TIMESTAMPTZ NOT NULL,
    cancel_at_period_end BOOLEAN NOT NULL DEFAULT false,
    canceled_at TIMESTAMPTZ,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

`processed_webhook_events` — prevent duplicate processing

Stripe can send the same webhook twice. Store processed event IDs:

CREATE TABLE processed_webhook_events (
    event_id TEXT PRIMARY KEY,
    event_type TEXT NOT NULL,
    processed_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

Why idempotency matters: Without it, one payment could create two subscription rows and unlock paid features twice.

Part 3: Stripe client (server-side)

Install the SDK:

npm install stripe

Example server helper (keep this file private in your repo):

import Stripe from "stripe";

function getSecretKey(testMode: boolean): string {
  const key = testMode
    ? process.env.STRIPE_TEST_SECRET_KEY
    : process.env.STRIPE_SECRET_KEY;

  if (!key) throw new Error("Stripe secret key is not configured");
  return key;
}

export function isTestMode(): boolean {
  const flag = process.env.NEXT_PUBLIC_STRIPE_TEST_MODE;
  if (flag === "true") return true;
  if (flag === "false") return false;
  return process.env.NODE_ENV === "development";
}

let testClient: Stripe | null = null;
let liveClient: Stripe | null = null;

export function getStripe(testMode?: boolean): Stripe {
  const useTest = testMode ?? isTestMode();

  if (useTest) {
    if (!testClient) testClient = new Stripe(getSecretKey(true));
    return testClient;
  }

  if (!liveClient) liveClient = new Stripe(getSecretKey(false));
  return liveClient;
}

Code	What it means
`getStripe(true)`	Test API key (`sk_test_...`)
`getStripe(false)`	Live API key (`sk_live_...`)
`isTestMode()`	Pick test links locally, live in production
Cached client	One instance per mode — don’t create new clients on every request

Part 4: Payment Link URLs in code

Store Payment Links in a config module inside your project (do not paste live URLs publicly):

const TEST_CHECKOUT_URLS = {
  starter: {
    monthly: "https://buy.stripe.com/test_XXXXXXXX",
    yearly: "https://buy.stripe.com/test_YYYYYYYY",
  },
  pro: {
    monthly: "https://buy.stripe.com/test_AAAAAAAA",
    yearly: "https://buy.stripe.com/test_BBBBBBBB",
  },
  business: {
    monthly: "https://buy.stripe.com/test_CCCCCCCC",
    yearly: "https://buy.stripe.com/test_DDDDDDDD",
  },
} as const;

const LIVE_CHECKOUT_URLS = {
  // Same shape — your live links from Stripe Dashboard
} as const;

export function checkoutUrl(planId: string, interval: "monthly" | "yearly") {
  const urls = isTestMode() ? TEST_CHECKOUT_URLS : LIVE_CHECKOUT_URLS;
  const plan = urls[planId as keyof typeof TEST_CHECKOUT_URLS];
  return plan?.[interval] ?? null;
}

Link checkout to the logged-in user

When a signed-in user subscribes, pass their user ID so the webhook knows who paid:

export function checkoutUrlForUser(
  baseUrl: string,
  user: { id: string; email: string },
): string {
  const url = new URL(baseUrl);

  if (user.email?.trim()) {
    url.searchParams.set("prefilled_email", user.email.trim());
  }

  // Stripe passes this back on the session — use YOUR internal user id
  url.searchParams.set("client_reference_id", user.id);
  return url.toString();
}

Parameter	Purpose
`prefilled_email`	Pre-fills email on Stripe checkout
`client_reference_id`	Your user ID — primary way to link payment → account

For guest checkout from a landing page, you can skip client_reference_id and match by email instead (Part 9).

Part 5: Subscribe button in the dashboard

"use client";

export function SubscribeButton({
  planId,
  interval,
  user,
}: {
  planId: "starter" | "pro" | "business";
  interval: "monthly" | "yearly";
  user: { id: string; email: string };
}) {
  const base = checkoutUrl(planId, interval);
  if (!base) return null;

  const href = checkoutUrlForUser(base, user);

  return (
    <a href={href} className="btn-primary">
      Subscribe
    </a>
  );
}

On the landing page, link directly to the Payment Link (no user params):

<a href={checkoutUrl("starter", "monthly") ?? "#"}>Buy now</a>

Part 6: Map Stripe prices to your plans

When a webhook arrives, Stripe sends a price_... ID. Map it to your internal plan names:

const PRICE_TO_PLAN: Record<string, { planId: string; interval: string }> = {
  price_1ExampleStarterMonthly01: { planId: "starter", interval: "monthly" },
  price_1ExampleStarterYearly001: { planId: "starter", interval: "yearly" },
  // Add every test + live price ID from YOUR Stripe account
};

export function planFromPriceId(priceId: string | null | undefined) {
  return priceId ? PRICE_TO_PLAN[priceId] ?? null : null;
}

Part 7: Save subscriptions to the database

import type Stripe from "stripe";

export async function findUserForSubscription(
  subscription: Stripe.Subscription,
  userIdHint?: string | null,
) {
  if (userIdHint) {
    const user = await db.user.findUnique({ where: { id: userIdHint } });
    if (user) return user;
  }

  const customerId =
    typeof subscription.customer === "string"
      ? subscription.customer
      : subscription.customer?.id;

  if (!customerId) return null;

  const byCustomer = await db.user.findFirst({
    where: { stripeCustomerId: customerId },
  });
  if (byCustomer) return byCustomer;

  const stripe = getStripe();
  const customer = await stripe.customers.retrieve(customerId);
  if (!customer.deleted && customer.email) {
    return db.user.findUnique({ where: { email: customer.email } });
  }

  return null;
}

export async function saveSubscription(
  subscription: Stripe.Subscription,
  userIdHint?: string | null,
) {
  const user = await findUserForSubscription(subscription, userIdHint);
  if (!user) {
    throw new Error("No user found for subscription");
  }

  const item = subscription.items.data[0];
  const price = item?.price;
  const plan = planFromPriceId(price?.id);
  if (!plan) throw new Error("Unknown price");

  const customerId =
    typeof subscription.customer === "string"
      ? subscription.customer
      : (subscription.customer?.id ?? "");

  await db.user.update({
    where: { id: user.id },
    data: { stripeCustomerId: customerId },
  });

  return db.subscription.upsert({
    where: { stripeSubscriptionId: subscription.id },
    create: {
      userId: user.id,
      stripeSubscriptionId: subscription.id,
      stripeCustomerId: customerId,
      stripePriceId: price?.id ?? null,
      planId: plan.planId,
      billingInterval: plan.interval,
      status: subscription.status,
      currentPeriodStart: new Date(item.current_period_start * 1000),
      currentPeriodEnd: new Date(item.current_period_end * 1000),
      cancelAtPeriodEnd: subscription.cancel_at_period_end,
    },
    update: {
      status: subscription.status,
      currentPeriodStart: new Date(item.current_period_start * 1000),
      currentPeriodEnd: new Date(item.current_period_end * 1000),
      cancelAtPeriodEnd: subscription.cancel_at_period_end,
    },
  });
}

Key idea: upsert = create if new, update if exists. Same function handles first payment and renewals.

Part 8: Webhooks — the heart of the integration

The webhook route

Use a path only you know, e.g. POST /api/billing/stripe-webhook (example):

import { NextResponse, type NextRequest } from "next/server";

export const runtime = "nodejs";

export async function POST(req: NextRequest) {
  const payload = await req.text();
  const signature = req.headers.get("stripe-signature");

  if (!signature) {
    return NextResponse.json({ error: "Missing signature" }, { status: 400 });
  }

  try {
    const event = verifyWebhook(payload, signature);
    await handleStripeEvent(event);
    return NextResponse.json({ received: true });
  } catch {
    return NextResponse.json({ error: "Invalid webhook" }, { status: 400 });
  }
}

Verify the signature (required)

Never trust webhook JSON without verification:

export function verifyWebhook(payload: string, signature: string) {
  const stripe = getStripe();
  const secret = process.env.STRIPE_WEBHOOK_SECRET!;
  return stripe.webhooks.constructEvent(payload, signature, secret);
}

If the signature doesn’t match, reject the request. This blocks fake “payment succeeded” attacks.

Handle events

async function alreadyProcessed(eventId: string) {
  const row = await db.processedWebhookEvent.findUnique({
    where: { eventId },
  });
  return Boolean(row);
}

export async function handleStripeEvent(event: Stripe.Event) {
  if (await alreadyProcessed(event.id)) return;

  switch (event.type) {
    case "checkout.session.completed": {
      const session = event.data.object as Stripe.Checkout.Session;
      if (session.mode !== "subscription" || !session.subscription) break;

      const user = await ensureUserFromSession(session);
      const subId =
        typeof session.subscription === "string"
          ? session.subscription
          : session.subscription.id;

      const stripe = getStripe();
      const subscription = await stripe.subscriptions.retrieve(subId);
      await saveSubscription(subscription, user?.id);
      break;
    }

    case "customer.subscription.created":
    case "customer.subscription.updated":
    case "customer.subscription.deleted": {
      const subscription = event.data.object as Stripe.Subscription;
      await saveSubscription(subscription);
      break;
    }

    case "invoice.payment_succeeded":
    case "invoice.payment_failed": {
      const invoice = event.data.object as Stripe.Invoice;
      const subId = invoice.subscription as string | null;
      if (!subId) break;

      const stripe = getStripe();
      const subscription = await stripe.subscriptions.retrieve(subId);
      await saveSubscription(subscription);
      break;
    }
  }

  await db.processedWebhookEvent.create({
    data: { eventId: event.id, eventType: event.type },
  });
}

Events to listen for

Event	When it fires	What to do
`checkout.session.completed`	First successful checkout	Create account if needed, save subscription
`customer.subscription.updated`	Plan change, cancel scheduled	Update status and period end
`customer.subscription.deleted`	Subscription ended	Mark canceled
`invoice.payment_succeeded`	Renewal paid	Refresh billing period
`invoice.payment_failed`	Card declined	Update status to `past_due`

Part 9: Guest checkout — auto-create accounts

When someone buys without an account, create one on the server after payment (never trust the browser alone):

import { randomBytes } from "node:crypto";

function randomPassword() {
  return randomBytes(16).toString("base64url");
}

export async function ensureUserFromSession(session: Stripe.Checkout.Session) {
  const email =
    session.customer_details?.email?.trim() ||
    session.customer_email?.trim();

  if (!email) return null;

  const normalized = email.toLowerCase();
  const existing = await db.user.findUnique({ where: { email: normalized } });
  if (existing) return existing;

  const password = randomPassword();

  // Use your auth provider’s admin API (Supabase, Clerk, Auth0, etc.)
  const newUser = await authAdmin.createUser({
    email: normalized,
    password,
    emailVerified: true,
  });

  await sendWelcomeEmail({ email: normalized, password });

  return newUser;
}

Edge case: Webhook and success-page redirect can both run at once. Handle “user already exists” without crashing.

Part 10: After payment — success page

Stripe redirects with session_id. On your success route, retrieve the session from Stripe (server-side) before unlocking anything:

export async function GET(request: NextRequest) {
  const sessionId = request.nextUrl.searchParams.get("session_id");
  if (!sessionId) {
    return redirect("/login?billing=error");
  }

  const stripe = getStripe();
  const session = await stripe.checkout.sessions.retrieve(sessionId);

  if (session.payment_status !== "paid") {
    return redirect("/login?billing=processing");
  }

  const user = await ensureUserFromSession(session);

  const subId =
    typeof session.subscription === "string"
      ? session.subscription
      : session.subscription?.id;

  if (subId) {
    const subscription = await stripe.subscriptions.retrieve(subId);
    await saveSubscription(subscription, user?.id);
  }

  if (user?.isNew) {
    await signInUser(user);
    return redirect("/dashboard/billing?welcome=1");
  }

  return redirect("/login?billing=success");
}

Why both webhook AND success page?

Path	Purpose
Webhook	Reliable sync even if user closes the tab
Success page	Better UX — sign in and show dashboard

They can run in parallel. Idempotency prevents duplicate rows.

Part 11: Cancel and reactivate

Let users cancel inside your app:

export async function cancelAtPeriodEnd(userId: string) {
  const active = await getActiveSubscription(userId);
  if (!active) throw new Error("No active subscription");

  const stripe = getStripe();
  const updated = await stripe.subscriptions.update(
    active.stripeSubscriptionId,
    { cancel_at_period_end: true },
  );

  await saveSubscription(updated, userId);
  return updated;
}

export async function reactivate(userId: string) {
  const active = await getActiveSubscription(userId);
  if (!active?.cancelAtPeriodEnd) return active;

  const stripe = getStripe();
  const updated = await stripe.subscriptions.update(
    active.stripeSubscriptionId,
    { cancel_at_period_end: false },
  );

  await saveSubscription(updated, userId);
  return updated;
}

Protect the API with auth — only the logged-in owner can cancel their own sub:

export async function POST(request: NextRequest) {
  const user = await requireAuth(request);
  await cancelAtPeriodEnd(user.id);
  return NextResponse.json({ ok: true });
}

Cancel at period end keeps access until current_period_end. That’s what users expect.

Part 12: Local development with Stripe CLI

Webhooks can’t reach localhost without forwarding.

Terminal 1 — app:

npm run dev

Terminal 2 — Stripe CLI:

stripe listen --forward-to localhost:3000/api/billing/stripe-webhook

Copy the whsec_... from the CLI into .env.local as STRIPE_TEST_WEBHOOK_SECRET.

Test card: 4242 4242 4242 4242 — any future expiry, any CVC.

Test checklist

Subscribe on localhost
Pay with test card
CLI shows checkout.session.completed
Billing page shows active plan
Cancel → status “canceling at period end”
Reactivate → active again

Part 13: Production checklist

[ ] NEXT_PUBLIC_STRIPE_TEST_MODE=false in production
[ ] Live keys only in server environment variables
[ ] Webhook URL registered in Stripe Dashboard (your real URL — keep it private)
[ ] Live Payment Link success URLs point to production domain
[ ] All live price IDs mapped in your private config
[ ] Webhook idempotency table exists
[ ] Test one small live charge, then refund
[ ] Cancel / reactivate tested end-to-end

Register webhook in Stripe

Developers → Webhooks → Add endpoint with your production URL and these events:

checkout.session.completed
customer.subscription.created
customer.subscription.updated
customer.subscription.deleted
invoice.payment_succeeded
invoice.payment_failed

Store the signing secret in STRIPE_WEBHOOK_SECRET — never in source code or blog posts.

What NOT to share publicly (important)

When you write tutorials or open-source sample code:

Do share	Do NOT share
General patterns and Stripe event names	Live `sk_live_` or `whsec_` secrets
Dummy placeholders (`sk_test_XXX`)	Your real Payment Link URLs
Generic table/column ideas	Exact production routes (`/api/...`) from your live app
Stripe’s official test card `4242…`	Webhook endpoint URL attackers could spam
How signature verification works	Auth admin keys or service role keys

Attackers scan GitHub and Medium for leaked webhook URLs and keys. Your tutorial code should teach the pattern, not document your production stack.

Common mistakes

1. Trusting the frontend for payment status

Never unlock paid features because the user landed on a success page. Verify the session server-side and/or wait for the webhook.

2. No webhook idempotency

Stripe retries failed webhooks. Without a processed-events table, you get duplicate subscriptions.

3. Mixing test and live keys

Test IDs contain _test_. Live IDs contain _live_. Use the matching API key.

4. Forgetting `client_reference_id`

Logged-in checkout won’t link to the right user without it.

5. Publishing secrets in tutorials

Rotate any key that was ever committed or pasted online.

6. Skipping guest account creation

Landing-page buyers need a login after they pay.

7. Immediate cancel instead of period-end cancel

Use cancel_at_period_end: true unless your product policy says otherwise.

Quick reference

Goal	Approach
Accept subscriptions	Stripe Payment Links
Link payment to user	`client_reference_id` + email fallback
Keep DB in sync	Webhooks + upsert
Prevent duplicates	Processed event IDs table
Test locally	`stripe listen --forward-to ...`
Cancel	`cancel_at_period_end: true`
Guest checkout	Provision user on `checkout.session.completed`

The complete flow (save this)

Subscribe click
      ↓
Stripe Payment Link
      ↓
Payment succeeds
      ↓
      ├── Redirect → your success page (verify session_id)
      │
      └── Webhook → your private endpoint
                ↓
          Verify Stripe signature
                ↓
          checkout.session.completed
                ↓
          Find or create user
                ↓
          Upsert subscription row
                ↓
          Mark event processed
      ↓
User sees active plan in dashboard

Final thought

Stripe integration looks complex until you see the loop:

Checkout — Payment Links handle cards
Link — client_reference_id ties payment to your user
Sync — Webhooks update your database
Trust — Verify everything on the server

Copy the patterns. Use dummy keys while learning. Plug in your real values only in private .env files and your hosting dashboard.

Your next paying customer is one verified webhook away.

WordPress Cron Explained (Real-World Guide After 6 Years)

MD Hemal Akhand — Thu, 11 Jun 2026 03:57:02 +0000

If you’ve built WordPress features that should run in the background, you’ve probably hit this:

Email should send every hour → doesn’t
Cleanup should run nightly → skips
One-time reminder after signup → never fires

The code looks fine. Local works. Production doesn’t.

After 6 years building WordPress themes, plugins, and WooCommerce projects, I can tell you: most cron issues are not syntax errors. They’re misunderstanding how WordPress scheduling works.

What is a scheduled task in WordPress?

A scheduled task is a job WordPress runs later — automatically.

Examples:

Send reminder emails
Clean old logs
Sync data to a CRM
Fire a one-time follow-up after purchase

WordPress calls this system WP Cron.

WP Cron ≠ Server Cron

Server cron runs at an exact time (e.g. 3:00 AM daily).

WP Cron runs based on traffic.

WP Cron behavior

Site type	Behavior
High traffic	Reliable
Low traffic	Delayed
Staging	Unpredictable

The mental model

Schedule → Hook name → add_action() → Function runs

The 2 functions you’ll use most

// Check if already scheduled
wp_next_scheduled( $hook, $args );

// Schedule repeating task
wp_schedule_event( $timestamp, $recurrence, $hook, $args );

Safe pattern

wp_next_scheduled() → check first
wp_schedule_event() → schedule
add_action() → connect callback

1. Repeating task (hourly email)

Hook registration

add_action( 'butterfly_hourly_email_hook', 'butterfly_send_email_func' );

Schedule it

function butterfly_create_cron_event() {

    $args = [
        'hemal.akanda.39@gmail.com'
    ];

    if ( ! wp_next_scheduled( 'butterfly_hourly_email_hook', $args ) ) {

        wp_schedule_event(
            time(),
            'hourly',
            'butterfly_hourly_email_hook',
            $args
        );
    }
}

Callback

function butterfly_send_email_func( $email ) {

    wp_mail(
        sanitize_email( $email ),
        __( 'Reminder', 'butterfly-cron' ),
        __( 'Hey Butterfly. Its a custom message from butterfly', 'butterfly-cron' )
    );
}

2. One-time task

add_action( 'butterfly_single_event_hook', 'butterfly_send_email' );

function schedule_single_event() {

    $args = [
        'hemal.akanda.39@gmail.com'
    ];

    if ( ! wp_next_scheduled( 'butterfly_single_event_hook', $args ) ) {

        wp_schedule_single_event(
            time() + 3600,
            'butterfly_single_event_hook',
            $args
        );
    }
}

function butterfly_send_email( $email ) {

    wp_mail(
        sanitize_email( $email ),
        __( 'Send a email subject', 'butterfly-cron' ),
        __( 'Send email message', 'butterfly-cron' )
    );
}

3. Remove a scheduled task

function butterfly_schedule_an_event() {
    wp_schedule_event( time(), 'hourly', 'butterfly_schedule_an_wp_event' );
}

add_action( 'butterfly_schedule_an_wp_event', 'butterfly_create_an_wp_event' );

function butterfly_unschedule_an_event() {

    $timestamps = wp_next_scheduled( 'butterfly_schedule_an_wp_event' );

    if ( $timestamps ) {
        wp_unschedule_event( $timestamps, 'butterfly_schedule_an_wp_event' );
    }
}

function butterfly_create_an_wp_event() {

    wp_mail(
        sanitize_email( 'hemal.akanda.39@gmail.com' ),
        __( 'Create a meetup on wordpress in dhaka', 'butterfly-cron' ),
        __( 'Hey! Lets create a meetup for WordPress Community in Dhaka/Bangladesh', 'butterfly-cron' )
    );
}

4. Custom intervals

add_filter( 'cron_schedules', 'butterfly_cron_schedule' );

function butterfly_cron_schedule( $schedules ) {

    $schedules['weekly'] = [
        'interval' => 604800,
        'display'  => __( 'Once a week', 'butterfly-cron' )
    ];

    return $schedules;
}

Use it

wp_schedule_event( time(), 'weekly', 'my_weekly_hook' );

5. Debug scheduled tasks

$cron = _get_cron_array();
$all_schedules = wp_get_schedules();
?>

<?php foreach ( $cron as $timestamp => $hooks ) : ?>

    <?php foreach ( (array) $hooks as $hook => $events ) : ?>

        <?php foreach ( (array) $events as $event ) : ?>

            <tr>

                <td>
                    <?php echo date_i18n( 'M j, Y @ G:i', wp_next_scheduled( $hook ) ); ?>
                </td>

                <td>
                    <?php echo ! empty( $event['schedule'] )
                        ? esc_html( $all_schedules[ $event['schedule'] ]['display'] )
                        : 'Once'; ?>
                </td>

                <td>
                    <code><?php echo esc_html( $hook ); ?></code>
                </td>

            </tr>

        <?php endforeach; ?>

    <?php endforeach; ?>

<?php endforeach; ?>

Quick reference

wp_schedule_event() → repeating task
wp_schedule_single_event() → one-time task
wp_next_scheduled() → check exists
wp_unschedule_event() → remove task
cron_schedules → custom intervals

Common mistakes

No wp_next_scheduled() → duplicates
Never unscheduling → ghost jobs
Low traffic sites → delayed cron
Heavy tasks on page load
Missing add_action()

Production tip

define( 'DISABLE_WP_CRON', true );

DEV Community: MD Hemal Akhand

Uploaded first part of my typescript tutorial. See here: https://dev.to/mdhemalakhand1999/master-typescript-part-01-452g

Master TypeScript — Part 01

Master TypeScript — Part 01

Core Types

Arrays

Objects

Functions

Type Inference

Type Aliases

Union Types

Intersection Types

Generics

What You Learned

OOP - Make Your Code More Scalable

TL;DR — what you will learn

Why OOP matters in WordPress

Part 1: Method chaining

Part 2: Dependency injection

Part 3: SOLID principles (all five)

S — Single Responsibility Principle (SRP)

O — Open/Closed Principle (OCP)

L — Liskov Substitution Principle (LSP)

I — Interface Segregation Principle (ISP)

D — Dependency Inversion Principle (DIP)

Putting it all together

Common mistakes (and how to fix them)

From small plugin to scalable plugin

Final thoughts

No More Load On WordPress! Try Ajax Today!

What is AJAX in WordPress?

The one rule that breaks most projects

The full request loop

Part 1: Your first AJAX handler

Part 2: Secure AJAX with nonces

Step 1 — Create the nonce and pass it to JavaScript

Step 2 — Send the nonce from JavaScript

Step 3 — Verify in PHP before doing anything else

Part 3: Enqueue scripts and pass data correctly

Part 4: Put the pieces together

Part 5: JSON responses — success and error

Part 6: Frontend AJAX for logged-out users

Part 7: Enqueue on the frontend

Part 8: Using fetch() instead of jQuery

Part 9: admin-ajax.php vs REST API

Part 10: Debugging when AJAX fails

Quick reference

Common mistakes

Checklist before shipping

What you can build with this

Read more

What I am building now

Final thought

Stripe Subscriptions in a SaaS (Step-by-Step With Code)

What you’re building (the big picture)

Part 1: Set up Stripe (Dashboard)

Step 1 — Create products and prices

Step 2 — Create Payment Links

Step 3 — Get your API keys

Part 2: Database tables

users — link account to Stripe customer

subscriptions — subscription history

processed_webhook_events — prevent duplicate processing

Part 3: Stripe client (server-side)

Part 4: Payment Link URLs in code

Link checkout to the logged-in user

Part 5: Subscribe button in the dashboard

Part 6: Map Stripe prices to your plans

Part 7: Save subscriptions to the database

Part 8: Webhooks — the heart of the integration

The webhook route

Verify the signature (required)

Handle events

Events to listen for

Part 9: Guest checkout — auto-create accounts

Part 10: After payment — success page

Part 11: Cancel and reactivate

Part 12: Local development with Stripe CLI

Test checklist

Part 13: Production checklist

`users` — link account to Stripe customer

`subscriptions` — subscription history

`processed_webhook_events` — prevent duplicate processing

4. Forgetting `client_reference_id`