- Can I use seven/symfony-rpc-bundle in a Laravel application?
- No, not directly. It is a Symfony bundle built around Symfony 2.x kernel container wiring, and it has no Laravel ServiceProvider, facade, publishable config, or illuminate/* constraints. In Laravel you should re-implement the dispatch and fault-mapping pattern rather than install the package.
- Does seven/symfony-rpc-bundle support Laravel 10, 11, or 12?
- No. The bundle targets Symfony 2.x and relies on symfony/xmlrpc, which was deprecated in Symfony 2.8 and removed in Symfony 3.0. Modern Laravel 10-12 applications on PHP 8.x will generally fail Composer resolution on transitive constraints. It also uses PHP 5.x idioms without strict types or return types.
- How do I install seven/symfony-rpc-bundle with Composer?
- The nominal command is composer require seven/symfony-rpc-bundle, but installing it into a modern Laravel app is not recommended. Composer will likely fail on legacy Symfony and PHP constraints, and even a successful install would not wire into Laravel's container. Treat the repository as a reference implementation and vendor nothing.
- What PHP versions does seven/symfony-rpc-bundle support?
- The code targets PHP 5.x-era idioms and the Symfony 2.x stack, with the last release in 2014. It has not been updated for PHP 7 or PHP 8 strict types, return types, or modern libxml behavior. Assume it is not PHP 8 compatible without a fork.
- Is seven/symfony-rpc-bundle maintained and safe for production?
- No. It has been unmaintained for roughly 11 years, with the last release on 2014-10-25, and there is no CVE response path or security triage. XML-RPC parsers handle untrusted XML and are prone to XXE, billion laughs entity expansion, and type-coercion issues. An abandoned parser is a standing security-review finding.
- What are the best alternatives to seven/symfony-rpc-bundle for XML-RPC in Laravel?
- If XML-RPC is contractually required, build a Laravel-native endpoint with a POST /rpc route, middleware for auth, IP allowlisting and content-length caps, an XmlRpcRequestParser, a MethodRegistry mapping method names to invokable classes, typed response serialization, and XML-RPC fault envelopes. Evaluate maintained Laravel XML-RPC packages where available. If no external counterparty mandates XML-RPC, use REST/JSON or GraphQL instead.
- How do I build an XML-RPC server in Laravel without this bundle?
- Implement a single Laravel route, such as POST /rpc, behind middleware for authentication, IP allowlisting, and payload size limits. Map method names to invokable service classes through a registry, serialize typed responses, and return XML-RPC fault envelopes on exceptions. Use a hardened XML loader with LIBXML_NONET, disabled entity substitution, no LIBXML_NOENT, and explicit depth and size limits.
- Does seven/symfony-rpc-bundle support system.multicall and XML-RPC introspection?
- The bundle's core purpose is container wiring for an XML-RPC server in Symfony 2.x, and introspection (system.listMethods, system.methodSignature) and multicall (system.multicall) are compatibility questions to verify in the source. Do not assume they are implemented. If clients such as Odoo or WordPress require them, implement them explicitly in your Laravel registry and add contract tests.
- What security risks should I consider with XML-RPC in Laravel?
- XML-RPC is attack-surface-heavy: XXE and external entity injection, entity-expansion billion laughs denial of service, and type-coercion ambiguities in value element parsing. Mitigate with a hardened XML loader, LIBXML_NONET, disabled entity substitution, no LIBXML_NOENT, and explicit depth and size limits. Add authentication, IP allowlisting, content-length caps, and malformed-payload tests. Avoid XML-RPC unless a named external counterparty requires it.
- When should I use XML-RPC instead of REST or JSON in a Laravel app?
- Use XML-RPC only when an external counterparty mandates it, such as Odoo, WordPress, some ERP or POS systems, provisioning agents, or Supervisord-style control planes. It is a legacy protocol and a poor default for greenfield internal services. If the requirement is only an internal architectural preference, stop and use REST/JSON or GraphQL.