core
core copied to clipboard
zikula
[Search] [RFC] Replacing the Search Module
It is time to start discussing replacing the search module. We need a more robust and easily implemented solution for third party modules.
here are some resources to begin the discussion:
https://github.com/doctrine/search
http://www.opensearch.org/Home
http://www.elasticsearch.org/ (JAVA server side app)
http://lucene.apache.org/solr/ (JAVA server side app)
http://framework.zend.com/manual/1.12/en/zend.search.lucene.html (PHP based - Zend_Search_Lucene)
I've not looked into this in any great detail and am not prepared to work on it at the moment. But we need to discuss a future solution and work out a timeline.
I think the PHP solution above seems like the obvious choice. It doesn't seem like JAVA solution would be a good one for a PHP Framework. Also the Doctrine Search can use the Lucene project. Seems like a good fit. The Opensearch suggestion comes from a suggestion from drak on an earlier ticket.
In the end, I would like a third party module to either provide an ID and fields to search and leave the rest to the Search module or come up with some kind of Abstract class that modules inherit from that clearly defines the module's role/responsibility.
@drak @hvorragend @phaidon @jusuff @Guite @dmm1 @planetenkiller @matheo @aperezm @tfotis @paustian @tebbenhof @ifs-net @rallek @espaan @rgasch @halbrooktech
Certainly the search module must be replaced, but I think the general structure (Search module asking all other modules) is ok. Only the realizing is not the best.
What is wrong with the current search module? On my (easy) sites I do not have recognised any problem.
If there is the need to have a new one, why not create an api where different modules/scripts can be used like scribite is the api for editors.
The API of the search module is not very good. For a search you have to access the search table directly instead of doing an API call.
@rallek - it is not an issue from the user/admin perspective. It is a complete disaster from the developer perspective.
ok @craigh you know this much better than me.
But if it is a desaster, how can you make it robust for the future?
Today one of the above mentioned scripts is cool, but tomorrow it is outdated (like xinha as an editor). Can we include something like scribite to let the user/admin choose which offer he wants to use? One will use a simple search script because of his simple site (like me) another wants to use google to reduce the server load, the next one is loving Java, ...
I don't mind any solution as long as we KISS (keep it simple stupid) ;-)
I have never really looked into the search module, only have updated some methods in modules for it. As long as the module side stays relatively simple and we have module that has an own indexed table with search items (id, title, keyword, ?, what else).
For me the search module works fine, except the fact, that it is not possible to go back, after you clicked on a result. I have a simple idea to fix the problem: If you have a search result that is more than 10 entries, you see the pager under the list. If I use the pager an then click on the result, it is no problem to go back and see the last search-list. How can we build the same kind of URL for the first search-list?
http://symfony.com/blog/the-new-symfony-documentation-search-engine
https://github.com/algolia/AlgoliaSearchBundle
Adding some reading materials:
- https://github.com/doctrine/search
- https://www.strangebuzz.com/en/blog/implementing-a-search-engine-with-elasticsearch-and-symfony
- https://www.strangebuzz.com/en/blog/implementing-a-search-engine-with-elasticsearch-and-symfony-part-2
- https://www.strangebuzz.com/en/blog/implementing-a-search-engine-with-elasticsearch-and-symfony-part-3
There are tons of tutorials about how to use ElasticSearch with Symfony:
- https://betterprogramming.pub/3-ways-on-how-to-use-elasticsearch-in-a-symfony-project-with-apiplatform-689674f6059e
- https://medium.com/@demianchuk.sergii/symfony-elasticsearch-builder-pattern-dto-criteria-object-f9b1ceae9e6c
- https://www.mon-code.net/post/143/Which-tool-to-choose-to-use-Elasticsearch-in-a-Symfony-project
- https://sergiiblog.com/symfony-elasticsearch-model-data-layer/
- https://medium.com/@demianchuk.sergii/symfony-elasticsearch-search-service-and-query-builder-sergii-demianchuk-blog-da56a95767b
- https://sergiiblog.com/symfony-elasticsearch-search-service-and-query-builder/
No need to provide something Zikula-specific. Hence, closing as won't fix.