It’s becoming increasingly important to be able to test your website – be it a standard version, responsive or a mobile specific version – on multiple devices. All of the major smartphone makers use Webkit (the basis of Chrome & Safari), except, of course, Microsoft.
Quite often websites will display the same in Google Chrome as they do on Android. However, sometimes they do not. Also, sometimes interactivity needs to be tested to see just how well it works on a touchscreen. Using the Android SDK helps you do that without having to have a huge range of devices with multiple versions of the Android OS at your disposal.
Step 1: Downloading and Installing the Android SDK
Download the SDK from the Android developer site
Read the Installation instructions – the page will change depending on which OS you use it for. I’m on a Mac, so I see the Mac instructions.
Personally I put the unzipped folder into my /Applications/Utilities directory.
Why not use Internet Explorer 9’s Developer Tools for testing IE8 & IE7? Here’s why.
Twice last week this issue has come up so I’m providing some examples and reasoning as to why you should not even bother using Internet Explorer 9 for testing websites for how they would look in Internet Explorer 8 and Internet Explorer 7.
IE has traditionally not been developer friendly out of the box. In IE9, that changed and Microsoft provided Compatibility Modes within Developer Tools (F12).
Months back, working with a couple devs, I was told this is how they test with IE8. I thought “wow, great that Microsoft is trying to help developers.” I never looked into this feature before, as I had always just used VMs for testing, long before IE9. So when IE9 came out, I continued that patter. (Microsoft provides free virtual machine images for testing.) However, my distrust for them overpowered me and I decided to run some tests.
The first test I ran was Acid3 http://acid3.acidtests.org/ Viewing the screenshots below, you will see the immediate differences I saw: A different score and slightly different rendering (eg “FAIL” in the corner.) Continue reading
Support forums are nothing new. They exist for all sorts of projects, including just about every WordPress plugin. 99.9% of the time they are “users helping users” with the occasional response from a developer.
That’s how WooThemes handled their forum, until recently. Although their official responses were fairly common, users could still help users. Now WooThemes has overhauled their backend (dashboard), along with their support forum.
Users can no longer help users.
Why? Because WooThemes saw people were often posting to resolved threads trying to get answers. This is really common on forums. In fact, many forums will ban you if you start a new thread instead of reviving a recent one on the same topic. WooThemes thinks this doesn’t work well for them. (They also mentioned sometimes posts were creating confusion.)
WooThemes has gone and done two thing in opposition to the status quo. And you know what? It’s for the better.
Better WordPress Theme Support
The reason WooThemes has done this is because they want each and every forum question to get an official response. I don’t know of a single other product support forum that does this. Not even big companies like Intel offer this sort of support.
There are quite a few companies that promise quick response times from customer support. Really those are quite pointless. Often they’re canned responses that are sent simply to get back to you quickly. My least favorite are the one that ask you information you just provided them with like “What browser are you using?” And you already told them “Chrome 15.0.874.15, extensions off, cache flushed.”
WooThemes does things differently. Their responses are always useful. Sometimes they remind users they need more info, but sometimes that’s needed. They offer simply awesome support and not only that, but now they’ve streamlined it as well.
In the end my only complaint is that I can no longer give them a hand by answering questions or help confirm issues.
A year or so ago I did some research and testing of the variety of website uptime monitoring services out there. Sure any half-decent host does this as well, but sometimes a server only goes down externally and sometimes it doesn’t trigger their monitors. I also did this because I wanted to get a clear picture of just how much downtime a site might have.
Sites do go down, even if just for schedule maintenance. I wanted to see just how reliable my hosts were. Some of my hosting is supposed to be much more reliable than other hosts, and I wanted to see if I was getting what I was paying for.
When searching the first thing I realized were most all of the free or free trial offers were limited to the point of being useless. The next thing I noticed was that the paid options seemed rather expensive.
But then I came across Uptime Robot. They provided monitoring up to 50 sites – for free. They offer a number of configuration options, as well as uptime checking every five minutes which is much better than the 10-30 minutes other services offer. (I mean, really. If a service is only going to check every 30 minutes, that’s pretty much worthless. I’m going to have received a call by then.)
I’ve exchanged some emails with Uptime Robot. They helped me discover a problem with one host’s email, and they also implemented a feature I requested. They’ve been monitoring away on about a dozen sites of mine for about a year now, and they’ve done a very good job at it.
Having moved WordPress blogs before, the process is not as easy as it should be but it’s also not very difficult. That is, however, unless you’re using the Thesis theme from DYIthemes.
Hopefully this will save you from much grief. If you’re using that theme, you have to disable it first, the move it. And even still, if you re-enable the theme, you must edit some files before you do so.
I experienced this issue both moving WP from one directory on a site to the root directory, and moving the site from one domain to another. No amount of scouring through the database to find the old blog URL and changing it would do the trick. I dug, and I dug and I dug – eradicating all instances of the old blog URL. All to no avail.
When moving the blog, step #4 is to change the WordPress address under Administration > Settings > General and step #5 is the same for the Blog address. If you use the Thesis them and make this change, you will watch as the change immediately reverts.
You can make the change in the database itself and after you load a page on the site, check the DB again and it too has reverted to the old URI(s).
The answer? Check your theme files. The Thesis theme files update when the theme is enabled, hardcoding the site’s URL into the theme code. Do a search for the old URL, and you will find it in the theme code. Change it to the URL of the new/updated site, or disable the theme altogether.