What's the catch with calling admin-ajax.php ?

Yes, there’s a good reason.

First thing – using AJAX, allows this plugin to be compatible with caching plugins.

Second thing – every AJAX call with WP coding standards uses a beckend admin-ajax.php call. So it’s not the plugin, but the WordPress itself.

Regards,
Bartosz / dfactory

Thanks @dfactory for the answer.

Do you think if I restrict access to /wp-admin/admin-ajax.php with .htaccess method that would stop the plugin from functioning correctly?

I do restrict the whole “wp-admin” folder with .htaccess on some websites, because too many bots and remote scripts scan it permanently trying to find happiness here…

Oh, man, definitely – you should never do that! So many functionalites rely on admin-ajax.php, so fix that ASAP!

BTW, there are other ways to keep bots out of wp-admin (create and setup robots.txt file)

The problem is those bots are not friendly ones which will comply nicely to robots.txt directive, as their purpose is to break the website, find holes in plugins, trying to get site or users data, inject stuff, bruteforce everything, exploit 0-days,… and their path is mostly through wp-admin and wp-content/plugins folders…

On these installations, wp-admin is only allowed for users who did enter login/pass, so I’ll check if there is a way to cope with cookies without using /wp-admin/admin-ajax.php ??

Thanks

I understand, but I don’t support your solution ??

I understand too ??
Thanks anyway for you answers, I do greatly appreciate having this talk with you.

So I forked the sources for my own purpose and commented the line 108 to inactivate the load of fronted JS
// add_action( 'wp_enqueue_scripts', array( $this, 'front_load_scripts_styles' ) );

Then I integrated front.js to my main JS file, as well as the inline javascript produced by the plugin. And I removed the part of frontend inline script about “admin-ajax.php”.

Everything works!