- How do I install j0k3r/php-readability in a Laravel application?
- Install it with Composer using composer require j0k3r/php-readability. There is no service provider, facade, or config file, because it is a framework-agnostic library rather than a Laravel package. You register it yourself by wrapping the Readability class in your own service class under app/Services and binding that wrapper to an interface in a service provider.
- Which PHP and Laravel versions does php-readability support?
- The 1.x line targets broad PHP support and is still receiving backports, while 2.x requires PHP 7.4 or higher. The library itself has no Laravel dependency, so your Laravel version is only constrained by the PHP floor you choose. Pin a branch explicitly and check that your PHP floor matches across local, CI, and production runtimes.
- How do I extract an article title and content with php-readability?
- Create a new Readability instance with the HTML string and its source URL, call init(), then read getTitle()->textContent and getContent()->textContent. If init() returns false, no content was found and you should run your fallback path. Note that in 2.x the loadHtml() call moved from the constructor into init(), so older snippets copied from blog posts may behave differently.
- Do I need the Tidy extension to use php-readability?
- Tidy is suggested by Composer but not required. The library falls back to libxml when ext-tidy is missing, but the README explicitly recommends installing Tidy if parsing fails, so the fallback is not a clean equivalent. You can also force the libxml parser by passing 'libxml' and false to the constructor. If any target environment lacks Tidy, extraction quality becomes environment-dependent.
- How do I log Readability extraction issues with Monolog or another PSR-3 logger?
- Call setLogger() on the Readability instance and pass any Psr\Log\LoggerInterface implementation, such as a Monolog logger. This is useful for debugging why a specific page failed to extract its main content. In Laravel you can inject the framework's logger into your wrapper service and hand it to the library.
- Is it safe to pass user-supplied URLs to php-readability?
- The library does not fetch anything; it only parses HTML you already have, so SSRF risk lives entirely in whatever HTTP client you use to retrieve pages. If you fetch arbitrary user URLs, add URL validation, block private IP ranges, and enforce timeouts and response size limits. Extracted output is raw HTML, so you must sanitize it before rendering to avoid stored XSS, and rewrite relative URLs if you keep images and links.
- Should php-readability run in a queue instead of the request cycle?
- Extraction is CPU- and memory-bound because it builds a DOMDocument via libxml, so it is a queue-shaped workload rather than a request-path one. Running it inline risks slow responses and memory exhaustion on large or adversarial HTML. A fetch, extract, sanitize, store pipeline with a queue and a cache in front is the safer pattern for any real content volume.
- What is the difference between php-readability 1.x and 2.x?
- The 1.x line has wider PHP compatibility and is still maintained with backports, while 2.x requires PHP 7.4 or higher and aligns its API more closely with mozilla/readability. The main behavioral break is that loadHtml() moved out of the constructor into init(). Choose a branch based on your PHP floor and pin it in composer.json.
- What should I do when php-readability init() returns false?
- A false return means the heuristic engine could not identify a main article, which is expected on some pages because extraction quality varies by site. Decide up front between falling back to a truncated summary, storing the full page, or returning a hard error to the caller. Because there is no accuracy SLA, log failures through the PSR-3 logger and track the failure rate so you can tune or replace the extractor.
- Is j0k3r/php-readability actively maintained, and what are the alternatives?
- It is a maintained fork of an unmaintained Bitbucket lineage, stewarded by a small number of contributors, so bus factor is the main long-term concern rather than code quality. Releases are heuristic fixes to a hard-to-read codebase, and there is no published security policy or documentation site. Because the API is a single class, it is easy to abstract behind an interface and swap for a Node worker running @mozilla/readability or a hosted extraction API if maintenance stalls.