- What is php-soap/wsdl-reader used for?
- It is a pure PHP library that parses a WSDL document into a structured object model covering services, ports, bindings, port types, operations, messages and schema types. Instead of walking raw XML by hand, your code can inspect a SOAP contract as plain PHP objects. It is deliberately narrow infrastructure used by SOAP clients, code generators, validators and internal tooling rather than a product feature on its own.
- Does php-soap/wsdl-reader work in a Laravel application?
- Yes, but it is framework-agnostic: there is no service provider, no config file and no runtime hooks. In a Laravel codebase it usually arrives transitively through the php-soap driver or engine stack rather than being installed deliberately. That means your app may already depend on it without an explicit decision, so check your composer.lock and see which integrations rely on its WSDL interpretation.
- How do I install php-soap/wsdl-reader and what are its requirements?
- Install it with composer require php-soap/wsdl-reader, though in many projects it is already pulled in as a transitive dependency of the php-soap stack. Requirements are ordinary: ext-dom, ext-libxml and a supported PHP version, all of which any SOAP runtime already implies. There is no application code to write, no migration and no configuration step.
- Is version 0.34.0 a breaking change for my SOAP integration?
- The API is compatible, but the release contains two semantic correctness fixes for XML namespace resolution of attribute ref declarations: ref-declared attributes are now reported as qualified, and refs into a no-namespace schema are now reported as unqualified. For contracts that use attribute ref, the serialized request bodies your code produces will differ from 0.33.0. The change is a correction, but a partner system may have been coded against the previous, incorrect output, so treat it as a behaviour change worth verifying.
- How do I check whether my WSDL files use attribute ref?
- Inspect each WSDL in your corpus for attribute elements that use ref, including refs pointing into a schema with no target namespace. This single fact decides whether 0.34.0 is a no-op for you or a behavioural change. If none of your contracts use attribute ref, the namespace fixes are unlikely to alter your outgoing envelopes.
- Should I pin php-soap/wsdl-reader or use a caret constraint?
- Pin explicitly to ~0.34.0 rather than floating on ^0.33. The package is pre-1.0, so minor releases carry no contractual stability guarantee even when method signatures stay the same. Pinning keeps an upgrade of this component an attributable, reviewable decision instead of a silent drift inside a routine composer update.
- How should I test a php-soap/wsdl-reader upgrade before deploying?
- Upgrade in a branch and run your existing SOAP integration suite as a baseline. Then add a contract-level check: capture the serialized requests for each WSDL in your corpus before and after the upgrade and diff them, reviewing any difference against partner expectations. Also invalidate and regenerate any cached WSDL metadata or generated client code as part of the same deploy, and keep the change isolated so a rollback is a simple lock-file revert.
- Does php-soap/wsdl-reader cache parsed WSDL metadata or generate client code?
- No. It only reads and models the WSDL; caching parsed metadata and generating proxies or clients are decisions made by the consuming code. That matters during upgrades, because stale cached semantics or pre-generated proxies can keep the old, incorrect namespace behaviour alive even after the library is updated. Plan cache and code-generation invalidation into the same deploy as the version bump.
- What are the alternatives to php-soap/wsdl-reader?
- If you only need to call a SOAP service, PHP's native ext-soap SoapClient in WSDL mode is often sufficient and needs no extra package. wsdl-reader earns its place when you need to inspect or manipulate the contract itself, for example code generation, validation or internal tooling. Alternatives in this niche are limited, and most PHP SOAP stacks pair with the php-soap ecosystem rather than replacing it.
- Is php-soap/wsdl-reader actively maintained and safe for production?
- It is small, focused and low risk in terms of blast radius, but diagnostics can be expensive when something goes wrong. The community footprint is small, with a low star count and few listed dependents, which implies a concentrated maintainer bus factor worth recording as a standing dependency risk. Confirm whether symfony/var-dumper is runtime or dev-only in your resolved graph; if it is dev-only, production exposure is effectively nil.