indie-wiki-buddy icon indicating copy to clipboard operation
indie-wiki-buddy copied to clipboard

Feature Request: Custom Search Engine URLs

Open NullCub3 opened this issue 1 year ago • 4 comments

Hi there! So, I have my own instance of SearXNG (a self-hosted search engine) on my home server, and I'd like to be able to use the Indie Wiki Buddy search filtering feature with it, but as far as I can tell there's no support for this in the extension. I am definitely a niche user here, so it's completely understandable for this to be a low priority, but if there's somebody willing to implement this I would be grateful forever.

What I'm requesting would be for the ability to add custom URLs to Indie Wiki Buddy to have search filtering on, with a set of presets for different self-hosted search engines such as aforementioned SearXNG or Whoogle Search. So for example, if you had a SearXNG instance at search.my-address.com, you would go into the extension settings, add search.my-address.com to a custom URL section, select the preset for SearXNG, apply, and then assuming all goes well you now have the search filtering work on that instance.

NullCub3 avatar Jan 17 '24 12:01 NullCub3

I wasn't aware of these self-hosted search engine options, that's pretty awesome. Currently a low-priority for me, as you predicted, but I would like to see us support this at some point!

KevinPayravi avatar Feb 19 '24 21:02 KevinPayravi

Any news on this front? Looks like the functionality has been in the extension for a while, just hidden (#648). Is there any way to enable it?

DokterKaj avatar Sep 12 '24 14:09 DokterKaj

@DokterKaj indeed, the custom search engine functionality was commented out due to an unforeseen issue with how content script registration works.

Currently, normal search engine filtering is done through a content script that is declared in the manifest.json and has access to the domains of the search engines we support. In contrast, filtering search results on a custom domains requires us to register a new content script for that particular domain via code instead of the manifest. This worked perfectly well except for one hurdle: whenever the extension updates, the browser will un-register any content scripts that were registered via code.

I experimented with setting up a listener that would trigger whenever IWB updates, to re-register the content script. However, there's a limitation: content scripts can only be registered through direct user actions, not programmatically in the background.

One unideal but simple solution may be for us to just communicate to the user that they need to re-register their custom domain whenever the extension updates. And we could potentially auto-open an IWB settings page prompting the user to do so.

That being said, I am planning to re-work how search engine filtering permissions are set up so that we no longer have to define all our search engine domains via the manifest. Instead, I'd like for users to opt-in to search engines, at which point they would provide host permissions and we would execute the filtering scripts via the scripting API. I haven't fully explored this idea yet, but if it's feasible, custom search domains may also work well through it.

KevinPayravi avatar Sep 13 '24 06:09 KevinPayravi

Good news: on my local, I've re-worked search filtering to be done via executeScript instead of via registering a content script. Works well for custom search engines. Will test a bit more and push the changes up.

KevinPayravi avatar Sep 17 '24 09:09 KevinPayravi