Wordpress Interop Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package. Before you reach for it, know where the boundary is: if your app is Laravel-only, you cannot composer require this and get a Laravel service provider out of it. You either (a) work in a Symfony app, or (b) use the underlying williarin/wordpress-interop library directly and wire it into Laravel manually. The assessment below covers both angles, with the Symfony path as the primary.

Minimal steps (Symfony host):

1. composer require williarin/wordpress-interop-bundle:^1.3
2. Register the bundle in config/bundles.php (Symfony Flex usually does this automatically).
3. Publish/author the config — typically config/packages/wordpress_interop.yaml — pointing at your WordPress root (the directory containing wp-load.php), plus DB/environment settings.
4. First use case: boot WordPress from a Symfony console command or controller and call core WP functions (get_posts(), wp_insert_post(), etc.) against the same database, or hand Symfony services to a WP hook.

Where to look first: the package README, the bundle's DependencyInjection/Configuration.php (that is the authoritative config reference — far more reliable than prose docs), and the service definitions in Resources/config/services.php.

Version 1.3.0 itself is a compatibility release: Symfony 7 support. There are no new APIs, no deprecations, and no breaking changes called out. Treat it as a drop-in upgrade if you are already on 1.2.0.

Implementation Patterns

Boot-on-demand, not boot-on-every-request. WordPress is heavy and defines hundreds of global functions. The practical pattern is to boot it only in the code paths that need it — a console command, a queue worker, a specific controller — rather than on every HTTP request. Keep a thin wrapper service around the boot so it is lazy and testable.

Bridge services both ways. The value of an interop bundle is bidirectional:

• Symfony → WordPress: inject repositories/services into WP actions and filters (e.g. sync a post to an Eloquent/Doctrine model on save_post).
• WordPress → Symfony: call WP APIs from Symfony commands for data migration, cron replacement, or back-office tooling.

Use console commands as the primary integration surface. WP-CLI-style batch jobs (import, sync, recalculate) are far easier to reason about than request-time bridging, and they sidestep the global-state problems described below.

Configure per environment. Keep the WordPress path and DB config in environment-specific config files. Local, staging, and production almost never share the same ABSPATH, and hardcoding it is the fastest way to a broken deploy.

Incremental migration. The realistic use case is not "replace WordPress"; it's "wrap an existing WordPress install and move features into Symfony one at a time." Design the boot layer so legacy WP code and new Symfony code can coexist behind a feature flag.

Laravel-specific bridging. If you are on Laravel, do not attempt to register a Symfony bundle in the Laravel container. Instead, wrap the underlying interop library in a small service provider, register it as a singleton, and defer booting until first resolution. This keeps WordPress out of the bootstrap path and preserves Laravel's request lifecycle.

Gotchas and Tips

Global function collisions. WordPress defines global functions and constants (get_posts, $wpdb, ABSPATH, etc.). Only one WordPress install can be booted per PHP process, and collisions with similarly named helpers in your app are real. Namespace your own code carefully and avoid booting WordPress in long-running processes you cannot restart.

Load order and constants. ABSPATH, WP_USE_THEMES, and WP_DEBUG must be defined before the WP bootstrap runs. If a function is "undefined" at call time, it is almost always a boot-order problem, not a missing dependency.

Shared database, conflicting prefixes. The bundle typically reuses the host app's DB connection. Verify the WordPress table prefix (wp_) does not collide with your app's tables, and be explicit about which connection WordPress uses — mixing Doctrine/Eloquent transactions with WP writes is a common source of silent data drift.

Compiled container and cache. After upgrading to 1.3.0, clear the Symfony cache (bin/console cache:clear). If your app pins other bundles that still constrain Symfony to 6.x, Composer will refuse the upgrade — check composer why-not symfony/framework-bundle 7 before assuming the bundle is at fault.

Symfony 7 upgrade caveat. 1.3.0 adds Symfony 7 compatibility, but it does not remove support for older versions. Do not treat the version bump as a signal to upgrade Symfony itself; the constraint widening is orthogonal. Test on your actual Symfony version.

Testing. WordPress needs a database. Point tests at a dedicated WP test database, and prefer booting WP in a setUpBeforeClass rather than per test. WP's global state does not reset cleanly between tests.

Debugging. The Symfony profiler will not see inside WordPress. Use WP_DEBUG, WP_DEBUG_LOG, and the WP error log for that half of the stack; use the profiler for the Symfony half. When something fails silently, check the WP debug log before the Symfony log.

Extension points. The bundle's DI layer (service aliases, compiler passes) is where you customize behavior — decorate the interop service, add a compiler pass to tag WP-aware services, or override the config tree. There is no event system exposed by the bundle itself; the natural extension surface is Symfony's container and the WP hook system.