If you care about the performance of your site, please stick with WP Super Cache unless you have a very good reason to switch. It works, and it works well.

Some people tell us that W3 Total Cache works just as well if it’s properly configured, and they may well be right — but it seems like it’s difficult to configure properly. Our experience is showing that it’s easy to get wrong, and performance ends up suffering. WP Super Cache makes it easy to get great performance.

But recently we’ve seen a number of our customers getting hammered by a ton of requests from FeedBurner. Usually the request is of this form:

/somepost?utm_source=feedburner&utm_medium=feed&utm_campaign=SomeCampaignString

We’ve also seen FeedBurner going crazy and making thousands of duplicate requests. One of the sites we host has gotten 45,000 simple status requests (HTTP “HEAD” requests) from FeedBurner today, for no good reason that we can see.

Unfortunately, the default rules of WP Super Cache prevent it from caching any request with a query that contains an equal sign. So all of these requests are being unnecessarily run freshly each time, rather than being served from the cache.

There’s an easy fix to this. Open your Web site’s .htaccess file. Look for the section of lines for WP Super Cache, and find the line which tests %{QUERY_STRING}. Insert this new line of text immediately above the existing line:

RewriteCond %{QUERY_STRING} ^utm_source=(feedburner|twitterfeed) [OR]

The new line (ending with [OR]) must come before the existing %{QUERY_STRING} line. After inserting, the two lines should look exactly like this:

RewriteCond %{QUERY_STRING} ^utm_source=(feedburner|twitterfeed) [OR]
RewriteCond %{QUERY_STRING} !.*=.*

There are two very similar blocks right next to each other in the .htaccess file. Be sure to add the new line to the same place in each block.

That’s the only change you’ll have to make! WP Super Cache will now be able to cache requests for normal pages that come from FeedBurner or Twitterfeed. If your Web site was being abused by FeedBurner (or Twitterfeed), you should see a definite improvement.

There’s an obvious potential conflict-of-interest here. An unscrupulous company could easily make more money by rejecting the transfer and forcing the domain name owner to renew it there instead.

Fortunately, this shouldn’t be a problem. ICANN, the organization that controls domain name policy, requires registrars to follow some very specific rules about transfers (here, with an update here). They list nine specific situations in which a transfer can be rejected, explicitly banning other reasons.

For the most part, this prevents arbitrary rejections. However, there are a few registrars that continue to violate the rules. We’ve complained (again and again) to ICANN about this, but they don’t seem interested, so I’ll mention a few problems here.

Register.com is one frustrating company. The ICANN policy clearly prohibits blocking a transfer of a domain name that has expired but not yet been deleted. Despite that, a customer trying to transfer a three-day-expired Register.com domain name told us last week that they flat out refused to give him the necessary code to allow him to transfer — unless he pays them to renew it first. That isn’t the first time we’ve heard this, either.

GoDaddy (and their reseller arm, Wild West Domains) have a different problem. They still block transfers for 60 days after a registrant contact update, even after the ICANN update specifically prohibited doing so. They freely admit it, too. GoDaddy’s Disputes Manager recently told us that blocking transfers for this reason is okay because “It is not necessary to update registrant information in order to transfer a domain name”. That’s irrelevant, of course; domain name owners are legally required to update registrant information whenever it becomes inaccurate, as ICANN’s update makes clear. GoDaddy can’t legitimately block transfers just because someone followed the legal requirement to update their contact information.

We see a similar problem with many transfers from Network Solutions. They often tell their customers that they’ve rejected the transfer “due to potentially suspicious activity in your account”. When customers ask for details, they’re told that the only “suspicious activity” was a recent contact update. Again, this is exactly what the policy prohibits.

GoDaddy and Network Solutions claim they’re protecting registrants by implementing these security measures, as if a recent contact update is a reliable sign of malicious activity. But many registrants update all their contact information just before they transfer their domain name to make sure the transfer approval notices reach their current address. They just don’t think about until then. It’s perfectly normal.

In addition, the “security measures” probably don’t work anyway. Surely by now any competent domain name thief knows not to update the registrant contact until after they’ve transferred the domain name to another registrar, thus bypassing the “security” completely.

While the GoDaddy and NSI efforts almost certainly have blocked some fraudulent transfers, so would a rule saying “you can’t transfer domain names during months that contain an R”. What really matters is how many legitimate transfers are also blocked. We’ve been on the receiving end of many blocked transfers, and we always try to push the other registrar to provide details about the “security problem” — I’ve spent literally days of my time doing this over the last two years. In every single case, the attempted transfer has turned out to be legitimate.

