Entity Laravel Package

Product Decisions This Supports

• Build vs. buy for content modeling: pollora/entity is a thin, MIT-licensed abstraction for registering WordPress custom post types and taxonomies in PHP. It shifts the decision from "write our own registration layer" to "adopt and wrap a small dependency," which is attractive when the alternative is 300–800 lines of bespoke register_post_type() boilerplate spread across a codebase.
• Roadmap sequencing for content-driven features: Any roadmap item that requires new structured content—directories, marketplaces, job boards, case-study libraries, resource hubs, event calendars—depends on clean CPT/taxonomy definitions. Adopting this package early de-risks those features and shortens the lead time between "we've prioritized it" and "we can model it."
• Architecture standardization: If multiple squads or plugins register post types ad hoc, this package offers a single declarative pattern. That is a platform decision, not a feature decision: standardize now, or accumulate inconsistent registration code that is expensive to audit later.
• Laravel/Pollora ecosystem alignment: This is most defensible as part of a broader bet on the Pollora stack. If the org is already Laravel-centric and using WordPress as a content backend, this fits the mental model and reduces context-switching for engineers.
• Headless and hybrid WordPress strategies: Typed, code-defined content models make it easier to expose consistent schemas to a separate frontend or API layer, which supports decisions about whether to go headless, hybrid, or stay traditional.
• Vendor vs. internal ownership: Because the surface area is small and the license permissive, it can be forked or wrapped. That supports a "buy-and-wrap" decision rather than a full build, with a documented exit path.

When to Consider This Package

Consider it when:

• The team is on PHP 8+ with Composer and is comfortable with modern, class-based configuration.
• You are already in or evaluating the Pollora/Laravel-for-WordPress ecosystem; the package's value is highest as part of that stack.
• You need repeatable, testable, version-controlled content-type definitions rather than admin-UI-driven configuration.
• The CPT/taxonomy surface is modest and stable—you want a clean registration layer, not a full content-modeling platform.
• You are willing to vendor or wrap the dependency behind an internal adapter to insulate against abandonment.

Look elsewhere when:

• The team is WordPress-native and expects admin UI tooling. ACF, CPT UI, Pods, or Custom Post Type UI Pro will be a better cultural and operational fit.
• You need mature field management, relationships, repeaters, or editorial UX out of the box. This package registers types; it does not manage fields.
• You require a large community, long support history, or vendor SLAs. Three stars and zero dependents means no ecosystem safety net.
• The project is high-traffic or long-lived and cannot tolerate single-maintainer risk without an internal fork strategy.
• You are not using Composer or are locked to legacy PHP versions.

Risk notes to weigh: the release date is forward-dated, adoption is effectively zero, and there is a single apparent maintainer. Treat this as an early-stage internal-quality dependency: pin versions, wrap it, and budget a small amount of engineering time to own the abstraction if upstream goes quiet.

How to Pitch It (Stakeholders)

For executives: This is a small, free, permissively licensed PHP package that standardizes how we define structured content in WordPress. It reduces the custom code we write for features like directories, resource hubs, and marketplaces, which shortens delivery time on content-heavy roadmap items and lowers long-term maintenance cost. The financial exposure is near zero—MIT license, no procurement, no vendor lock-in—and because the package is small, we can replace or absorb it internally if needed. The real risk is maturity, not money: it is early-stage with minimal adoption, so we should adopt it deliberately, behind our own interface, rather than as a load-bearing dependency.

For engineering: It gives us declarative, testable, version-controlled definitions for post types and taxonomies instead of scattered imperative registration calls. It fits a Laravel/Pollora-style codebase and is easy to reason about. We should wrap it in a thin internal adapter so our domain code does not import it directly—that keeps our options open, makes future replacement a one-file change, and lets us patch upstream behavior locally. We should pin the version, add a smoke test around registration, and assign an owner to review upstream activity each quarter.

Recommendation: Adopt as an evaluated dependency for a bounded pilot on one content-driven feature, wrapped behind an internal abstraction. Revisit at the next planning cycle with pilot results and an upstream health check before expanding to the wider platform.