Meiliscout Laravel Package

Technical Evaluation

Architecture fit

• Premise correction, and it is decisive. The 2.5.0 surface is unambiguously WordPress, not Laravel: meiliscout_register_suggest() / meiliscout_suggest() global functions, wp meiliscout check-suggest (WP-CLI), a "MeiliScout › Suggestions" admin screen, a Gutenberg "Search with suggestions" block with a Suggestions setting on the core Search block, theme parts and Twig templates, meiliscout/post/thumbnail_size filter naming, posts/taxonomies indexes, and featured images. The prior evaluation assumed a Scout engine registered at the scout.driver seam; that assumption is falsified. There is no evidence of a Scout engine contract, service provider, or composer-installable Laravel integration.
• The package is not a driver — it owns the whole vertical: index schema, admin UI, REST namespace /meiliscout/v1/, block registration, browser client, WP-CLI. None of that is addressable from a Laravel application, and none of it is valuable if you strip the WordPress half.
• Fit for the Laravel app is therefore zero as a drop-in, for a stronger reason than previously stated: wrong platform, not merely redundant driver.
• One addressable scenario survives: WordPress as a content backend producing indexes that a Laravel delivery tier reads. There the package is an index-schema producer, not a dependency — its schema becomes a contract we consume, which is a narrower and cheaper evaluation than adoption.
• Verdict: close the adoption evaluation for Laravel. Re-open only as a read-only index-consumer decision in a WordPress estate, pinned to schema 6.

Integration feasibility

• For the Laravel service: not feasible. A fork that strips WordPress would discard the blocks, admin screens and WP-CLI, which is the product. Not worth the cost.
• For the shared-index case: feasible but gated on contracts we do not control — exact schema-6 document shape (thumbnail: {url, width, height, alt} or null), field names, filterable/sortable attributes, ranking rules, and index naming. Our query parity would then track an external team's release cadence.
• New external surface to assess: GET /meiliscout/v1/suggest/{id}/token and GET /meiliscout/v1/suggest/{id}/search are WordPress REST routes. Anything that fronts or proxies a WP instance — including a Laravel BFF — now inherits them and their auth/rate-limit posture.
• Spike cost drops sharply: ~0.5 engineer-day to confirm platform mismatch and close out; 2–3 days to diff schema 6 against existing consumers if WordPress is in the estate.

Technical risk

• The release materially raises the capability bar. This is no longer a thin adapter: tenant-token minting with a dedicated search-only Meilisearch key scoped to posts and taxonomies indexes, a real browser-side client (debounced, aborted, remembered, recent searches), an accessible combobox, a full-screen mobile sheet with visual-viewport handling, pluggable templates (HTML, Blade, Twig, theme part, callable, SuggestTemplate class, js:<name>), a server-side fallback transport, a diagnostics screen and a CLI check. That is a large surface behind a single agency.
• Security posture changed this release and is now the dominant risk. A key that signs tenant tokens is served to browsers via a REST endpoint. Must verify: is the token route authenticated and nonce-protected, what is the token TTL, is minting rate-limited, and can the search-only key leak through the admin screen or REST payload. A search-only key is low-blast-radius, but an unauthenticated minting endpoint makes our Meilisearch quota a free public API.
• Template trust boundary. Accepting raw HTML and js:<name> is fine when declared in code by an administrator. If any template value is stored in an option editable by a lower role, it is stored XSS. This needs an explicit answer, not an assumption.
• Schema versioning is a genuine maturity signal. posts index schema 6 is additive, queries keep reading a schema-5 index, degradation is graceful (no images in suggestions), and wp meiliscout status reports the need for a full indexation. That is better release engineering than the prior assessment had evidence for. The trade-off: every schema bump is a scheduled reindex operation.
• Prior adoption-risk findings stand and are now more expensive. Still no vendor SLA, no external production signal, and the earlier release-hygiene anomaly (future-dated release metadata) is not resolved by these notes. The scope increase means abandonment costs more, not less.

Key questions

1. Is MeiliScout exclusively a WordPress plugin, or does it ship a framework-agnostic core that a Laravel app could consume? (Release evidence says WP-only — confirm and close.)
2. Is /meiliscout/v1/suggest/{id}/token authenticated, nonce-protected and rate-limited? What is the tenant-token TTL and scope?
3. Where are template values stored, and which capability is required to edit them? (Stored-XSS boundary.)
4. What is the exact schema-6 document shape, and is the schema number documented as a public contract with a deprecation policy?
5. What is the reindex cost of a schema bump at our catalogue size, and do suggestions degrade or fail during it?
6. Who owns the search-only Meilisearch key, and how does rotation invalidate tokens already cached in browsers?
7. Does the plugin pin the official meilisearch/meilisearch-php SDK at an explicit version, and what is the tested matrix across WordPress, PHP and Meilisearch server?
8. Is the rest transport opt-in, and what governs its request volume — it puts one PHP request behind every debounced keystroke?

Integration Approach

Stack fit