If GoDaddy and NSI wanted to prove they were protecting registrants, they could share some statistics about how many of the blocked transfers eventually get completed later anyway, vs. how many of the blocked transfers result in complaints or actions by registrants to block future transfers (such as authorization code changes) . We’re pretty sure the former vastly outweighs the latter.

Of course, they won’t share those statistics, because that would reveal how many domain name owners they’re inconveniencing. Instead, they’ll just continue to flout the ICANN transfer rules, and ICANN will continue to do nothing.

Here’s our pledge to our customers: We’ll always abide by the letter and spirit of the ICANN transfer policies. If you want to transfer your Tiger Technologies domain name elsewhere, we’ll help you, not hinder you. In fact, we’re one of the few companies that publicly explains how to do it. We value your business, but we’ll never force you to stay with us against your will.

(And by the way, we’re not ignoring security, either. Every domain name transfer gets reviewed by a real person here, and if we see anything unusual, we’ll send you an e-mail message and/or give you a call to find out what’s really going on.)

We are now seeing newer versions (commonly called “Gumblar”) which spread by inserting “script” tags with encoded JavaScript code. Because there are several variations of this approach, and because some legitimate commercial scripts use the same technique to hide their source code, we cannot perfectly identify and strip out these infections. Therefore, we will not automatically strip out the “script” tags from any upload file that looks suspicious.

If your Web site is infected, your best solution is to:

1. Scan your computer for malware. See our prior blog post for links to suggested scanning software.
2. Change your account password in our control panel (since your account password is also your FTP password).
3. Change the passwords for any additional FTP accounts you may have defined.
4. Re-upload (or “re-publish”) your Web site to our servers.

Of course, we always recommend that users run anti-virus software on their systems, and keep backups of their Web site files and data.

We’ve taken a step to protect you against this problem (described below), but it’s wise to protect yourself, too.

The way these viruses work is:

• You visit an infected Web page (on someone else’s site, not your own site) that loads a virus onto your personal computer.
• The virus examines your computer to see if you use any common FTP programs, and whether you’ve told those programs to save your username and password.
• It sends the usernames and passwords to a server controlled by “hackers”.
• The hackers make an automated FTP connection to our servers and download any HTML or PHP files they find.
• They modify those files to add HTML code (an “iframe” tag) that spreads the virus, then upload the changed files back to our servers.
• Your site starts spreading the virus to new victims.
• Within a few days, your site will be marked as “This site may harm your computer” on Google, causing the number of visitors to drop dramatically.

Obviously, you don’t want this to happen to you. It’s bad enough to be infected with a virus, but it’s even worse for your Web site to get a reputation as “harmful”.

The first thing to do is protect your computer against this kind of virus. Make sure that you’ve updated Windows and any Web browsers you use. Also make sure you’ve recently updated Adobe Reader or Adobe Acrobat (which allow your Web browser to display PDF files), since many Web viruses are spreading through an Adobe security vulnerability discovered just two months ago. (You can download the latest version of Adobe Reader from this page on the Adobe site.)

It’s also a good idea to scan your computer for “malware” every so often. Some of these infections disable standard virus scanners, so checking with a different program is wise even if you think you’re protected. One product that can detect these kinds of viruses is Malwarebytes.

If you’re really concerned about this, you might also avoid saving your password in your FTP program. It’s a little less convenient to type it each time, but it prevents these viruses from getting your password.

We mentioned that we’re doing something to protect you, too. We’ve modified our FTP servers to scan uploaded HTML and PHP files and automatically remove malicious “iframe” tags. If your computer does get infected with this kind of virus, this can prevent your site from spreading it and being listed as “harmful” in Google. (We’ll notify you if the system alters one of your files.)

Our servers currently only look for a couple of common “iframe” exploits, and we certainly can’t guarantee that we’ll catch them all. But it’s a good start — we’ve already caught and prevented several Web site infections.

Update 2009-05-19: The virus now also spreads via a “script” tag that we cannot filter out. Please see our newer post for more details.

Update 2009-10-01: The virus is also spreading through certain versions of the Adobe Flash player. You can update your copy from this page on the Adobe Web site. (These mentioned programs are not meant to be a comprehensive list of all vulnerabilities — you should keep all of your software up to date.)

• Friday, August 22 (servers beginning with letter “l-z”)
• Saturday, August 23 (servers beginning with letter “a-k”)

