Laravel Where Like Laravel Package

Getting Started

1. Install with Composer and let Laravel's package auto-discovery register the service provider:

   composer require diarsa/laravel-where-like
   

   There is no config file to publish in the typical setup — the provider adds whereLike / orWhereLike macros to the query builder during boot().

2. Look first at two places: the package's service provider (to see exactly which macros are registered and their argument signature for the version you installed) and the README examples. Confirm the case-sensitivity flag's position/name rather than assuming it from memory, since it's the one API detail you'll use most.

3. First real use case — replacing collation-dependent LIKE with a portable, case-insensitive search:

   $users = User::whereLike('name', 'john')->paginate(20);
   // instead of: ->where('name', 'like', '%john%')
   

   Reach for it anywhere you'd otherwise hand-write LIKE and then worry about MySQL collation versus Postgres case sensitivity.

Implementation Patterns

Single-column filters. The bread-and-butter call: whereLike($column, $value) for a case-insensitive contains match, plus the orWhereLike counterpart.

Multi-column search boxes. Chain the or variant to emulate a global search across a few columns:

User::query()
    ->whereLike('first_name', $term)
    ->orWhereLike('last_name', $term)
    ->orWhereLike('email', $term)
    ->get();

Wrap it in a local scope so controllers stay thin and the search behaviour is testable in one place:

public function scopeSearch(Builder $q, string $term): Builder
{
    return $q->whereLike('name', $term)->orWhereLike('email', $term);
}

Compose, don't replace. These macros return the builder, so they mix cleanly with when(), soft deletes, eager loads, and pagination:

User::query()
    ->when($request->filled('q'), fn ($q) => $q->search($request->string('q')))
    ->when($request->filled('role'), fn ($q, $role) => $q->where('role', $role))
    ->with('team')
    ->paginate();

Validate before you query. Put the searchable columns in a Rule::in([...]) allowlist and map a request parameter to a column, rather than passing request input into the column argument. Keep the value as a bound parameter (the macro does this for you) and never interpolate it into a raw expression.

Case sensitivity on demand. Where exact-case matching matters (codes, slugs), use the macro's case-sensitive mode rather than dropping back to a raw LIKE. Keep the default case-insensitive path for human-facing search.

Gotchas and Tips

• Leading wildcards still defeat indexes. The macro makes LIKE portable; it doesn't make %term% fast. On large tables plan for a fulltext index, a trigram index (Postgres pg_trgm), or a dedicated search service. Verify with EXPLAIN on production-sized data, not your seeded local DB.
• User input can contain % and _. Those are LIKE wildcards, so a search for 100% or a_b may behave surprisingly. Decide deliberately whether to escape them or accept the broader match — and document the choice.
• Case-insensitivity is engine-dependent. Postgres typically needs ILIKE-style handling, SQLite's default LIKE is only ASCII case-insensitive, and MySQL depends on column collation. Always verify behaviour against the database you actually deploy on; SQLite in tests can hide differences.
• NULL columns never match. whereLike on a nullable column silently excludes rows with NULL, which can look like a search bug in admin screens.
• Qualify columns when joining. Use users.name rather than name to avoid ambiguous-column errors; the grammar handles quoting, but test the generated SQL with ->toSql().
• Don't let the caller pick the column. Column names are identifiers, not bindings. An allowlist is the only safe pattern.
• Macro collision / override. If you already define a whereLike macro or another package does, boot order decides the winner. Check Builder::hasMacro('whereLike') when debugging odd behaviour, and register your own override in a provider that boots later.
• Version discipline. v1.1.4 is a patch release whose notes are only a compare link (and the URL itself contains a typo, v.1.1.4), so read the GitHub diff before bumping in a large codebase. A patch should bring no config or migration changes — pin ^1.1 and let the diff confirm it.