- Can I use iloh/simple-html-dom-bundle in a Laravel application?
- Not in any meaningful way. The package is a Symfony bundle: a DI extension plus a thin service wrapper with no Laravel service provider, facade, publishable config, or package auto-discovery. You could technically require it, but you would be pulling in Symfony wiring you cannot use. In Laravel, bind your own adapter or use symfony/dom-crawler with symfony/css-selector instead.
- Does this package support Laravel 10 or 11 with package auto-discovery?
- No. There is no Laravel service provider and no extra.laravel block in composer.json, so auto-discovery will register nothing. The bundle targets Symfony applications and their bundle registration flow. For Laravel you should use a maintained parser behind your own service provider.
- What does this bundle actually add beyond the simple_html_dom library?
- Only container registration and a thin service wrapper around the upstream parser. There is no caching layer, no configuration model, no error translation, and no retry logic described. All real parsing and traversal behavior lives in the unmaintained upstream library. If you are not in a legacy Symfony app that already resolves it, the bundle adds a dependency hop without adding capability.
- How do I install and register iloh/simple-html-dom-bundle in a Symfony app?
- Install it with Composer, then enable the bundle in your Symfony bundle configuration so the DI extension is loaded. After that you can autowire or fetch the parser service in controllers, commands, and other services instead of including the library manually. This is the one scenario where the bundle is genuinely useful: an existing Symfony application.
- Is the simple_html_dom library compatible with PHP 8.x?
- It is a SourceForge-era library with known friction on modern PHP, including dynamic property deprecations, nullable-string patterns, and Composer constraint conflicts. Memory growth on large or deeply nested documents is also a common complaint. If you need the exact find() API, use the maintained voku/simple_html_dom fork; otherwise prefer symfony/dom-crawler or PHP 8.4's native \Dom\HTMLDocument.
- What are the Laravel-friendly alternatives for jQuery-style HTML parsing?
- symfony/dom-crawler with symfony/css-selector gives you CSS-selector traversal and is maintained, PHP 8 clean, and often already present as a transitive dependency. masterminds/html5 is a good choice when HTML5-tolerant recovery of malformed markup matters. For simpler cases, native DOMDocument or PHP 8.4's \Dom\HTMLDocument is enough, and voku/simple_html_dom covers the find() ergonomics specifically.
- Is iloh/simple-html-dom-bundle safe to use in production?
- The risk profile is poor: a single maintainer, effectively no dependents, no visible CI, no release cadence, and no security disclosure process. Because it wraps an abandoned library, you inherit that library's known PHP 8 and memory issues plus a second trust hop with no audit trail. Adding it to a production Laravel codebase is strictly worse than depending on a maintained parser behind your own interface.
- How do I scrape third-party HTML with malformed markup in Laravel?
- Define a small internal contract such as HtmlExtractor in your app namespace and back it with symfony/dom-crawler plus symfony/css-selector for selector ergonomics. If HTML5 recovery of broken markup is the priority, use masterminds/html5 as the parser behind the same contract. Keeping the abstraction in your own code means you can swap primitives later without touching call sites.
- Can I inject the HTML parser as a service instead of using global helper functions?
- Yes, that is precisely what this bundle provides inside Symfony: the parser is exposed through the DI container, so you can autowire it into controllers, commands, and services rather than relying on global functions and manual includes. In Laravel you would achieve the same result by writing a short service provider that binds an adapter to a constructor-injected interface. The abstraction is the durable asset, not the package that happens to provide it.
- Does this package handle JavaScript-rendered content when scraping?
- No. Any server-side HTML parser, including simple_html_dom, only sees the initial response body and cannot execute JavaScript. If the target content is rendered client-side, the correct tool is a headless browser such as Browsershot, Laravel Dusk, or Symfony Panther. Choose the parser only after confirming the markup you need is present in the raw HTTP response.