Product Decisions This Supports
- Build vs. buy for CMS foundations. This is a WordPress library (not Laravel), so it belongs specifically to the WordPress product line. If we are shipping any WordPress-based content product—publisher sites, directories, marketplaces, documentation portals, membership sites—this package replaces dozens of lines of hand-rolled
register_post_type() / register_taxonomy() boilerplate with a declarative configuration array. That is a "buy" (adopt) decision, not a "build" one.
- Roadmap scoping for content-heavy features. Any roadmap item that says "add a listings section," "support editorial sections," "add a resources library," or "launch a directory" implicitly requires at least 2–5 custom post types. Extended CPTs makes those features cheaper to scope and faster to ship without custom admin plugins.
- Admin UX as a differentiator. The most undersold value is the admin experience: sortable columns, custom filters, featured-image columns, "at a glance" dashboard widgets, and taxonomy-aware permalinks. If our editors or clients are the buyers, admin polish is a retention and upsell lever—not just a dev convenience.
- Multisite / template standardization. For agency or multi-tenant WordPress footprints, this package lets us codify CPT registration in a reusable mu-plugin or starter theme, giving consistent admin behavior across sites. That is a standardization decision with real operational payoff.
- Migration and tech-debt decisions. Sites with scattered, inconsistent CPT registration can be consolidated onto this package as a low-risk refactor. It is also a reasonable hedge against "we'll just use a page builder for everything," which tends to age poorly.
- Explicit non-decision: this does not address custom fields/schema. It complements ACF, Meta Box, or native block bindings rather than replacing them. Don't let a "we have extended-cpts" conversation substitute for a real content-modeling decision.
When to Consider This Package
Adopt when all or most of these are true:
- The product is WordPress-based. (It has no applicability to Laravel or framework-agnostic PHP projects—if the initiative is a Laravel app, this is out of scope and should be closed.)
- The content model requires three or more custom post types, or one CPT with meaningfully complex taxonomy/permalink needs.
- Editors, clients, or internal ops teams will live in wp-admin and benefit from sortable columns, filters, and dashboard widgets.
- We are doing repeatable WordPress delivery (agency, multisite, starter kit) where consistency across sites matters.
- The team is comfortable with PHP-level configuration (arrays, filters) rather than a GUI-only workflow.
- We want permalink structures that combine CPT + taxonomy (e.g.,
/section/category/post-slug/) without writing custom rewrite rules by hand.
Look elsewhere or skip when:
- The project is headless/API-only with no meaningful wp-admin surface—the admin features (the bulk of the value) go unused.
- The content model is trivially small (one CPT, no taxonomies)—native
register_post_type() is enough and adds no dependency.
- The team is Gutenberg/FSE-first with site editing, where block-based template work and theme.json handle much of the structural needs.
- The real requirement is custom fields, relationships, or structured data—that's ACF/Meta Box territory; this package won't solve it.
- We have a policy of zero third-party WordPress plugins, or the license/provenance review can't clear GPL-2.0 dependencies.
Risk notes for the decision record: single-maintainer project (~1k stars), GPL-2.0 (fine for WordPress, but confirm it aligns with distribution plans), and last release June 2025—actively maintained but with a small contributor base. Mitigate by pinning versions and keeping a thin wrapper so we are not coupled at call sites.
How to Pitch It (Stakeholders)
For executives (30-second version): This is a small, mature, free WordPress library that makes custom content types—listings, resources, directories, editorial sections—faster to build and much cleaner for editors to manage. It is not a platform commitment; it saves engineering days per WordPress project, reduces the amount of bespoke admin code we own, and is used across thousands of WordPress sites. Low cost, low lock-in, clear time-to-value.
For engineering leadership: Extended CPTs is a well-regarded, actively maintained library (v1k stars, release June 2025) that extends register_post_type and register_taxonomy with declarative support for admin columns, filters, sortable columns, dashboard widgets, and taxonomy-aware rewrite rules. It's a thin abstraction over core APIs—no DB changes, no custom tables, no runtime magic beyond standard WordPress hooks. Adoption is a composer require plus a wrapper function; removal is equally trivial. Recommend adopting it as the default CPT registration standard for WordPress work, with a pinned version and a thin internal wrapper to insulate call sites.
One-line framing: It makes WordPress behave like a proper CMS for structured content, at the cost of one dependency we can remove in an afternoon.