Abigailm

Actually, I’m not entirely certain that the fix provided @drivengalle has solved the problem. In reviewing my error logs, I see that the message was only thrown off twice, on [06-Feb-2017 09:06:55 UTC] and [07-Feb-2017 09:08:50 UTC]. I made the correction about an hour after the last error.

However, I shifted to PHP 7.1 several days earlier — so at least for me, it may be something else causing the problem. I’m going to leave things are until after 9:10am UTC on 8 Feb to test. After that I am going to revert back to the original distribution file and monitor closely.

I might have jumped the gun because I am seeing a lot of error messages being logged from various themes and plugins with the shift to PHP 7.1 – so I was just going through error logs and reporting as I found them. But now I am questioning whether this is actually a problem.

Just a note for anyone considering a PHP upgrade– I’m running PHP 7.1 and the plugin functions fine for , and it is not throwing off any errors. The code problem seems to relate to a minor issue on the dashboard, but doesn’t appear to impact anything on the front end.

I think the error impacts display of server information on the “Overview” screen in the admin area. I see this line:
MySQL version:Undefined

So I am guessing that is the only issue, caused by the use of the deprecated mysql_get_server_info

• This reply was modified 9 years, 4 months ago by Abigailm.

, using forums for tech support is much slower, and can create a lot of confusion.

In this case there are bugs in the code that clearly have impacted thousands of sites, and many of the people posting are not seeking support, but trying to share information about the nature of the error.

Sometimes crowd sourcing a problem is a better way to go, especially when so many are impacted. If everyone who had a problem ignored theses forums and went straight to your site, then you would be swamped with many more requests for support.

But many people who read about the problem here will recognize that the problem is still unresolved, and disable or roll back the plug-in, to wait until a stable release is issued.

For you, this situation has become an urgent matter requiring diligent effort to fix as quickly as possible. But for many of your users, the best course of action is to simply wait things out until the matter is resolved. And this forum is the best source of information for users to determine whether or not the issue has been solved.

Scott, I’m tired of these stupid arguments and games.

I didn’t have a support request yesterday or today.

Yesterday I had a feature request; today I reported an error message from my logs. I also confirmed that the error message that Kona reported from your site support submission form is the same that I got yesterday when I tried to comply with your demand that I submit my feature request there.

These are things meant to help you debug and improve your product. If users are encountering errors on forms on my sites, I want to know, so I can fix them.

Obviously you are reading these forums, given that you take the time to argue with and chastise everyone who posts .. so there’s no reason for me to want to mess with complicated forms on your web site anyway.

You pushed out an upgrade last night with a serious conflict with a common and widely used plugin (Wordfence), and it brought down a lot of sites. Since then you have been trying to fix things but there are flaws in your fixed code so it just creates more problems.

Your problem was bigger than it had to be because you have designed your plugin to auto-update without giving clear notice to users, when that is unusual behavior for a plugin. So instead of a few hundred users updating their sites today and reporting a bug back to you, you pushed the error out to thousands. That is why experienced developers generally don’t force updates.

Now because you pushed out the bad update, you’ve been scrambling to fix it and rushing out one fix after another… and obviously don’t know how to fix the problem that is generating the repeated error message and clogging up server logs.

And right now you are only dealing with the first wave of complaints, from those of us who are attentive to our web sites and sophisticated enough to quickly figure out what is going on. (For example, we have FTP access and know where to find wordpress error logs). There are a whole lot of users who aren’t paying attention and don’t even know yet that there is something wrong with their web sites; and some of them are on cheap hosting plans and are going to find out they have a problem when their error logs break their quota and their sites stop functioning.

And you are spending time debating online with people who are rightfully annoyed at the problems you’ve created… for reasons I can’t fathom.

I think you would be wise to issue a new update that is a rollback to version 1.9.9.8.1 (but numbered 1.9.9.8.6) — go ahead and push that out — and after that disable the automatic update feature until you can debug properly. After that, if you want to restore the automatic updated feature, I’d suggest that you make it a prominent option that users can toggle on when they activate the plugin.

At least that is what I would do if I were in your shoe.

But you don’t have to take my suggestions. I don’t care. I’ve already rolled back my sites and disabled the updates, and will implement and roll out other solutions to the sites I manage. The only reason that I haven’t already removed this plugin entirely from all the sites is that I want to have time to test whatever alternatives I decide on first.

Good night.

We simply ask users to work through the troubleshooting guide, the FAQs, and the Known Conflicts page.

As noted above, the problem is that the form throws up that error message even for users who HAVE checked the troubleshooting guide already. So in my eyes it is just a bit of poorly coded javascript intended to discourage people from submitting support requests.