See the bottom of the post for updates on my adventures with shared hosting..

My experience in selfhosting my blogs with GoDaddy moved from a glowing enthusiasm via consternation and frustration into a deep distrust and disbelief. In this post, I want to take you through the past year, as I discovered some of the issues one should know before choosing a selfhosting service.

Much is written about hosting your own blog and how to choose your hosting company. Whole blogs are dedicated to attracting customers to this or that hosting supplier, a clear sign hosting is big business.
I will not analyse which hosting company is the best, nor what the pros and cons of all hosting companies or hosting formulae are. Others are more qualified to do so. But… as with most items we cover on BlogTips, I want to share my experience, hoping others will learn from my many mistakes. My experience concentrated mainly around GoDaddy.com, one of the biggest and cheapest hosting companies around.

My first steps into the hosting world:

I have been blogging for over three years. My first blogs were hosted by Blogger, WordPress, Skynet and Tumblr. Later on, I also started some blogs on Posterous. About two years into blogging, I thought it was about time to take more control over my blogs and to selfhost some of them.

As with many things in life, I found myself walking a road, unconscious of the direction I took, and soon enough, found myself in a middle of a mediaeval battlefield with all kinds of things happening I had no control over, no influence on the outcome, nor did I have the faintest clue “how the **&&%% I got there”. Let me explain: I choose GoDaddy.com as my hosting provider. It was not a calculated choice, but Godaddy was the service Google used as a registrar when I registered the domain of my very first blog. The migration from a Blogger domain to my own, went fast and transparently, so I thought GoDaddy would also be the way to go for hosting services too. Little did I know that domain registration and hosting services are two completely different things.

Via GoDaddy’s home page, I found a link to their selfhosting services, and registered. Not really thinking what I choose for. “Linux economy plan” smelled about right. And at less than US$4/month for 10 Gb of diskspace and 300 Gb/month of traffic, what could go wrong? Right? So before I knew it, I started walking the road of “Shared Linux Servers” selfhosting.

PLUS: shared hosting services are cheap
PLUS: shared hosting services provide loads of diskspace and high internet traffic quota

Starting my first selfhosted blog Have Impact was a breeze. When I registered the domain, I could select the hosting service I wanted. The DNS entries – the link between the domain and the physical space where my blog lives – were done automatically. Installing WordPress was just a matter of clicking a few buttons and I had a blog up and running in minutes.

PLUS: a fast and transparent link between the domain registration
PLUS: an easy “Pay and Go” solution which brings up a website in no time
PLUS: easy and fast installation of the blogging software

I thought: “Why did I not do this earlier?”

A clear blue sky

Using a selfhosted WordPress.org blog is pretty much like using a blog on WordPress.com, where your blog is hosted by WordPress themselves. But it gave me more freedom to install and tweak themes and plugins, making my blog do exactly what I wanted.

All fine so far. Apart from a bit of a surprise how much time it took to ensure my blogsoftware, themes and plugins were kept up to date with the latest software releases, I was a happy camper: My blog was puttering along nicely, with a few dozen posts, updated once or twice a week, and a few thousand visitors a month.

PLUS: For a low traffic, simple blog shared hosting services are just fine.

So I continue walking on that path: I created several other blogs hosted by Godaddy, amongst which your very own BlogTips, this blog. Before I knew it, I had a dozen selfhosted blogs, all on GoDaddy. I even started a Drupal site, Humanitarian News.

The first signs of trouble

The latter took off into cyberspace like a rocket, with loads of content and more visitors every month. It was also the first site I experienced problems with. Problems I would also encounter with my other blogs later on: The increased traffic and the amount of posts I published forced me to tweak the site continuously: I applied aggressive caching and stripped it off all functions that had a bad influence on its performance. Soon I was forced into the Drupal internals, PHP/MySQL tweaks and all other stuff a naive blogger like myself should keep his hands off. Really… Soon enough, I needed help. As GoDaddy promised 24h/7d telephone and email support, I thought nothing could go wrong.

I learned their Email support did not work well. Most of the time, the answers I got were off-topic, or not to the point, and looked like pre-cooked “cut-and-paste” replies. It honestly felt like they let you go through a couple of to-and-fro iterations to ensure you are persistent enough, and you “really have a problem”, before you do get a real answer…

As most of my issues were performance related, most of the time, their answer was a standard “we see your site might be loading a bit slow, but we advise you to”… and then came an explanation on how to increase the speed of a website by compressing pictures, etc… Even though none of my performance issues had anything to do with the web-side (or front-end) of the chain of events, but were rather concentrated on the back-end.

The more I insisted, the more frequent the “end the discussion now”-killer sentence came: “We don’t see any performance issues on your shared server, but if you want better performance, we suggest you upgrade to a hosting package XYZ”… Which implied moving all my data myself, at a significant higher price tag. Beh..

Shared hosting = shared trouble

As time went by, I discovered I took the cheapest and most unreliable of all packages: a shared host. Meaning, I shared the machine my blog ran on, with thousands of other users, rather than having a machine to myself. Other formulae were “dedicated virtual hosting” services (where you run on your own virtual machine) or “dedicated hosting” (where you run on your own physical machine)…

Minus: Shared hosting is not a good idea for high traffic sites
Minus: There is little or no performance to be expected from shared hosts
Minus: Email support seldom leads to actual solutions. Real support is only possible via telephone.
Minus: Most Email support mostly consists of standard cut-and-paste answers.

The more I used the support services, the more I discovered problems: each time I called or emailed, I got another person on the line. Who might or might not do the effort of reading through the history of problems. Who might or might not be knowledgeable. Who might or might not be interested or motivated to really help you.

