Weave Code
Wordpress Bundle Laravel Package
happyr/wordpress-bundle
Symfony bundle that integrates WordPress into your Symfony application, letting you run WordPress alongside Symfony routing, services, and templating so content can be managed in WordPress while the front end is built with Symfony.
At a glance
Frequently asked questions about Wordpress Bundle
- Can I use happyr/wordpress-bundle in a Laravel application?
- No. happyr/wordpress-bundle is a Symfony bundle whose entry point is a Bundle class plus a DI extension and service tags. There is no Laravel service provider, facade, or Eloquent bridge, so Composer will install code your container cannot boot. Making it work in Laravel means rewriting the container wiring yourself, which is effectively reimplementing the package.
- What does happyr/wordpress-bundle actually do?
- It bootstraps WordPress inside a Symfony application so WordPress handles authoring, taxonomy, and media while Symfony handles routing, templating, and rendering. The bundle wires WordPress code to Symfony services and configuration and supports standard WordPress themes and plugins. In practice it is a content-as-a-service bridge with no write path back into WordPress.
- Is happyr/wordpress-bundle still maintained?
- The last release was July 2021, targeting the Symfony 5 and PHP 7.4 era. The project has roughly 16 stars, zero dependents, and a single maintainer, so there is no realistic upstream security patch path. Treat it as vendored source rather than a dependency if you adopt it at all.
- How do I install and configure happyr/wordpress-bundle?
- On Symfony you would composer require happyr/wordpress-bundle, register the bundle in bundles.php or your Kernel, and supply WordPress database or REST credentials through bundle configuration. On a modern Symfony 6 or 7 baseline expect to fork first: tighten composer constraints and fix deprecated Cache and HttpClient signatures before the bundle will boot. There is no install path for Laravel.
- Which Laravel and Symfony versions does happyr/wordpress-bundle support?
- It targets the Symfony 5 and PHP 7.4 era and has no Laravel support of any kind, so questions about Laravel 10 or 11 are moot without a rewrite. On Symfony 6 or 7 with PHP 8.2+, budget three to five engineer-days to fork the package and get the test suite running. Expect missing return types on entities and deprecation notices the existing tests do not cover.
- How does the bundle fetch WordPress content: MySQL tables or the WP REST API?
- Historically the bundle shipped two integration modes: reading directly from WordPress MySQL tables such as wp_posts, wp_postmeta, and wp_terms, or consuming the WP REST API. The database path is the fragile one because any plugin that alters schema can break your application. A REST-only design avoids that coupling and also avoids holding read credentials to the WordPress database.
- How should I handle cache invalidation when editors publish in WordPress?
- The bundle does not solve cache invalidation for you. WordPress publish events do not notify your application cache, so you must add a webhook or a short TTL yourself. Decide with editorial whether a five-minute staleness window is acceptable or whether instant invalidation is required, because that choice drives the design.
- What are the production risks of the direct WordPress database approach?
- The direct database approach couples your application to WordPress table schemas, so a marketing-team plugin install becomes a potential production outage. It also means your app holds read credentials to the WordPress database, which is a lateral-movement concern. The bundle itself is unmaintained, so schema changes and security fixes become entirely your problem.
- What is a better alternative for a Laravel team that needs WordPress content?
- For Laravel, reimplementing is cheaper than porting: a WordPressClient around the WP REST API, a handful of DTOs for Post, Category, Tag, Author, and Attachment, a cache decorator, and a Blade presenter. That is roughly one engineer-week and produces code your team can reason about. Alternatively, evaluate maintained headless CMS packages or a dedicated WordPress REST client rather than a dormant Symfony bundle.
- How do I test and production-harden a WordPress integration in Laravel?
- Test the REST client with Laravel HTTP fake helpers and contract tests against a staging WordPress instance, and unit test the cache decorator separately from the transport. On the Symfony side, run PHPStan and the package own test suite on your PHP version before trusting it. In production, keep WordPress credentials read-only and monitor for plugin-driven schema changes.
Weaver
How can I help you explore Laravel packages today?