SilverPen Goes Mobile With WPTouch

As you may or may not know, I’ve been going ’round about mobile browsing on the web for some time. I was almost convinced once that I had found a mobile solution for my WordPress sites, but it just didn’t work that well. The main problem was caching: WordPress, for those unfamiliar with it, can become bloated pretty easily, which makes loading a site very slow. Using a plugin to cache your pages helps compress them to speed up load time. Unfortunately, sometimes the regular version would be cached and served up to mobile devices, and sometimes the mobile version would be displayed on the desktop. Admittedly, this was more an issue with the caching plugin I use, but if it’s got to be one or the other, caching is necessary and a mobile view is not.

And then I stumbled upon WPTouch. This WordPress plugin came completely out of left field for me. I had been looking, trying out, beta testing, and giving feedback on different mobile solutions for a while before I gave up, but I had never even heard about WPTouch. All of a sudden it was there, I installed it, and it worked. No real configuration needed, no tweaking, no fiddling with cached pages or having the mobile view show up in desktop browsers. Everything Just Worked.

So I’ve been using it for several months now. It’s on both my site and on our work site, and I am confident enough in it to recommend it to you. If you self-host WordPress, there is absolutely no reason your site shouldn’t have a mobile view, and WPTouch provides that free of charge and very simply. Now that I’m finally comfortable with it and settled, I’ll be making a donation to the fine folks at Brave New Code for their great work. Give WPTouch a try, and if it works for you, I encourage you to do the same.

A Bit More About WPTouch

SilverPen Publishing on an iPhone in Mobile Safari

Mobile plugins for WordPress have one primary function: serve up a different theme to cell phones than to regular web browsers. This means that if you visit my site in Firefox on your computer, you see one thing, but if you visit on your iPhone or other smart phone, you’ll see the mobile version. The mobile version is much simpler than the regular one, which makes it much smaller. This means it loads faster, which is important on mobile connections like Edge. Even on 3G, you’ll have significantly faster load times with a mobile version of a site. In addition, text and such is reformatted to fit better on a smaller screen.

The previous plugin I tried, WordPress Mobile Edition, is built on the Carrington framework. Though very shiny, I found it to be too much. It was bigger than necessary, which slowed load times. In addition, it slowed down my site overall. I’m not a programmer and can’t claim to know how, but WordPress Mobile Edition contributed .5-.7 seconds to my site’s load time by itself. Half a second might not seem like much, but it can make a lot of difference in perception of a site’s functionality and reliability.

WPTouch doesn’t negatively impact my site overall, and it’s very quick to load on mobile browsers. It also has a very polished menu system that can be customized through the WordPress Admin Panel. It should be said that the developers are very responsive as well–there was a problem with the menu a month or two ago where it wasn’t loading right, and they had it fixed pretty quickly even though this problem wasn’t happening on all sites. They seem very committed to this product and doing a good job, hence the donation.

Check it out. It’s free and available at BraveNewCode.com.

Upgrade WordPress–Don’t let strangers root through your trash

Version 2.9 of WordPress introduced the Trash, a wonderful little feature that most of us became acquainted with when Windows 95 launched. When you delete a post, page, or comment, it goes to the trash where you can review or restore it if you so desire. Apparently there was a vulnerability in it, though, where logged in users could see get in and see anything that was in the trash, even if they wouldn’t have been able to see it previously.

Version 2.9.2 was just released to fix this exploit, so be sure to grab it and update.

How to Use Page Templates in WordPress

Before I had a custom theme designed by Ryan Burrell, I would find free themes and do my best to modify them into a simulacrum of how I wanted my site to appear. Because I’m not a coder by any stretch of the imagination, this was often a painful process, and the documentation provided by WordPress was often confusing to me. It would tell me the code I needed, but not how to actually do anything with it.

When I began messing with page templates in WordPress, it took a while before I figured out the very simple tricks of how to actually implement them. Templates allow you to impress a great deal of variety on your site, with different pages looking different ways, and I’ll share a few basics with you in regards to setting them up.

Note: You can only use templates on Pages, not on Posts. For the sake of this exercise, we’re going to take a look at an Archive page and how you can modify its appearance and contents.

Name and create your template

There is one very simple component to creating a page template, and that is the meta data located at the top of your new template page. To start off, go into your theme’s files ((For those using a hosted WordPress solution that employs CPanel, that’s probably something like public_html/wp-content/themes/theme_name)) and create a new file titled archives.php.

