Expand Search Functionality (for bigger modules)

jeroendesloovere's Avatar


08 Mar, 2013 02:00 PM

A good feature could be to expand the existing search functionality.

The current limitation:

I'm going to use the blog module to explain my idea.
You can only search in one table for a module, f.e.: in the "blog_posts" for "blog module".

Requested result:

Search should be able to search in "blog_posts", but also in "blog_comments" and "blog_categories". This could be awesome for bigger modules to make more things searchable.
Possible solutions (thinking out loud):

Add extra field in "search_index" table:

- containing the action type: 'detail', 'category', 'comment'

- or containing the function you want to call, f.e.: 'search' (=> FrontendXModel::search($ids)) or 'search_category' (=> FrontendXModel::searchCategory($ids))

Another (and maby better) solution could to add another row to search_index, containing the function you want to call.
F.e.: in blog/actions/add_category.php, we add the callback parameter:

BackendSearchModel::saveIndex($this->getModule(), $item['id'], array('callback' => 'search_categories',** 'title' => $item['title']));

What does the community think about this?

  1. Support Staff 1 Posted by mlitn on 11 Mar, 2013 04:46 PM

    mlitn's Avatar

    Your understanding of the search module is not 100% accurate.

    It is not at all tied to a certain table per module. One can easily have his module's data be spread among multiple tables and still search for all of that data. Actually, that's the "beauty" of it: the modules' tables are never queried in the actual search.
    If we were in fact to read every module's own columns instead of a dedicated index, it would not be able to manage large data.

    The only times that a modules' tables are being queried is after the search results have been gathered already. Based on the module & other_id of the results it finds after searching search_index, it will fetch the "real" module data (using the module's FrontendModel::search method) to:

    • make sure that the result is still valid (e.g. timestamp-based results; a blogpost will be in the search index, but should not show up when publication date is still in the future)
    • build SERP output data (title, text, full_url, ...)

    The search is always performed on search_index. All that you'd need to do is alter the blog module's code. E.g. on add.php, it currently does:

        BackendSearchModel::saveIndex($this->getModule(), $item['id'], array('title' => $item['title'], 'text' => $item['text']));

    which you could change to:

        BackendSearchModel::saveIndex($this->getModule(), $item['id'], array('title' => $item['title'], 'text' => $item['text'], 'categories' => $categories));

    with $categories being a string e.g. like "general technology" ("general" and "technology" being 2 example category names)

    As a result of this, not only will a row for 'title' and 'text' be written to the search _index for this blog entry, an additional 'categories' row will be added as well, whose values will then also be included in a search.

    Note: you should not forget to write some additional code to make sure that once a category is changed/deleted, it also updates that data for every blog entry whose data has been written to search_index already.

  2. mlitn closed this discussion on 11 Mar, 2013 04:46 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac