KirkM

@anima9 (#95) – It’s under your host’s cPanel called, “phpMyAdmin” which is the online (server) software that allows you access to your MySQL database. However, if you’re not familiar with working with your database using phpMySql then it’s highly recommended that you contact someone who does have experience and let them do it.

This is no insult to you at all but much damage can be done to your WordPress database if you don’t know what you’re doing, especially if you don’t back up the database first before you change anything which is also done in phpMyAdmin.

You’re choice of course but if you chose to try it yourself first find out how to back up and restore your database via phpMyAdmin before you do anything. ??

@mikko Virenius (#82) Many thanks. Your solution worked like a charm. And @netpagz(#83) gives a good explanation of what you might find as far as GA by Yoast entries in your DB and good advice if you’re not familiar with working with phpMyAdmin, Db queries and deleting table entries. For me it was 4 entries in my **_options that I deleted before the plugin actually worked.

Too bad that the developers have remained silent about this.

@karlwolfschtagg (#68). It’s a problem with the plugin itself, not WordPress. I’ve done some troubleshooting myself and I’ve found that the plugin is still sending data to GA but fails on the WordPress admin side of things. I finally resorted to removing the “GA by Yoast” plugin altogether and installed the “Google Analytics Dashboard for WP” plugin which, more or less, works the same way at least as far as authentication goes and it authenticates and works fine. No problems.

This isn’t the first time an update to “GA by Yoast” has messed up something with the plugin itself (these things happen occasionally no matter what the plugin is, I understand this) but this is the first time the developers have not kept us updated on the progress of the fix.

Oh, and yes, GA updates it’s analytics (for your site) every 24 hours, not in real time. By what I understand, there’s a new GA API that includes “real time” updating but it’s still in beta and is “invite only” for current GA users. Until it’s released to the public we’re stuck with our GA stats being one day behind. At least that’s what I understand.

It’s become awfully quiet around here. How about an update there, devs.

Just updated the plugin to 5.4.2–no change whatsoever. Problem still exists. Tried with both Firefox and Chrome. However, manually entering the UA code now works. This doesn’t solve the real problem of course but it’s a step in the right direction.

One thing I’ve noticed though (without manually the UA code) is that data still appears to be sending to my GA page despite the fact that the plugin appears to not be working. The analytics data for both my sites is there for the 21st of April even though the plugin stopped working yesterday morning (supposedly) with the update to 5.4.1.

I just did some testing on my personal WP powered blog (one of the two sites I mentioned in my previous comment).

I removed the latest version of GA by Yoast plugin (5.4.1) and downloaded the SVN 5.4 and 5.3.3 versions from the WordPress Plugin directory page for GA by Yoast. I used the “CleanOptions” plugin to remove any of the plugin’s entries in my “wp-options” DB table so I could install fresh.

First I installed the 5.4 version of the plugin and attempted to authenticate–same problem encountered. No difference. I removed 5.4.

I then installed version 5.3.3 (the last version that worked) and attempted to authenticate and this version failed as well. Same problem seen as with 5.4.1.

So now I’m wondering. Is it possible that Google Analytics changed something and it’s not the plugin that’s at fault? Just pure coincidence or a combination of both? Or maybe the fact that WordPress just had a security update issued (4.1.1 to 4.1.2) had something to do with it?

The bottom line for me is that no version of the plugin works now when 5.3.3 was working fine yesterday.

I’ve just checked this in Firefox 37.02 with all history deleted (I always delete all my browser history upon exit of restart) and the problem isn’t due to browser cache. If I try to re-authenticate I get the authentication code, copy and paste it into the authentication box and click “Save authentication code” and all I get is the following at the top of the page:

“There were no changes to save, please try again.”

I have javascript enabled, the uBlock extension (ad blocker and anti-tracking Firefox extension) disabled for my site so they aren’t interfering.

This problem wasn’t seen until updating to version 5.4.1 on 2 different WordPress powered sites (fully updated). One thing I noticed was that the previous version of the plugin was 5.3.3 on both sites and I’ve had no notification of any previous updates to the plugin until 5.4.1. Seems like quite a jump.

Anyway, it’s looking more and more like something is wrong with the latest version.

@laserjobs – Many thanks for the link. Nine years usinig WordPress to power my websites and I’ve never found a link to previous versions of any given plugin. Either it’s hidden or I’m just not seeing it. ??

Oh, and I solved my problem with 5.3.1. It was indeed not the plugin.

In short, the plugin’s interface (free version) is severely crippled if an ad blocker is in use in the browser. For myself, I use Firefox with AdBlock Plus and I always have it disabled for my own websites but for some reason it was enabled again for the site that had the problem with the update (probably middle-clicked the icon by accident?)

I disabled AdBlock Plus for that particular site and all is well again, the plugin updated to 5.3.1 without a problem. The plugin’s interface (including the Dashboard) is working normally now.

I tested this 3 times so I’m pretty sure about this. First time for everything?

mueggemarvin – Glad the problems is fixed for you. Who is your host by the way. Mine is Bluehost and they usually are up to date as far as PHP (and other modules) are concerned.

If your problem was fixed due to fixing a problem with your host’s PHP interpreter then something changed between version 5.3 and 5.3.1 that the devs didn’t bother mentioning in the change log. According to the change log for 5.3.1 as presented by the WP plugin update dialog box, there was no mention of say, a new minimum version of PHP that was required or something of a similar nature.

So I don’t consider this problem fixed. Something changed between 5.3 and 5.3.1 and I need to know what it was before I go bothering my host about it. Perhaps one of the developers can shed some light on this? I know that they participate in their plugins WP support forums now and then.

laserjobs – It looks like it although what is missing in the plugin’s setting is a bit more extensive as to what is not working. I was able to revert back to version 5.3 but not without a fair amount of work.

I downloaded the 5.3 version of the plugin via FTP from my other site where the plugin was not updated and uploaded it to the site where the update to 5.3.1 “killed” the plugin. Simply activating version 5.3 didn’t work–same problems as seen with 5.3.1. I had to remove all the plugin’s entries from the site’s “options” table in the database before 5.3 would work again. Once that was done I reactivated 5.3,and I was able to re-authentic and now version 5.3 is working normally. It also kept all my tracking data.

Same here. The update to 5.3.1 renders the plugin useless.No reports, fields missing from the Dashboard, drop down menu is blank in the Dashboard as well.I can’t re-authenticate, reset defaults. All links within the plugin itself have no urls attached to them–clicking them does nothing.

After the 5.3.1 update the plugin’s settings pages appear to bejust a framework with all the functions missing. That’s the best I can describe it.

Furthermore, I found that after the update, in my WordPress admin, the (collapsed) left-hand WP menu bar’s fly-out menus were disabled as long as I was in any of the plugin’s settings pages. Upon leaving the plugin’s settings pages, the fly-out menus returned to normal.

I deleted the plugin for now and won’t update the one in my other WordPress powered site until a fix is found.

@tacoverdo – I also have version 5.2.7 installed which was supposed to fix this problem. Now, the problem did change a bit once the plugin was updated to 5.2.7. Although the “re-authenticate” warning still comes up at the top of my “Dashboard” when I first login to my site’s admin, all I have to do is refresh the page or navigate to another WP admin page and the warning disappears. This didn’t happen in 5.2.6 where the warning remained persistent.

Tracking works regardless of the (5.2.7) warning as you stated it would.

Now I find that the warning only comes up on my two WP powered sites randomly but it’s still pretty often.

I should mention that I keep AdBlock PLus disabled on both my sites so it’s not affecting the problem. I should also mention that I clear all of Firefox data when I close the browser (history, cookies, Persistent, Flash and DOM cookies [via an extension], Site preferences, Active logins, Offline website data, Passwords) so I always start Firefox with a clean slate as far as the above mentioned Firefox data is concerned.

The plugin obviously works despite the occasional re-authenticate warning and at worst it’s only a minor annoyance. Sure, it needs to get fixed but with 5.2.7 it’s hardly a reason to remove the plugin.

Hope you find a solution.

I’m using the BruteProtect plugin Version 2.0.4 and just now I couldn’t log in to my site and it took a significant amount of time for the login form to appear. Once it did, I entered my username and password and got this:

Error BP100: This site is not properly configured. Please ask this site’s web developer to review for information on how to resolve this issue.

There’s no math capthcha seen.

Clicking the link referenced in the error call out above I get this:

“Error BP100 indicates that your login form is not properly configured. When the BruteProtect plugin is unable to connect to our API server, we fall back to a math-based CAPTCHA to protect your site. In order for this to work, we rely on the “login_form” action hook, which is included on the built in WordPress login form, and should be included on any non-standard forms. If you’re receiving this error, that is an indication that this hook is not being invoked.
How to fix

Simply add:
<?php do_action( 'login_form' ); ?>
within the HTML of your login form, between the <form> and </form> tags”

Okay, the captcha is obviously not being invoked and I’m using the standard built-in WordPress 3.9.1 login form. I’m using no non-standard forms.

I moved the BruteProtect plugin to another directory I use for the occasional misbehaving via FTP and I was able to log in. I moved the plugin back (into “wp-contents”) and reactivated it via my WP admin. I logged out, waited a few minutes and attempted to log in again and this time I got in with no problem with BruteProtect activated.

Looks like the latest version of BruteProtect isn’t falling back to the math captcha correctly in my case. My site is a standard WordPress installation (and has been for over 8 years) and has never used any non-standard forms.

For now I’m leaving BruteProtect activated. If the problem happens again without falling back to the captcha then I’ll leave it deactivated.

Heh, nothing like a quick response from the plugin author. Thanks, Chris.

That “bug report” was actually rather hard to word correctly. I was hoping it would come across clear enough.

In the Beta Tester plugin options you have to check the “Bleeding edge nightlies” check box before you run the update otherwise you’ll only be updated to the current versions latest pre-release “point” release and there isn’t one yet, that’s why it still states 3.8.1. Once you check the box I mentioned and run the update you’ll be updated to the latest nightly version of 3.9.

Notes and warnings:

Never run bleeding edge nightlies on a production site unless you don’t care what happens to it.

WordPress 3.9 includes TinyMCE 4.0 which is much different internally than previous versions. If you have plugins that are specifically for the TinyMCE editor (adds icons to the tool bars for example) they probably won’t work unless they have been specifically rewritten to be compatible with WordPres 3.9 and TinyMCE 4.0.

Same goes for premium and premium-style themes with specialized options that interact specifically with TinyMCE.

If you do this you don’t necessarily have to update every-single-day. I tend to update every couple of days or so.

Always back up your DB before updating to a bleeding edge nightly the first time and every time after you publish a new post.