Minus: There is not a single focal point for each account, nor a focal team. The quality of support really depends on the person.

Consumer rights

Around late last year – I also discovered other problems. The top of the iceberg, it seemed. One of my websites ran significantly slower than all others. The lack of speed had nothing to do with my blog itself, nor the posts: Just about anything I did in the WordPress dashboard was at least ten times slower than on any of my other blogs. I found out the IP address from the server on which “the slow blog” was running, was in a different range from the servers of my other blogs. I gathered it ran on a different server array, or even ran in another location. That seemed like an obvious explanation of the source of the problem: the slower website must have a server with a resource problem: CPU, bandwidth, memory, load etc…

It was by then I also started see some variations in performance on my other blogs, including this very same blog, BlogTips. At times the site would load THAT slow, browsers would time out. WordPress admin functions would take minutes rather than seconds. The problem would persist for about half an hour and by the time I called or emailed support, the problem disappeared… To re-appear a few hours later, or on the following day, or the following week, or the following month.

Next thing I knew, the CRON jobs on Humanitarian News stopped working. CRON is the mechanism scheduling and executing background jobs such as indexing your site for the internal search. CRON is particularly important on Humanitarian News as it also imports posts from RSS feeds. No CRON, no new posts…
Once more the answer from GoDaddy’s support desk was similar to previous issues: at first there was a denial there was a problem, but when I persisted, they confirmed there was indeed a problem, but were unable to tell me when the problem would be resolved. Nor could they inform me by email when the problem was resolved. This also made me realize there is no system to actually ‘close’ a support ticket. A support issue seems to be closed the moment the client gives up, or when the answer is ‘we know of the problem, and it will be resolved. Bye!’…

Minus: When there is a recognized problem that can not be cured on the spot, support often can not give you a time frame when it will be resolved, nor will they contact you when the problem is actually resolved.
Minus: There is no system to close support tickets

That made me think about consumer rights… I guess I had only one right: To leave… But for the rest, it seemed I had no way to escalate a problem, or to appeal to what I felt was unfair consumer treatment. Imagine you buy a car, and the engine stops. You can drive it downhill, but for the rest, you won’t get far unless if you push it. And the garage won’t be able to tell you when the problem will be resolved. Would you accept that?

The first step to recovery, is to recognize one is ill

Despite repeated emails to the support service, little I could do to convince them about most of the performance problems. True, I used to manage DEC VAX and PDP systems twenty years ago, but Linux is not my thing and I have no system tools at my finger tips. I could not measure the actual performance of my site. But to my surprise, it seemed they did not have much of the tools neither to measure, monitor or benchmark performance issues on shared hosts. And even less tools to analyse and/or cure the problems. I witnessed  little eagerness, willingness (or ability?) to check performance logs.
Nor could anyone tell me what performance I could expect. What metrics were used? I figured I basically signed a blank cheque.

Minus: There is no benchmark or agreed performance to be expected from shared hosts.
Minus: There is hardly any action taken on performance complaints

On some single occasions, I had GoDaddy admit there were actual problems on my shared server, but then their answer often was: “In the mean time, the problem has been resolved, please revert if you experience similar problems”.

It was then I also discovered:

Minus: there is no refund for downtime, nor a money-back guarantee for dis-satisfied customers

Signing a blank cheque

As Humanitarian news continued to grow, I learned there were several system limits which are undocumented or rather grey-ishly documented: the fact that you can have 10 SQL databases per hosting service is fine, but none of them can be larger than 1 Gigabyte… If it grows larger than 1 Gigabyte, you can not back it up. Punto. It was also difficult to find what the maximum memory size. And there was no way to increase any of these. Virtual shared hosting formulae were not modular in design. Take or leave the standard formulae…
It was also difficult for me to analyse the problem as I had limited access to error logs.

Minus: Undocumented or poorly documented limitations of the hosting service.
Minus: No PHP-error log access.

Hackers aboard

Then came the April-May debacle of the massive shared host hacks. Several of my GoDaddy hosted websites got infected. Even though I cured the sites quickly, several sites went down repeatedly. I spent hours curing the infections the hackers left behind. Meanwhile Godaddy did not admit guilt, and continued to point the finger-of-blame towards WordPress and the individual users.
I discovered how little repercussion the clients of (shared) hosting services really had. None of the hacks happened on dedicated hosts, the security holes apparently only happened on shared hosts.

Minus: Shared hosting services are more vulnerable to hackers’ attacks

I discovered how little support was given for the applications running on the hosting service: few of the support people actually understood Drupal, or WordPress, or Apache, or MySQL…, something which is not clearly stated when you sign up for a hosting service:

Minus: Application support is limited.

The past few weeks, the problems with Humanitarian News got from bad to worse.The SQL server completely failed on several occasions, it timed out most others. This caused all kinds of database errors, which took days and days to resolve. I got mixed up into a whirl of snowball effects…

The apotheosis

It felt like the support desk would no longer put up with my persistent complaining on the lack of performance on their services: A few days ago, I received an email my website was put offline “as I used up too many resources”:

It has come to our attention that your humanitariannews.org hosting account, specifically the humxxx database is causing the shared resources to be over-utilized. This, in turn, affects the usage by other customers.

We have disabled your database to return the server to normal usage. To re-enable your database, you will need to correct the following query:

Access is revoked. Problematic query:
SELECT t.word AS realword, i.word FROM search_total t LEFT JOIN search_index i ON t.word = i.word WHERE i.word IS NULL

EXPLAIN:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t index PRIMARY 152 266794 Using index
1 SIMPLE i ref word_sid_type,word word 152 humxxx.t.word 29 Using where; Using index; Not exists

