Going mobile Part 2 – dealing with legacy content

This is part two in my “Going Mobile” series. As some you know I’m migrating my website to work on all smartphones and tablets. It’s been a really fun process, especially since at my day job I usually consult on how to do this. So, it’s been great to actually sink my teeth into my own full-blown project that also includes a content management system.

As I’ve mentioned before, I have almost 100 posts to manage through this transition along with a variety of plugins and hundreds of images. This site is not custom so upgrades and changes should be fairly routine.  What I mean is it’s a fairly run-of-the-mill WordPress installation so there isn’t anything really fancy or complicated about it. And, that’s the way I like it so it just runs itself without much maintenance or intervention.

So, I’m still in the preparatory phase of migrating over to mobile. There’s been a lot more things to deal with than the typical applications that I build. Here are some of the issues I’m working through now:  

Images not optimized for mobile. I have hundreds of images that I pasted into blog posts. Some of these are up to 400 pixels wide, which covers most of the screen for your average smartphone. Perhaps some good news is all of my images are PNG format, but they were intended for use on 1024×768 or greater monitor sizes. Now, if I change the size of these it could affect my default page formatting. I tried to avoid that type of problem in the very beginning in terms of how my images are placed on the page, but we’ll see. I’m still experimenting on what do, and in my estimation it all comes down to performance. If anyone has any recommendations let me know?

Web Server Permissions. My blog hosting provider is fairly strict on the server configurations and the mobile plug-in model requires server-side access. I basically traded some access for massively reliable uptime.  There have been some issues with the mobile plug-in and how it works with various pieces of WordPress, PHP and the web server itself. If you work for an organization with full admin access to your web server then this shouldn’t be much of an issue.

Blog post length. I have some long blog posts that require a bit of scrolling. I don’t know if there is a right or wrong answer on the appropriate length of a non-paginated blog post. Personally, I hate paginated websites and as a default I expect to get the full article. I read a few blogs already on my phone and while I don’t mind scrolling down I’ll have to see what kind of feedback I get from visitors and regular readers.

Cross-browser testing. With my current blog, I’ve never ever had to worry about cross-browser testing. WordPress just works, period. I’ve occasionally received browser-related complaints. However, after some investigation the majority of the complaints were spam emails try to trick you into clicking on a hostile link. Once I get everything up and running I’ve created a simple test sheet with various check-off items to make sure I’m (mostly) comfortable and can sleep at night knowing I didn’t just hose things up dramatically.

Plug-in compatibility with WordPress upgrades. This is a major concern. I like building my own software because I can adapt it to any underlying changes. With a plug-in you are at the mercy of the plug-in vendor and your content management system. My fallback plan for this is I can always disable the plug-in. For now while I’m in the experimenting phase, my blog foundation will remain fixed and designed for 1024×768 content. Ah yes good old 1024×768. So, if I do pull the plug on the plug-in (no pun intended) then in theory everything should revert back to my default theme until I can figure out a fix or move on to a more responsive design approach.

Going mobile with blogging

I’ve had several comments that my blog is not mobile web enabled and that I need to “put my money where my mouth is” and “practice what I preach”. Little did they know that I have in fact been investigating the various mobile web options and doing my homework. In fact, just in the last week I started experimenting on my live blog, which I will add is a scary thing to do and there have been some problems. So if you come back to the website and it looks like something has changed, it’s very possible it’s related to my ongoing modernizing efforts. And, puh-lease let me know if you see something is broken.

The approach(es). I’ve started with the approach of having two different themed websites: one theme for desktop and one theme for mobile web. Why? Because I’ve gotten quite a bit of feedback that some people like the utilitarian look and feel of the desktop theme. On that note, if you don’t like it now is the time to say something. I’m also looking at responsive (fluid) designs that use CSS3 media queries to hide and unhide content depending on the device and browser you are using. I’ll be tackling responsive designs next, and perhaps much sooner than expected if approach numero uno crashes and burns in a flaming, twisted mess.

Challenges. I can say one of my primary challenges is handling legacy content, for example short codes and existing plugins such as the ones that affect page load performance like Total Cache. If you are just starting out fresh then your life is significantly easier as you are starting with a clean slate. But I have almost 100 blog posts that need care and feeding and I don’t really want to be manually changing page content, if I don’t have to, so that the new website theme or plugin can have its’ way.

Fallback plan. At the moment I’m being very careful with taking a full backup of the website and the database, as well as copying specific files before playing with any plugins or theme changes. In the best case scenario I’d like to create a completely separate copy of the website to play with, however there is a good chance this isn’t going to happen unless I simply can’t get a theme or plug-in to work. Usually theme or plug-in changes are relatively painless, with the emphasis on ‘relatively’. Besides, I always recommend clients create a test copy of their website that’s not visible to the public. But, they are usually big(ger) organizations and have more resources. I may still do this if time permits, but my theory is if I really mess something up I can restore the site or database.

Maximum WordPress Spam Prevention: Part 2

Anyone who has a public facing blog knows about being bombarded by spam. Recently I got so annoyed I started locking down blog comments after thirty days. After a month or so I realized this was counter productive. Readers could no longer participate, ask questions, etc. so I started searching for a better way to handle my anti-spam measures.

After doing a bunch of research I landed on Askimet. Note, I am not being sponsored by Askimet, I truly did this research on my own. I can say so far the results have been awesome. I’ve been able to turn all blog comments back on, and it’s very rare for a spam comment to sneak through. 99.9999% of the time when that happens it seems that Askimet has already killed the spam by the time I get around to viewing the WordPress spam queue.

Since turning Askimet on I haven’t had to personally deal with 462 spam comments. Yay! In the screenshot below, the 228 spam comments number represents a partial snapshot of the spam that I had to manually delete prior to Askimet.