A Twitter contact from Kuala Lumpur sent me a message saying that she couldn’t access my web site and asked if I have geo-blocking turned on. Can’t imagine why I would and of course, I don’t. I immediately dived into Google Analytics to see if traffic from Malaysia was being blocked. It wasn’t. I’d had about 16 page reads in the last 30 days from Kuala Lumpur.
So I wrote back explaining that the web site must be blocked at her local ISP – it sometimes happens that ISPs block sites they suspect are spreading malware or doing something similarly antisocial and evey now and then some get blocked in error, which is what I think may have happened to HaveMacWillBlog in this instance. In any event, I suggested that if she wanted to look at the web site, she use Anonymizer.com.
You may not know what Anonymizer is. It’s a web site and service for those who are paranoid (and believe that some agency is tracking their every move) or for those who’d like to circumvent blocks that they encounter on the Internet. Using its service, you can surf the web anonymously – and because it routes you to your target sites it will circumvent most blocks, including geo-blocks. My friend from Kuala Lumpur was able to both visit my web site and visit others sites that were geo-blocked to her normal connection.
A WordPress Performance Issue
While messing with Google Analytics I stumbled into a plugin that I thought I’d try out. But when I tried to load it in WordPress Admin, I noticed that the performance of WordPress was suddenly terrible. So terrible in fact that I couldn’t load it. I didn’t remember changing anything that could have caused that, so I spent a while examining performance logs and then raised a trouble ticket with my hosting company.
The hosting company responded by recommending that I check the plugins. I responded by saying that I hadn’t changed anything and they responded by suggesting that I remove them anyway. This was sound advice – born of experience I suspect. The easiest way to unplug all the plugins is to change the plugin directory names on the host, but I was in one of those moods where I wasn’t thinking. I was nervous because I was forced into doing this on the live web site. So I went through the tortuous process of unplugging then one-by one, through WordPress.
It was tortuous because it took a long time. And then to compound the problem, DAMN, suddenly my Internet connection went on the fritz. It was late Saturday night, and the web site had been running like a snail all day. If you tried to access it directly the likelihood was that you’d get a 404. That happened about half the time I tried it. The rest of the time you’d get the page, but slowly. So now in the middle of removing plugins I lost the Internet. With no alternative access, I went to bed thinking that the Internet would be back in the morning.
Time Warner
My Internet service is RoadRunner. The service had been on the fritz in the middle of the week. There’s rarely a problem, but Time Warner had a phone message which apologized for a failure that had occurred in my area. I presumed, wrongly, the same thing was happening again.
In the morning there was no change, so I rang Time Warner in order to complain vociferously. The technician checked my cable modem remotely, rebooted it and then told me that the “signal” was below the acceptable level and it needed to be swapped out. However it now worked. So I checked this web site and discovered that it had been down all night because the last plugin I removed had caused an error. I put it back, the site started to behave normally and the performance was fine.
I spent the morning loading plugins and then removing them until a identified the culprit. When I track down the cause I’ll report fully on the problem, just in case anyone else runs into it.
The Lesson Here
First lesson is that you never want to have two problems to deal with at once in IT.
But there is a problem here worth reporting in general anyway. There is no way that I can check WordPress performance issues on the MAMP test setup I have. The only way to check them is on the live system. I have proven to my cost that WordPress plugins can cause performance issues, but this one was surprising because it moved the web site from acceptable to unacceptable performance – but it disn’t happen instantly – so the cause was elusive.
The truth of the matter is that when you plug lots of components together written by different people, there is simply no guarantee that some of them won’t clash. So when I use a new plugin, if it ever breaks and reports error messages, I simply throw it away. I could investigate, but it would take too much time, so I just junk anything that produces errors – knowing that the errors might be due to the coding I have done to customize WordPress. That has been pretty much the only QA I did when adding a plugin. Now I’ll have to change my ways.
Tomorrow I’ll post some more reviews of plugins I use, or have tried and fired.
Leave a reply