This query examines 7737026 rows, which is unacceptable in shared hosting.

Please respond to this message via email or phone with the steps you will take or have taken, to correct this issue, and access to your database can be restored.

Admittedly the timing of this was rather weird. Anyways, I figured out the offending query was caused by the standard Drupal “Search” function. I disabled it, and it took GoDaddy 20 hours to bring the website back up. I asked them what the metrics they used to determine what resource consumption was acceptable and what was not. I am waiting for the answer.

Minus: There are unclear metrics used on the use of shared resources

I was given administrator rights to the entire server.

Interestingly enough, when they gave me back the access to my own database, something really weird happened: I went into PHPMyadmin, to look at my SQL database and did not find the usual two databases, but over 2,400 databases. I clearly had access to the databases from all other users on my shared server.

And I found dozens of processes on my server too:

By error, I was given access to all 2,400 databases and all processes on my shared hosts. I could delete 2,400 websites right there on the spot. Or I could play cat and mouse, and delete random SQL processes, and see how long it would take before Godaddy caught me.

Honestly lasts longer, though. I called them. Was put on hold for 12 minutes. Talked to a support guy. Who did not really seem to believe me at first. Then forwarded the request to the hosting experts, and thanked me for reporting the problem.

It took them a few hours to take away my “administrator” access on the shared server. This did not particularly strengthen my belief in the rigidness of the shared server management. And, just as before this incident, I could still read everyone’s access log (the log registering who does what on a website). Godaddy is still checking if ‘that is normal’ or not. (Update: GoDaddy support confirmed it was normal I could read everyone’s access log)

Access logs for a site called "humongous"

Minus: “Shared hosting” and “security” are two words that should not be used within the same sentence.

I *did* get an email from “the office of the President” – that is the president of “GoDaddy.com”, and not of “the United States”, to thank me for reporting the security problem, saying they tried to call me to see if the issue was resolved.

I wrote them back stating the only way they could show their gratitude to me, and to their thousands of customers, was to monitor and cure their performance problems on the shared hosting servers…

So what did I learn from all of this:

• There are many hosting formulae, and many hosting suppliers. Choosing the right one is as critical as choosing the plot of land on which you will build your house.
• GoDaddy Shared Hosting Services are only good for low traffic, low demand websites.
• Technical support from Godaddy is limited, and only effective when you call.
• If your website is critical, and you want a guaranteed performance and uptime, shared hosting is not what you want. Certainly not from Godaddy. Go for dedicated (virtual) hosts.

The bottom line:

Am I pissed off? Kinda.. Mostly on myself. What kind of support would I have expected when paying US$4/month? Indeed: when you pay peanuts, you can only get monkeys.

I am now looking for another hosting formula, on another hosting provider. I will keep you in the loop of my discoveries in “Blogging Never-Ever-Land”.

Updates:

1. One day after publishing this post, once again, BlogTips.org gave time-out errors. After half an hour online with the support services, they admitted there was a load problem on the server. They said it would typically take 3 days to resolve.
   Meanwhile another site gave “500 Internal Error” problems, which turned out to be a DNS setting which was changed. How? I still don’t know. — GoDaddy confirmed later on that this was a new option people could set. Apparently there was a problem in the migration.
2. Meanwhile, it seems that the option causing the DNS error is taken away from all hosting accounts…
3. I continued to experience problems, mostly time-outs when loading pages, but also performance problems with the SQL database. Godaddy support suggested I moved my shared hosting accounts to grid hosting, a process which can be done by the click of a button.
   Indeed, the migration process was fast and flawless.
   Let’s see if the performances gets better.
4. After migrating all but one of my hosting accounts to grid hosting, most of them started to give time-outs upon loading. Godaddy let me do a TRACERT to my domains, which showed on all but one, time-outs.
5. After 5 days of “we’re working on it”, I got a mail saying “Solved!”, but it failed at the first test. After that, for three days, I got “Working on it, but can not say when it would be resolved”.
6. The rest of my sites started to give “500 Internal errors”. I can’t wait for this holiday to end so I can migrate all my hosting accounts off Godaddy.
7. On July 20, Godaddy publishes an update on their support website: “We’re aware of an issue within our Grid Hosting services impacting a few customers. While we’re fixing it, you might experience longer than normal phone support hold times. Thanks for your patience.”
   ..a few customers… Right…
8. GoDaddy confirmed by telephone that TRACERT of one’s own domain should give a time-out as soon as the route enters their domains, as a security precaution. Makes me wonder then why I can do a TRACERT of all my domains I tried, except the one for the site which was unreachable… Beh.

Pictures of “Tintin and The Seven Crystal Balls” and “Tintin, Destination Moon”, courtesy Editions Casterman.

An interesting slide set by social media guru Beth Kanter, showing how social media can be used as a marketing tool – specifically for non-profit organisations.

Some of the slides contain details you will only see when watching the slide show in full screen (click on the menu icon – Choose “Full screen”)..

777,  Seven hundred seventy-seven.

That is the amount of nonprofit blogs I have collected so far. They are all on my Delicious bookmarking list. Excerpts from their posts are republished on Humanitarian News and The NonProfit Blogs.

777, discarding blogs which have not been updated since six months.  777, including the Good, the Bad and the Ugly. With absolute gems, but also “so-so” blogs. Blogs with daily updates, and blogs with one post per month. Team blogs, project blogs, blogs advising on nonprofit fundraising and those written by field workers deep in Africa. Photo blogs and blogs supporting scientific research.

For me, the nonprofit blogs collection is a good research basis:  As I flip through them, I turf different criteria, like their pagerank, an analysis published in an earlier post. Or I jot down different observations.

