Source: Dev.to

The Problem and Introducing WPPF

If you’ve built more than a few WordPress plugins, you’ve probably run into the same pattern.
A plugin starts clean, but as features grow it slowly becomes a mix of

• scattered add_action calls,
• copied boilerplate code,
• an includes/ folder full of dissimilar items.

After dealing with this enough times while building client plugins, I decided to standardize how I structure my projects. That eventually became the WordPress Plugin Framework (WPPF).

---

Why This Happens

WordPress gives you incredible flexibility, but large plugins benefit from a little structure.

• Freedom → little guidance – WordPress doesn’t impose a strict project structure.
• As plugins grow you often see:
  • hooks scattered across files,
  • features implemented wherever convenient,
  • utility functions copied between projects,
  • an includes/ folder turning into a “stuff drawer”.

None of this is necessarily wrong, but over time it can make a plugin harder to understand and maintain.

---

My Solution

The Core Idea: Modules

Instead of organizing code primarily by what it is (classes, templates, utilities, etc.), I organize plugins by what they do – a feature‑based architecture.

A plugin might contain things like:

• a REST API,
• admin UI screens,
• custom post types,
• scheduled tasks,
• integrations with other platforms/plugins.

Each of these areas becomes a module that owns its own hooks, logic, and supporting code.

“Where is the code that registers this feature?” → you can usually find it directly inside the module responsible for that behavior.

---

CLI Scaffolding

One of the most repetitive parts of plugin development is creating the same structural pieces over and over (bootstrapping files, registering CPTs, creating meta boxes, configuring admin screens, etc.).

WPPF includes a CLI tool that can scaffold common plugin components:

# Create a new plugin
vendor/bin/wppf make:plugin

Other commands can generate:

• custom post types,
• meta boxes,
• admin modules,
• other common scaffolding.

This eliminates boilerplate and ensures a consistent starting point.

---

Versioned Namespaces

WordPress sites often load many independent plugins at once. If two plugins ship different versions of the same library, conflicts can occur.

WPPF solves this by using versioned namespaces:

// Instead of a static namespace
WPPF\Plugin

// Use a versioned one
WPPF\v1_2_2\Plugin

Different plugins can safely ship with different framework versions without colliding.

---

Who This Framework Is For

• Developers building large or growing plugins who need a clear, maintainable structure.
• Teams that want consistent scaffolding and reduced boilerplate.
• Anyone who prefers a feature‑oriented architecture over a file‑type‑oriented one.

---

Try It Out

The framework focuses on a few practical goals:

1. Organizing plugin code around feature modules.
2. Keeping WordPress hooks close to the feature they belong to.
3. Using a custom PSR‑4 autoloader for predictable project structure.
4. Providing CLI scaffolding for common plugin components.

The result feels very “WordPress”, but scales better as plugins grow.

---

Example Module

A module represents a single feature area within a plugin and acts as the entry point for that feature’s behavior.

  
- **GitHub Repository:** 

The project is open source, and feedback from other plugin developers is always welcome. I’m particularly interested in hearing how other developers structure larger plugins and what kinds of tooling would make plugin development easier.

If you try the framework or have ideas for improving it, feel free to:

- Open an issue on GitHub  
- Start a discussion in the repository

WordPress plugin development is incredibly flexible, and this framework is simply an attempt to add a little more structure where it helps.