Note: You have to be careful when naming template files to avoid overwriting existing files in the template. In this case, I already have an archive.php (used to display a list of posts within an archive, such as the page for September, 2009), so I had to name my template something else. ((In addition, some names are reserved by WordPress (such as index or sidebar) so avoid using these names. For a more detailed (and slightly bewildering) explanation, check out Template Hierarchy and Using Themes in the WordPress Codex.))

After you have created this file, open it for editing and place the following at the beginning of it:

<?php
/**
 * @package WordPress
 * @subpackage Default_Theme
 */
/*
Template Name: Archives
*/

The key, which I was missing for-freaking-ever, was that “Template Name: <name>” part. It wasn’t mentioned anywhere in the codex (at the time) so even though I had my template all created, I wasn’t able to select it for a page.

With that done, you can build your template. See the attached archives.rtf file for a full example of what my archives template looks like.

Select your template

Once your template file is built and ready, you’ll be able to see it when you create a new page in WordPress. Just select it from the drop down menu on the right!

Select the template using the drop down menu on your new page.
Select the template using the drop down menu on your new page.

Using Different Sidebars

I was asked recently how you would use different sidebars on different pages depending on the template, ((Rather than using a different sidebar for all pages, as my other guide details)) and the process should be pretty straight-forward. ((Though I haven’t tested this myself and, again, not being a coder I’m not confident in my logic here)) Just omit the call for the standard sidebar (using the WordPress get_sidebar tag) and call a different one using the following code:

You would, of course, have to have a sidebar2.php file in your template directory for this to work, but you get the idea.

Connecting Facebook and SilverPen Publishing

As a blog author, I have a variety of goals when writing and posting an entry. I want to help or inform people, and I also just want to write for the sake of writing. But there is most assuredly a part of me that wants feedback, community, and discussion, primarily in the form of comments on individual entries.

This has been happening regularly on Facebook, which imports all of my blog entries as notes, and that’s great. Unfortunately, those comments can’t be moved or copied from Facebook to my primary site, so the conversation happens there among a small group of my Facebook Friends while general visitors to my site never see them. I’ve only had a few hundred comments on SilverPen articles here locally, but that number would easily double or triple if comments left on Facebook were added in.

Because of all this, I have been seeking a solution to the Facebook-Comment issue. My initial desire was some sort of plugin or API hook to simply copy comments left on Facebook notes to their corresponding entries on SilverPen, but this has been tried and failed. Facebook’s API changes too often, and though it has opened up some in the last year or so, it is still pretty walled off. Comments simply can’t be taken out reliably.

Therefore, my desire became channeling people from Facebook to my site, so they comment here instead of there. To do that, I needed to integrate my site with Facebook.

To this end I have employed the built-in Facebook Notes Import feature in Facebook and the WPFacebook-Connect plugin. My original intent had been to use the WordBook plugin and stop using Facebook to grab my RSS feed, but upon attempting to publish this post it failed in a horrible, fiery way. Shocked and dismayed, I looked at some other options and then hit upon an idea that seemed both elegant and simple. I will have Facebook keep importing my notes through RSS, turn off commenting on Facebook notes, and modify my Feedburner Feed to add a comment button to the end of each post. Nearly the same end-result with one less plugin and a lot less fidgeting and work. I’m a bit disappointed I hadn’t thought of this to begin with, to be honest.

The next step was far more complicated and cumbersome, but I thought it important that Facebook users who are being forced to go to another site to comment be able to do so pretty effortlessly. WPFacebook-Connect allows single sign-on between my WordPress blog and Facebook, so Facebook users can connect to their Facebook account with a single click and then comment.

Of course, a fair few modifications had to be made to SilverPen for this all to work.

Login Page

Login Box

When you first install WPFacebook-Connect, your login page may look pretty janky. I have a custom login page (designed by the same genius who did my theme, Ryan Burrell) and it broke badly when the “Connect” button slapped itself on there, so I had to style it a bit.

Unfortunately, this button is the same one used in the blog comment area, so modifications here affect those pages as well. In addition, it’s not immediately obvious how to style this. The div tag used for this button isn’t listed anywhere other than the common.php file and there is no corresponding CSS to modify–by default, it is unstyled. Add something like the following to the fbconnect.css file in the /plugins/wp-facebookconnect folder.

