Strattic Developers by Elementor

Implementing FuseJS for Static Search

What sort of custom search solutions are possible on Strattic?

Just about everyone who has a PHP or admin-ajax based search solution…

This is a difficult question to answer, since there are an unlimited number of options available 🤓 .

Below, you’ll find all the info you need. We’ve always provided a bit of an explanation, and you’re free to start wherever you like.

  • Gimme the TL;DR
  • … actually I’d like to know how to think about the problem here…

Whichever you choose, don’t forget to have some fun 🤓 !

Just show me how to implement this!

This plugin was made a while ago by one of our engineers which uses FuseJS alongside the twentytwentyone theme for WordPress. Review the code and you can see how this type of thing can be implemented.

Demo: There’s a demo for you here, to show how it works on a website:
https://fusejsdemo.preview.strattic.io/?s=test

It overrides the default WordPress search system with a FuseJS based one. When viewed in WordPress, it will show the WordPress results, but a split second later it will override it with the FuseJS results.

In the case of Strattic, it will just use the home page to provide the search template in this case (since ?s=something will just use the home page on Strattic) and you won’t see any WordPress results show up since they won’t exist there.

In the case of that example plugin, the JSON file is located at /search.json, but it is not a real file in the file systems, it’s just generated dynamically on the fly (or cached once published via Strattic). That plugin uses the strattic_paths filter to ensure that the JSON file is published by Strattic.

In this example, the JOSN file is generated on every single page load whenever /search.json is loaded, the contents are regenerated dynamically on the fly, every time. It uses a very simple database query to pull all the data out, so it’s very fast, and since it’s cached when published, there’s no performance problems at all on the live site.

A bit of an explanation…

By default, WordPress search is quite basic. More complicated solutions tend to be quite heavily customised per site. The only difference from a “normal” WordPress search customisation and on Strattic, is that the search engine itself needs to be either an external third party API (Algolia is a good example of this) or a database stored locally on your site (FuseJS is a good example of this).

While you can connect to the Algolia database already connected to your site, you are certainly not limited to this. The primary thing to remember on Strattic is that you cannot rely on WordPress itself being present to handle the search. So, no PHP or MySQL queries can be involved. The search either needs to happen on the current site itself via static assets, or by connecting to a third party API providing the search results.

If you don’t want to use a third party service, then a local system like FuseJS would be ideal.

You may be asking: “But how can the JSON file be stored locally or updated?

Glad you asked 🤓 😎 !!

On Strattic, you can typically make the JSON file get generated on every page load (if the generation is fast enough). When it’s published to your site, it’s stored statically, so it loads instantly.

Note: The only time we would advise caution using this type of method is if the amount of data is enormous. However, we’re yet to come across anyone with a site where that was a problem. And even if the content was enormous, it could in theory be sharded across multiple files and relevant files loaded when required.

For example: Consider a 300KB JSON file. That isn’t very big so long as it’s not loaded on every page load and only loaded as required. In our experience, loading a 300 kB JS file will normally be faster than running a query to WordPress. And if you preload it (for example when someone clicks a search box), it will effectively be instant.

You may now be asking, “Great! But where should I put the JSON file?”

You can locate the JSON file anywhere you like. It just needs to be somewhere that the web page can load it from, like wp-content/uploads for example.

There is an unlimited number of ways in which you can implement this type of functionality. You can store the files anywhere you like, or generate them on the fly (though they would then be cached when you published the site).