Zend used to maintain a PHP port of Lucene 15 years ago that I used, but not sure what happened to it.
Yes, Zend_Search_Lucene was dropped from Zend Framework 2 and never officially maintained for modern PHP. There's a community fork.
Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
11–20 of 35 posts
Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
#12I 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 in…
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…
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.
Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
#13Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
#14Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
#15Earlier 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.
+1. This eliminates a whole class of bugs in which you declared phpunit as a dev dependency but end up using a class that it brought in without declaring as a regular dependency. Without an external linter, you can’t really catch that until your production code doesn’t bring the class in and throws a fatal error.
Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
#16Earlier quoted context omitted.
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.
> I would recommend declaring the phar dependency with phive +1. This eliminates a whole class of bugs in which you declared phpunit as a dev dependency but end up using a class that it brought in without declaring as a regular dependency. Without an external linter, you can’t really catch that until your production code doesn’t bring the class in and throws a fatal error.
2. If you use phpunit class in prod code, you deserve to get a fatal error
Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
#17Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
#18Earlier quoted context omitted.
> I would recommend declaring the phar dependency with phive +1. This eliminates a whole class of bugs in which you declared phpunit as a dev dependency but end up using a class that it brought in without declaring as a regular dependency. Without an external linter, you can’t really catch that until your production code doesn’t bring the class in and throws a fatal error.
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
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
#19Re: Show HN: PHP-fts – Full-text search engine in pure PHP, no extensions
#20We've been using https://github.com/loupe-php/loupe , works quite well for small-to-medium single-instance apps.