One of the tools we offer our customers is the “wget” program, which can be used to fetch files from other Web or FTP servers.
It turns out that wget has a security bug that needs to be avoided. As a result, the behavior of wget has changed in some situations. If you use wget (most of our customers don’t), you should be aware of this change.
In a previous post, we talked about how increasing the WP Super Cache “Expire time” from 1 hour to 48 hours can help the performance of WordPress blogs.
Here’s another tip that can help dramatically: Remove “bot”, “ia_archive”, “slurp”, “crawl”, “spider” and “Yandex” from the Rejected User Agents box in the WP Super Cache plugin settings. (In most cases, this will leave the box completely empty.)
Update: This post is outdated. We now offer SSL certificates for free to all customers, and recommend that you make your entire WordPress blog use SSL (rather than just making the dashboard SSL using the FORCE_SSL_ADMIN trick described below).
Do you login to your WordPress blog securely? Are your username and password encrypted so that “hackers” can’t steal them and then break into your blog? (Probably not!)
By default, each WordPress blog is configured to send the login username and password as plain (unencrypted) text. If a hacker can see what you are sending during your login, they can easily steal your username and password. This can happen if you have a virus installed on your computer. It can also happen if your computer is virus-free but connects via WiFi. If your main computer uses a wireless connection, or if you or other users of your blog ever login with their laptops — blogging from a coffee shop, anyone? — remember that these connections can be insecure, and could be susceptible to revealing your password.
You can protect your blog by installing an “SSL certificate” and configuring WordPress to require secure logins. Your browser will then encrypt your username and password so that no one can intercept them.
In the last few days, there’s been a lot of talk on the Internet about the security of WordPress blog software.
Several shared hosting companies apparently allow customers to view the text of other customer’s files by default, and that allows malicious customers to discover the database password of another site (from the “wp-config.php” file) and alter the site.
We recently added the Spamhaus Domain Block List (dbl.spamhaus.org) to our spam filters.
The Domain Block List is an extremely reliable list of domain names that are used only in spam. Blocking most mail that advertises these domain names improves our spam filtering: we’re now blocking about 1% more spam as a result.
That may not sound like much, but it represents about 150 more blocked spam messages per year for each customer. (We block an average of over 15,000 spam messages per year per customer.)
If you use a MySQL database with large tables, it’s possible to accidentally run queries that try to sort millions of rows (usually through some kind of programming error, such as an “unconstrained table join”).
Those runaway queries can slow down the MySQL server for many minutes on end, causing performance problems.
To prevent the worst of that, we’ve set the max_join_size setting to 1,000,000 on our MySQL servers.
We keep coming across WordPress customer sites that have hurt their performance by switching from the “WP Super Cache” plugin we recommend to a newer plugin named “W3 Total Cache”. Unfortunately, their site often ends up being far slower after switching to W3 Total Cache.
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.
After upgrading our systems to PHP 5.2.6, we received reports of an incompatibility with Joomla. Some URLs do not work when Joomla is configured to use “Search Engine Friendly URLs”, but to not have “Use Apache mod_rewrite” turned on.
We’ve investigated this, and it’s caused by Joomla assuming that PHP has a bug that makes it work incorrectly, when in fact it’s supposed to work differently (and is clearly documented to work differently). Older versions of PHP had this bug, but the new version doesn’t.
To help our customers work around this, we’ve “patched” PHP to intentionally reintroduce the old bug for now, thus keeping it “compatible” with Joomla. If you were having trouble with Joomla’s “Search Engine Friendly URLs”, it should be fixed.
We’ll provide more technical details (and a more robust long-term solution) in the near future.
Update: We’ve also reported this problem to the Joomla developers and suggested a solution.
Due to software updates on our servers, Web hosting customers will experience about seven minutes of scheduled maintenance downtime between 11 PM and 1 AM Pacific time starting on one of the following nights, depending on which server your site is on:
Many Web sites write data to a database. Usually, the data absolutely must be properly saved, so the default way of adding records (using an SQL “INSERT” statement) ensures that the data is permanently stored on the server’s disks. Doing that takes a relatively long time in computer terms — it’s much slower than most things computers do.
In some cases, you might be storing data that’s not quite so important. And if it means your application can run much faster, you might be willing to risk a very small chance of data loss. That’s where MySQL’s “INSERT DELAYED” statement, which works with MyISAM table types (but not InnoDB tables), can be useful. (Tables are created as type MyISAM by default, so most tables are eligible to benefit from this tip.)
