Wordpress Interop Laravel Package

Product Decisions This Supports

• Decoupled / headless migration path: Lets a Laravel app read (and optionally write) the existing WordPress tables (wp_posts, wp_postmeta, wp_users, wp_options, wp_terms) through Eloquent models. This de-risks a “strangler” migration: ship Laravel-side features against live WP content instead of committing to a big-bang rebuild or a paid headless CMS.
• Build vs. buy on admin/tooling: If the business already runs WordPress but wants better internal tooling (reporting, editorial workflows, bulk operations, customer portals), this package supports building that layer in Laravel rather than buying a separate CMS or rebuilding content storage.
• Content aggregation and reporting: Enables analytics dashboards, content audits, SEO/link inventories, and cross-system reporting directly off the WP database without standing up the WP REST API or a sync pipeline — useful for scoping internal data products.
• Roadmap sequencing: Supports phased delivery — Phase 1 is Laravel reads WP content, Phase 2 adds write-back or a dual-write period, Phase 3 cuts over. Each phase is independently shippable and reversible, which makes it easier to justify incremental investment.
• Use cases to validate first: read-heavy content surfaces (public site, docs, blog), back-office tooling, migration dry-runs, and one-off data migrations. Write-heavy or plugin-entangled scenarios (WooCommerce, ACF-heavy sites, custom tables) are where scope and cost estimates should be treated as high-variance.

When to Consider This Package

Adopt when most of these hold:

• You have an existing WordPress database you must keep serving from while building a Laravel/PHP application alongside it.
• Your needs are predominantly read-oriented — displaying, indexing, reporting, or migrating content.
• The WordPress install is conventional: core tables plus a small number of well-understood plugins, with a stable schema you control.
• You want to avoid an API/sync layer (REST, webhooks, queues) for an MVP or internal tool, and can tolerate direct DB coupling.
• The team is small and already fluent in Laravel/Eloquent; the cost of a thin adapter is lower than standing up and operating a sync service.

Look elsewhere when:

• You need the full WordPress runtime — plugin hooks, shortcodes, Gutenberg block rendering, auth cookies, cron, media handling. This library models data, not behavior.
• Writes are heavy or concurrent with WP writers (locking, revisions, cache invalidation, transients become your problem).
• Content depends on plugin-specific tables or serialized PHP in postmeta/options — mapping and unserialization costs escalate quickly and are easy to underestimate.
• You need guaranteed schema stability across WP/plugin upgrades, or contractual support/SLAs.
• You are not on Laravel/Eloquent, or you need multi-tenant/multi-site (multisite table prefixes) isolation.

Vendor-risk note for the decision record: 67 stars, single-maintainer signal, last release July 2024, MIT. Treat it as a thin, forkable dependency rather than a platform bet. Budget a small spike to read the source and confirm table coverage, and isolate it behind your own repository/adapter interface so it can be replaced or vendored if maintenance lapses.

How to Pitch It (Stakeholders)

For executives: This is a low-cost bridge, not a platform commitment. It lets us ship Laravel features against our existing WordPress content in weeks rather than funding a full CMS migration up front, and it keeps the content where it is until we have evidence the migration is worth doing. No license fees (MIT), no new vendor contract, and every phase is reversible — if it doesn’t pan out, we’ve spent engineering days, not a migration budget.

For engineering: It’s a set of Eloquent models over the WordPress schema — a data-access layer, not an integration framework. It does not give you WordPress behavior (hooks, shortcodes, block rendering, auth), and it does not solve writes, revisions, caching, or serialized meta. Plan to wrap it behind our own repository interface, pin the version, and own the mapping for any non-core tables. The upside is we skip building a sync pipeline for read-only needs and get a clear seam for a later cutover.

Recommendation: Approve a time-boxed spike (1–2 weeks) against a real database snapshot to validate schema coverage and serialized-data handling, with adoption gated on that spike and on the adapter abstraction being in place before production use.