audiofoundry

Hi Michael,

I apologise about the delay in getting back to you on this. I came back to this today to finally get around to sorting it, and I’m a bit shocked to find the situation is actually worse than I initially thought it was.

I had put this issue off because I thought it was only the username being indexed but now I see that you’ve got the user_id in there too.

Could you please tell me why on earth your plugin indexes user_login by default? The fact it’s even called that feels like a spit in the face to the users’ security and privacy.

Short of providing the password too, it feels like the plugin is aiming to pull as much sensitive data as possible about the users.

I will try using the filters you provided but to be honest I think the defaults this plugin has on this are HORRIBLE – an obvious security and privacy violation.

Perhaps adding a manual filter should be required to check if your users want to send the user_login and user_id to be indexed, rather than the other way around? It seems that the current setup is simply assuming that everyone is fine having their users’ sensitive data pulled and sent to a third party. Requiring manual PHP edits to stop that happening seems to be the wrong way around.

Why aren’t you guys blocking this by default? Surely only the display name is needed to generate the author facet on the search page? It leaves a bad taste because we all know that the majority of your users will simply plug-and-play the plugin, and perhaps never even check this, yet I would wager that almost all of them would say they wouldn’t want this happening if they were informed and asked about it.

Hi there,

I apologise for my own delay in reply, but I just wanted to confirm that the new version of the plugin does indeed resolve this bug. Joli Table of Contents and Supportcandy now work together without issue.

Thank you!

Hi Saumya,

Thank you for getting back to me on this. I don’t know why, but it seems that it is the plugin ReviewX that is causing this error.

Deactivating ReviewX allows your menu module to return. Very weird! Maybe they have put something in a recent update that conflicts with your plugin.

I will let them know that this is happening and hopefully they can patch this.

(pic below showing module loading correctly with ReviewX deactivated)

Hi Mark, thank you for putting this forward as a feature request, that’s much appreciated! I’m glad the team like the idea and look forward to giving it a go when it’s ready ??

Honestly all three of username, nickname, and email. Particularly username and nickname. Thank you.

Thank you for the reply and screenshot but it seems that tab doesn’t display for some of the default fields. Username, Nickname, and Email don’t show a validation tab?

Hi Michael,

Thank you for such a prompt response.

Yes sorry for not specifying. Indeed you are correct that it is post_author which is pulling the username.

Thank you for providing those filters, I shall have a go with those and see what happens.

Hi Angela,

Brilliant, thank you for getting that changed and updated so quickly!

Thank you, I hope you have a great week also!

Hi Michael,

Thank you for your rapid reply!

Unfortunately I can’t get this to work at all for some reason. I copied and pasted your snippet in to my child theme functions.php, and changed the terms to the names listed by the plugin ‘Find My Custom Post Types’ .

I reindexed from the Algolia tab, then cleared cache and opened a private tab so there wouldn’t be any cookies. Frustratingly, nothing has changed and I am not sure why?

Is there perhaps a way to do the inverse? Rather than blacklist post types that are not wanted, instead only allow Posts, Pages, and Products to display?

My apologies for such a tedious issue here, and thanks once again for your help with this.

Hi Michael,

I apologise for bringing this old thread back up.

One of the custom post types I want to disallow is called viwec_template. Do I need to replace every instance of custom_post_type in the snippet with the name? Or just the second line? Would it look like:

function mb_blacklist_viwec_template( array $blacklist ) {
    $blacklist[] = 'viwec_template';

    return $blacklist;
}

add_filter( 'algolia_post_types_blacklist', 'mb_blacklist_viwec_template' );

Or is it just the second line, like

function mb_blacklist_custom_post_type( array $blacklist ) {
    $blacklist[] = 'viwec_template';

    return $blacklist;
}

add_filter( 'algolia_post_types_blacklist', 'mb_blacklist_custom_post_type' );

Thank you for any help you can offer on this.

Ahh I see! Thank you very much for those hook codes. That has solved it perfectly!

Thank you again for your help with this!

Hi Saumya,

Thank you for your prompt reply. That all makes a lot of sense!

That screenshot was really helpful and it’s awesome to know that you have so many important cookies bypassed by default.

Thanks again!

Hi Fernando,

Troubleshooting this situation actually helped me find out that there was a way to use the Cloudflare Supercache by using Cloudflare Workers rather than using the /?swcfpc=1 URL addition which relies on Page Rules. Those URLS had bothered me for a while so I made the switch, and the lightbox now works perfectly for both logged in and logged out users.

As a result, I did not test the preloader to see if this was also a fix, so unfortunately I do not know if that would have also worked. However, the fact that the lightbox works perfectly now that Supercache is not adding any URL parameters seems to suggest that it was indeed the ‘/?swcfpc=1’ which was causing the issue.

Hopefully that information is of interest to you! ??