• Split the estate explicitly: (a) Laravel application, (b) WordPress content estate. MeiliScout addresses only (b). If (b) does not exist, the evaluation ends here.
• Default remains Scout plus the first-party Meilisearch driver for the Laravel app. Nothing in 2.5.0 changes that.
• In a shared-cluster scenario, integrate at the index boundary, not the code boundary: Laravel reads posts/taxonomies indexes read-only and owns settings only for attributes it does not share.
• Still introduce the internal SearchEngine interface in Laravel — but justify it now as decoupling from a third-party-owned index schema, not as driver-swap insurance.

Migration path

1. Platform confirmation (0.5 day). Check the repo root for composer.json versus plugin headers. This closes or continues the work.
2. Schema capture (2–3 days, shared-index only). Dump a schema-6 document from staging; diff field names, thumbnail nullability, filterable/sortable attributes and ranking rules against what Laravel consumers expect.
3. Contract test as the dependency substitute. A Laravel fixture suite asserting the document shape we read, executed against the WP staging index on every MeiliScout release. This replaces the dependency contract we do not have.
4. Consumer isolation. Laravel reads through its own DTO/hydrator; plugin field names never leak into domain code.
5. Reindex runbook. Name who runs wp meiliscout status, who triggers full indexation, and what the customer-visible window is — queries keep serving schema 5 with degraded (image-less) suggestions rather than failing.

Compatibility

• Pin five things, not three: MeiliScout version, WordPress version, PHP version, Meilisearch server version, and the index schema number. Treat the schema number as an API version in the runbook.
• If Laravel writes to any index the plugin also writes, stop. Two writers to one index is not a supported configuration.
• Validate the browser-direct path against our CSP and key-handling policy: a client-side Meilisearch call requires the search-only key in the browser and connect-src allowance. If policy forbids that, we are on the rest transport and its PHP cost.

Sequencing

• Decide first whether we are an index consumer or a co-owner. Consumer is cheap and reversible; co-owner means negotiating schema changes with an external maintainer and is expensive to unwind.
• Then the schema contract test, then reindex coordination, then — only if we proxy — auth and rate-limit hardening on the new REST routes.
• Do not start by building a Laravel UI over the suggestion endpoints. The token model is the decision that actually matters, and it can invalidate the whole approach.

Operational Impact

Maintenance

• Consumer-only: ~0.1 FTE to run contract tests and coordinate reindexes on plugin releases. Laravel code needs no maintenance.
• Proxying or forking is now a much larger commitment than the pre-2.5.0 picture implied — admin screens, blocks, REST, WP-CLI and a browser client. "Vendor a small package" is no longer a credible framing.
• Record an ADR naming schema 6 as the consumed contract and the exact plugin version that produces it.

Support

• Still no SLA and no vendor escalation path. But credit where due: diagnosability improved materially — wp meiliscout check-suggest, a status field reporting schema drift, per-field validation that surfaces "every error given," and a screen showing groups, public URL and key with a replacement path. On-call has real affordances now.
• Write down the ownership boundary before an incident: is a broken search a WordPress indexing problem or a Laravel consumption problem? That determines who pages whom.

Scaling

• New scaling axis this release: the rest transport moves every debounced keystroke to PHP. On WordPress that is an uncached PHP worker per request — it is the first thing to fail under suggestion traffic. Require the browser-direct path wherever Meilisearch is publicly reachable.
• Token minting is now a hot endpoint. Uncached minting on every page load shows up directly in TTFB; cacheable is complicated by rotation.
• The plugin remains the write-path risk, not Meilisearch. Verify batched versus per-document bulk writes, chunk sizing, HTTP client reuse and explicit retries before trusting it with catalogue growth.

Failure modes

• Cross-tier schema drift: plugin ships schema 7, Laravel's hydrator expects 6, thumbnail vanishes silently. Contract tests are the only detector.
• Token endpoint abuse: weak or absent auth turns our Meilisearch quota into a public search API.
• Stale browser tokens after key rotation — replacement is supported, but cached tokens and persisted recent-search state must expire cleanly.
• Stored XSS via template if the trust boundary is admin-only in name but editable by lower roles.
• Silent degradation: an un-reindexed schema-5 index serves image-less suggestions indefinitely. Intentional behavior, but it must be alarmed on rather than discovered through a support ticket.
• Abandonment now blocks a WordPress upgrade and our index contract simultaneously — a wider blast radius than previously assessed.

Ramp-up

• ~0.5 day for a Laravel engineer to confirm the platform mismatch. In the shared-index case, ~1 day to learn the schema and ~0.5 day of source reading on the token and suggestion flow for the designated owner.
• Comprehension cost stays low. The cost is coordination: an external maintainer now sits directly in the path of our index schema.

Recommendation: the prior recommendation stands and is strengthened — default to Scout's first-party Meilisearch driver, and treat MeiliScout 2.5.0 as not addressable from Laravel. Close the adoption evaluation. If a WordPress estate exists and shares a Meilisearch cluster, re-open as a narrow index-consumer evaluation pinned to schema 6, gated on a document-shape contract test and an auth review of /meiliscout/v1/suggest/{id}/token; in that case prefer the browser-direct path over the rest transport.