Earlier quoted context omitted.
Thank 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…
I would actually reconsider adding phpunit as a dev dependency. It is a tool that runs independently from your project. Therefore it should not live in composer. I would recommend declaring the phar dependency with phive. https://docs.phpunit.de/en/12.5/installation.html#phar-or-co... I find this project very impressive and have bookmarked it for potential use in future projects. Thank you for making this.
Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
21–30 of 35 posts
Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
#22I 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.
Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
#23Earlier quoted context omitted.
1. Just add phpcsfixer and phpstan like any sane project 2. If you use phpunit class in prod code, you deserve to get a fatal error
1. Both tools will not catch it, you need something like https://github.com/maglnet/ComposerRequireChecker 2. That doesn’t apply to PHPUnit specifically, but if you, for example, import PHP-cs-fixer as dev dependency, it will bring symfony/console, and if you rely on that on your own code without importing it on composer.json as a regular dependency, the class will be missing when you composer install for production.
Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
#24You can also do something like this with static pages using 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.
A comparable alternative might be TNTSearch: https://github.com/teamtnt/tntsearch though that requires some (common) PHP extensions to be available, which this library does not require.
Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
#25Great 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
Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
#26We've been using https://github.com/loupe-php/loupe , works quite well for small-to-medium single-instance apps.
Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
#27Earlier quoted context omitted.
Yes, Zend_Search_Lucene was dropped from Zend Framework 2 and never officially maintained for modern PHP. There's a community fork.
Any 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.
Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
#28Earlier quoted context omitted.
Thank 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…
Do you have comparative benchmarks on the filter performance? I'm particularly interested in the SQLite FTS case.