As I was processing a batch of 150 new blogs in the last week, I took note of common problems I saw with many blogs. Let’s call it the “Top 10 of Nonprofit Blog Problems”:

Blog Problem 1: I have no clue what your blog is about

As I showed in my case study: about 85% of all traffic on your blog, are occasional or new visitors. They stumble upon your blog via search engines, bookmarking sites or forums. As the case study showed, it only takes between 20 and 60 seconds for these new visitors to make up their mind, whether to stay on your blog or not. Thus, first impressions are important.

When I come across a new blog, one of the first things I look for is: “What is this blog all about”? I look at the title, glance quickly through the last blogposts, and often I check an “About” link on the page.

It is striking how many blogs obscure what they are all about. Is it a field blog? Are you solely writing about a certain event. Or is it about a research project? An advocacy blog?

If I can not make it out in the typical 20 to 60 seconds I spend on your blog, you lost me. As you will lose many new visitors.

My suggestions:
Take an outsider. Have your nephew, a friend or your aunt go to your blog. Give them 60 seconds. In this time they have to tell you what your blog is about. If they can’t, you will need to change something:
Make it obvious what your blog is about. Give your blog a clear title, publish a prominent tagline or slogan. Include an “About” tag somewhere on your prime real estate, as described in this post, linking to a page where you explain what your blog is all about. Ensure that “About” tag is visible on all blogposts and not just your home page.

Blog Problem 2: I have no clue what your post is about

You would be amazed how many blogs use vague titles. “June update”, “Pictures of the day”, “Links of 1/6/2010″. Those don’t tickle my interest.

Think of a post title as if it were a book title. Do you think a writer just slams any title on a book he worked on for six months? Of course not.

A post title is a teaser, just like a book title is. It should entice enough interest for people to actually read the content. Sure enough, “Links of 1/6/2010″ contains probably some weblinks you recently discovered but “Links: Agriculture research in Africa, Harvesting Techniques and more” will tease more, wouldn’t it?

Remember many of your readers get you blog updates via RSS links, Email and aggregators. New visitors find a link via a search engine. If your title does not look interesting, they will skip reading the post. Another visitor lost.

My suggestions:
Before you hit “Publish”, spent just 10 seconds thinking about the title. Ask yourself two questions: “Does it represent the content?” and “Am I teasing interest?”.

Blog Problem 3: I can not find your RSS feed

Returning visitors are a blog’s most precious resource. One new RSS subscriber, adds one more returning visitor.  So why do so many blogs hide their RSS?

Dear people, we live in the 21st century. The electronic age with its inherent information overflow. Most people don’t check updates on your blog every day, as they are following dozens of blogs. Most stay up to date via RSS readers, automatic Email updates, and aggregators. A blog without an RSS feed is a car without an engine. Nice, but pretty useless, unless if you tie a donkey in front of it. The car that is, not the blog.

Even if your blog has an RSS link, as a lazy visitor, I don’t want to go and look for it. Make my life easy please: make the RSS link prominent. Put a big fat RSS icon on your prime blog real estate and publish it correctly so browsers can pick it up.

Worse than NOT doing something, is to do something sloppy. Regularly, I come across blogs with outdated or faulty RSS links. The RSS feed is empty, contains outdated posts, links to an old Feedburner feed or the feed just does not validate. Some feeds feature blog posts with dates in the future, which appear on top of the RSS feed forever.

My suggestions:
Make it easy for people to subscribe to your blog with a prominent icon or “Subscribe” link, and check your own RSS feed regularly.

Blog Problem 4: Your blog is slow

I have a very fast Internet connection, but even then, I find blogs that take forever to load. As I mentioned before, if a page doesn’t load within 5-8 seconds, you will lose one-third of your visitors. People simply don’t have patience.

The common problems are not server related, but blogger related: too many pictures, or non-compressed pictures. A heavy Flash thingie on the banner. Or they are using too many widgets or RSS feeds.

My suggestions:
In this post, I list ways to test your blog speed, and the most obvious ways to increase your blog’s download performance.
If you selfhost your blog, it is a MUST to use a good cache plugin.

Blog Problem 5: Who are you and how to contact you?

When I stumble upon a new blog, I not only want to know what the blog is about, but also who you are, or what your organisation does. Don’t hide that information from me, please!

When you publish that information, make it concrete, to the point and short. Within the text, you can link to other pages or posts describing the various aspects of the work you do, but don’t give me a four course meal if I only want a snack. Please.

Why do so many blogs make it difficult to get in contact with the blogger? Scanning through my list of 777 nonprofit blogs, I often want to write a quick note or email to the blogger, when I notice a problem. If I want to do that effort, then why would you make that difficult for me?

Suggestions:
Feature “Who are we” and “Contact us” as short but prominent links on your blog’s prime real estate. Or at least include them in your “About” text.
Ensure this link is visible on every post, not just on the home page

Problem 6: You have outdated links, missing pictures or dead videos.

As blogposts rack up, it is more and more difficult to keep track of your older posts and to keep them up to date. However, visitors do land on older posts. Outdated links to internal or external posts, “Video no longer available”  or blank spaces where “a picture once was”, all give a very sloppy impression.

And not only that, search engines are said to punish sites with excessive dead links, so in the end your pagerank might suffer if you don’t maintain your posts regularly.

My suggestions:
Use a tool like Google Webmaster or the W3C Link checker to verify your links regularly.
From time to time, just have fun, and click around your site, browse through your old posts. Not only will you see what other visitors see, but sometimes it is just fun going through stuff you wrote three years ago!

Problem 7: Your blog or your posts are messed up

