A picture is worth a thousand words or so the old saw goes and it is certainly true that an image can greatly help the look of a blog post.
Several people have asked me recently how to add images to blog posts so I thought I’d put up a blog post explaining how I do it in case it would be useful for others.
I store my images online on Flickr. When I want to use an image in a blog post I use the copy of the image which is stored on Flickr. This has the advantages that:
- it saves me diskspace from my hosting account,
- it saves me bandwidth from my hosting account and
- it is easy because Flickr provides the code to use the image from their site!
Being a simple soul, I like it when things are made easy for me.
How do I do it?
Well, click on the image you want to use in your Flickr account. If you don’t have a Flickr account, get one! A free account will allow you to upload 200 images and if you need more than that it costs around $25 p.a.
Once you have selected your image, click on the All Sizes button above the picture.
This brings you to the Available Sizes screen. Here you decide which image size you want in your blog post and select it. I generally go for images around 500 pixels wide (although the one selected below is 240 pixels wide).
When you select the size you want, the code required to place the image in your blog post is in the field under:
1. Copy and paste this HTML into your webpage:
Copy and paste that code into your blog post et voilÃ , you now have an image in your blog post.
Due to issues with the server this site was on, my hoster agreed to move it to another server this morning. That move happened at around 11am GMT today.
Just now I noticed a comment which was made yesterday on one of my posts and which I was not notified of by my blog software (presumably due to my mail being on the same troublesome server) – hopefully I didn’t miss too many other comments.
If anyone left a comment or emailed me in the last two days and I haven’t responded, you have my sincerest apologies and please contact me again. Hopefully this move to the new server will resolve the problems this site has been having.
Anyone trying to access this site or my PodLeaders site today between around 12:54 GMT and 13:14 GMT would have seen a screen somewhat like the one below.
My hoster told me when I rang them that they were ‘working on it’ but didn’t tell me what ‘it’ was!
This is the second time in just over a week that this has happened – not very confidence inspiring!
My hoster has been back on to me to tell me that the problem is that my site is hosing the server! We’re tying to work out why now.
The site has been up and down (mostly down) for most of the afternoon. Hopefully my hosters will get this sorted asap.
Apologies if you were trying to access this site or its podcasts at around 1am GMT this morning – the site was briefly offline. The site was offline because I exceeded my hosting bandwidth allowance – due to the unprecedented success of my podcasts!
A victim of my own success!
Fortunately the nocturnal FrankP rang me to alert me (knowing that I was probably asleep but also knowing that I would be prefer to be woken to get this sorted asap) and even more fortunately, I have the mobile number of the MD of my hosting co. I rang him and he said he’d get it sorted – that’s good service, thanks Michele.
I mentioned in a post earlier this morning that I was having problems accessing wordpress.com blogs – wordpress.com is a hosted multi-user version of the blog software I use, WordPress. The site is now available again but suffered a “major disk failure” according to a message on the wordpress.com Dashboard.
The data loss is presumably because the drive which failed was not in a RAID array and the last backup of the site was a couple of days ago!
This is unforgivable. No matter how small a hosting organisation you are (and WordPress.com couldn’t be considered small), your users data is sacrosanct. Users will tolerate occasional downtime but not loss of data.
Matt and the rest of the WordPress.com team, you need to try to resurrect as much of your users data as possible (if you haven’t already done this), put the site on a RAID array, put a disaster recovery plan in place which ensures no data can ever be lost again and then try very hard to rebuild your now shattered reputation.
MacManX alerted me, in the comments of this post, to the fact that Matt has put up a post about this issue. In the post, Matt explains what happened, how the WordPress.com team responded and that fact that no data was lost:
Donncha was on the ball and switched all the traffic to a recent backup so most things would work while we investigated the hardware failure. This means that an old version of your site was shown for a few hours.
A few minutes ago we restored the up-to-date database and weâ€™re currently syncing it to the backup to get back any posts you might have made during the semi-downtime. Even though we were able to recover everything, weâ€™re looking at ways to make things even more redundant, so if this ever happens again the problems will be measure in seconds or minutes
It is lucky for the WordPress.com team that no data was lost, this will help people’s confidence in the platform. However, they need to get a RAID solution in place for the database (preferably with multiple RAID containers – 1 for OS, 1 for db and 1 for transaction logs) and a live backup db server in case of a logic board failure on the db server. Only at this level of redundancy will they be able to sleep at night and hand on heart be able to promise data integrity to WordPress.com users.