Weave Code
Xml Laravel Package
php-soap/xml
php-soap/xml is a lightweight XML library for PHP focused on SOAP. It offers namespace-aware parsing and generation so you can build, inspect, and transform SOAP envelopes and XML payloads through a small, predictable API. Designed for dependable XML handling in PHP applications.
XML wrapper for dealing with SOAP
Frequently asked questions about Xml
- How do I install php-soap/xml in a Laravel application?
- Install it with Composer using composer require php-soap/xml. The only real system requirement is the ext-dom extension, which is present on virtually every PHP image, and there are no native extensions to compile, credentials to configure, or network calls at install time. In most Laravel projects you should not require it directly at all: it normally arrives transitively through php-soap/engine and a PSR-18 transport, pinned in composer.lock.
- Does php-soap/xml support Laravel 10 and Laravel 11?
- The package is framework-agnostic and contains no Laravel service provider, facade, or config file, so it works in any Laravel version that runs a supported modern PHP release with ext-dom enabled. Compatibility is driven by the package's PHP version constraint rather than the Laravel major version. Check the package's composer.json and CI matrix for the exact PHP versions tested before upgrading your application.
- How does php-soap/xml handle XML namespaces?
- Namespace-aware parsing and element access are first-class features, which is precisely what makes the library practical for SOAP envelopes where the soap:Envelope and body elements live in different namespaces. Before relying on it in production, read the source or ask the maintainer whether elements are resolved by namespace URI or by literal prefix string, and how default namespaces are treated. Resolving by URI is the behaviour you want, because prefixes are arbitrary and can change between services.
- Is php-soap/xml safe against XXE and entity expansion attacks?
- XML parsing carries real risk from external entity injection, entity expansion, and namespace confusion, so the thing to audit is the wrapper's default libxml flag handling rather than any transport concern. Confirm in the source whether parsing defaults to safe flags such as LIBXML_NONET with entity substitution disabled, and whether that behaviour is configurable per parse call. If the defaults are not safe, wrap parsing in your own flag-passing layer before feeding untrusted responses into it.
- What is the difference between php-soap/xml and PHP's native SoapClient?
- SoapClient gives you WSDL-driven class mapping, __soapCall, and typed results for free; php-soap/xml gives you none of that because it is only a small, expressive wrapper around the DOM extension. It handles envelope construction, namespace-aware element access, and response traversal, leaving WSDL handling, HTTP, and typing to the surrounding php-soap engine and transport packages. Treat them as complementary layers rather than drop-in replacements.
- Can I use php-soap/xml to build SOAP request envelopes?
- Yes. The library ships fluent builders for creating XML structures, so you can construct SOAP envelopes and payload bodies without the usual DOM boilerplate. It is designed to sit beneath a client abstraction, which means your builders should be called from a dedicated SOAP client class rather than scattered through controllers or domain code. That keeps the XML detail in one place if you later swap the underlying implementation.
- Does php-soap/xml support XPath queries over XML documents?
- Yes, XPath querying over DOM documents is a supported feature, which is useful for pulling values out of deeply nested SOAP responses without hand-rolled traversal loops. Combine XPath with namespace-aware access when querying SOAP bodies, since default namespaces frequently trip up naive XPath expressions. Keep the query strings in your client or decoder layer so application code receives plain arrays or DTOs.
- Should php-soap/xml be a direct Composer dependency in my Laravel app?
- In most cases no. It belongs underneath a SOAP client abstraction, either the php-soap engine stack or your own client, and should arrive transitively and be pinned in composer.lock. If feature or domain code is importing this wrapper directly, the abstraction boundary is wrong and you will feel it the next time the package ships a major version. Require it directly only if you are deliberately building that abstraction layer yourself.
- Is php-soap/xml actively maintained and stable enough for production?
- The library is niche, with low star counts and effectively a single maintainer, though the wider php-soap organisation is competently engineered. Its small surface area means breaking changes are cheap to absorb, but also cheap to ship, so constrain it with caret ranges and a committed lockfile and verify release history and issue responsiveness. The mitigation for abandonment is strong: the MIT licence plus a few hundred lines of straightforward DOM code means a fork is measured in hours, not weeks.
- How should I test SOAP request and response handling built on php-soap/xml?
- Unit test your envelope builders and response parsers against fixture XML captured from the real service, asserting on the produced DOM or serialised string. Fake HTTP at the transport layer, for example with Laravel's Http::fake or a mocked PSR-18 client, so tests never touch a live SOAP endpoint. Add cases for fault responses, unexpected namespaces, and large payloads to cover the parts of the wrapper your integration actually depends on.
Weaver
How can I help you explore Laravel packages today?