.dark {
 position: relative;
 float: right;
 margin: 0 19px 0 10px;
}

The div in question is simply .dark (for reasons I don’t quite understand, though I appreciate the terror some might experience when connecting to Facebook), and the above code floats it to the right so it doesn’t break anything and then lines it up with my login boxes.

Comment Area

Connect Box

Because the stupid button is styled off .dark and is used on both the login page and for the comment form, you can’t style them differently. I went round and round about this, trying to figure out how to do it, and came to the conclusion that the button would have to be duplicated in the code and one set up with a different style. This seemed like it might break some functionality and I wasn’t confident enough to give it a go, so I decided to work around it.

The above code meant my button on the comment page was off-set to the right, rather than being properly centered inside the border I created for it with:

.fbc_connect_button_area {
 float: right;
 border:2px solid #D5D5D5;
 color:#417378;
 width: 160px;
 text-align: center;
}

Note that width element, though. I decided if I couldn’t beat it, I’d work around it, so I just centered the text and tweaked the box size until the button looked centered. /smug

The float: right up there is to move the whole thing over to the right and not break anything. If you’re curious, I placed the FBConnect code (per step 2 of the instructions for WPFacebook-Connect) right after the else statement in my comment.php, a la:

<li><strong>Logged in as <a href="<?php echo get_option('siteurl'); ?>/wp-admin/profile.php">
<?php echo $user_identity; ?></a>. <a href="<?php echo wp_logout_url(get_permalink()); ?>"
title="Log out of this account"> Log out &raquo;</a></strong></li>
<?php else : ?>
<?php do_action('fbc_display_login_button') ?>
<li>
<label for="author">Name <?php if ($req) echo "<span>(required)</span>"; ?></label>

Profile Header

Facebook Profile Box

When someone is connected through Facebook, it adds a little box to the top right of your WordPress blog with their name, picture, and an option to log out. Of course, you can move this anywhere you like, but I chose to leave it up there. In addition, per Ryan’s recommendation, I styled it with Facebook’s colours so it would actually make sense (instead of looking ugly and out of place–by default it has a white background, the font is browser default, and the font colour is dark blue).

.fbc_profile_header {
 text-align: right;
 padding-top: 10px;
 padding: 5px;
 border:2px solid #8B9DC3;
 background: #3B5998;
 color: #fff;
 width:160px
 font-size: 0.5em;
}

What all this unfortunately means is every time the plugin is upgraded I’ll have to go back and make these changes again. Thank goodness I have it all documented in a handy blog post ^_^

Conclusion

Though the process was a bit tedious (due mostly to my own ignorance), I learned some new things about both PHP and CSS by implementing this, and I’m excited to see it work decently because I would like to use this same setup for the new Help Desk website I’ve been working on. We’d like people to be able to comment and interact with us using the accounts they already have, so knowing how to connect Facebook and WordPress is going to be a big help.

My next curiousity is to see how people interact with the new comment-redirection from Facebook notes and the ability to connect SilverPen Publishing and Facebook. Will you comment and give it a try?

Speed up WordPress by Disabling Plugins

I’ve known for a long time that WordPress plugins extend load times of both the front-end site and the administrative interface on the back-end. Each one has numerous sets of PHP calls and, since each page is loaded dynamically, every plugin has to be called and checked to see if it is included or not. WordPress leaves nothing out, so the more plugins you have, the slower it becomes as it has to check more and more.

What’s worse, if you have inefficient plugins, they can slow your site down to a crawl. The fault isn’t WordPress’s, your web host, or an overly-large image, but rather is due to poor javascript execution, logic loops, redundant code, or other culprits of Programming Gone Wild™. In these cases, the only options are to rewrite the plugin to make it more efficient or ditch it altogether.

Tired of my administrative interface taking forever to load and switch pages, I decided to test each plugin I use individually to discover the culprit and expunge it from my WordPress installation. Some of the instigators were surprising, but they’re all gone now.

Woopra

I love this little tracking utility because it allows me to see people live when they hit my site. I can see when they came in, what they’re looking at, where they are in the world, and watch the ping away as they leave. It’s just very cool, but it’s also very bloated. It violates the common wisdom of tracking technologies hosted off-server, which is, “Since all the work is being done by our servers, rather than yours, it should have next to no impact on your site performance.” Google Analytics and WordPress Stats also operate in this fashion, where my web server isn’t doing the tracking or analysis so my performance shouldn’t take a hit.

