Potter Laravel Package

Product Decisions This Supports

This package informs three decisions, though it should not be the thing you ship.

• Theming architecture roadmap. Potter is the clearest articulation of the "WordPress with Laravel ergonomics" direction: replace the template hierarchy with Blade, add a container, model queries with Eloquent-style objects. If your roadmap includes reducing theme spaghetti and onboarding Laravel-fluent engineers onto WordPress, this is a useful reference design for that target state — not the implementation.
• Build vs. buy vs. fork. Potter is a fork-and-own candidate at best. It is MIT-licensed, small, and self-contained, which means the pattern is free to adopt even if the package is not. The real decision is whether you buy into an actively maintained equivalent (Roots Sage + Acorn, Timber, Themosis), fork Potter internally, or build a thin Blade layer yourself.
• Vendor and dependency risk policy. With 18 stars, a 0.21 composite score, and a last release of 2015-04-25, Potter is a textbook example for a dependency-risk checklist. Use it to pressure-test whether your org requires: recent releases, a security-response path, PHP version support aligned to your hosting baseline, and an identifiable maintainer.
• Use cases it legitimately fits. Internal tools, throwaway prototypes, a teaching/reference codebase for engineers learning how Blade + a container map onto WP hooks, or a greenfield theme on a frozen legacy stack you fully control.
• What it does not inform. Block editor strategy, full-site editing, or REST/GraphQL-driven front ends. Potter predates Gutenberg entirely; it assumes classic PHP-rendered themes. Any roadmap item touching blocks, theme.json, or headless delivery should be scoped on a different foundation.

When to Consider This Package

Adopt only under a narrow set of conditions — ideally several of them together:

• You are on a legacy PHP 5.x/7.0-era stack that you cannot upgrade, and Potter's constraints match your environment rather than fight it.
• The theme is internal or low-exposure, not a client deliverable with a multi-year maintenance commitment or a security surface.
• You have in-house Laravel capability and appetite to fork and maintain — treat it as vendored source code you now own, not a dependency you consume.
• You want a reference implementation to study before committing to a maintained alternative.
• Your team already knows Blade and you need to justify why a Blade-based WP setup is worth pursuing; Potter is a low-cost way to prototype that argument.

Look elsewhere — decisively — when any of the following hold:

• Production or client work with a maintenance horizon beyond ~12 months. An eleven-year-old package with no releases means no PHP 8.x compatibility guarantees, no security patching, and no upstream fixes. Your team absorbs 100% of that cost.
• You need modern WordPress. No block editor support, no theme.json, no full-site editing, no evidence of REST API alignment.
• You want community support. 18 stars implies effectively no ecosystem: no Stack Overflow corpus, no third-party extensions, no hiring pool that has seen it.
• You need a support contract or SLA. Not available.
• Obvious maintained alternatives fit: Roots Sage with Acorn delivers Blade, a container, and Laravel-style config with active maintenance — it is essentially Potter's thesis, executed and sustained. Timber if Twig is acceptable. Themosis for a heavier Laravel-integrated framework. Headless WordPress behind a Laravel or Next.js front end if the real goal is separating content from presentation.

Net recommendation: do not adopt Potter as a dependency. Adopt its thesis, and fund the maintained implementation of it.

How to Pitch It (Stakeholders)

To executives — one paragraph: Potter is a 2015 open-source experiment that brings Laravel's Blade templating and service container to WordPress themes. The idea is sound and is now standard practice in the WordPress ecosystem; the package itself is abandoned — last release April 2015, minimal adoption, no security or PHP-version maintenance path. We should not build on it. We should adopt the pattern via an actively maintained equivalent, which gets us the same developer-experience gains without inheriting an unmaintained dependency and its full maintenance liability.

To engineering — the substance:

• What it gets right: Blade layouts/partials/components over the template hierarchy, a container and facades to pull logic out of functions.php, Eloquent-style querying for posts/terms/users, WP-CLI scaffolding. These are the right instincts and they reduce the "WordPress theme as a pile of globals" problem.
• Why we're saying no: last release 2015-04-25; 18 stars; score 0.21. That combination means no PHP 8 compatibility work, no security response, no upstream fixes, and no community to hire from. Forking means we own a PHP framework adapter forever, including every future WordPress core change.
• What we do instead: Roots Sage + Acorn gives us Blade and a container with active maintenance and a real contributor base; Timber if the team prefers Twig; headless if the strategic goal is decoupling. All three keep the developer-experience win and drop the abandonment risk.
• Cost framing: the delta is not license cost — it's the ongoing cost of owning an unmaintained dependency (compatibility patching, security review, onboarding without documentation). That delta is reliably larger than the switching cost to a maintained alternative, and it compounds.

Ask: approve the pattern (Blade + container + typed models for theme logic) as the architectural direction; approve a short evaluation spike of Sage/Acorn against one representative theme; retire Potter to the reference-reading list.