David

Basically, you will need to audit any other code in your theme’s functions.php or any plugins (which is probably easier to disable one by one). You’ll need to look for a PHP method called getCookie() and you can probably do a search for “getCookie(” without the quotes, to find the code that is conflicting with the new Ninja Forms code. Once you remove the conflicting method, Ninja Forms should load again. Hopefully you understand coding, otherwise this will be pretty tough.

A second option which is only a temporary fix and I personally would not recommend doing, would be to alter Ninja Forms code directly. This isn’t a good idea because it will get overwritten on an update.

Ninja Forms File:
<YOUR-SITE>/wp-content/plugins/ninja-forms/assets/js/min/front-end-deps.js

On line 176 you will see:
const getCookie = (cname) => {

This can be altered and by changing ‘const’ to ‘var’ which should not break or conflict with anything else:
var getCookie = (cname) => {

You could probably use ‘let’ instead of ‘var’ but I know ‘var’ works.

Again, you’re better off finding the conflicting code and not altering Ninja Forms directly!

Hope that helps you out.

• This reply was modified 3 years, 11 months ago by David.

While I know the power of BBQ is it’s simplicity/speed, in which removing the word is probably smarter and easier. Granted, I adapted/wrote this code, which works (with very little testing done, could have errors!) to clear out words from the current domain.

        if ( preg_match( '/' . implode('|', $user_agent_array) . '/i', get_bloginfo( 'url' ), $url_matches ) ) {
                $user_agent_array = array_diff($user_agent_array, $url_matches);
        }

Would go just before the existing plugin check:

       if ($request_uri_string || $query_string_string || $user_agent_string || $referrer_string) {

Again, the simpler solution of removing the word is probably better but just another option if you wanted to keep words in the User-Agent check while clearing out false positives automatically.

I put some print statements into the plugin itself to see what was happening. From there I visited the “Site Health” page. Expanded the REST error and it looks like WordPress sets it’s User-Agent to the WordPress/version with the current site domain.

e.g.

The REST API call gave the following unexpected result: (403) 
HTTP User-Agent: WordPress/5.6; https://domainnamewiththewordninja.com

Which seems to be where all of my problems are coming from regarding User-Agent.

• This reply was modified 5 years, 6 months ago by David.
• This reply was modified 5 years, 6 months ago by David.

@specialk
So I ended up going through all my nginx configs and made them identical and still had the issue. Checked my WordFence settings and disabled all the plugins once again.

At this point I ended up slowly commenting out piece by piece in BBQ. When I commented out the conditional isset $_SERVER[‘HTTP_USER_AGENT’] the error went away. I then started working through deleting the $user_agent_array entries. When I got to ‘ninja’ the problem disappeared. I have the word ‘ninja’ in the domain of all three sites that were having issues. So somehow it seems that ‘HTTP_USER_AGENT’ is somehow seeing the domain name along with the User-Agent.

Also, to be clear when I print out the User-Agent from the plugin itself using:
print $_SERVER[‘HTTP_USER_AGENT’];

I get:
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0

I haven’t dissected the compare enough to yet understand what is happening here. I can dig deeper but guessing you may know off the top of your head whats happening to where User-Agent is interfering with the domain name itself. Also, guessing this would be easy to replicate by adding a word from the domain your testing from into the $user_agent_array, array.

Hopefully enough info to work with, if not let me know and more than happy to dig deeper.

Also, the 2.0.10 update did fix my issue, thank you!