itxpressnc

A little more detail for folks that may still be seeing this. We’re seeing the same error and our Hubspot widgets had disappeared off our site (for us anyway). We didn’t change anything on our site. We have CloudFlare cache enabled (and have forever). We added js.hubspot.com into the exclusion list. Ad blocking is disabled (uBlock). It’s just was not working at all. Turns out we had DuckDuckGo’s privacy plugin running (was hidden under the puzzle piece – didn’t realize it). We added js.hubspot.com to the DDG extension exclusion list – but didn’t work. HOWEVER – if you click on the extension icon when you’re at your WordPress dashboard hubspot plugin page, you can turn the extension off for the WordPress dashboard page… and now the plugin loads normally.

Having done more digging – very weird issue. Two web sites – nearly identical (same company, different subsidiaries in different cities). Same hosting platform/config, same firewall configurations (enhanced).

With option to load wordfence before WordPress, we get a ton of these unrecognized addresses. But with it off, one site gets two of these errors. THe other site works fine. Can’t tell if it’s some bad entry in a dynamic blacklist or something else. The errors only happen with IPv6 access (which is a LOT more common now that Charter and Spectrum have rolled it out for much of their residential base. ) But we’re stumped on how to get rid of these errors. We can’t hide the warnings because they happen before WordPress is loaded (which hides all PHP warnings). Our php.ini on this hosting platform is weird so we can’t easily hide them from there.

This has been an ongoing thing – we’ve seen these errors hit before, then a plugin update fixes them.

I’m seeing this behavior also. It only happens when you access the site with an IPv6 address. IPv4 works fine. I think it’s related to the preblocking option where Wordfence blocks or checks IPs before WordPress loads.

Thanks for the quick reply. I wiped out the site, started over, used the version you sent to try and everything created like it was supposed to.

FYI if it helps, our MySQL version was 5.1.66

The tabs may have been only part of the problem. I went in and edited the activation script to remove all tabs and ^M characters in the MySQL command sections (CREATE and ALTER), and then got this:

[Sat Jan 23 13:41:06 2016] [warn] [client xxxxxxxx] mod_fcgid: stderr: WordPress database error Access denied for user ‘db_wood’@’%’ to database ‘wp_woods’

OK that makes no sense. WordPress and all the other plugins can access the database just fine. I’m completely dumbfounded how I’m getting access denied errors from a single plugin.

So apparently it’s an issue with the file encoding. It looks like the plugin files are Windows encoded vs Unix encoded (or UTF8). So in the activation script where commands are indented so nicely:

$wpdb->query(“CREATE PROCEDURE upgrade_$table()^M
BEGIN^M
IF NOT EXISTS( SELECT NULL^M
FROM INFORMATION_SCHEMA.COLUMNS^M
WHERE table_name = ‘$table’^M
AND table_schema = ‘$db_name’) ^M
THEN^M
CREATE TABLE $table ($fields_to_create, PRIMARY KEY ($primary)) ^M

The CREATE has 4 tabs in front of it and they’re being fed into MySQL instead of ignored.

Trying to find a setting that’ll ignore this – but first time I’ve ever run into something like this…

So apparently none of the plugin tables are getting created. Found this in error_log:

[Sat Jan 23 13:41:07 2016] [warn] [client x.x.x.x] mod_fcgid: stderr: \t\t\t\tCREATE TABLE wp_estatik_manager_types (type_id int(11) NOT NULL AUTO_INCREMENT, type_title varchar(255) NOT NULL, PRIMARY KEY (type_id)) , referer: https://xxxxxxx.com/wp-admin/plugins.php?plugin_status=all&paged=1&s

What’s with the tabs in front of all the commands? Still digging…