Blunt dispatch

WP Effective Acceleration Movement

Bring back what made WordPress fast, simple, and unstoppable.

WordPress took over the web because a builder could ship a feature before a meeting ended. No committees, no sprints—edit PHP, refresh, done.

Hooks kept every layer flexible without forking core. Direct server edits kept the loop between idea and live change to seconds. That's the original acceleration.

Then we buried it under SaaS dashboards, drag-and-drop theater, JS confetti, and hosts who hide logs behind enterprise-plan upsells.

WP e/acc refuses that drag. We keep WordPress terrifyingly fast for people who ship.

Read the Principles See What You Can Do Today
signal awake()
impact
real
simplicity
sane
resilience
built‑in

Choose fewer steps when possible. Make necessary steps obvious and safe.

SECTION 01 — MANIFEST

What we stand for

Operating doctrine for people shipping production. Anything that slows the builder, admin, or user gets removed.

Hooks over guesswork

Document every hook and priority. Treat it like a contract so teams can extend without spelunking minified bundles.

Zero bloatware

If the first screen is an upsell or a nag, it's gone. Tools either speed up users or they're rot.

Simplicity = scalability

Everything should plug in, work, and stay obvious. Complexity is earned only after the simple path actually breaks.

Real-time development

If you can't edit on the server and refresh, the tool isn't WordPress ready. Short feedback loops beat deployment theater.

Order on the front end

Events and hooks exist on the front end too. Publish them, respect sequence, and stop forcing devs to diff bundles.

Debugging & observability

Know what's logged, where it lives, and who can hit the switch. Observability is a baseline, not a premium SKU.

Who this is for

For people who fix WordPress by doing the work, not by filing tickets and waiting a quarter.

  • —Developers who publish hook maps, expect the same from vendors, and delete anything opaque.
  • —Operators who need fast, predictable sites without circus dashboards or mystery cron jobs.
  • —Owners who want receipts for every millisecond and refuse "enterprise" paywalls for logs.

If that's you, stay loud and keep shipping.

hooks over theater zero bloatware themes server editable speed blocks with order acf x block parity logs & profiling for all

SECTION 02 — PRINCIPLES

Principles of the WP Effective Acceleration Movement

Not slogans—tests. If a theme, plugin, tool, or host fails these, it doesn't touch production.

  1. 01

    Hooks as the engine of acceleration

    WordPress runs on actions and filters. Treat them as the API surface and build your product story around them.

    • •Change behavior without forking or breaking updates.
    • •Stack plugins safely because priorities and intent are explicit.
    • •Coordinate complex behavior inside a predictable lifecycle.

    Ship hooks or ship a black box. Black boxes slow everyone down.

  2. 02

    Zero bloatware

    Acceleration means nothing sits between the user and the work. Kill upsells, nags, vanity features, and anything that only exists to sell pro tiers.

  3. 03

    Simplicity, scalability, and development speed

    Simplicity is the multiplier. Install it, it behaves, and nobody has to learn a new religion.

    WordPress is supposed to be "drop a file, edit on the server, refresh." Blocks and builders either respect that immediacy or they don't ship.

  4. 04

    Development speed over deployment theater

    Deployment rituals don't impress users. Optimize for the seconds between "change this" and "it's live." If a workflow adds friction, treat it as a bug and remove it.

  5. 05

    Front-end order instead of JavaScript chaos

    The front end deserves the same discipline as PHP. Publish events, honor hook order, and quit forcing people to attach mystery listeners to unnamed globals.

  6. 06

    Controls and custom fields that don't suck

    Controls should feel the same whether you build with classic meta or blocks. ACF-level clarity should be default. If a panel wastes time or duplicates data, delete it.

  7. 07

    Debugging and transparency: fix WP_DEBUG

    WP_DEBUG and PHP error_reporting must agree, be visible, and be safe to toggle. Builders and admins should know what's logged and where without opening SSH.

  8. 08

    Hosting, profiling, and logging as basics

    Logs, slow query data, and profilers are table stakes. Hosts who hide them or charge "enterprise" tax are hostile to builders. Reward the ones who hand you the tools.

SECTION 03 — ACTION

What you can do today

Action, not vibes. These are the moves to make every day when you build, host, and maintain WordPress.

  1. 01

    Build and choose for hooks

    Choose tools that publish hooks, priorities, and examples. When you add hooks, document them and treat them as APIs, not trivia.

  2. 02

    Say no to bloatware

    Audit every plugin. If the first thing it shows is an upsell, a badge, or a modal, delete it. Admin attention spans are finite.

  3. 03

    Protect development speed

    Lean into PHP's strength: edit on the server, refresh, see the result. If a block or builder adds ceremony to that loop, open an issue or drop it.

  4. 04

    Demand order on the front end

    Use tools with published event systems. If you have to read minified bundles to know when something fires, treat it as debt. When you ship components, document the lifecycle like you would in PHP.

  5. 05

    Unify controls and custom fields

    Push ACF-level integrations into blocks. Kill the split between "old" meta boxes and new UIs. One clean control panel per context, nothing redundant.

  6. 06

    Make debugging and logging first-class

    State exactly how WP_DEBUG and error_reporting interact, where logs write, and how to flip switches. Give privileged admins UI controls so they never guess.

  7. 07

    Vote with your wallet on hosting

    Pay hosts who expose logs, traces, and profilers out of the box. Fire anyone who hides them behind enterprise paywalls and explain why to your clients.

SECTION 04 — ORIGINS

About & Get Involved

How we got here

WordPress was a hook-driven PHP app on $5 hosting that you edited live. Hooks plus instant feedback let it swallow the web. Drag builders, JS sprawl, and opaque hosting buried that loop.

Where we go from here

This is course correction, not nostalgia. We re-center hooks, strip bloat, restore the "edit-refresh" loop, bring order to the front end, and demand accessible debugging, logging, and profiling.

How you can get involved

Ship differently and write receipts. Publish how your work uses hooks, avoids bloat, and exposes observability. Call out what made WordPress win, what's holding it back, and how you are fixing it.

Final reminder

You don't need approval. Change what you tolerate, show your work, and ship WordPress the way it wins: hooks, simplicity, speed, and proof.