Placeholder position in search button

Home Forums Product Support Forums Ajax Search Pro for WordPress Support Placeholder position in search button

This topic contains 21 replies, has 2 voices, and was last updated by renad renad 1 month ago.

Viewing 15 posts - 1 through 15 (of 22 total)
  • Author
    Posts
  • #40701
    renad
    renad
    Participant

    Hello, I have a problem after upgrading to version 4.24.2.

    The problem is that after upgrading from version 4.24.1 to version 4.24.2, the “vertical” position of the placeholder in the search buttton has changed.

    No changes were made to the Ajax Search Pro settings, only the plugin was upgraded.

    I am attaching a screenshot that clearly shows the problem.

    Site with plugin v4.24.1 = OK: https://blog.gtowizard.com
    Site with plugin v4.24.2 = error: https://wpbakery.renad.sk

    The plugin settings are 100% the same on both sites.

    Thanks for the solution, Dusan

    • This topic was modified 1 month ago by renad .
    • This topic was modified 1 month ago by renad .
    • This topic was modified 1 month ago by renad .
    • This topic was modified 1 month ago by renad .
    Attachments:
    You must be logged in to view attached files.
    #40712
    Ernest Marcinko
    Ernest Marcinko
    Keymaster

    Hi Dusan,

    Thank you for the details, it helps a lot.

    The issue is caused by unintended HTML code, which is not coming from the plugin. See this screenshot of the final page output: https://i.imgur.com/oJDEina.png
    There are line breaks added for the empty line codes, which then push the input field.

    This usually happens when the plugin shortcode is used in a text block of some sort, which converts text to HTML, so line breaks, empty lines etc.. are wrapped by extra HTML tags. My guess is, that in the new release there is a slightly different indentation, and more unwanted HTML is added by the formatter.

    If you use a widget or a block of some sort to hold the search shortcode, make sure to switch it to a shortcode or HTML block instead of a plain text block, so indentaion is not converted to HTML tags.

    Best,
    Ernest Marcinko

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


    #40713
    renad
    renad
    Participant

    Hello,
    I understood everything you wrote.

    The problem is, however, that both websites are 100% identical = with the same The7 Theme template, the same plugins, the same version of WordPress, …

    In other words, the website “wpbakery.renad.sk” is a 100% copy of the website “blog.gtowizard.com”

    The website “wpbakery.renad.sk” was created only to demonstrate what happened after the upgrade from 4.24.1 to 4.24.2

    If I now return the old version 4.24.1 to the “wpbakery.renad.sk” website – it will appear fine – I have already tried that.

    #40714
    renad
    renad
    Participant

    I send one screenshot

    Attachments:
    You must be logged in to view attached files.
    #40716
    Ernest Marcinko
    Ernest Marcinko
    Keymaster

    I understand that, still the issue is unrelated to the plugin – the unwanted line break HTML code is not outputted by ajax search pro.
    There is very like an extra line break character in the shortcode output in the newer release (as we changed and added new aria-labels), which is converted to the an actualy line break HTML character – and that should not happen whatsoever, nothing should ever change or temper shortcode outputs. In other words the plugin output code is altered by the container in which it is placed into, and that is the cause of the problem.
    This also happens on the other site as well with the previous release, the difference is only a single line break, so the “push” is not apparent.

    The best and quickest way to resolve this is to use the proper widget for the shortcode, so that it is considered as HTML instead of simple text – so it is not altered by the widget handler code.

    Best,
    Ernest Marcinko

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


    #40717
    renad
    renad
    Participant

    I’ll try to explain it like this:
    I am sending the page code for 4.24.1 and the page code for 4.24.2

    As you can see, after upgrading to 4.24.2 your plugin “generates” one empty line = <br>

    Note:
    your shortcode “[wd_asp id=1]” is inserted as plain text (not formatted text)

    Attachments:
    You must be logged in to view attached files.
    #40719
    renad
    renad
    Participant

    There is only one solution:

    Tomorrow I will create a working 100% copy of “blog.gtowizard.com” for you with version 4.24.1 that displays correctly.

    At the same time, I will send access to the server – and you yourself can then upgrade to version 4.24.2 – and you will see the result.

    • This reply was modified 1 month ago by renad .
    #40721
    Ernest Marcinko
    Ernest Marcinko
    Keymaster

    The plugin does not generate any <br> empty characters – that is what I am trying to say. That is not coming from ajax search pro, please understand that. There are also empty paragraphs injected to the final plugin code as you can see on the screenshot. None of that is coming from ajax search pro.

    Empty lines are only present as part of the HTML code formatting, as /r/n characters, which is perfectly normal. The problem is, that these lines are converted further into HTML by the widget handler, that is a huge problem.

    This conversion usually happens when a TEXT widget is used as a container for HTML or shortcode like in your case – where the widget output code is further processed to add paragraphs and empty lines as HTML.

    The reason why it seeming is okay on the previous release is, that there are fewer lines of indentation used because we have changed some attributes on the form controls.

    To test, you can place the plugin shortcode anywhere into a post content or into the template directly – you will see the output will be correct.

    To resolve this, just switch the widget container to a HTML or a shortcode container and it will be immediately resolved.

    Best,
    Ernest Marcinko

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


    #40723
    renad
    renad
    Participant

    You wrote yourself:

    “The reason why it seeming is okay on the previous release is, that there are fewer lines of indentation used because we have changed some attributes on the form controls.”

    So the empty line (br) could not have arisen by itself. As I already wrote, your code is inserted as RAW text (HTML text)

    So I’ll try to help myself somehow through CSS styles, I simply have no other option 🙁

    Thanks for now.

    • This reply was modified 1 month ago by renad .
    #40725
    Ernest Marcinko
    Ernest Marcinko
    Keymaster

    If you simply test the shortcode anywhere, you will see the correct output without these added line breaks and paragraphs.

    There are no br tags within the plugin output, nor any empty paragraphs. They certainly arent coming from thin air, but from the container widget. It is a common practice for text based widgets to convert emtpy lines to paragraphs as well as line breaks to br characters before the final output is printed.

    Best,
    Ernest Marcinko

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


    #40726
    renad
    renad
    Participant

    Hello,
    as a temporary solution I used CSS:

    #ajaxsearchpro1_1 .probox .proinput input.orig {
    margin-top: -20px !important;
    vertical-align: middle;
    }

    Here is result wit 4.24.2
    https://wpbakery.renad.sk

    • This reply was modified 1 month ago by renad .
    Attachments:
    You must be logged in to view attached files.
    #40729
    renad
    renad
    Participant

    After adding your own CSS, it already works correctly everywhere (header, page, post) – and regardless of whether it is HTML plain code or Formatted text.

    Link: https://wpbakery.renad.sk/placeholder/

    Unfortunately, the error is in your upgrade 🙁

    Thank you for your time, Dusan

    Attachments:
    You must be logged in to view attached files.
    #40733
    Ernest Marcinko
    Ernest Marcinko
    Keymaster

    Your CSS code does not apply for those instances… It only applies for the header search, because it has a different IDs – DOM elements can’t have the same IDs, it is invalid HTML.
    When I apply the CSS to those searches as well, it becomes apparent: https://i.imgur.com/6rnz5Cj.png
    Also, if you remove the CSS code the header search will be broken, while the other two will look fine: https://i.imgur.com/cpsdiNG.png

    When I look at the source code of the search on the page, it is correct: https://i.imgur.com/oaKs7rX.png
    vs. look at the source of the header search: https://i.imgur.com/FaUp6Ui.png

    Best,
    Ernest Marcinko

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


    #40734
    renad
    renad
    Participant

    OK, I will try to contact the author of the theme The7, how to insert the raw html code into the header.

    This is currently handled in The7 theme via the Microwidgets shortcode.
    I am attaching 2 screenshots.

    Thanks for the overall explanation.

    Attachments:
    You must be logged in to view attached files.
    #40738
    Ernest Marcinko
    Ernest Marcinko
    Keymaster

    You are welcome, thank you for the details!

    There is still one thing you can try. There is a hook available to modify the plugin HTML output. In theory if that would be minified, then the br/p tags will not be appended.

    Try adding this code to the functions.php file in your theme/child theme directory – make sure to have a full server back-up first for safety. For more details you can check the safe coding guidelines.

    add_filter( 'asp_shortcode_output', 'asp_minify_shortcode_output', 10, 1 );
    function asp_minify_shortcode_output( $output ) {
        $search = array(
            '/\>[^\S ]+/s',
            '/[^\S ]+\</s',
            '/(\s)+/s',
            '/<!--(.|\s)*?-->/'
        );
        $replace = array(
            '>',
            '<',
            '\\1',
            ''
        );
        return preg_replace($search, $replace, $output);
    }

    If all goes well, the line break will disappear.

    Best,
    Ernest Marcinko

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


Viewing 15 posts - 1 through 15 (of 22 total)

You must be logged in to reply to this topic.