Unfortunately, Woopra (or at least the Woopra plugin for WordPress) often hangs with javascript errors, leading to very long load times on all pages, be they front- or back-end. I had to disable Woopra on our wiki at work because of how much it was slowing things down (which was not using the plugin, by the way, just the stock code), but I hung onto it for my personal site because I like the utility so much. Unfortunately, I just can’t put up with it any more.

WordPress Mobile Edition

I’ve gone back and forth on mobile browsing so many times it’s like a worn out joke that just won’t go away. While I like the idea of providing improved functionality for mobile users, this plugin added at least half a second to all page load times, and often the lag was more than that. Half a second doesn’t sound like much until you’re waiting over and over again for what we have come to expect as instant. That functionality simply isn’t worth the lag to me.

WP-DBManager

This plugin allows you to manage your database through the WordPress administrative interface, and in the meantime automates some nice routine maintenance matters. However, it also slowed down my site, and since I don’t actively use it often, I went ahead and disabled WP-DBManager. I can still re-enable it if I want to do a quick backup or optimization, but most of the time it will sit dormant now.

WP Greet Box

This plugin pops up a box at the top of each post when someone comes from Google, Facebook, et. al. saying, “Welcome! You should consider subscribing!” Though generally annoying, I felt that WP Greet Box did this in a more polished, unobtrusive manner, so I’ve been using it for a while. Unfortunately, it was right behind Woopra in causing my site to slow down, so it had to go.

Total Gains

Though each of these only accounted for 0.4-1 second each of lag, between them they were doubling the load time of everything on my site, from 1-3 seconds to 4-7 seconds (approximately). In addition, now that I don’t have to worry about a mobile edition of my site, I can turn WP Super Cache up to full blast and cache/compress all my pages, decreasing load times further.

Though I’m sorry to see some of these plugins go (I’ve been using Woopra for well over a year now), it’s hard to justify negatively impacting load time across the entire site for both myself and visitors for a few minor conveniences. We must always balance functionality against speed (and security, and a slew of other things for that matter), and in this case speed won out.

For the other 26 plugins I will continue to actively use, they do slow my site down some, but all of them together only impact site times by 1-2 seconds. In those cases, the loss of speed is well worth the gain in functionality.

Which plugins do you keep even though they slow things down a bit? And which is more important to you: Speed, Functionality, or Security?

Will 404 links hurt my SEO? Only if I’m bleeding internally.

I’ve spent a lot of quality time with the Google Webmaster Tools (GWT) this week, and it has been an altogether frustrating and enlightening experience. The bottom line is that it is showing my site as having a lot of errors of the 404 – Not Found variety, and this caused a bit of concern because 250+ of those has got to be hurting my search engine ranking.

It is additionally frustrating because I’ve gone to great lengths to prevent this very sort of thing from happening. I use Robots Meta to prevent certain pages from being indexed by search engines, All In One SEO to create meta data, and Redirection to make sure modification or deletion of posts doesn’t cause any disruption. And yet, there they are, staring me in the face. A bunch of pages that can’t be found and are returning errors. First, I’m going to talk about where these errors came from–because not all errors are equal–and whether they actually need to be fixed or not. Second, I’ll let you in on the secret to 404s and SEO.

What causes the errors?

Deleted Posts/Pages

GWT admits that not all errors are really a problem with the text:

Note: Not all errors may be actual problems. For example, you may have chosen to deliberately block crawlers from some pages. If that’s the case, there’s no need to fix the error.

If you have deleted a post or page, updated your sitemap, and you consider the case closed, you probably don’t need to worry about it. Eventually Google will stop trying to reach the link and the error will disappear all on its own. The problem is if you have other pages on your site that link to those you have deleted. GWT will tell you what those pages are, and you should edit them to remove the offending links.

This is probably the most benign of the errors because you can see it coming. Others are more mysterious.

Related Posts Plugin

Similar to the last, Related Posts plugins (I use YARPP and rather like it) don’t generally set all of their links nofollow, so they generate a ton of internal links on your site. These links aren’t generally set to nofollow because 1) they’re internal and 2) if you delete a post, Related Posts will update automatically and won’t link to the deleted post anymore. Unfortunately, Google has indexed that Page A links to Page B, so when Page B gets deleted, Google decides there’s an error. This, too, will pass in time as Google catches up, but it’s something of which you should be aware.