Some blogs just don’t show up properly and blurbs of text, video or pictures run over the margins. Too lazy  to crop a picture to the right size? Or or ignorance on how to change the code of embedded videos to make it fit within your post column?

Remember also that inter-browser compatibility is a real challenge for a blogger.

My suggestions:
This post gives you some useful tools to check how your blog looks like in different browsers.
Spend the time to ensure the post is properly formatted.

Problem 8: Too much text

Yep, it is easy to take a Word document and then simple cut/paste to publish it. It takes a little more time to put some pictures in it, and to properly format a text into paragraphs. But boy, some blogs present just chunks of text. Chunks and chunks.

Personally, I don’t care how relevant your content is, but if it takes a real effort for me to read it, I will skip it.

My suggestions:
Use pictures (and properly compress them) to brighten up your posts.
Put some breathing space in your text and use paragraphs,  or subtitles. Emphasize the pieces which are important.

Problem 9: Too little text

Unless you have a photo blog and you only want people to admire your pictures, posts deserve a bit of text. Pictures speak a thousand words, and are a power medium, but make sure people also understand what it is all about.

A blog only showing pictures with a one liner “Our village got a new water pump” is not enough. Explain what the background is, why the village waited for a water pump, how it will change the lives of people. The pictures will convey a much stronger message with a few lines of text.

Remember we are mostly considering nonprofit blogs. Therefor, your blog is a tool to bring a message to your audience. A tool in the hands of advocacy, fundraising, public information, etc… Just a flurry of pictures gives the impression “I’ll just throw it out there, and you go and figure it out”… Is that the impression you want people to have from your nonprofit?

My suggestions:
Balance between pictures and text. Use pictures as illustrations, teasers or catalysts for the message you want to bring. A message you condense in the blog text. Make sure that message is not obscured.

Problem 10: Spelling mistakes

Sloppy, sloppy! It takes only one minute to spell check a post before it goes out. So spell check before you hit publish.

My suggestions:
Even if your blog platform does not have a spell checker, use your browser’s or cut/paste the text into your word processor and check it there.

And above all: ensure you continue to have fun while you blog!

If you don’t selfhost your blog, skip this post. It talks about a common problem all of us, selfhosters have. But if you don’t selfhost, you’re immune to this disease, which has as symptoms:

• anxiety attacks,
• dizzy spells,
• recurring nightmares,
• adversity to “check for upgrades” or even “admin menus” buttons,
• and above all: fierce regret to ever have gotten to this stage where you are considered a “webmaster”, but deep down inside you realize you know shit, and that big “Internet Publishing” monster is far bigger and more powerful than you will ever be.

But as you are here, welcome. Welcome into this safe space. This is the selfhosters’ cocoon. You don’t have to click any critical upgrade buttons here. You are safe here… Everything will be OK! (soft music playing in the background, a bunny-dressed waitress brings you your favourite drink,..)

<pink off> Where were we? Oh, right, back to the post. We were talking about dreaded upgrades…

Do you have that feeling too? Do you stare at the “Upgrade available – Click here” prompt… For your laptop software, your iPhone applications, you know what that might mean: “Heaven or Hell”… Either you get additional functionality, or “The World As You Know It” will crash. For the former, you’re cool until the next week when more upgrades are available. In case of the latter, you’ll be busy downgrading, retrofitting, restoring backups and patching for the rest of the night.

Upgrading your iPhone and laptop is one thing, but upgrading your blog, is another. If you fail, you can’t keep it private. When you website crashes, it is there for the world to know. You’re then just waiting for the first tweet from one of your visitors:

"www.yoursite.com is down again. Daaah. #FAIL"

But still, you know, to be “part of the bunch”, you really should click that button, and upgrade. Although, for myself, I have to admit, half of the time I don’t really know why I should upgrade. Hardly any of the upgrades give me additional functionality I have really been waiting for. When reading through the upgrade notes, I rarely come across anything I need, or even understand. Know that feeling?
And yet the feeling of “I have to execute that upgrade”, is compulsive. I don’t really know why. Probably because I don’t want to be left out. Because it somewhere guarantees that my plugins remain compatible one to another. Or it might solve a bug I have not come across yet. Or I don’t want to skip upgrades for several months, only to realize half a year down the line none of my plugins are compatible anymore with a really needed upgrade, a security patch for instance. And we all know what a drag it is to go through six months of delayed upgrades, and how all the possible conflicts would then be condensed into one major upgrade, increasing your chance of:

"www.yoursite.com is down again. Daaah. #FAIL"

I have about 10 selfhosted sites. Most on WordPress and Drupal. I use plugins (or modules in Drupal) sparingly, and restrict myself only to those I really need. Here on BlogTips, I have 15 of them. A pretty average number I have across all of my blogs. On most sites I actually use the same plugins. Even so, I get about two to five upgrade notifications per week. Per week…. Two to five chances to wake up in hell.

Sure enough, just like any conscientious blogger, I have a test site where I try out the upgrades first. (You have one too, right? Right????) If my testblog survives the plugin upgrade, I do the upgrades on my life blogs. But it is a drag. It is something as a blogger, I don’t look forward to. I want to concentrate on writing content, not on dealing with all of that “webmaster” stuff…

Then comes the time, where the ultimate nightmare comes. A major upgrade of your blogsoftware is released. Like this weekend’s WordPress 3.0 release.
Don’t get me wrong, I love WordPress. I think it is -hands down- the best blogging software around. I love the idea such a piece of quality software is put in the public domain, free for all to use. I love the idea that hundreds of software developpers all over the world contribute to it. I love the user forums and support infrastructure. I also love that, compared to any software, the bugs are few and the functionality is great.

