Kayue Wordpress Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for CMS integration. When a WordPress site already holds the content and user accounts your product needs, this bundle is a "reuse what exists" option: it exposes WordPress posts, terms, and users as Doctrine-backed repositories inside Symfony, avoiding a CMS rebuild or a parallel content store.
• Incremental migration ("strangler fig") off WordPress. It supports a roadmap where new functionality ships in Symfony while WordPress remains the system of record for content and credentials — users log in once against WordPress and are authenticated inside the Symfony app.
• Identity and SSO strategy. The bundle's user provider/authentication path is a concrete input to the decision "do we treat WordPress as the identity source, or introduce a dedicated IdP?" It makes the cheap version of that decision cheap to test.
• Scope of a legacy modernization program. Choosing this package caps near-term investment: it buys content and login reuse for one release cycle rather than funding a full re-platforming or a headless-CMS procurement.
• Feature sequencing. Because it is read-oriented (repositories over WordPress tables) rather than a publishing integration, it enables read-side features first — archives, search, member-only areas, author pages — while deferring editorial workflow and write-back to a later phase.
• Vendor and maintenance budgeting. With ~99 stars, zero dependents, and a last release in mid-2020, adopting it is effectively a decision to own a small fork; that cost belongs in the roadmap and resourcing plan, not in a hidden assumption.

When to Consider This Package

Consider it when all of the following hold:

• The application is on Symfony 2.x (or you are willing to maintain a backport) and you cannot yet move off it.
• There is an existing WordPress database you want to read from directly — posts, taxonomies, and user records — without building a content sync.
• You need WordPress-backed login for a Symfony front end and want a working reference implementation of the user provider and password-hash handling rather than designing one from scratch.
• The integration is read-mostly and short-horizon: a bridge to unblock a release, not a five-year foundation.
• You have PHP/Symfony engineers who can fork and patch the bundle, and a plan for security review of the authentication path.

Look elsewhere when:

• You are on Symfony 5/6/7 or PHP 8 — the package targets Symfony 2 and has been dormant since June 2020; expect incompatibility and unpatched dependencies.
• You need writes, editorial workflow, or media handling — a direct database integration is the wrong abstraction; use the WordPress REST API or a GraphQL layer instead.
• Security and identity are load-bearing — for anything beyond a stopgap, prefer OAuth2/OIDC or SAML against WordPress or a dedicated IdP rather than shared-table password verification.
• Multi-site, high availability, or schema churn matter — coupling to WordPress table structure makes you fragile to plugin and core upgrades.
• You want active maintenance, CVE response, or vendor support — none of that exists here; zero dependents is a signal about the support ecosystem, not just popularity.

How to Pitch It (Stakeholders)

For executives: We have an existing WordPress property holding content and user accounts, and a Symfony application we want to grow. This package lets us connect the two in days rather than quarters — reusing WordPress content and logins inside the Symfony product without a CMS migration or a new identity platform. It is a bridge, not a destination: it defers re-platforming cost and risk while we validate which features earn investment. The trade-off is maintenance — the package has been unmaintained since 2020 and will effectively become a small piece of code we own. Recommendation: approve as a time-boxed integration for the next release, with an explicit checkpoint to replace it once we commit to a modern Symfony version or a headless content strategy.

For engineering: This is a Symfony 2 bundle providing Doctrine repositories over WordPress tables plus a WordPress-backed user provider for login. Treat it as reference code and a starting point: fork it, pin and audit the authentication path, add integration tests against a real WordPress schema, and document the table coupling so upgrades are visible. Budget for the fact that the upstream will not patch security issues; assign an owner and a sunset date at adoption. If the platform roadmap includes a Symfony upgrade, plan the replacement (WordPress REST API or an OIDC-based identity handoff) in the same cycle rather than after.