pwewegama

It does not affect my site. Thank you for addressing for future releases.

Hi guys,

I have fixed the HTTPS issue myself by changing the img src of the search icon within the php file to a search icon I actually found in the plugin source code. I think the developers must have just forgotten to update the code. I have detailed the instructions below.

It might look like many steps but it’s fairly easy and you do not need coding experience to fix it. Just some copy and pasting.

1. Go to https://www.ads-software.com/plugins/helpie-faq/advanced/ and scroll down to the bottom. Select 0.8.0 and click download. If the version is not available, that means that HelpieFAQ has rolled back to 0.8.0 because of a separate problem they were having with 0.8.1. In that case, you can download 0.8.0 from the main plugin page (https://www.ads-software.com/plugins/helpie-faq/). Do NOT download 0.8.1 as they are currently working on fixing a bug the causes some websites to break. At the time of this writing, they are still working on the bug in 0.8.1 so I cannot speak to any versions that come after. I did all of this with 0.8.0.

2. Once the file has downloaded, go ahead and unzip.

3. Go into the unzipped folder and open up the following file in your favorite text editor: helpie-faq/lib/stylus/components/search.php

4. Within the get_view function, look for the third line down which should be $html .= '<img class="search__icon" src="https://www.endlessicons.com/wp-content/uploads/2012/12/search-icon.png">';

Change this to the following:
$html .= '<img class="search__icon" src="' . HELPIE_FAQ_URL . '/assets/img/search-icon.png" >';

This will cause the search icon to be delivered from the plugin asset folder itself instead of a 3rd party non secure URL. Thus, as long as your website is running over HTTPS, this icon will now be served over HTTPS.

5. Save and close everything. Delete the old zip file so you don’t confuse yourself with which one you need to upload. Then compress/zip up the entire helpie-faq directory you were working with.

6. Go to your plugin page on your WordPress admin dashboard. Deactivate and delete the old HelpieFAQ plugin. I chose “temporary deactivation” when it asked me for a reason.

7. Manually upload your updated plugin by going to Add New > Upload Plugin in the plugins page and uploading the new zip file.

8. Once it has finished installing, activate it.

Now go back to your website pages that use HelpieFAQ and you should see the search icon now being served over HTTPS directly from your plugin folder. For those who were previously seeing Not Secure should now see the secure padlock icon on Chrome and Firefox.

If you are still seeing Not Secure, make sure it’s not caused by some other asset on the website. You can always right click and inspect the search icon to confirm that the src has been changed.

• This reply was modified 4 years, 8 months ago by pwewegama.

What do you mean by “look at your backend.” What exactly are you looking for?

I have emailed you the plugin version that’s causing the bug.

I am getting this new error for 0.8.1 now:

main.bundle.js?ver=0.8.1:1 Uncaught TypeError: Cannot read property 'addEventListener' of null
    at Object.eventHandlers (main.bundle.js?ver=0.8.1:1)
    at Object.init (main.bundle.js?ver=0.8.1:1)
    at HTMLDocument.<anonymous> (main.bundle.js?ver=0.8.1:1)
    at i (jquery.js?ver=1.12.4-wp:2)
    at Object.fireWith [as resolveWith] (jquery.js?ver=1.12.4-wp:2)
    at Function.ready (jquery.js?ver=1.12.4-wp:2)
    at HTMLDocument.J (jquery.js?ver=1.12.4-wp:2)

When I click on the error main.bundle.js?ver=0.8.1:1, it takes me to the following:

eventHandlers: function() {
            var e = this;
            document.querySelector("section.helpie-faq").addEventListener("click", (function(e) {
                1 != e.target.classList.contains("accordion__header") && e.stopPropagation()
            }
            ), !0),
            jQuery(".accordion__header").on("click", (function(o) {
                o.preventDefault(),
                o.stopPropagation(),
                e.onHeaderClick(this)
            }
            ))
        },

