- Does goutte/wordpress-bundle work with Laravel?
- No. Despite being listed alongside PHP packages, goutte/wordpress-bundle is a Symfony2 bundle: it ships a Bundle subclass, a DI extension, and XML/YAML service definitions bound to the Symfony 2.x container. There is no service provider, no package auto-discovery, and no publishable config, so the normal Laravel install story does not exist. Getting it to boot inside Laravel would require a fork plus --ignore-platform-reqs. Treat it as a reference implementation you read, not a dependency you install.
- How do I install goutte/wordpress-bundle and what are the Composer requirements?
- You add goutte/wordpress-bundle with Composer inside a Symfony 2.x application, register the bundle in AppKernel, and configure it under the bundle key in config.yml. It also pulls in the Goutte scraper and pins Symfony framework packages to the 2.3–2.8 range. In a modern Laravel app those constraints collide with the symfony/* ^6 or ^7 components Laravel pulls transitively, so installation fails without ignoring platform requirements.
- Which Symfony and PHP versions does goutte/wordpress-bundle support?
- It targets the Symfony 2.x era, with Composer constraints around symfony/symfony and symfony/framework-bundle in the ~2.3 to ~2.8 range. Symfony 2.8 reached end of life in November 2018, so the bundle cannot receive security or compatibility fixes even if a maintainer wanted to write them. Plan for an old PHP runtime if you evaluate it at all.
- What can goutte/wordpress-bundle actually do — what WordPress data can I read?
- It boots a WordPress install from inside a Symfony kernel and exposes repositories for Posts, Pages, and Attachments, giving read-oriented access over wp_posts, wp_postmeta, and wp_term_relationships. That is the whole scope. It is not a content API, not an authentication bridge, and not a sync engine, and the package documentation is honest about that boundary.
- Is goutte/wordpress-bundle still maintained?
- Effectively no. It has roughly 15 stars, zero dependents, no issue traffic, and no downstream consumers providing production signal. The foundation it depends on is end of life, so compatibility and security fixes are not coming. The moment you adopt it, you are the maintainer.
- Is goutte/wordpress-bundle safe to use in production?
- Technical risk is high on every axis that matters to a delivery plan. Reading WordPress tables directly promotes WordPress internal schema to a de facto public API, which means post_type and post_status semantics, post_date versus post_date_gmt, serialized postmeta, attachment GUID drift, and table-prefix assumptions all become your problem. Any plugin that adds custom post types or meta changes the data your repositories must interpret, and the bundle predates the block editor entirely. It is acceptable for a read-only prototype, not for a funded delivery.
- What are the best alternatives to goutte/wordpress-bundle for Laravel?
- The default should be the WP REST API or WPGraphQL over HTTP, which decouples Laravel from the WordPress schema, survives WordPress upgrades, and gives you caching, rate limiting, and auth at a boundary you own. If direct database access is mandated for latency or plugin reasons, use Corcel, which is Laravel-native, actively maintained, and provides Eloquent models over WordPress tables including postmeta and taxonomies. Porting this bundle's repositories into a small internal module is a distant third, justified only when both other options are ruled out for concrete reasons.
- Can goutte/wordpress-bundle handle WordPress login and session handling?
- It includes Goutte-based helpers that authenticate against the WordPress login form and keep cookies in a scraper session so you can reach authenticated pages. That is scraper plumbing, not an auth bridge: it does not map WordPress users onto Symfony or Laravel users, and it does not provide tokens or session sharing. It is also fragile against two-factor plugins, security plugins, and login page changes.
- Does goutte/wordpress-bundle support custom post types, ACF fields, taxonomies, or WooCommerce?
- No. It is scoped to core Posts, Pages, and Attachments and assumes core schema with a default table prefix. Custom post types, Advanced Custom Fields with serialized postmeta, additional taxonomies, and WooCommerce tables are not modeled, and any plugin that mutates the schema changes what the repositories return. Budget custom query work if your content model goes beyond core posts and pages.
- How do I migrate goutte/wordpress-bundle code into a Laravel application?
- Do not install it — read the three repository classes and reimplement that logic as a small internal WordPressReader module, budgeting the work as new code that happens to have a reference rather than as integration work. Before porting anything, confirm whether the requirement is read-only access or write-back (this bundle only credibly serves read-only), and confirm the WordPress version, table prefix, and multisite topology in production. Validate post_type and post_status semantics, post_date versus post_date_gmt, serialized postmeta, and attachment GUID drift against real data. In most cases replacing it with Corcel or an HTTP API boundary is cheaper than porting.