Ezsolrsearchextrabundle Laravel Package

Getting Started

First, the context shift. This is not a Laravel package. It is a Symfony bundle for eZ Platform / Ibexa (the ezsystems/ezplatform-solr-search-engine world). If you are coming from Laravel, map it like this:

Minimal install

1. Confirm the base Solr engine already works before touching this bundle. composer require ezsystems/ezplatform-solr-search-engine, point ez_search_engine_solr at a running Solr with the shipped configset, and run a reindex. If vanilla search is broken, this bundle will only confuse the diagnosis.
2. composer require novactive/ezsolrsearchextrabundle.
3. Register Novactive\Bundle\eZSolrSearchExtraBundle\NovaeZSolrSearchExtraBundle in your kernel/bundles list.
4. bin/console cache:clear.
5. Run a reindex (see below) — the schema/index changes need fresh documents.

Where to look first

• doc/file_indexation.md — binary/plain-text indexing into the fulltext field.
• doc/fulltext_criterion.md — the extended FullText criterion (multi-field boost, publish-date boost, phrase boost, exact-match boost). This is the file 90% of your day-to-day use comes from.
• Resources/config/ — service definitions and DI aliases; this is where you find extension points and what the bundle actually decorates.
• composer.json — the eZ Platform version constraint. Match it to your install before anything else.

First use case (30 minutes): take an existing content search that uses the stock FullText criterion and swap it for the bundle's extended criterion so title outranks body, with a mild recency boost. One criterion, no schema changes if the fields are already indexed. That gives you an immediate relevance win and validates the bundle is wired up.

Reindex, once, so you have a baseline:

bin/console ezplatform:solr:index --no-interaction   # or ibexa:reindex, depending on version

Implementation Patterns

Pattern 1 — Boost profiles in configuration, not in code. The most common real-world need is "marketing wants titles to weigh more." Hardcoding the boost map into a controller means a deploy every time they change their mind. Load boasweights from a parameter:

parameters:
    search.boost.title: 3.0
    search.boost.body: 1.0
    search.boost.recency: 0.5

Then inject them into your search service and build the criterion once, in one place. Keep a single ContentSearchFactory that owns the criterion construction; never assemble it ad hoc in controllers.

Pattern 2 — Wrap SearchService, don't call it directly. Every controller and repository that injects SearchService directly will eventually need the same pagination, the same score handling, the same fallback when a criterion option is unsupported. One App\Search\ContentSearcher with search(SearchQuery $q): SearchResult keeps it consistent and gives you one place to log the generated Solr query.

Pattern 3 — Extended FullText criterion, shaped like this:

use eZ\Publish\API\Repository\Values\Content\Query;
use Novactive\Bundle\eZSolrSearchExtraBundle\...\Criterion\FullText; // confirm FQCN in doc/

$query = new Query();
$query->query = new FullText(
    $userInput,
    [
        // option keys below are illustrative — the authoritative list is
        // doc/fulltext_criterion.md in the installed version
        'boost'           => ['title' => 3.0, 'body' => 1.0],
        'boostPublishDate' => 0.5,
        'boostPhrase'     => 2.0,
        'boostExact'      => 4.0,
    ]
);

Verify the option names against the doc shipped with your installed version — these bundles rename keys between minor releases, and an unrecognized key typically fails silently rather than throwing.

Pattern 4 — File text indexation. Enable it only where you need it. The pattern is: the bundle maps binary file content's extracted text into the fulltext field, which means Solr must actually have a text extractor available (Tika or the Solr extract handler, depending on your Solr version and configset). Workflow:

1. Configure the file indexation per doc/file_indexation.md.
2. Restart/reload the Solr core so the schema/field definitions apply.
3. Reindex and spot-check a known PDF: bin/console reindex one Content ID rather than the whole tree if your version supports it.
4. Search for a phrase you know is only inside the PDF, not in the metadata.

Pattern 5 — Versioned reindexing with core swap. For anything beyond a dev box: index into a new core, verify document counts and a handful of queries, then repoint the alias. This bundle's changes touch indexing, so a partial in-place reindex can leave you with a mixed index that returns inconsistent relevance and is miserable to debug.

Pattern 6 — Integration test against a real Solr. Unit-testing the criterion object only proves it serializes. Spin Solr up in CI (Docker, with the eZ configset), index a small fixture set, and assert ordering: "searching 'foo' returns the exact-title hit first." Relevance assertions are the only tests that catch boost regressions.

Gotchas and Tips

• This is a subtree split. The repo you're looking at is a read-only copy. Issues and PRs must go to https://github.com/Novactive/Nova-eZPlatform-Bundles. Don't file against the split repo, and don't expect fixes here.
• 1 star, 0 dependents → treat it as vendored code. Pin an exact version, and assume you may need to fork. Read the classes you depend on rather than trusting the README; it is short and the docs are the real spec.
• License is NOASSERTION. Open the LICENSE file and get sign-off before shipping this in a commercial product. Packagist not being able to classify it is a red flag worth resolving early, not at release time.
• Extended criterion fails quietly. If a boost field isn't in the Solr schema, or a boost option name is misspelled, you often get results with no boost rather than an exception. Symptom: "the boost has no effect." Check the field name in the Solr admin schema browser, then check the option key against the doc.
• Publish-date boost needs a real date field. It relies on a date-typed Solr field populated at index time. If your content's publish date isn't being indexed in the expected representation (timezone offsets, missing values), recency boosting degrades to noise. Verify with a *:* query sorted/faceted on that field.
• Schema changes require a reload + reindex, always. Adding file text or a new boost field without reindexing leaves the old documents empty in that field. Half your corpus silently scoring zero for that field is a classic "why is search weird" bug.
• File text indexation inflates the index fast. Exclude irrelevant MIME types, watch the Solr extract handler's maxStringLength/field size limits, and note that extracted text is not free at query time either. Monitor core size after rollout.
• Debugging the actual query. Turn on Solr request logging or inspect the Solr admin's query log while reproducing, and enable the search engine's logging in config. The PHP-side criterion often looks correct while the serialized Solr query differs. If you have a ?debug=1-style flag in your install, use it; otherwise log from your wrapper service.
• Cache clear is not optional after config edits. Changing bundle config or boost parameters without cache:clear is the #1 source of "my change did nothing."
• Extension points to look for in Resources/config/: the decorated search handler / criterion visitors (to add your own criterion type), and field mappers (to index custom fields into the fulltext field). Decorate rather than patch — the subtree split means your patch has no upstream home.
• Don't reach for this bundle for non-fulltext needs. Facets, filters, and sorting are vanilla eZ Solr. Keep the extended criterion confined to your relevance path so an upstream break only affects relevance, not all search.
• Version compatibility matrix bites. eZ Platform 2.x vs 3.x vs Ibexa 4 have different bundle registration, different reindex command names, and different criterion namespaces. Check composer.json constraints against your install before debugging anything else.