Weave Code
Wordpress Bundle Laravel Package
metabolism/wordpress-bundle
Bridges WordPress and Symfony by bootstrapping WordPress inside a Symfony bundle. Query posts, pages, and taxonomies through Symfony services, then render them with Twig and your existing routing. Ideal for hybrid CMS or headless-style setups.
Use Wordpress and Symfony together using a Symfony bundle
Frequently asked questions about Wordpress Bundle
- Does metabolism/wordpress-bundle work with Laravel?
- Based on its repository, changelog, and release notes, this is a Symfony bundle that bootstraps WordPress inside a Symfony application and renders content through Twig. There is no Laravel service provider, facade, or Eloquent model in the codebase, despite the Laravel-flavoured package description. Treat the Laravel claim as unverified until you read the source yourself, and prefer a dedicated Laravel headless WordPress package if Laravel is your target framework.
- How do I install metabolism/wordpress-bundle with Composer?
- It is Composer-installable and MIT licensed, so procurement friction is low. Run composer require metabolism/wordpress-bundle, then register the bundle in your Symfony bundles configuration and point it at your WordPress installation and database. Check the required PHP version and Symfony floor first, since the 3.0.2 release moved both.
- Which Symfony versions does this bundle support?
- Symfony 4 support was dropped in the 3.0.2 release, so the oldest supported Symfony major is at least 5. The release notes do not state an explicit Symfony 6 or 7 ceiling, so the upper bound is currently unknown. Confirm support against your exact Symfony minor before committing it to a roadmap.
- Is WordPress 7 supported and has it been tested?
- Version 3.0.2 adds WordPress 7 support, but WordPress 7 is a late-cycle or unreleased major at the time of the notes. The changelog does not show whether this was validated against both WordPress 7 and the current WordPress 6.x line, or swapped in without testing. Given the package bootstraps WordPress directly, a WordPress major bump touches a very large surface area, so verify it in a spike.
- Why did a patch release drop Symfony 4 support?
- The 3.0.2 patch drops Symfony 4 while simultaneously adding WordPress 7 support, which is a semver contract violation regardless of whether the removal actually landed in 3.0.0. The practical consequence is that you cannot rely on version numbers to signal breaking changes. Diff the changelogs between releases rather than assuming a patch is safe.
- What was the cache key issue fixed in version 3.0.2?
- Cache key derivation was weak and has now been corrected, which means earlier versions should be treated as having suspect cache isolation until patched. If cache keys are guessable or under-specific, that is a correctness problem and potentially a cache poisoning vector. Because the fix changes the keys themselves, expect a cold-cache event on upgrade and the origin load that comes with it.
- Is this bundle a good fit for headless or API-first WordPress?
- No. The 3.0.2 release shows the package optimising for server-rendered Twig templates, which is the opposite direction from an API-first headless build. It now owns block registry semantics, JSON encoding of block allowlists, and cache-key derivation for those views. If you want WordPress purely as a JSON source for a JavaScript front end, a plain REST or GraphQL layer is a better fit.
- What does blog.registered_blocks do and why does it matter?
- It is a Twig-exposed, filterable collection of WordPress block names, consumed directly in a Symfony and Twig template to constrain InnerBlocks allowedBlocks. That confirms the bridge does real work at the presentation seam rather than just proxying HTTP. It also means any WordPress plugin that registers or de-registers blocks silently changes your Twig output, which is why the release notes show a filter removing acf/accordion as a workaround.
- What are the performance costs of the dual bootstrap?
- The bundle runs two autoloaders, two error handlers, and two configuration systems in a single request. That roughly doubles the per-request memory floor compared with either framework on its own. Benchmark this on your own Symfony minor and PHP 8.2 setup before assuming it is acceptable in production.
- What should I verify before adopting this package?
- Run a one-week spike on your actual target matrix: Symfony minor, PHP 8.2 or later, and WordPress 7. Validate the cache invalidation contract, including whether cache keys incorporate the filtered block list rather than the raw registry. Check maintainer activity and real dependents, since the assessment has no telemetry and adoption remains unverified. With no vendor behind it and a two-track plus security patch cadence, plan for the maintenance burden to sit with your team.
Weaver
How can I help you explore Laravel packages today?