with the line document.querySelector("section.helpie-faq").addEventListener("click", (function(e) { underlined as the cause of the error.

• This reply was modified 4 years, 8 months ago by pwewegama.

Hi,

https://platinumcustompool.com/

WordPress version: 5.4.2

PHP version: 7.0.33

MySql version: 5.7.30 – MySQL Community Server

Thanks.

Hi there,

I am using Astra Version: 2.4.5 by Brainstorm Force.

Hi There,

Unfortunately I cannot give admin access to anyone on the site. I have rolled back to v0.8.0 which got my website back online.

Should I reinstall v0.8.1 so you can see the error in the web console?

Hi,

I’ve noticed this type of question being asked several times in the forum where the user asking for help always seems to figure out the issue on his/her own but never shares the solution.

I too ran into a similar problem and figured out the solution below. I should also mention that I am using the “page scroll to id” plugin which I believe most of you are using as well. This plugin enables a link with a hash to be clicked so that it scrolls to the element with the ID that matches the value of the hash (on the same page or different page).

Problem: URLs with hashes meant to scroll to certain sections on a specific page do not work when in a different language (subdirectory) but work for the default language (no subdirectory).

For an example, if there’s a link on https://example.com (default English site) that points to “/about/#OurTeam”, behavior works as expected where clicking the link will load the About page and scroll to the ID ‘#OurTeam.’ However, when that same link is clicked from https://example.com/br (Portuguese version of the site), the About page will load but will not scroll to the ID “#OurTeam.”

Solution:
Tl;dr – Make sure the “Force language in custom links” in your TranslatePress plugin settings is set to “Yes.” Then change EVERY href for every link on every page to the absolute version of the URL (https://domain.com/path/to/the/page/#OptionalHash). Don’t forget the links in the menu, header, and footer.

Long version: The issue arises primarily because of a trailing slash that is added to the URL when you click a link from a subdirectory (non default language of the site) of the site. In the example above, clicking the link from the default language (English) of the site will result in “https://example.com/about/#OurTeam” while clicking it from the Portuguese version of the site will result in “htttps://example.com/br/about/#OurTeam/”.

Besides the ‘br’ in the URL, notice the trailing slash at the end of the URL in the Portuguese version. This breaks the functionality of plugins like “page scroll to id” because now it’s looking for an ID called “#OurTeam/” instead of “#OurTeam”. The fix to this issue is to use absolute URLS throughout your entire website (links, buttons, menu, etc). So in our original example, instead of having the href of the link simply be “/about/#OurTeam”, it should be “https://example.com/about/#OurTeam”. TranslatePress handles adding the language subdirectory in the URL automatically, so don’t worry about that.

The second problem I noticed is that having relative URLs on the page that you end up on after clicking a link (when on a non default language version of the website) will also break the scrolling functionality for plugins like “page scroll to id”. You can actually see this happen if you open up your browser’s developer console and click some link that’s not scrolling to a certain section of a page. You will probably see errors being thrown about to some ID on the page (and those IDs will have a trailing slash too).

So even if you use the absolute URL for a link to get to a different page (when on a non default language version of the site), the website won’t even get a chance to scroll to the correct ID because the plugin basically complains and crashes because of some relative URL on the page you end up on. This only seems to happen when you’re on the non default language version of the website. I do not know why.

The fix here is to make sure ALL the URLs of the page you are landing on is also using absolute URLs. And of course, avoid adding your own trailing slashes when you do.

Hi @mikes41720,

Thank you for your quick response. I followed the instructions and it worked perfectly. My mistake was misidentifying the YOAST SEO sidebar settings (which doesn’t have a social tab) with the one at the bottom of the page (which has a social tab).

I will mark this as resolved now. I appreciate the support!

• This reply was modified 4 years, 9 months ago by pwewegama.

@pauplesupport

Hi There,

When do you think we can expect the next release with this fix?

Thank you!

• This reply was modified 4 years, 9 months ago by pwewegama.

@rafinkhan Thank you! I appreciate it.

@rafinkhan Thank you for getting back to me.

Why does ‘Ajax’ Loading functionality need to be available for the Filterable Gallery? It looks like you are preloading the data of all the elements in the gallery on page load and the Load More button simply appends to the gallery div using the existing locally stored data.

Would it not be possible to search for the string query from the locally stored data object that contains the data for all the elements instead of simply searching from the ones that are showing up on the DOM?

• This reply was modified 4 years, 9 months ago by pwewegama.

@pauplesupport Thank you for your support! It’s much appreciated.

@pauplesupport I have updated and everything is working as it should!

However, there seems to be errors being generated in the console log if the search query includes any spaces. More specifically, the errors occur the for all characters entered in after a space.

From what I can tell, this error does NOT affect the user experience in anyway, but I thought I should let you know in case it causes any trouble down the road.

Here is an example of typing in “What is” into the search bar. The errors start right after typing in the ‘i’ of the word ‘is’:

Uncaught Error: Syntax error, unrecognized expression: [data-search-term *= what is]
    at Function.ea.error (jquery.js?ver=1.12.4-wp:2)
    at ea.tokenize (jquery.js?ver=1.12.4-wp:2)
    at ea.compile (jquery.js?ver=1.12.4-wp:2)
    at ea.select (jquery.js?ver=1.12.4-wp:2)
    at ea (jquery.js?ver=1.12.4-wp:2)
    at Function.ea.matches (jquery.js?ver=1.12.4-wp:2)
    at Function.n.filter (jquery.js?ver=1.12.4-wp:2)
    at z (jquery.js?ver=1.12.4-wp:2)
    at a.fn.init.filter (jquery.js?ver=1.12.4-wp:2)
    at HTMLElement.<anonymous> (main.bundle.js?ver=0.8:474)
    at Function.each (jquery.js?ver=1.12.4-wp:2)
    at a.fn.init.each (jquery.js?ver=1.12.4-wp:2)
    at Object.onSearchKeyup (main.bundle.js?ver=0.8:457)
    at HTMLInputElement.<anonymous> (main.bundle.js?ver=0.8:507)
    at HTMLInputElement.dispatch (jquery.js?ver=1.12.4-wp:3)
    at HTMLInputElement.r.handle (jquery.js?ver=1.12.4-wp:3)

@pauplesupport Perfect. Thank you!