(The servers named “bender” and “lrrr” have already been upgraded, and those customers are not affected.)

If you’re interested in the details: Our servers use the Debian Linux operating system, which is periodically updated with new versions (just like Windows or Mac OS X). Last year, Debian was updated to version 4.0 (called “etch”), and since then, we’ve been running a “mixed” system on our older servers. Many programs (such as MySQL, PHP 5, and any program that had a security vulnerability) have long since been upgraded to the newer “etch” versions, but some other programs still need to be updated.

What we’re now doing is finalizing the upgrade on all servers that aren’t already fully using “etch”. This will simplify our management of security updates and give customers access to newer versions of some programs.

Unfortunately, a side-effect of the upgrade is about 10 total minutes of downtime, divided into a four-minute outage while the server is restarted, and a couple of separate two-minute outages while other programs are updated. We always strive to avoid any downtime, but in this case, it’s unavoidable.

Incoming mail may be delayed for a few minutes during the maintenance, but as always, no mail will be lost: it will just be queued and delivered a few minutes later.

Please contact our support team if you have any questions. We appreciate your business!

Update: all scheduled maintenance was completed normally, and there will be no additional interruptions to service.

However, thread view has a potential downside: it you have several active threads going with several messages each, new messages can sometimes appear on the second page of the incoming mail screens, instead of the first page.

That’s not a problem if you’re expecting it. However, since we introduced the new Webmail system, we’ve had several complaints from customers who accidentally clicked “Switch to Thread View” without realizing what it does, then thought some of their incoming mail was missing because they aren’t used to looking for new mail on other pages. Since thread view is “remembered” even after you logout and login again, this caused some people a great deal of heartache.

From our logs, we’ve found that very few people actually use thread view. Because it seems to cause frequent problems and few people use it, we’ve made it an optional feature instead of being always enabled.

If (like most people) you don’t use thread view, you don’t need to do anything. If do you want to use thread view, it’s still available: just click “Preferences”, then click “Display Preferences”, then change “Show ‘Thread View’ Link” to “Yes”.

Table upgrade required. Please do "REPAIR TABLE `users`" to fix it!

Hmm. Well, that error message seems odd, but what the heck. After making sure there’s a current backup, let’s give it a shot:

mysql> REPAIR TABLE users;

+---------------------+--------+----------+-----------------------------+
| Table               | Op     | Msg_type | Msg_text                    |
+---------------------+--------+----------+-----------------------------+
| database.users      | repair | status   | Table is already up to date |
+---------------------+--------+----------+-----------------------------+

And yet, CHECK TABLE still says there’s a problem:

mysql> CHECK TABLE users;

+---------------------+-------+----------+-------------------------------------+
| Table               | Op    | Msg_type | Msg_text                            |
+---------------------+-------+----------+-------------------------------------+
| database.users      | check | error    | Table upgrade required. Please do   |
|                     |       |          |  "REPAIR TABLE `users`" to fix it!  |
+---------------------+-------+----------+-------------------------------------+

Hmmm. We tried every reasonable combination of REPAIR TABLE and myisamchk options we could think of, but nothing helped. Then we tried unreasonable options, including the frightening REPAIR TABLE table USE_FRM option. In our experience USE_FRM usually ends up doing the same thing as DELETE FROM table, and this time was no exception. (And that’s why you make a backup first.)

Well, let’s take a look at the table status (with the uninteresting bits removed):

mysql> show table status;

+-------+--------+---------+-----+---------------------+
| Name  | Engine | Version | ... | Create_time         |
+-------+--------+---------+-----+---------------------+
| good  | MyISAM |      10 | ... | 2007-06-08 09:44:01 |
| users | MyISAM |       7 | ... | 2005-03-15 12:03:11 |
+-------+--------+---------+-----+---------------------+

Sure enough, the bad “users” table is a different version than a good table that doesn’t have this problem. And the bad table was created when we were still using MySQL 4.1.x. This table should have been changed when we upgraded to MySQL 5, and it should be possible to fix now. Why on earth won’t REPAIR TABLE fix it?

We puzzled over this for some time, and eventually just decided to reload it from a dump. But here’s the strange thing: it wouldn’t reload from the dump, either!

ERROR 1060 (42S21) at line 20: Duplicate column name 'user_id'

What the heck? So we looked closely at the dump file, and it somehow contains this line:

PRIMARY KEY (user_id,user_id)

