This is part two — read part one of What can go wrong with your web site here.
6. The CMS.
This is the glue that, usually, publishes the actual pages, handles the interactions between the database and the front-end (the front end being the web site your visitors see). Wordpress is a light-weight open-source CMS used for publishing blogs. Drupal calls itself a “content management platform,” which means it’s like a CMS with lots of room to build onto it. Django, a “web framework” written in Python, occupies the space between CMS and programming language. There’s usuallly the “back-end” of the CMS, which is a password-protected website that the people publishing the information write and edit and administer that inforamtion. Then there’s the front-end, which is what you see when you go to that particular web site.
What can go wrong with the CMS?
This is not an easy question to answer. There are so, so very many things that can go wrong here in the context of web publishing. More than anywhere else. There can be security flaws in the CMS (see Drupal’s archive of security-related announcements here).
There can be problems in the administration area of the CMS (the place where you go to write / upload whatever it is you’re publishing). The user interface (UI) can be clumsy or inadequate — this won’t break your site, but it will make it more difficult to publish what you want to publish. Ever had to decide between 300 items in one of those select-form drop downs? That’s clumsy. Ever used feedburner to edit multiple feeds in multiple tabs at the same time? You can’t do it — it’s built in a way that will mess and combine your feeds settings should you try this (and worse yet, it doesn’t know it’s making a mistake which means you don’t know you’re making a mistake until you’ve made it).
There can be problems with the front-end of the CMS — with what the CMS does to publish the information you want to publish. There can be issues with internationalization and character sets — ever seen one of these on a website? That’s because not all letters are created equal. Some, like the english alphabet, are simple. Others, such as é, are more complex, and thus take more intelligence to handle correctly. Others, such as the japanese language, are even more complex.
Recommended reading about CMSes
CMS and the Single Web Designer
Web-Based Content Management System: Basics
Wikipedia’s article on Content management systems
7. The external servers / Content Delivery Network (CDN).
Your CMS won’t necessarily serve all your data. That’s because lots of the time, the people who wrote the CMS were more interested in building a cool tool to publish information than they were interested in building a tool that can handle a lot of traffic. It’s possible and likely you use another server to handle your “flat” files (i.e. files you wouldn’t want to change very often, like images used in your site template).
What can go wrong with the external servers?
When you’re dealing with CDN’s you’re not just dealing with one server, you’re dealing with hundreds, all over the world. All those servers make it more likely that the person visiting your website will get all the files they need. So what can go wrong with the CDN itself? I don’t know.
Recommended reading about external servers and CDNs
Wikipedia’s article on Content delivery network
8. The vendor software and servers.
Not all web sites are self-contained. Many rely on information from other sites — news sites rely on a large number of vendor sites in their quest to accomplish their online information goals. Examples of information published on web sites that come from other servers include The Associated Press headline lists, FeedBurner generated headline lists, and SportsDirect stats.
What can go wrong with the vendor software and servers?
External servers can mess with your site look-and-feel — every time The Denver Post adds the AP primary-vote results to its homepage, many of the Post links turn orange. That’s because the AP wrote some sloppy CSS that runs over into non-AP parts of the site, and it’s because us Post onliners don’t care enough for this limited use-case to address it. This isn’t something that’s awful, but it does happen. If you use javascript to include vendor information on your site, and the vendor’s servers serving that javascript are slow, it can cause your whole site to load slower.
Then there are situations like what happened with FeedDigest — FeedDigest (now FeedInfomer) was bought by a group of investors more interested in building audience than customer support. Such things happen.
9. You.
The technical term for this is “the client,” but I like writing “you” more. It may be something wrong with you, the person, but more likely it’s something wrong with the web browser you’re using to read this page.
What can go wrong with you?
Well, you’re pretty good the way you are. Not much worth changing. Sure, there’s a chance you’re looking at a browser-cached version of this web page — “cached” meaning an older version of the page saved on your computer. Or maybe you’re running an old computer with a super-old broswer (cough, IE6). But if sites don’t work in that super-old browser, that’s not your fault, no. Blame the ego of the people that made the website and forgot that people different than they might be using it.
Recommended reading about you
Wikipedia article on PEBKAC
Google search for “Our Browsers, Ourselves”
10. Did I forget something?
Do you have a story of yours to add? Contribute it in the comments.
Recent Comments