Back-end or Codeish Errors

Some errors are beyond comprehension.
Some errors are beyond comprehension.

I have no idea what causes these or where they come from, but GWT claims that a lot of my pages are linking to things that simply don’t exist. Namely, some pages are supposedly linking to */function.include, but near as I can tell, there are no links on the originating page that point at */function.include. This would point to there being a problem with the theme I’m using–maybe it has some code pointing to the wrong place and that’s throwing errors–but if that were the case, the errors should be happening from every single page, not just a few.

I went through and manually removed these links from Google’s index, but I’m skeptical of that solution. I’d rather know what is causing it and get it fixed, but this issue is so perplexing that I don’t know how. The good news is that actual users of the site aren’t attempting to follow these links because they don’t really exist on the page, so while the crawler may have trouble, the readers won’t.

Subdirectories

This one is more because I’m spastic than anything else. For those of you who have followed this site for a while, you might recall that it has undergone significant changes in the last four years. I’ve gone from WordPress to Mambo!+WordPress to Joomla!+WordPress and then back to WordPress exclusively. I have created a dozen different sub-sites, spin-off blogs, forums, wikis, etc., and consequently deleted those blogs and come back to just having the one centralized site.

As such, I should have gone back and edited my robots.txt to exclude… well, pretty much everything. I’ve done that now, in addition to removing those links from Google’s index, so hopefully that will take care of it.

Combining WordPress blogs

When I closed the blogs I mentioned above, I usually imported their posts into my primary site. This causes so many headaches if you’re not careful, so be prepared to sort out the kinks. GWT’s ability to tell you where the errors are happening is great for going back end editing posts to remove or update links, but it’s definitely a manual process. There is simply no way around fixing this stuff: you’re going to have to set aside a block of time, sit down, and get it right.

Pagination

This one originally perplexed me, as I had pages and pages of errors due to Pagination. This is where you’re browsing through the site and you’re on */page/108, and you can go to either */page/107 or */page/109. When I was typing this, it finally hit me what caused this: going from a single blog post on each page to 5 or 10. I suddenly have less pages, but Google hasn’t caught up yet and is still trying to hit those old links. It’ll learn eventually.

So, do 404s hurt SEO?

That depends, as I alluded to above, on whether they are internal or external links that are Not Found. Search engines won’t penalize you if other sites link incorrectly to your content and those links can’t be followed. If they did penalize you for that, then spammers or trolls could create sites with massive amounts of broken links to any site they wanted and drop its pagerank immediately. This obviously wouldn’t be fair, and thankfully search engines don’t work that way. Regardless, it is best to have a custom 404 page to deal with external links that 404. The key is making sure that actual people (rather than bots or crawlers) find your site helpful and get to the information they need/want.

Internal 404s will most certainly cause harm, and that’s where GWT can be of great benefit. By displaying not just the pages that can’t be found but also the pages that link to the 404ed, it helps you find the pages and fix them. As far as search engines are concerned, if your site can’t maintain internal link integrity, it isn’t trustworthy or helpful, so why would they send people your way? If Google started sending people to a bunch of broken sites that didn’t work well, people would stop trusting Google to provide good search results and they’d use a different search provider. That’s why the search engine checks to make sure sites are holding up and working well, and if the site isn’t, it’s pagerank will drop.

Maintaining internal link integrity is essential, not just for SEO, but also for keeping you readers happy. If someone clicks on a link on your site that goes to your site, they expect that link to work. When it doesn’t, no custom 404 page is going to make them happy. They might accept one error, but beyond that they’re more likely to just surf away.

In Conclusion

While it would be ideal to never generate errors, chances are you’ll have at least a few if you’ve been around for a while and actually do something with your website. After 4+ years of active development and changes and well over 300 blog posts in just the last year and a half, these things happen, so I’m going to try to not let them get me down. Use the Google Webmaster Tools to your benefit and get your errors sorted. The work will be worth it in the end, and both the crawlers and your users will be happier when they are able to breeze through without hitting brick walls.

And once you get them taken care of, make sure to check back with GWT regularly to make sure the problem never gets out of hand. Once I get this all fixed, I’ll be logging into GWT at least once a week to make sure nothing new has cropped up. I am confident that my pagerank will benefit from the dilligence, and it’ll make my readers happier to have a site that functions entirely as it should. For that happiness, it is well worth the extra work.