JG Web Development

Hello @absoluteweb,

You are welcome! Currently, it is not possible to disable federated multi-search. We will add the ability to do so in the next release of the plugin. Look for the ability to do this within the next couple of weeks. Thank you.

Hello @absoluteweb, thanks for your interest in Scry Search. I will do my best to address all your questions here. Let me know if I misunderstood anything.

• Right now, Scry Search does not include any custom blocks or shortcodes to replace they built-in WordPress search blocks. This is what allows the plugin to operate with zero frontend changes to the site: it intercepts search queries regardless of where they come from, and uses Meilisearch to find results. To limit a particular search bar to only search pages, as opposed to searching all indexes, we do plan on supporting a url parameter post_type=<enter_post_type_here> in the future. This is how most default search bars from plugins like WooCommerce implement their search filters by default, which would allow Scry Search to work seamlessly with them. Would this solve the problem you mentioned first, about having a particular search bar only search pages?
• As for Scry Search’s autosuggest filling in in tandem with the other plugin’s auto suggest, we have a solution for that. In the “Search Settings” tab for Scry Search, there is a setting at the bottom called “Class Selector”. You enter a class of your choosing into this box. Then, you can apply this class to all search forms on your site that you want to use Scry Search auto suggest on, and auto suggest will only apply to those forms. So you can leave that class name off of the form from your screenshot above, and then Scry Search autosuggest will not appear there, removing the “double autosuggest” issue you were having.
• As for your last concern, which seems directly related to your first one (search bars on one page only searching through pages, search bars on another only searching products, etc.), we will get to work on publishing a change to address this asap. We will first release support for searching indexes based on a url parameter, and if that does not fully meet your needs, then we will begin looking in to developing a custom block/shortcode. I appreciate this piece of feedback in particular, because we want to develop this plugin directly in response to user feedback!

We appreciate your interest in switching over to our plugin. If you are willing to work with us by providing feedback through the development process, we will be able to publish patches that address your needs. Expect to see that initial patch within 1-2 weeks, and then we can take a look at whether a fully custom Scry Search block+shortcode is in order. Thanks!

Erlisa,

Thank you very much for the kind words. I am glad everything is working well for you. Please let us know if you have any more feature requests/issues with the plugin. And if the plugin is working well for you, please consider leaving a review, it really helps a lot! Thank you very much, have a great day!

Hello Erlisa,

We are very glad you are using our plugin. This is an excellent suggestion, and is something that has been on our list of features to add to the plugin for a while now. Due to your request, we will bump this up in the priority queue. Plan to see a patch this week addressing this issue. Apologies for the inconvenience in the meantime!

Great. Just sent you an email. Thanks for reaching out.

Hello,

Thank you for taking the time to look over my plugin and to provide feedback.

Both of the things you mention are certainly possible. Let me address them in order:

• Firstly, the use of a custom post type instead of an external api call to populate the verse card would certainly work, but there are some things I would have to consider before taking the entire plugin in that direction. Firstly, it would likely be a lot on the website administrator to load all the content for all the custom post types for every Bible verse onto the site. Even if they only upload verses as they need them, it would likely add a lot of time to the content creation process. What do you think of this concern? The initial idea of this plugin was to be a quick and convenient drop-in for organizations to include verse on their site without adding more work to their current workflow. If, however, I were to switch to using custom post types, it could be implemented in a couple different ways:
  • All the verse content could be rendered to the webpage on the initial page load using a content filter hook. This method would result in no loading time when a reference is clicked, but a higher initial page load time. Also, no switching translations under the current implementation would be possible.
  • WordPress REST API call. The api call could be made to the internal WordPress api instead of to an external api. This would be a tidy upgrade of the current system, and custom post types could be used in the api handler.
• As for using a taxonomy/setting for search references, that is overall a good idea. For instance, I could support “II Peter …” in addition to “2 Peter …”. This is something I will definitely consider adding when I make another update to this plugin.
• Preferred version storage is something I also plan to add at some point… and use of a cookie is not a bad way to approach that… it will either be that, or enforced by the site admin in a wordpress setting.

Currently, I have several other projects going on that prevent me from devoting a lot of serious time to adding features to this plugin. I am currently in “maintenance mode”, meaning that I am fixing breaking issues at this time, and not adding new features. However, at some point in the near future I hope to return to and expand this plugin. In the meantime, if you are able, feel free to fork the repo and make changes. If you make a pull request, I’ll try to review it and possibly merge it into the main version of the plugin. Otherwise, rest assured that this plugin is not abandoned. Thanks for all your help and insights.