Fulltext indexing and searching for Laravel

Related tags

Search hacktoberfest
Overview

Laravel fulltext index and search

Latest Version on Packagist Software License Buy us a tree Build Status Total Downloads Made by SWIS

This package creates a MySQL fulltext index for models and enables you to search through those.

Install

  1. Install with composer composer require swisnl/laravel-fulltext.
  2. Publish migrations and config php artisan vendor:publish --tag=laravel-fulltext
  3. Migrate the database php artisan migrate

Usage

The package uses a model observer to update the index when models change. If you want to run a full index you can use the console commands.

Models

Add the Indexable trait to the model you want to have indexed and define the columns you'd like to index as title and content.

Example

class Country extends Model
{

    use \Swis\Laravel\Fulltext\Indexable;

    protected $indexContentColumns = ['biographies.name', 'political_situation', 'elections'];
    protected $indexTitleColumns = ['name', 'governmental_type'];

}

You can use a dot notitation to query relationships for the model, like biographies.name.

Searching

You can search using the Search class.

$search = new \Swis\Laravel\Fulltext\Search();
$search->run('europe');

This will return a Collection of \Swis\Laravel\Fulltext\IndexedRecord which contain the models in the Polymorphic relation indexable.

If you only want to search a certain model you can use $search->runForClass('europe', Country::class);. This will only return results from that model.

Commands

laravel-fulltext:all

Index all models for a certain class

 php artisan  laravel-fulltext:all
 
Usage:
  laravel-fulltext:all 
   
    

Arguments:
  model_class           Classname of the model to index


   

Example

php artisan laravel-fulltext:all \\App\\Models\\Country

laravel-fulltext:one


Usage:
  laravel-fulltext:one 
    
    
     

Arguments:
  model_class           Classname of the model to index
  id                    ID of the model to index


    
   

Example

php artisan laravel-fulltext:one \\App\\Models\\Country 4

Options

db_connection

Choose the database connection to use, defaults to the default database connection. When you are NOT using the default database connection, this MUST be set before running the migration to work correctly.

weight.title weight.content

Results on title or content are weighted in the results. Search result score is multiplied by the weight in this config

enable_wildcards

Enable wildcard after words. So when searching for for example car it will also match carbon.

exclude_feature_enabled

This feature excludes some rows from being returned. Enable this when you have a flag in your model which determines whether this record must be returned in search queries or not. By default this feature is disabled.

exclude_records_column_name

The column name for that property (which acts as a flag). This must match the exact column name at the table.

An example of using this feature

Think about when you have a blog and then you add this search functionality to your blogging system to search through your blog posts. Sometimes you do not want some posts to be appeared in search result, for example when a post is not published yet. This feature helps you to do it.

Change log

Please see CHANGELOG for more information on what has changed recently.

Testing

$ composer test

Contributing

Please see CONTRIBUTING and CODE_OF_CONDUCT for details.

Security

If you discover any security related issues, please email [email protected] instead of using the issue tracker.

Credits

License

The MIT License (MIT). Please see License File for more information.

This package is Treeware. If you use it in production, then we ask that you buy the world a tree to thank us for our work. By contributing to the Treeware forest you’ll be creating employment for local families and restoring wildlife habitats.

SWIS ❤️ Open Source

SWIS is a web agency from Leiden, the Netherlands. We love working with open source software.

Comments
  • Exlude some rows feature

    Exlude some rows feature

    Description

    I added a feature to the search query logic

    Motivation and context

    I had a requirement to not get some indexable records (my models which use Indexable). In my scenario think about a blog system which my model (the post model) has an is_published column. If this column is false is must not get anything search result about that post. I want it to be handled when I make query not after I get results from search and pruning it.

    How has this been tested?

    Please describe in detail how you tested your changes.

    Include details of your testing environment, and the tests you ran to see how your change affects other areas of the code, etc.

    Screenshots (if appropriate)

    Types of changes

    What types of changes does your code introduce? Put an x in all the boxes that apply:

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [x] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to change)

    Checklist:

    Go over all the following points, and put an x in all the boxes that apply.

    Please, please, please, don't send your pull request until all of the boxes are ticked. Once your pull request is created, it will trigger a build on our continuous integration server to make sure your tests and code style pass.

    • [x] I have read the CONTRIBUTING document.
    • [x] My pull request addresses exactly one patch/feature.
    • [x] I have created a branch for this patch/feature.
    • [x] Each individual commit in the pull request is meaningful.
    • [ ] I have added tests to cover my changes.
    • [x] If my change requires a change to the documentation, I have updated it accordingly.

    If you're unsure about any of these, don't hesitate to ask. We're here to help!

    opened by samberrry 6
  • Make multiple db connections work

    Make multiple db connections work

    Description

    When having multiple db connection, one can choose which one to use

    Motivation and context

    Having multiple db connections and needed to have fulltext-index NOT in the default one, this lead me to this ;)

    How has this been tested?

    Build into our system and let it run on a "not common" connection -> work Put it into a default laravel and let it run unchanged -> works a before

    Screenshots (if appropriate)

    Types of changes

    What types of changes does your code introduce? Put an x in all the boxes that apply:

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [x] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to change)

    Checklist:

    Go over all the following points, and put an x in all the boxes that apply.

    Please, please, please, don't send your pull request until all of the boxes are ticked. Once your pull request is created, it will trigger a build on our continuous integration server to make sure your tests and code style pass.

    • [x] I have read the CONTRIBUTING document.
    • [x] My pull request addresses exactly one patch/feature.
    • [x] I have created a branch for this patch/feature.
    • [x] Each individual commit in the pull request is meaningful.
    • [ ] I have added tests to cover my changes.
    • [x] If my change requires a change to the documentation, I have updated it accordingly.

    If you're unsure about any of these, don't hesitate to ask. We're here to help!

    opened by spresnac 5
  • Use data_get() instead of writing custom nesting logic

    Use data_get() instead of writing custom nesting logic

    Make the Indexable trait use Laravel's data_get() helper so we can use dot notation to get deeply nested values regardless of whether they're an array or relation or casted object.

    This allows users to specify stuff like this:

    protected $indexContentColumns = [
        'casted_object.title',
        'categories_relation.*.title',
        'deeply.nested.relation.value',
    ];
    

    It removes the constraint that $indexContentColumns and $indexTitleColumns must be either an attribute on the Model or a hasOne() relation.

    opened by mattdinthehouse 3
  • support for laravel 8

    support for laravel 8

    updates composer json to support laravel 8

    Description

    Describe your changes in detail.

    Motivation and context

    Why is this change required? What problem does it solve?

    If it fixes an open issue, please link to the issue here (if you write fixes #num or closes #num, the issue will be automatically closed when the pull is accepted.)

    How has this been tested?

    Please describe in detail how you tested your changes.

    Include details of your testing environment, and the tests you ran to see how your change affects other areas of the code, etc.

    Screenshots (if appropriate)

    Types of changes

    What types of changes does your code introduce? Put an x in all the boxes that apply:

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [ ] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to change)

    Checklist:

    Go over all the following points, and put an x in all the boxes that apply.

    Please, please, please, don't send your pull request until all of the boxes are ticked. Once your pull request is created, it will trigger a build on our continuous integration server to make sure your tests and code style pass.

    • [x] I have read the CONTRIBUTING document.
    • [x] My pull request addresses exactly one patch/feature.
    • [x] I have created a branch for this patch/feature.
    • [x] Each individual commit in the pull request is meaningful.
    • [x] I have added tests to cover my changes.
    • [x] If my change requires a change to the documentation, I have updated it accordingly.

    If you're unsure about any of these, don't hesitate to ask. We're here to help!

    opened by samberrry 2
  • Migration fails due to key length

    Migration fails due to key length

    I get the following error when running the initial setup migration:

     Illuminate\Database\QueryException  : SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes (SQL: alter table `laravel_fulltext` add unique `laravel_fulltext_indexable_type_indexable_id_unique`(`indexable_type`, `indexable_id`))
    

    This is because the when using utf8mb4 encoding, the maximum length of an indexed VARCHAR column is 191 characters. The default of 255 will fail. Using utf8mb4 encoding is essential for proper emoji support, which can be important for many applications.

    Does the indexable_type column need to be 255 characters? Would 191 suffice?

    question 
    opened by chrisgherbert 2
  • Does this library supports fuzzy search?

    Does this library supports fuzzy search?

    Detailed description

    Questions: Does this library supports fuzzy search?

    Context

    I would like to implement fuzzy search.

    Possible implementation

    Levenshtein?

    Your environment

    • Laravel 5.1
    opened by rmariuzzo 2
  • Remove space character from the replace function

    Remove space character from the replace function

    When searching for a search string ending in a special character, 2 terms were created. This resulted in an error. The pull request fixes this behaviour.

    opened by marijnz0r 2
  • Improve README

    Improve README

    Description

    This PR mostly fixes some typos and updates the markdowns of some commands. I also removed the redundant artisan commands since it is already implied what command is from the heading.

    Motivation and context

    Why is this change required? What problem does it solve?

    Not required, but it could help make the README look nicer. My motivation is for Hacktoberfest 😄

    How has this been tested?

    Not applicable.

    Types of changes

    What types of changes does your code introduce?

    README Documentation Change

    Checklist:

    Go over all the following points, and put an x in all the boxes that apply.

    Please, please, please, don't send your pull request until all of the boxes are ticked. Once your pull request is created, it will trigger a build on our continuous integration server to make sure your tests and code style pass.

    • [x] I have read the CONTRIBUTING document.
    • [x] My pull request addresses exactly one patch/feature.
    • [x] I have created a branch for this patch/feature.
    • [x] Each individual commit in the pull request is meaningful.
    • [ ] I have added tests to cover my changes.
    • [x] If my change requires a change to the documentation, I have updated it accordingly.
    opened by hpacleb 1
  • Working with relationship in model

    Working with relationship in model

    Good morning, I need to know how to index relationships in depth. I explain below User has many books and books have authors. I need to know how to know what the authors read the users. This would be the relationship in depth. user.book.author.name Also want to know what the difference between $ indexTitleColumns and $ indexContentColumns is. Regards

    question 
    opened by yanielbf 1
  • Add support for morph maps

    Add support for morph maps

    Description

    This PR wil add support for morph maps.

    Motivation and context

    If you've enabled morph maps, it is currently impossible to run the searcher for one model. Laravel inserts the morph type in the indexable_type column, but we currently query it with the FQCN.

    How has this been tested?

    Tested in an application with morph maps enabled. Test coverage is pretty low at the moment, so I consider adding missing tests out of scope.

    Types of changes

    What types of changes does your code introduce? Put an x in all the boxes that apply:

    • [x] Bug fix (non-breaking change which fixes an issue)
    • [x] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to change)

    Checklist:

    Go over all the following points, and put an x in all the boxes that apply.

    • [x] I have read the CONTRIBUTING document.
    • [x] My pull request addresses exactly one patch/feature.
    • [x] I have created a branch for this patch/feature.
    • [x] Each individual commit in the pull request is meaningful.
    • [ ] I have added tests to cover my changes.
    • [x] If my change requires a change to the documentation, I have updated it accordingly.
    opened by JaZo 0
  • Move to GitHub Actions for CI

    Move to GitHub Actions for CI

    Description

    This PR will move the tests to GitHub Actions.

    Motivation and context

    The Travis account ran out of credits so tests aren't being ran and GitHub Actions is way better 😃 It would allow us to spin up a database and actually test the queries for example.

    How has this been tested?

    Config copied from other swinl-packages.

    Types of changes

    What types of changes does your code introduce? Put an x in all the boxes that apply:

    • [x] Bug fix (non-breaking change which fixes an issue)
    • [x] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to change)

    Checklist:

    Go over all the following points, and put an x in all the boxes that apply.

    • [x] I have read the CONTRIBUTING document.
    • [x] My pull request addresses exactly one patch/feature.
    • [x] I have created a branch for this patch/feature.
    • [x] Each individual commit in the pull request is meaningful.
    • [x] I have added tests to cover my changes.
    • [x] If my change requires a change to the documentation, I have updated it accordingly.
    opened by JaZo 0
  • Multiple indexes

    Multiple indexes

    Hello,

    This package is great really, thanks for the good work.

    Detailed description

    Search index are bound to grow and I think that a great feature to add would be to allow for a per model index. In many case, we need to add search on more than one model, and with a single table, we will end up with unnecessary big one. The "global search" could be made optional, and only include the models specifically declared as such.

    I also think that the underlying model should avoid using auto increments as primary key, as they tend to degrade performance when growing, especially for the "global search" usage. Would be better to use UUids. Uuid kind is not very important for the usage, as we don't expect to order the table on them, but ordered UUids mays still be worth it for better write throughput (as new records are almost always happened to the index). I wrote a simple package for that https://github.com/fab2s/SoUuid There are others but base62 format may be worth considering to reduce index length (it requires a case sensitive column though, or in laravel / mysql world $table->char('id', 21)->charset('ascii')->collation('ascii_bin')->primary();).

    The index structure also should have no opinion about the models id type and just use case sensitive string type, as it would work for both auto-incremented and uuid models (any kind).

    Context

    It would make increase performance (a lot) every time one needs to index several models but does not necessarily want to search all of them at once, for example to smart auto complete to most models.

    Possible implementation

    I just discovered this great package, so I just took a quick look, but from what I see, the change surface should not be that big. The trait could include a variable to ask for a dedicated table, and another one to be included in the global index or not.

    The search run would only consider the global index, and the runForClass would just have to set the table name in the Index model if applicable, and use a slightly different query (to not use the morph relation in that case).

    There would be a need to be able to create relevant specialized table "on the fly" when indexing (another way would be to put those model based settings in config (array of model classes) or to parse model to read props (and maybe add an option in config for extra model paths) and leave the dedicated table creation to the commands. The on the fly option seems ok if the table exist check (model table name could be implicit and or specifically set by the indexed model props) result in stored in cache.

    Then tweak the "live" and "batch" indexing to either index globally, or locally, or both.

    I know this would represent still some changes, but I really think it would make this package battle ready for many more use cases, and BC should also remain possible.

    I am willing to help, but I won't be able to code much immediately. I would though be happy if you would consider it and would help as much as I can.

    Keep up the good work !

    Cheers

    enhancement 
    opened by fab2s 1
  • Remove IN BOOLEAN MODE

    Remove IN BOOLEAN MODE

    Removed IN BOOLEAN MODE, as it does not seem to add any features.

    I like this package, have used it on several projects and also on https://github.com/WebDevEtc/BlogEtc

    However, I've had a problem with some searches not showing any results. I had a play around, and it works if I remove the boolean mode parts of the query.

    for example, if I change the (generated) SQL query from:

    select * from `laravel_fulltext` where
    MATCH (indexed_title, indexed_content) AGAINST ('+the +between  +difference ' IN BOOLEAN MODE)
    order by (1.5 * (MATCH (indexed_title) AGAINST ('What is the difference between')) +
              1 * (MATCH (indexed_title, indexed_content) AGAINST ('What is the difference between')))  
    DESC  limit 100
    

    to

    select * from `laravel_fulltext` where
    MATCH (indexed_title, indexed_content) AGAINST ('the between  difference ')
    order by (1.5 * (MATCH (indexed_title) AGAINST ('What is the difference between')) +
              1 * (MATCH (indexed_title, indexed_content) AGAINST ('What is the difference between')))  
    DESC  limit 100
    

    (the first query shows zero results, the second shows results, as it should as there is content in indexed_title with the exact text "what is the difference between something and something else". I don't really why know it wasn't working).

    I did some digging in the source code, and as far as I can tell, it isn't possible for the user to add any boolean search queries, as in TermBuilder::terms() it will remove any boolean characters (such as - or +).

    So, I was wondering - why is the boolean mode stuff there (the + before each word, and the IN BOOLEAN MODE)?

    I thought that maybe it used to be possible to do boolean searches (such as restaurant -pizza, but then with this fix: https://github.com/swisnl/laravel-fulltext/pull/9 that functionality got removed, but the "IN BOOLEAN MODE" parts stayed?

    Anyway, I've removed the IN BOOLEAN MODE. Maybe there was some other reason that I missed, and it should stay. If that is the case, I'd be interested in the reason why.

    I've attached a pull request.

    Description

    Removed $termsBool and IN BOOLEAN MODE. Tested on local machine and a production machine, it works fine.

    Motivation and context

    See above

    How has this been tested?

    Tested, seems ok.

    Screenshots (if appropriate)

    n/a

    Types of changes

    What types of changes does your code introduce? Put an x in all the boxes that apply:

    • [x] Bug fix (non-breaking change which fixes an issue)
    • [ ] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that would cause existing functionality to change)

    Checklist:

    • [x] I have read the CONTRIBUTING document.
    • [x] My pull request addresses exactly one patch/feature.
    • [x] I have created a branch for this patch/feature.
    • [ ] Each individual commit in the pull request is meaningful.
    • [ ] I have added tests to cover my changes. - none added
    • [ ] If my change requires a change to the documentation, I have updated it accordingly. - none required
    opened by WebDevEtc 3
  • Fix updating a record twice in one session

    Fix updating a record twice in one session

    When updating a record a second (or more) time(s) in the same session, the changes are not being saved to the fulltext search. It seems that the changes get cached the first time, and don't get updated on the fulltext model. Performing the refresh reloads the model from the DB. This will be slightly less efficient due to the DB access a second time, but it is probably worth the slight inefficiency to have expected behavior when updating your models.

    Steps to replicate:

    1. Open tinker
    2. Update a model that uses Indexable
    3. View record in fulltext DB table to verify record updated
    4. In same tinker session make another update to same model record
    5. View record in DB again to verify that record did NOT update

    Restarting tinker in between updates does not result in the inconsistency.

    opened by kadivadavidak 2
Releases(0.21.1)
  • 0.21.1(Feb 8, 2022)

  • 0.21.0(Jun 30, 2021)

    Added

    Added support for using dot notation to read nested values for index values, see #30 (thanks @mattdinthehouse).

    Changed

    Dropped PHP <7.2 support. Dropped Laravel <6 support.

    Source code(tar.gz)
    Source code(zip)
  • 0.20.0(Sep 28, 2020)

  • 0.19.0(Apr 30, 2020)

    Added

    New feature which you can enable in the config:

    • exclude_feature_enabled This feature excludes some rows from being returned. Enable this when you have a flag in your model which determines whether this record must be returned in search queries or not. By default this feature is disabled.

    • exclude_records_column_name The column name for that property (which acts as a flag). This must match the exact column name at the table.

    An example of using this feature Think about when you have a blog and then you add this search functionality to your blogging system to search through your blog posts. Sometimes you do not want some posts to appear in the search results, for example when a post is not published yet. This feature helps you to do it.

    Thanks to @vhessam for the PR #23.

    Source code(tar.gz)
    Source code(zip)
  • 0.18.0(Mar 6, 2020)

  • 0.17.0(Oct 13, 2019)

    Added

    • Added support for Laravel 6 #19.
    • Database connection can now be set in the configuration (db_connection) (thanks @spresnac) #18 #20.

    Changed

    • Changed namespace from Swis\LaravelFulltext to Swis\Laravel\Fulltext.
    Source code(tar.gz)
    Source code(zip)
  • 0.16.0(Mar 20, 2019)

  • 0.15.0(Jan 28, 2019)

  • 0.14.0(Sep 21, 2018)

    This is a maintenance release which does not change any functionality. However, please note we have dropped PHP 5.6 support.

    Changed

    • Run tests on multiple PHP and Laravel versions.
    • Restrict Laravel versions to ^5.1,<5.8.
    • Rename tests namespace.
    • Improve README and other documentation.

    Fixed

    • Add missing dependency to composer.json.

    Added

    • Code style checker/fixer.
    • Add CHANGELOG.

    Removed

    • Drop PHP 5.6 support.
    Source code(tar.gz)
    Source code(zip)
  • 0.13.0(Aug 30, 2018)

  • 0.12.2(Jun 22, 2018)

  • 0.12.1(Jun 14, 2018)

  • 0.12(May 28, 2018)

  • 0.11(May 14, 2018)

    Changed

    • Allow searching for empty string in searchQuery method so the package doesn't throw a query exception.

    Added

    • Added basic .gitignore.
    Source code(tar.gz)
    Source code(zip)
  • 0.10(May 9, 2018)

  • 0.9(Sep 21, 2018)

Owner
SWIS
SWIS
A scout DB fulltext-based driver that store index data in related tables

A scout DB fulltext-based driver that store index data in related tables This package provide a Laravel/Scout Engine based on database/fulltext only,

Ivano Matteo 10 Nov 10, 2022
Unmaintained: Laravel Searchy makes user driven searching easy with fuzzy search, basic string matching and more to come!

!! UNMAINTAINED !! This package is no longer maintained Please see Issue #117 Here are some links to alternatives that you may be able to use (I do no

Tom Lingham 533 Nov 25, 2022
Laravel package to search through multiple Eloquent models. Supports sorting, pagination, scoped queries, eager load relationships and searching through single or multiple columns.

Laravel Cross Eloquent Search This Laravel package allows you to search through multiple Eloquent models. It supports sorting, pagination, scoped quer

Protone Media 844 Dec 25, 2022
This package offers advanced functionality for searching and filtering data in Elasticsearch.

Scout Elasticsearch Driver ?? Introducing a new Elasticsearch ecosystem for Laravel. ?? This package offers advanced functionality for searching and f

Ivan Babenko 1.2k Dec 20, 2022
Laravel Scout provides a driver based solution to searching your Eloquent models.

Introduction Laravel Scout provides a simple, driver-based solution for adding full-text search to your Eloquent models. Once Scout is installed and c

The Laravel Framework 1.3k Dec 31, 2022
Think-scout - A driver based solution to searching your models. Inspired By Laravel Scout

前言 whereof/think-scout根据thinkphp设计思想参考laravel/scout进行扩展 whereof/think-scout 为模型的全文搜索提供了一个简单的、基于驱动程序的解决方案。 目前,Scout 自带了一个 Elasticsearch 驱动;而编写自定义驱动程序很简

wangzhiqiang 6 Mar 18, 2022
Plastic is an Elasticsearch ODM and mapper for Laravel. It renders the developer experience more enjoyable while using Elasticsearch, by providing a fluent syntax for mapping, querying, and storing eloquent models.

Plastic is an Elasticsearch ODM and mapper for Laravel. It renders the developer experience more enjoyable while using Elasticsearch, by providing a f

Sleiman Sleiman 511 Dec 31, 2022
Search among multiple models with ElasticSearch and Laravel Scout

For PHP8 support use php8 branch For Laravel Framework < 6.0.0 use 3.x branch The package provides the perfect starting point to integrate ElasticSear

Sergey Shlyakhov 592 Dec 25, 2022
This is an open source demo of smart search feature implemented with Laravel and Selectize plugin

Laravel smart search implementation See demo at: http://demos.maxoffsky.com/shop-search/ Tutorial at: http://maxoffsky.com/code-blog/laravel-shop-tuto

Maksim Surguy 215 Sep 8, 2022
Store and retrieve objects from Algolia or Elasticsearch

Store and retrieve objects from a search index This is an opinionated Laravel 5.1 package to store and retrieve objects from a search index. Currently

Spatie 440 Dec 30, 2022
Easily add weighted searches through model attributes and relationships

Laravel Searchable ?? Easily add weighted searches through model attributes and relationships. This package currently supports MySQL and PostgreSQL. I

H-FARM 93 Nov 1, 2022
Build and execute an Elasticsearch search query using a fluent PHP API

PACKAGE IN DEVELOPMENT, DO NOT USE YET Build and execute ElasticSearch queries using a fluent PHP API This package is a lightweight query builder for

Spatie 94 Dec 14, 2022
symfony solarium integration and solr management

solarium-bundle symfony bundle for solarium integration and solr management. current state of this bundle for now this bundle is me messing about with

null 2 Jan 11, 2022
Vagrant configuration for PHP7, Phalcon 3.x and Zephir development.

Phalcon VM 2.0.1 Phalcon VM is an open source Vagrant configuration which contains wide range of tools required in modern web development. Like a Swis

Eugene Manuilov 42 Nov 17, 2022
This script was made to aid the process of migrating PHP and MySQL based websites

This script was made to aid the process of migrating PHP and MySQL based websites. Works with most common CMSes.

interconnect/it 3.9k Jan 5, 2023
A metadata catalog and search engine for geospatialized data

resto is a metadata catalog and a search engine dedicated to geospatialized data. Originally, it’s main purpose it to handle Earth Observation satellite imagery but it can be used to store any kind of metadata localized in time and space.

Jerome Gasperi 50 Nov 17, 2022
[Deprecated] We now recommend using Laravel Scout, see =>

[DEPRECATED] Algolia Search API Client for Laravel Algolia Search is a hosted full-text, numerical, and faceted search engine capable of delivering re

Algolia 240 Nov 25, 2022
Maps Laravel Eloquent models to Elasticsearch types

Elasticquent Elasticsearch for Eloquent Laravel Models Elasticquent makes working with Elasticsearch and Eloquent models easier by mapping them to Ela

Elasticquent 1.3k Jan 4, 2023
A search package for Laravel 5.

Search Package for Laravel 5 This package provides a unified API across a variety of different full text search services. It currently supports driver

Mark Manos 354 Nov 16, 2022