- What is wa72/htmlpagedom and how is it different from Symfony Crawler?
- wa72/htmlpagedom is a Composer library that extends Symfony's DomCrawler with a jQuery-inspired API for traversing and manipulating HTML, not just reading it. Symfony Crawler gives you CSS-selector and XPath querying, while this package adds editing operations such as attribute changes, class toggling, element insertion, and serialization back to HTML. It handles both complete HTML documents and fragments through a DOMDocument-backed layer. Think of it as a small server-side DOM manipulation toolkit rather than a framework component.
- How do I install wa72/htmlpagedom in a Laravel application?
- Install it with Composer using composer require wa72/htmlpagedom and let Composer resolve the Symfony dom-crawler and css-selector dependencies it needs. There is nothing to register in config/app.php because the package ships no service provider or facade. Wrap it in your own service class, for example an HtmlDomTransformer, so controllers, jobs, and Blade templates never call the library directly. Then run composer why-not wa72/htmlpagedom to confirm it resolves cleanly against your Laravel and Symfony versions.
- Does wa72/htmlpagedom have a Laravel service provider or facade?
- No. It is a plain, framework-agnostic utility library with no service provider, facade, config file, publishable assets, or queue integration. That is normal for a DOM helper of this size and is not a red flag on its own. Treat it as an internal adapter-wrapped dependency and bind it into the container yourself if you want it injected. Keeping it behind an interface also makes it easy to swap for Symfony Crawler or raw DOMDocument later.
- Which PHP, Laravel, and Symfony versions does wa72/htmlpagedom support?
- The package declares its PHP and Symfony component constraints in its composer.json, so treat that file and the release history as the source of truth rather than blog posts. Before adopting it, verify the release you want supports the Symfony dom-crawler and css-selector majors that your Laravel version already pulls in. A quick dependency spike on a branch with composer require and composer why-not is the fastest way to confirm PHP 8.2 to 8.4 and Laravel 10 to 12 compatibility. Pin the package and the Symfony DOM components to tested majors to avoid surprise transitive upgrades.
- How do I select elements with CSS selectors and edit them jQuery style?
- You load markup into the package's crawler object and then chain jQuery-like calls on the matched set, using CSS selectors instead of XPath. Typical operations mirror jQuery: filter and traverse to children, parents, or siblings, read and write attributes, add or remove classes, replace or append HTML, and finally serialize the document back to a string. Because selection is powered by Symfony's CssSelector, the selector syntax you already use in tests and front-end code mostly carries over. Keep chains short and assert on serialized output, since DOM edits are easy to get subtly wrong.
- Can wa72/htmlpagedom handle full HTML pages as well as fragments?
- Yes, the library is designed for both complete pages and HTML snippets, which is why it wraps DOMDocument rather than only exposing a query interface. Fragments are the trickier case because libxml may add implied html and body elements or reorder content depending on the input. Always test with the exact shapes of markup you expect in production, including malformed or truncated HTML. If you need strict HTML5 parsing semantics rather than libxml behavior, compare output against a dedicated HTML5 parser before committing.
- Can I use wa72/htmlpagedom to scrape remote pages in Laravel?
- Yes, and the usual pattern is to fetch with Laravel's HTTP client and then hand the response body to the package for parsing and transformation. That keeps retries, timeouts, proxies, and authentication in Laravel's HTTP layer where they belong, and leaves the package doing only DOM work. Cache aggressively and respect robots.txt, rate limits, and target-site terms, because server-side scraping is a policy question before it is a technical one. Watch for unexpected encodings and compressed responses, since broken input produces confusing DOM results.
- Is wa72/htmlpagedom an HTML sanitizer for untrusted content?
- No. It is a DOM manipulation library, not a sanitizer, and it will happily preserve scripts, event handlers, and dangerous URLs that were already in the markup. If transformed HTML is rendered to users, run the output through a dedicated sanitizer such as HTML Purifier or a maintained allowlist-based library, and escape text through Blade as usual. Parsing untrusted HTML with libxml also carries resource-exhaustion risk, so cap input size and disable external entity loading. Never treat successful parsing as a security guarantee.
- How should I test and integrate wa72/htmlpagedom safely in a Laravel app?
- Start with one bounded, non-user-facing use case such as a queued content-normalization job or an internal command, and put the library behind a thin adapter interface. Add golden-file tests that capture representative input HTML and the exact expected serialized output, including malformed fragments and edge-case selectors. Check that ext-dom and libxml are present in CI and in production, and log parse failures instead of silently emitting empty output. Roll out behind a feature flag so you can fall back to Symfony Crawler or raw DOMDocument if output drifts.
- What are the alternatives if wa72/htmlpagedom is abandoned or conflicts with Symfony?
- The closest fallback is Symfony's DomCrawler combined with CssSelector, which covers querying and basic manipulation without the jQuery-style sugar. If you need richer editing helpers, masterminds/html5 paired with DOMDocument gives you HTML5-compliant parsing and avoids some libxml quirks. For simple templating, native DOMDocument methods may be enough and remove a dependency entirely. Keeping your own adapter interface means switching implementations is a one-class change rather than a refactor.