The “Perfect” Look-and-Feel with a WordPress.com Hosted Premium Theme

As part of my work to update the website look-and-feel, close off some old server infrastructure, and reduce service provider costs, I moved wittzend.com to WordPress.com as its new platform. I had used WordPress as a blogging platform on-and-off for years (most recently, for the now defunct “WET Pod Foo” podcast), but always on my own servers; the old “download-install-maintain” bit. The one downside to self-hosting, having to keep up with a seemingly endless stream of security updates, is handled automatically for you if you allow WordPress.com to host the instance. Since this is a hosting arrangement Witt’z End Technologies has been encouraging others to look at when building new sites, it seemed appropriate to use the opportunity of consolidation to follow that advice for this site. Along the way, I found some issues that required creative work-arounds to get the exact look-and-feel I wanted from a theme…without having command-line access to edit the core files directly.

The process for migrating a site is pretty straight-forward. You begin by setting up a WordPress.com account, if you don’t already have one, and then proceeding to choose your hosting options. Once done, you get a site_name.wordpress.com address for the site. You also get the option of buying a new, custom domain, or pointing one you already own to the new pages. Choosing the latter requires entering the domain in the WordPress site management Dashboard, updating your DNS authoritative name servers with your domain registrar, and, if you are hosting email somewhere for the domain, updating the MX records in the WordPress DNS management interface for the domain. The nice part about this process is that you can build-up the site at the WordPress.com assigned name space, and then move your DNS pointers once the new site is fully ready for traffic.

Creating a nice looking WordPress site involves the use of themes. Themes are just easy-to-use collections of layout and stylistic elements that define the look-and-feel of the pages. Luckily, there are lots of creative people out there building awesome themes that can be customized to varying degrees to suit your specific use case. Often you may find the perfect one has a cost associated with it (not free), but WordPress.com has that covered too. As part of an annual subscription, you can get unlimited access to premium themes (among other things), or, if you prefer, you can access the online store to buy only the one you want. After some exploration, I settled on a premium theme named, “yumblog“. Once I got beyond the silly name, I found it did exactly what I needed (including being optimized using the Responsive Web Design approach) with some minor tweaks…but implementing the minor tweaks is where I ran into a little trouble.

I mentioned already that I was used to self-hosting WordPress sites. What that means is that all of the files for the WordPress implementation were on my server, and accessible to me for modification. This is not the case when hosting at WordPress.com. Your access to the files making up your site is limited to what they can provide via the web interface. This is not a problem for most things. In fact, I quite easily modified the colors, layout, and other design elements of my chosen theme through the appropriate screens available to me. There was one insidious problem, however, that I could not seem to address via the tools: no matter what I did, I could not change the coloring of the collapsible menu on the site when it was displayed on mobile devices. It remained this sickly green color that was the default of the theme. The color attribute for that screen type was hidden deep within the Cascading Style Sheet (CSS), and was not updating correctly with other color element changes made through the UI. The theme controls have a place for adding customized CSS, but it was not readily apparent what the element names were that needed updating. I also needed to identify the colors that needed changing along with the colors to which I wanted them changed. So, more investigation was required.

In order to capture the color codes for making my needed changes, I had to devise a way to capture them from the live site. Since I didn’t know what they were, or what the element names that I needed to change were, I needed a quick-and-dirty means of identifying them. Now, I know that someone that can read through CSS and HTML quickly and see “The Matrix” probably wouldn’t need this kind of hackery (so keep it out of the comments 🙂 ), but I do at this point. Sad, but true. I made use of a couple of things I always keep handy; a User Agent switcher and a color picker utility.

There are some cool extensions (Chrome)/add-ons (Firefox) that allow one to manipulate the User Agent the browser uses. The User Agent is what tells a web server what type of device and browser is accessing the site, and displays content accordingly. This is one of the things that allows a responsive web site to adapt its content dynamically by device type. I initially installed “Chrome UA Spoofer”, and attempted to load the site using the built-in Android User Agent, but found that Chrome for Windows would not allow me to compress the window to a narrow enough width to activate the menu collapse where the default color remained. I had to install the “Default User Agent” add-on for Firefox, and use it instead. There was no built-in modern mobile browser UA in the add-on by default, but I happened to have an old XML file containing some cool ones I used to use at Limelight Networks when I was there, so was up with what I needed in no time. The XML to import what I used:

<useragent description="DROIDX"
useragent="Mozilla/5.0 (Linux; U; Android 2.1-update1; en-us; DROIDX Build/VZW) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17 480X854 motorola DROIDX"
appcodename="" appname="" appversion="" platform="" vendor=""
vendorsub="" />

I could now open the site like a mobile device from my desktop browser, and could reduce the screen size to force the collapse of the menu. All good. Now, I just need to capture my ugly green color, and a few others that were messing up the look-and-feel. For this part, I used an add-on called “ColorPicker“. This tool allows one to mouse over colors in an open web page, and get the color HEX code and RGB numbers. Useful. So, with this installed, and the page opened as a mobile device, I could capture what I needed to search the theme’s CSS in order to implement my changes.

I found my “bad” colors to be #92B34C, #7E9A41, and #82BFB9. I wanted to replace all of them with #130B05. Easy enough. Now, I needed to find them. I opened the site up in Chrome, right-clicked on the page, and selected “View page source”. I searched the HTML source to find the reference to the linked CSS document. I needed to find the one for the “screen” media type:

<link rel='stylesheet' id='screen-css-4' href='http://s2.wp.com/wp-content/themes/premium/yumblog/style.css?m=1394717094g' type='text/css' media='screen' />

I opened up the referenced CSS document in a browser tab so I could copy-and-paste the entire contents into a text editor. From there, I just needed to search and replace the “bad” color values with the one I wanted to use. Once done, I was able to use the Appearance -> Customize -> CSS interface to drop my updated CSS in, and save it to the site. Just like that, issue fixed. Revisiting the site with the Firefox configuration allowed me to validate the changes were complete, but just for fun I visited it with my mobile device to make double sure.

Now, we’re in business with a fully customized (and non-green) theme, and good-to-go.