- Does atoolo/crawler-teaser-indexer work with Laravel?
- It is a Symfony bundle, not a native Laravel package, so it does not ship a service provider or Artisan commands out of the box. In practice you can reuse the crawling logic through Laravel's HTTP client or Symfony's DomCrawler, register the crawler and indexer in Laravel's IoC container, and wrap the scheduling command in an Artisan command. The 2.0.0 release makes this easier because indexing is now delegated to the atoolo/index-bundle contract instead of hard-coded Solr client logic. Expect to build a thin integration layer rather than install and go.
- How do I install atoolo/crawler-teaser-indexer?
- Install it with Composer using composer require atoolo/crawler-teaser-indexer, which requires PHP 8.2, 8.3 or 8.4. In a Symfony application you then register the bundle in your bundle configuration and supply the PHP array describing the data the crawler must extract. In Laravel you would not enable it as a Symfony bundle, but instead bind the crawler services and the index-bundle contract in a service provider and expose the scheduling command as an Artisan wrapper.
- Which PHP and Symfony versions are supported?
- The README badges list PHP 8.2, PHP 8.3 and PHP 8.4, and the codebase is statically analysed at PHPStan level 9. Because it is a Symfony bundle, you should verify the Symfony component constraints in the package's composer.json against your own Symfony or Laravel skeleton before adopting it. Laravel projects running on PHP 8.2 or newer can use the underlying crawling components even without the Symfony bundle wiring.
- Is Apache Solr still a hard requirement for this teaser indexer?
- Solr was the original and is still the default target, since the bundle's purpose is making crawled teasers discoverable through website search. However, version 2.0.0 moves indexing behind atoolo/index-bundle, so the crawler layer now depends on an indexer contract rather than a bundled Solr client. That means any conforming backend, including a Laravel Scout or Elasticsearch implementation, is architecturally acceptable. Solr remains the reference implementation, so test conformance carefully if you swap it out.
- What is atoolo/index-bundle and can I implement it with Laravel Scout or Algolia?
- atoolo/index-bundle is the indexing abstraction introduced in the 2.0.0 release; it exposes the contract the crawler uses to write teaser documents to a search backend. Implementing that interface against Laravel Scout, Algolia or Elasticsearch is the recommended route for Laravel teams, because it avoids reimplementing or forking Solr integration code. Before committing, review the exact interface in isolation to confirm it can be satisfied without depending on Solr-specific types. This dependency is an opportunity as much as a risk, since it decouples crawling from the search engine.
- What data can the crawler extract into a teaser?
- The crawler extracts the Title, Introtext, Date and DateTime from external sources and indexes them as teasers. You describe what to pull with a PHP array that the crawler consumes, typically mapping fields to selectors against the fetched markup. Those extracted fields are what become searchable through your website's search function once indexed. If your teasers need extra attributes, plan to extend the extraction mapping rather than expect them out of the box.
- How do I configure the crawler's source URLs and CSS selectors?
- Configuration is driven by a PHP array that tells the crawler which data to extract, combined with the bundle's Symfony configuration for the crawler and indexer services. In a Laravel integration you would typically map this to config/crawler.php plus environment variables, and keep index-related settings in a separate config/index.php because 2.0.0 splits indexing into the index-bundle namespace. For selector parsing, Symfony's CssSelector component remains the pragmatic choice since it handles real-world selector syntax better than lightweight alternatives.
- How do I run and schedule the crawler in a Laravel application?
- The bundle provides a scheduling command, which was refactored in 2.0.0, so the command signature, options and exit codes changed from 1.x. In Laravel you would derive an Artisan wrapper from the 2.0.0 source rather than porting a wrapper built against 1.x, then register it in the scheduler. If you need immediate indexing, the URL discovery, extraction, scoring and indexing flow also maps cleanly onto Laravel events and queued jobs. Pin 1.x until you have diffed the 2.0.0 command surface.
- What changed in version 2.0.0 and is there an upgrade guide?
- Version 2.0.0 is a breaking release: indexing moved behind atoolo/index-bundle, and the scheduling command was refactored, so command signatures and configuration ownership shifted. No deprecation notices were published alongside the bump, so you must diff the public command and configuration surface yourself against 1.x. Development tooling also changed from phpcs to php-cs-fixer and from phive to Composer-based phplint, which signals further minor churn in CI conventions. Treat any existing wrapper as invalid until re-verified against 2.0.0.
- How do I test the crawler and indexer, and is the package production ready?
- The project publishes Codecov coverage and passes PHPStan level 9, so the codebase has meaningful static analysis and test tooling behind it. For your own tests, bind a fake implementation of the atoolo/index-bundle contract in the container so indexing assertions never touch a live Solr instance, and use Laravel's HTTP client fakes to avoid hitting real external sites. Keep retry logic with exponential backoff at the HTTP layer so flaky sources do not fail an entire crawl run. Because the toolchain is still settling, align your contributor documentation and pin versions before relying on it in production.