Ezfindsearchenginebundle Laravel Package

Product Decisions This Supports

• Search relevance and ranking work. The 1.4.0 EzFindText criterion changes what a "full-text search" means in this stack: instead of matching a single ezf_df_text field (the FullText criterion), it emulates legacy ezfind behaviour by searching across all indexed content fields. This directly affects relevancy ordering, which is a product-visible outcome, not just an implementation detail. Teams can now ship relevance improvements behind existing search entry points without re-platforming.
• Migration vs. parity decisions. If the roadmap includes moving off a legacy ezfind-based search (or keeping it alive while a replacement is built), EzFindText is the lever for behavioural parity. It lets you answer "does the new/legacy path return results in the same order for our top queries?" before committing to a cutover.
• Ranking strategy with explicit scoring. Paired with the Score sort clause, the release makes score-based ordering a first-class, configurable choice. That supports A/B tests and product experiments on result ordering (e.g. "does cross-field matching improve click-through on long-tail queries?").
• Query composition rules as a product constraint. The release notes carry a hard usage rule: EzFindText must be the sole member of the query's query, with any additional criteria moved into filter. For a PM this is a scoping decision — it means relevance tuning and filtering are deliberately separated, and it constrains how "search + facets" features can be combined. Any feature spec that assumes "just add another condition to the main query" needs revisiting.
• Build vs. buy. This is a narrow, glue-layer capability. Choosing it means buying/inheriting the legacy search semantics rather than reimplementing cross-field matching, scoring, and ezfind emulation in-house. The trade-off is coupling to a legacy engine's behaviour and its indexing model.
• Concrete use cases to slot into a backlog: long-tail and natural-language query handling, relevance tuning for content discovery pages, search result re-ordering, and parity testing ahead of a search migration.

When to Consider This Package

Consider it when:

• You are running (or maintaining) an eZ Publish / ezfind-era content platform on PHP and need a modern query API over the legacy search engine.
• Relevancy quality is a live product concern and current results are matched against a single text field, producing poor ordering for multi-word or long-tail queries.
• You need legacy ezfind search emulation — i.e. matching against all indexed content fields — as a compatibility target rather than a new design.
• You want score-based sorting without hand-rolling query construction, and your team is comfortable with the constraint that the relevance criterion owns the query slot while all other criteria live in filter.
• You are doing a migration or parallel-run and need like-for-like behaviour to validate a replacement.

Look elsewhere when:

• You are on a greenfield stack with no ezfind heritage — the value here is emulation of legacy semantics, which is a liability rather than an asset if you have nothing to emulate.
• Your roadmap depends on a modern search backend (vector/semantic search, managed search services); this package optimises the existing engine, it does not replace it.
• Your feature set requires freely composable query criteria on the primary query — the "unique member of query" rule is a structural constraint, not a toggle.
• You need vendor-supported, long-term-roadmap guarantees; this is community/legacy-adjacent tooling and should be treated as such in risk planning.
• Search is not a differentiated surface for your product — the relevance gains are real but narrow.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, low-risk release that improves search result quality on our existing content search without a platform change. It restores the cross-field matching behaviour users had under the legacy search engine and enables score-based ranking, which is the foundation for any future relevance tuning or search experimentation. It is a targeted capability, not a strategic bet — it buys us parity and a measurement baseline, and it should be framed as such rather than as a reason to defer a search re-platforming decision.

For engineering: Release 1.4.0 adds an EzFindText query criterion that performs a full-text search across all indexed content fields, emulating legacy ezfind search, in contrast to FullText, which only matches ezf_df_text. Combined with the Score sort clause (descending), this materially improves relevancy ordering. Integration contract to design around: EzFindText must be the only criterion in $query->query; every other criterion belongs in $query->filter. That means our query-building layer needs to enforce this split explicitly — please treat it as an invariant, add tests for it, and audit existing query construction for places that would silently break or degrade if criteria are mixed. Low migration cost: additive API, no breaking changes or deprecations noted in this release.