WordPress 3.0 will for sure give me additional functionality. Some of it, I want. Some of it, I could not care less about.

• It has a new default theme, called Twenty Ten. – Mmm, don’t use the default themes.
• Theme developers get new APIs to easily implement custom backgrounds, headers, shortlinks, menus, post types, and taxonomies. – Thankyouverymuch, but I am not a theme developer
• MU and WordPress have now merged into one product, allowing you to create multiple blogs with one installation – Which I don’t need. Not at this moment anyway.
• Contextual help on every admin screen — Nice, but I hardly ever use the help screens.
• Proper menus – Ah something I really looked forward to. But you can only use it, if your theme supports menus. Some of mine don’t. But I have to admit, this, together with the taxonomy feature would make WordPress move closer into the functionality of a proper CMS (Content Management System), which is something I firmly believe in…
• Bulk updates so you can upgrade your theme, your 15 plugins and WordPress all with a single click – Something I don’t use, as I want to upgrade them one by one, just in case anything goes wrong.
• 1,217 bug fixes and feature enhancements – Oh dear, that many bugs?

Again, don’t get me wrong. Let me restate it clearly: I <heart> WordPress. And watching their release video, I can be nothing but enthusiastic about the work the team does:

But then again, my heart beats faster when I look at that dreaded “Upgrade Now” button. “To upgrade or not the upgrade”, that is the question.

As you know, on BlogTips I mostly write about stuff I am confronted with, as an average Joe Blogger. And stuff people ask me. So the question is indeed, upgrade or not? Well the first thing I did, is go to the WordPress support forums, and look at the upgrade problems people are faced with. While the WordPress 3.0 forum seems to be closed, most of the issues seem to be in the Installation forum. Browsing through the topics I see:

• There are some issues with hosting services:
  

  just finished chatting with Hostgator support and they’ve told me everyone is having issues installing wp3 – so they don’t recommend it for now.

• There are some issues with the memory size on hosting services, where 32 Mb does not seem to be sufficient. The work around by changing the memory limit in the php.ini and wp-config.php file seem to work around that, but I really can not remember what the memory limit is for the hosting service I use. And of course a search on Godaddy for “memory limit Linux hosting” returns ziltch.
• Some plugins are clearly not compatible, or are conflicting with WP 3.0. Some themes might have problems.
• And of course the worse of the worse, the blogmaster’s nightmare:
  

  I tried to upgrade to Wordpress 3.0 today. I did an automatic update, told me it was successful. Then I tried to go to another page in the dashboard and it gave me an error message.

Given the fact there are 10 million installations of WordPress in the world, I am sure there will be some issues popping up. We live in an imperfect world. The more as the quality control of plugins and themes is really left to the individual developpers. But, browsing through the forum, there does not seem to be a general ” #FAIL ” outcry. That is positive.

So what to do next? I quietly upgraded one of my test blogs. And..

…it worked fine. The new functionality was there (apart from the fact that my theme did not support menus). Writing and publishing new posts seemed to work. None of my plugins puffed out, and all seems to be happy-happy. So what was all the fuzz about? Were my fears really unfounded?

What to do next? Well, I will sit on my hands, and wait. I will weather the storm for a while. There are those who love to sail in fierce winds, but I am not that kind of sailor. I take the safe route. I will wait for a while, keep my ship at bay, and see what the others come up with. And wait for some inevitable bug fixes. That is what I am going to do.

And I will live with the fact that for the next couple of weeks, I will dream of only one thing:

Update July 16 2010:
Since publishing this post, I have successfully upgraded three blogs to WordPress 3.0, including one rather unconventional RSS based site. I had no problems thus far.
I am still waiting to upgrade my remaining sites.

Bloggers have rushed to secure their selfhosted WordPress blogs after the recent massive hacks on shared hosts. I was one of them, even though only one of my blogs was affected. I spent hours browsing, looking for good resources, common knowledge, and solid tips to form a list of quitessentials on WordPress security. I also found some useful plugins.

However, as with all things, there are good tips, tips that kinda work and tips that might bring you into more trouble. At the same level, you can keep on uploading plugins into WordPress until the year 2020. Each plugin is a potential hazard by itself. The developer can cease its support, leaving you standing in your underwear in the middle of Blogging Street. And the more plugins you have, the more maintenance your blog will need: upgrading to new releases might become a hassle, knowing every single release is a potential bug farm. It would not be the first time I do a quick ‘Upgrade’ of a minor plugin “just before going to bed” only to find myself trying to get my blog to work again as ‘the minor upgrade’ conflicted with something else and crashed the whole site. Sigh.

So… think before you do anything hastily. For every plugin, check the forum posts related to it, check for bug reports and Google its name to see if there are any complaints.

In a past week, I installed several recommended plugins on some of my test blogs, and will report back if I find good and useful stuff. Meanwhile, I will restrict my recommendation to the WordPress File Monitor plugin I wrote about in my previous post.

As for the tips on security, same thing: I will restrict myself to the bare essentials. After all, I am a blogger, not a systems engineer or a web designer. I have limited time and patience to devote to the technicalities of keeping a blog up and running. I’d like to concentrate on contents more than PHP code and SQL database queries.

Nevertheless, I want to list some of the posts on WordPress security that have been cross referenced several times.

• 12 Essential Security Tips and Hacks for WordPress by Syed Balkhi
• Hardening WordPress from the WordPress site itself.
• WordPress Security Tips and Hacks
• 11 Best Ways to Improve WordPress Security
• The Almost Perfect htaccess File for WordPress Blogs by Josiah Cole

