ASP scripts in the footer should be the rule

Home Forums Product Support Forums Ajax Search Pro for WordPress Support ASP scripts in the footer should be the rule

This topic contains 1 reply, has 2 voices, and was last updated by Ernest Marcinko Ernest Marcinko 8 years, 10 months ago.

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
  • #5757
    Jacques Letesson
    Jacques Letesson

    Hi there,

    As I always want to optimise the performance of the website in develop, I usually dequeue all scripts that are loaded in the header.

    Then I enqueue again all the scripts in the footer. It is a tedious task but it is mandatory if you want good performance.

    With ASP, it’s an other problem. Even if I do that, some JS is injected within the shortcode.

    Inside includes/views/asp.shortcode.php you require asp.shortcode.script.php

    Isn’t it possible to output this script in the footer like it should?

    I understand that this script output the options for ASP but I’m sure there is room for performance improvement here.

    ASP is an amazing tool, I’ve been amazed by it more than once.

    However, in order for me to use it on production website I need the scripts to be loaded at last.

    Thank you for your understanding.


    Ernest Marcinko
    Ernest Marcinko


    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.

    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.