Hi!
Well, there is a reason why that script is in that file. The problem with shortcode usage. There is currently no solid way of “detecting” which search shortcodes are used on the server side, before the footer loading. (not to mention that the user can use the shortcode directly in the theme files, which makes it even more difficult). So the only solution would be to instantiate every search instance created within the header or the footer – it’s excessive code, I’m not sure about the performance impact.
I figured out a solution though, but I haven’t had time yet to implement. Basically, I would create another javascript file instead of the script tags, which would only initialize the instances it finds on the page – and the configuration would be stored in a separate element or within a base64 encoded serialized data attribute. This solution should completely get rid off the inline scripts – but I see potential issues with dynamically loaded pages and other stuff.
I guess what I can do for the next release is to add a compatibility option for the user to choose to initialize the search instances by:
– Inline scripts (default)
– Header script
– Footer script
– Dynamically in the footer (the solution I just described)
I’m working on bugfixes and updates on this plugin on a daily basis, I will try to prioritize your request as much as I can.
Best,Ernest Marcinko
If you like my products, don't forget to rate them on codecanyon :)