After going through all of these, I found some good tips which I will consider, some I will disregard (e.g. I can not lock any file access to a fixed IP address as I don’t work from a single location, and my ADSL lines have dynamic IPs), but there is one I highly recommend to you:

Secure the wp-config.php file!

If you are not familiar with the wp-config.php file in your root directory, take a look at its content….

Yep, that’s right, you’d better believe your eyes… Here is the basic security access data for the inner workings of your WordPress blog. All readable in plain ASCII. So you’d better secure that file, or your blog is wide open as the Louisiana flood gates!

The fastest and easiest way to protect your wp-config file is by adding the following lines at the bottom of the .htaccess file on your root directory:

# BEGIN protect wpconfig.php
<files wp-config.php>
order allow,deny
deny from all
</files>
# END protect wpconfig.php


This code basically blocks “world access” to the file.

Do it now. Safe blogging!

This WP-config tip was discovered via WPSecurityLock and DevLounge
Pictures courtesy Public Domain Image and The Nosebean’s Blog

During the the latest spree of hacks in April and May, hackers dropped a malicious .PHP script on the root directory of selfhosted blogs.
The script changed all .PHP files, adding one line of code which redirected visitors to a virus-infested site, and then deleted itself. There was anything between a day and an hour between the drop of the hacking .PHP file, and its self-deletion.

In my frantic search to close the security holes on my blogs, I came across a WordPress plugin called WordPress File Monitor by Matt Walters.

The plugin monitors your WordPress installation for any file changes incurred by scanning your directories from the root down. The plugin detects changes based on the files’ hash (a number that uniquely identifies each file based on content, name and timestamp) or on the timestamp of the files only. Of course the “hash” method is more secure, but takes more computing time from your server.

“Changes” could be an upload of a file, the deletion of a file, or changes made inside a file.

You can configure the scan to happen between 1 minute and an indefinite interval. Or you can decide to only scan your files manually from the dashboard.

When a change is detected, a notification appears on your WordPress dashboard:

Clicking on “View changes” gives you more details. In our case a file called “try.php.jpg” was dropped at the root directory level:

Based on the alert, you can take the appropriate action, or just clear the alert.

You can also configure the plugin to send an email alert to a specified address. As a test, I set the scan interval to one minute and edited the .htaccess file on my root directory. The warning email was sent immediately:

This email is to alert you of the following changes to the file system of your website at http://www.haveimpact.org
Timestamp: Sun, 23 May 2010 00:11:54 +0200

Changed:
.htaccess

As some directories, such as cache directories, change their information on the fly, you can exclude them from the scan.

This plugin is highly recommended to help you secure your selfhosted WordPress blog!

Read more about blog security in these posts.

Picture courtesy Discoveries in Medecine

While researching ways to better protect my blog, I discovered a loophole typical for selfhosted sites on shared servers, such as GoDaddy.

The loophole concerns all PHP based CMS (Contents Management Systems), including WordPress, Drupal, Joomla, phpBB, etc…: Many of them allow users to upload files: Forums allow attachments to posts, users can upload their avatar in .jpg format, some comment systems allow code to be embedded. Combine this with shared-hosting services like mine, GoDaddy, which allow files without the .php extension to be executed as if they were PHP code, and you have a hacker’s bomb.

Here is how you can simulate a file drop hack:

1. Create a simple text file with a simple text editor and put the following PHP code in it:
   
   

   php
phpinfo();
?>

   This code does no harm. The command only displays the basic PHP variables for your site, but a hacker could put any malicious PHP code in it, including code that modifies all files on your site.

2. Save it as test.php.jpg
3. FTP it to the root of your site
4. Execute it in your browser (and you don’t have to be logged in) as: http://www.yoursite.com/test.php.jpg
5. If you get a “Page not Found” error, you are cool, and your hosting service protects you from this hacking method. But if you see something like this screen, the output from the php-code you just uploaded, your host is vulnerable:



… and if the code were malicious, the user just dropped a hacker’s bomb on your site….

Sure enough, a user does not have FTP access to your site (I hope!). But… as long as he can upload the file, even as a disguised .jpg file as in our example, and figure out where the uploaded file  is stored in your site’s file structure, he can execute it.

How can you can protect your blog from users uploading disguised PHP file? This documented vulnerability can be corrected by adding some code at the bottom of your .htaccess file in the root directory of your blog (or any PHP-based CMS):

1. As for any changes you make to any file on your site, first backup the .htaccess file, so you can roll back in case it does not work for you.
2. Edit the .htaccess file and add the following piece of code at the bottom:
   
   
   

   # BEGIN drop-file hack stopper
RemoveHandler application/x-httpd-php .php
<FilesMatch ".(php|php5|php4|php3|phtml|phpt)$">
SetHandler x-httpd-php5
FilesMatch>
<FilesMatch ".phps$">
SetHandler x-httpd-php5-source
</FilesMatch>
# END drop-file hack stopper

3. Upload the modified .htaccess file to your root directory
4. Now, assuming you still have the test.php.jpg on your root directory, try executing it again with the same command: http://www.yoursite.com/test.php.jpg

If now, you get a ‘Page not Found’ error, then you are protected. At least for this hack, that is.

One word of caution: this was NOT the method used in the most recent massive hack affecting thousands of sites, as described in this post, but at least it closes one more door for hackers. A door which gives them unlimited access to your website.

Safe blogging!

Cartoon courtesy Life on the Homefront

Godaddy got hacked again this morning (This is what Godaddy has to say about it). Update: and again on May 20.
If you host your blog on Godaddy, you would do well to check your site regularly for any malware, and here is how.

