Talk to us today

Sri Lanka
  • 40/2/21, Chakkindarama Rd,
    Sri Lanka

SilverStripe Elemental Site search

SilverStripe Elemental Site search

Back in 2017 SilverStripe blogged ”Don’t reinvent the block” and announced how they are drifting towards a block-based approach for content management than fixed fields or page types. From there onwards, the Elemental Module developed by DNA became the standard module to use for any website project.

Not to mention we are one of the early adopters of the module as well and started thinking of all the pages in terms of blocks.

For a number of reasons, site search was becoming an issue for us when we built elemental pages. Unlike the previous data models which happened to be on a single table or multiple tables which could be joined on the primary keys elemental scattered contents over different database tables. Sometimes this got really complex when virtual elements came to place. Writing database queries to do a full-text search for these were almost impossible.

The elemental module supports Apache SOLR with a different SilverStripe module. However, that required having a SOLR instance running and configured to any of the sites.

These are a few problems we faced with search.

  • Data is scattered over multiple tables and those would go to multiple levels.
  • Some of the elements didn't have enough value over having to index for searching. Eg: blog indexes, latest news like elements.
  • Having SOLR servers was expensive in multiple ways for our clients.
  • Not being using SOLR before and now needing that was too much to convince.
  • SQL search queries were getting complex and hard to manage. The queries itself was getting costly, even that manual PHP code needed to be written to curate the search results.
  • The solutions were not reusable.

With all these in mind, we thought of writing our own module to enable effective searching for elemental websites.

The module does a few things.

  1. It's a document generator, generating search documents for each of the pages and saves them in the database. Then when a full-text search is required it search in the document table and provide results.
  2. It ships with data extensions so other than the site tree it can decorate any object and generate a search document against that.
  3. It enables multiple types of data types to be queried within a single search. Like a Listing object which might form up a page over a controller action.
  4. Manages the search documents when the pages publish and deletes those when the page is published or archived.
  5. Support XPath queries when a search document is generated it only indexes the contents with the XPath DOM elements and saves that contents as plain text. This also makes search results more accurate as it searches only the visible contents.
  6. Easy to install on a new website and no codes needed to customize.

The module can be loaded via composer and has different configuration options described on GitHub.

You are welcome to give it a go, share your thoughts on the modules and if you see areas where it could be improved let us know.

Search module backend