6 ms·
Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
- isaisabella 4mo agoGreat start! This bridge between LIKE and a full-blown engine is exactly what's needed for the PHP long-tail.
- cpollett 4mo agocode looks pretty clean. is small and compact, decent benchmarks. might want to consider using an autoloader for classes.
- hparadiz 4mo agoThe PSR-4 definition is properly defined in composer. There's no need to include an autoloader. Any project pulling this in would have it's own.
- captn3m0 4mo agoZend used to maintain a PHP port of Lucene 15 years ago that I used, but not sure what happened to it.
- asmodios 4mo agoYes, Zend_Search_Lucene was dropped from Zend Framework 2 and never officially maintained for modern PHP. There's a community fork.
- trog 4mo agoAny idea if it's any good? I used the old Lucene implementation ages ago and thought it was OK, though wasn't using it in a big way.
- asmodios 4mo agoThe zf1s/zend-search-lucene fork still works and gets occasional updates, but it's essentially legacy maintenance on a PHP 5.3-era codebase. It crashed on PHP 7 for a while, and the original ZF team themselves recommended moving on.
- idoubtit 4mo agoI expected a toy project, but it is a usable library, which required a lot of work. Good job on delivering. A few comments: After reading "composer.json", I thought that the tests used a custom framework. I'm glad the project does not suffer from NIH syndrome, but the dev dependency on PHPUnit should be declared. There should a warning that it's only meant for some Western Latin languages. The normalization of the input is built on a character table for a handful of cases. That's not enough for some Latin languages, e.g. Turkish. And any input with Cyrillic, Arabic, CJK and so on, will be ignored. There is no Unicode normalization or cleanup. Real-life input have many corner cases, e.g. diacritics next to the characters, or invisible characters inside a word to prevent hyphenation. Unless I'm mistaken, this engine would treat the NFD form "fête" as "fe te", instead of the expected "fete", which the NFKD form "fête" produces. I suggest using ext-intl for Unicode normalization, at least as an option. Lastly, I can't think of a use case for this library. I've always had access to some external service (MySQL, Postgresql, Manticore Search, Solr, etc.) or to a PHP extension for a local Sqlite with FTS. Even for hobby projects, I haven't deployed to a shared hosting for more than two decades.
- asmodios 4mo agoThank you for the detailed feedback, it's genuinely valuable. You're right on all technical points : PHPUnit missing from dev dependencies is an oversight I'll fix, and the Unicode limitations are real and should be clearly documented. The NFD/NFKD case is a good catch. On the use case: fair point. My motivation came from testing MySQL and SQLite full-text search on a shared OVH hosting : the performance with filters was consistently disappointing. That's the itch this scratches. I understand it doesn't match your experience, and that's perfectly legitimate.
- francislavoie 4mo agoWe've been using https://github.com/loupe-php/loupe https://github.com/loupe-php/loupe, works quite well for small-to-medium single-instance apps.
- reconnecting 4mo agoLoupe seems to have a much longer dependencies list.
- asmodios 4mo agoLoupe is a great project and more feature-rich than php-fts (stemming, geo, Damerau-Levenshtein typo tolerance). The dependency difference isn't just about Composer packages. Loupe requires pdo_sqlite and SQLite >= 3.35.0, which isn't guaranteed on shared hosting.
- BoxedEmpathy 4mo agoThis is super cool! Thank you!
- ksamantha 4mo ago[flagged]
- ulrischa 4mo agoGreat tool. Does it work with german umlaut (äöü)? I find it very useful because shared hosting is still big for me. I use ultra cheap shared hosting for nearly everything. No Server maintainance and no funky serverless stuff
- asmodios 4mo ago[dead]
- deleted 4mo ago[deleted]
- gnyman 4mo agoYou can also do something like this with static pages using https://pagefind.app/ https://pagefind.app/ I built a ChatGPT/claude history search tool and it works surprisingly well. There are other tools also. Not to detract from this tool but just to inform people about alternatives.
- 4lun 4mo agoNot quite a comparable alternative. I use Pagefind and it's great for static sites but the search is all client side JS, there's no PHP (or otherwise) client to use it's generated index on the server. A comparable alternative might be TNTSearch: https://github.com/teamtnt/tntsearch https://github.com/teamtnt/tntsearch though that requires some (common) PHP extensions to be available, which this library does not require.
- napxuai 4mo ago[dead]
- galaSerge 4mo ago[flagged]
- kumiko_studio 4mo ago[flagged]
- Skinless1501 4mo agoThis looks pretty solid. What's so special about the dotless Turkish i that it's ignored?
- asmodios 4mo agoThanks, that was a legitimate omission. I’ve now added transliteration support for Turkish-specific characters (`İ`, `ı`, `Ğ`, `Ş`, etc.) in the normalization layer.
- asphodele 4mo agoAn alternative for PHP full text search is the PHP DuckDB client [1], and using DuckDB with the Full-Text Search extension [2]. It also stores everything on the local file system and can scale to millions of records. [1] https://duckdb.org/docs/lts/clients/php https://duckdb.org/docs/lts/clients/php [2] https://duckdb.org/docs/current/core_extensions/full_text_search https://duckdb.org/docs/current/core_extensions/full_text_se...
- asmodios 4mo agoThanks for the suggestion. DuckDB is a great tool, but it requires installing a native extension, which is exactly the scenario php-fts is designed to avoid. The primary target is shared hosting (OVH, Infomaniak, o2switch…) where you have no control over installed extensions. If you can install DuckDB, you can probably also run Meilisearch or Typesense, which are purpose-built for search.