The hack is the same as the previous 4 hacks, affecting thousands of sites: A oneliner malware code is inserted in every single .php file on your site, starting with:

?php /**/ eval(base64_decode("goobledegoob"))

I described before how to cure it, but here is another, slightly more sophisticated way which first lists the infected files, prompts to continue, deletes the oneliner malware in all of your .php files, and lists the cured files. It is inspired by a script written by Andy Stratton in this post.

The script will not only work for Godaddy + Wordpress, but for any .PHP based site (I used it this morning to cure a Drupal site) on any host.

Here are the right steps to follow:

1. Make sure you backup your site, just to make sure. There are many tools to do so, but a “brute force” copy of your entire blog directory to your local computer using an FTP tool like Filezilla, works fine.
2. Download this zip file. It contains a file called “fixfiles.php”. Extract it and store it on your computer.
   (Ok, no zipfile? Here is the fixfilesphp.txt version. Save it as fixfiles.php)
3. FTP the “fixfiles.php” file to the root directory of your blog. In GoDaddy, that is the /HTML directory (which also contains index.php, wp-login.php etc..):

   
   

   

   GoDaddy Root Directory

   If you only want to clean a subdirectory (and its underlying tree), put the file in that the subdirectory, but remember also the command in the next line will have to reflect that.

4. Then execute the code with the command:
   

   http://yoursite.com/fixfiles.php

   or

   http://yoursite.com/subdir/fixfiles.php


   if you put it in a sub directory)

5. The code will first scan for the malware code in your files, in both the directory it is put, and all underlying directories.
   If you get the message:

   0 Infected Files in ./

   …then your site is clean.
   If any malware is found, the script will list the infected files and prompt you to fix them:

   Click on “Fix Files”, Click OK on the prompt to proceed:

   
   The script will scan through all files again, and clean the malware. It will list all files that were cleaned.

   

6. Delete the “fixfiles.php” file from your site after execution.
7. If you are using a caching plug-in, don’t forget to CLEAR YOUR CACHE, otherwise the malware will continue to be served to your users, even though you cleaned your .php code

All of that is “curing” the problem. I have looked everywhere, but am yet to find a way to “avoid” the infection. It looks like the hackers found a loophole in Linux shared hosts (and not just those on Godaddy), which the hosting companies have been unable to identify and/or close.

Until such time, scan your sites every day, and cure the problem immediately before your visitors get infected.

Picture courtesy Owning Pink

Sucuri.net malware scanner

I reported before how to detect if your blog was infected with the recent massive hackers attacks on hosting sites, and how to cure it.

As a follow up, here is the easiest way to detect if your blog has the malware injected: Use the sucuri.net free scanner !

Just enter you blog URL including “http://”, press “Scan”, and there you go.

If the “Malware information” tab goes red, this means that -unfortunately- your site has been infected.

Cure the problem immediately as I described in this post.

If you are a technically a bit more savy, in this post I describe a script that verifies the infection and cures it.

Update: I adapted a script to easily verify and cure the infection on your site. Check this post for more.

The GoDaddy hosting service got hacked three times in a row now. On April 27, May 1 and May 7, many sites, including thousands of WordPress blogs, got infected by malware code. Update: GoDaddy hosted sites were massively attacked again on May 12 and May 17.
In a recent post, I described how I found out the hard way my Drupal site was hacked, and how I cured it the hard way.

Last night, BlogTips was hacked too, but this time, I was able to cure the problem faster.

The problem is so wide spread, and the impact for the infected blogs is that devastating it is worth to checking yours too, if it is hosted on GoDaddy. Once infected, you need to cure your blog real fast before browsers and search engines blacklist your blog. Here is how:

1. Check if your blog is infected

If your blog is part of the recent GoDaddy attacks, you (and your visitors) might see it if your site redirects to a malware site which gives a Windows-like screen asking to scan your computer.

The easiest way, however, is to check some of your .php files. If the first line of the file starts with:

?php /**/ eval(base64_decode("goobledegoob"))

(where “goobledegoob” is a long series of numbers and characters), then unfortunately my friend, your site was hacked too.

2. How to cure it

Cure the problem fast before your users and search engines start mistrusting your blog. Thecremedy is to remove that one-liner with the hack code from all your .php files. You can do that manually, but you’ll be busy for quite a while.

An easier solution is offered in this post by the folks of Sucuri Security.

1. save this PHP code in a file called “wordpress-fix.php” on your computer. It contains two basic commands to remove the EVAL malware code, and extra empty lines from all your .PHP files on your root directory and all sub directories.
   Update: to avoid the script to time-out before all files are cleaned up, you might add  the line
   set_time_limit(0);
   as the first PHP command
2. FTP the “wordpress-fix.php” file to the root directory of your blog. In GoDaddy, that is the /HTML directory (which also contains index.php, wp-login.php etc..):
   

   GoDaddy Root Directory

3. Then execute the code with the command: http://yoursite.com/wordpress-fix.php
4. Delete the wordpress-fix.php file after execution.
5. Update: if you are using a caching plug-in, don’t forget to CLEAR YOUR CACHE, otherwise the malware will continue to be served to your users, even though you cleaned your .php code

3. How to prevent from being hacked?

Well, at this moment, it looks like it is GoDaddy being hacked, and not the individual blogs. It is still advised to change your FTP password, and your admin password on your blog, but that by itself does not seem to prevent new hacks. One of my sites got hacked twice in a row.

You can also subscribe to Sucuri’s free malware monitoring service, so they can scan your blog automatically for malware,…

Let’s hope GoDaddy gets their security back inline quickly, otherwise we are all in deep poohooh for a while!

Picture courtesy TheTechHerald