- Can I use mukadi/wordpress-bundle in a Laravel application?
- No. mukadi/wordpress-bundle is a Symfony bundle, and Laravel has no bundle or service-container extension point that it targets, so it cannot be installed as a native Laravel dependency. For a Laravel stack, use Corcel for read-only Eloquent access to WordPress tables or go headless with the WordPress REST or GraphQL API.
- What does mukadi/wordpress-bundle actually do?
- It is a Symfony bundle that integrates WordPress into the same application by bootstrapping WordPress core in-process alongside Symfony. That lets you use WordPress core features, hooks, content, and templating without duplicating setup. Its design assumes a Symfony kernel owns the request, which is the opposite of how a Laravel app would normally consume WordPress.
- Which Symfony and PHP versions are supported by mukadi/wordpress-bundle?
- The provided evaluation does not include a maintained compatibility matrix, so you must verify the Composer constraints against your current PHP and Symfony versions before committing. Version compatibility is flagged as the most likely blocker. Pin WordPress core to an exact version and treat upgrades as change-managed releases.
- How do I install mukadi/wordpress-bundle?
- Installation is through Composer into a Symfony project, and the bundle expects WordPress core to be present and configured for in-process bootstrapping. You should enable the bundle in the Symfony kernel and confirm the required WordPress path and database settings. Check the repository README and Composer constraints first because the integration is invasive and version-sensitive.
- How are WordPress and Symfony authentication and sessions bridged?
- The evaluation flags this as a key unknown: the bridge could use shared cookies, a shared user table, or duplicated identities, and you must prove which one before relying on it. Test that Symfony Security and WordPress roles and capabilities resolve to one identity. Do not touch content routes until the authentication bridge is proven in an isolated spike.
- Is it safe to run WordPress plugins inside a Symfony application process?
- It is high risk. Every WordPress plugin becomes an attack path inside the application process and can bypass Symfony's firewall and middleware. Inventory every plugin, assign an owner, confirm none escape the Symfony middleware, and keep WordPress routes bounded to a content or blog area rather than the whole application.
- What are the GPL licensing implications of bundling WordPress into a proprietary app?
- WordPress is GPLv2, and bundling core into the application raises derivative-work questions for proprietary code. This needs legal review before adoption, especially if WordPress core is vendored or Composer-managed inside your application. Keeping WordPress behind a subdirectory or subdomain boundary can reduce exposure and preserve a reverse-proxy fallback.
- What are the alternatives to mukadi/wordpress-bundle for Laravel or Symfony?
- For Laravel, do not adopt this package; use Corcel for read-only Eloquent access to WordPress tables or go headless with the WordPress REST or GraphQL API and render in Laravel. For a Symfony app that must keep a WordPress admin experience alongside Symfony, this bundle is the closest fit but still needs a spike. Avoid it as a primary application architecture.
- Is mukadi/wordpress-bundle actively maintained and production-ready?
- Project health is a major concern: the evaluation cites 21 stars, 0 dependents, and no evidence of a maintenance cadence. That makes technical risk high, driven by project health rather than code alone. Pin versions, plan for a fork if the upstream author stops, and do not treat it as a production-ready primary architecture without a proven spike.
- How should I test or spike mukadi/wordpress-bundle before committing?
- Run a one-to-two-week spike in an isolated branch: install the bundle, boot a single WordPress-backed route, measure memory and latency, and prove the Symfony and WordPress authentication bridge. Migrate read-only pages and posts first, leave admin and plugins untouched, and audit every plugin and theme. Cut over behind a feature flag with a documented kill switch that disables WordPress routes without redeploying.