MySQL thinks this table has a composite (two-column) primary key, but on the same column twice, which doesn’t make any sense. So we fix the dump to look like this:

PRIMARY KEY (user_id)

And everything works perfectly when the table is reloaded.

So if CHECK TABLE tells you a table upgrade is required, but REPAIR TABLE won’t fix it, check whether you can actually reload a dump of that table. You might find something unusual and easily fixable in the dump.

PHP gives programmers a way to accept an uploaded file, store it in a temporary directory, then move it to a specific location using the move_uploaded_file() command. That’s all good — but what file permissions would you expect the resulting file to get? Most PHP documentation says that temporary files created by PHP will not be world-readable, so they’ll look like this:

0600 (-rw-------)

That’s good security. It makes sure the files can’t be accessed by Web site visitors, for example, unless the programmer takes additional steps to make that happen.

On many servers, mode 0600 is exactly what you get after using move_uploaded_file(). However, if the initial temporary directory used by PHP is on a different “file system” than the final destination, move_uploaded_file() makes a copy of the file instead of moving it. And when it makes a copy, it sets the permissions of the copy to something very different:

0644 (-rw-r--r--)

Yikes! And since you have no real control over whether there’s going to be more than one file system involved (it’s effectively random from the script author’s point of view), this means you have no idea whether an uploaded file is going to be world-readable after using move_uploaded_file(). If you want to make sure it is — or isn’t! — you have to set that yourself, using something like chmod:

chmod ($filename, 0600);

Or:

chmod ($filename, 0644);

There probably aren’t many widely-used scripts that rely on the default permissions of uploaded files (otherwise the scripts would fail on some servers and work on others, and someone would notice and fix it). So this shouldn’t be a problem, right?

Well, until recently, most of our servers had their “temporary directory” on a different file system (it was actually a “tmpfs”). This caused a problem, though: sometimes when a server hadn’t been restarted for several months, the smaller temporary directory would start to fill up (the directories only get cleaned out when a server is restarted). This made us nervous: what if a temporary directory filled up and ran out of space? So we recently decided to stop putting the temporary directory on a separate file system, setting it to use the standard disk file system after the scheduled restart last Saturday night. It shouldn’t really matter where it is, so we didn’t even bother mentioning it.

But this afternoon, a couple of customers contacted us to let us know their PHP file upload scripts had stopped working. Not being familiar with arcane details of how PHP handles uploaded temporary files, we were extremely puzzled… until a perusal of the PHP source code revealed the trouble.

Now, what we originally told the customers who had this trouble still stands: regardless of the cause, everyone’s scripts should explicitly set the mode of any uploaded files if it matters. That’s the only way to guarantee your script works properly on any server.

However, we value consistency a great deal. You should be able to rely on your scripts continuing to work if it’s possible for us to make that happen. So we’ve “patched” our versions of PHP (both PHP 4 and PHP 5) to always make move_uploaded_file() act as if the file was copied (giving mode 0644). This should “fix” any scripts that were broken by this change, even if you can’t actually fix the scripts for some reason.

I should mention that this “solution” is still too random for our taste. There’s no guarantee that this behavior is compatible with what you’d get if you tried another company’s PHP, for example. What would be better is for PHP itself to make sure the mode is always the same, and for that to be fully documented so PHP users could expect the same behavior on all servers. We’ve opened a PHP bug suggesting that. If the PHP folks ever see fit to make that change, we’ll make sure our versions of PHP do what the PHP documentation says, even if it means making our servers start using mode 0600. So again: if the mode matters to your script, make sure your script sets the mode itself to avoid problems.

Followup: the PHP developers changed how PHP works in response to our bug report, forcing PHP to use mode 0644 for files created with move_uploaded_file().

After doing a bit of diagnostics, it turned out that the problem was that her computer had selected a neighbor’s wireless network after she rebooted. This different network blocked the necessary e-mail ports, so she couldn’t do e-mail. None of this was obvious until we started examining her IP address. She solved the problem by plugging her computer into a wired Ethernet port on her router, rather than using the wireless connection. When she did this, she got a new IP address which belonged to a completely different network, and suddenly she could do e-mail again!

So if you are having intermittent wireless network problems, be sure to check which wireless network your computer is connecting to. Choosing the wrong network can cause problems for e-mail and (potentially) for other services too.

We offer a web page which displays your IP address and host name. The final part of your host name is the network which are you using to connect to the Internet. For example, if your host name is c-71-205-218-196.hsd1.ca.comcast.net, then you are connecting to the Internet via Comcast.