Now I can understand if this was a WordPress.com blog and they had restricted certain filetypes (or another shared host). But this was my blog, gosh darnedit, and I was gonna upload that file if I wanted to…!

A quick search revealed just the type of WordPress hack that I needed. Read the full explanation of how to modify the allowed upload types in WordPress on Chris Meller’s blog. The gist of the solution is that WordPress uses a function, “upload_mimes” to check what file types are allowed. You can add a filter to hijack that function, add your own filetype, and pass that back to WordPress.

I followed Chris’ directions, added ‘dng’ to the array, and it worked like a charm. Awesome.

In the admin area, you can create custom thumbnails for your images. An image is supposed to pop up that you can drag a thumbnail over. But for some reason, when I opened up the window to create a thumbnail, the image didn’t appear. The image was coming up blank, like if you link to an image that isn’t there.

The actual image was there on the server, so that wasn’t a problem. I followed the trail a bit and figured out that the image for the thumbnail creation process was created by a script, nggshow.php (part of the Nextgen plugin). The script itself was working. It fetched all the information, put it in an object, and then it was supposed to spit out an image.

The problem was that the final output is supposed to be a jpeg. But, some white space was added at the top of the file, so the output was corrupted. The jpeg was there, but the browser couldn’t render it because of the added white space at the top of the file. I don’t know where exactly that was coming from, but it was added in somewhere in the Nextgen Gallery plugin files.

I tried to go through, eliminate any extra lines outside the php tags, and get rid of the white space. I eliminated one of the two newline characters that was in the output, but I couldn’t find the second. After pulling my hair for a while, I realized that I was working with an older version of Nextgen Gallery (1.5.3). I updated to the most recent (1.5.5), and it worked fine. Doh.

So… simple solution. Upgrade to the latest version of the plugin.

But, a key part of the concept was to include a Nextgen Image Gallery in that excerpt. It’s a photography website, and the point of the blog posts is to show pictures. Seems kind of silly to show a text excerpt without the image gallery, eh? I love the Nextgen gallery because it lets me easily upload pictures to the server, organize them into galleries (i.e. job for clients) and then post them on a WordPress page/post with a single piece of shortcode.

The problem is that this shortcode will, by default, execute in the post (when you call the function the_content()), but it won’t execute in the excerpt (when you call the function the_excerpt()).

I searched around and found a simple solution. Open up (or create) a “functions.php” within the root folder of your theme. Insert these two lines of code…

add_filter( 'the_excerpt', 'shortcode_unautop');
add_filter( 'the_excerpt', 'do_shortcode');

This tells WordPress to execute any shortcodes that it finds when you call the_excerpt(). Just what I was looking for…

Well, according to Blogger’s ToS, you do. But, if you’re feeling brave, it’s incredibly simple to hide it.

It’s not very easy to physically remove it, but hiding it accomplishes the same goal. Your users will never see it, and it won’t interfere with any custom layouts you’ve designed.

Editing Your Blogger HTML Template 

In order to hide the navbar, you’ll need to edit your Blogger site’s HTML template.

To do so, go to your Blogger dashboard as if you were going to write a post. Then click on the “Layout” tab and choose “Edit HTML.”

This should bring up a giant box of text that you can edit (see the screenshot to the right).

If you are using the the classic template, you will either have to “Upgrade Your Template” (using the instructions that follow) or use slightly different code at the end.

Click on the “Layout Tab.” Then, choose “Customize Design.” Click the “Upgrade Your Template” button and choose the template you want.

Now, click on Layout -> Edit HTML.

Adding the New Code

In order to make the Navbar hidden, you’ll only need to add one line of code.

The beginning of the text in the textbox (your HTML template) deals with styling information. You want to scroll to the end of that. Scroll down until you see the following line:

]]></b:skin>

Just before that line, add the following line of code:

#navbar { display: none; }

Then click the Save Template button, reload your blog, and your navbar should be gone!

If you are using the classic template, you’ll need to do things only slightly different. In your template, search for this line:

</style>

Then, add the following line of code before that line:

#navbar-iframe { display: none; }

Why the difference? Blogger uses a slightly different mechanism for the navbar in the classic template. It’s launched in an iframe, which is styled by the id #navbar-iframe. In the customized templates, the navbar is within the main page, so you can hide it directly without having to hide the iframe.

That’s It?

Umm… yeah.

I’ve seen some examples online where people included a bit more styling information (zero-ing out the margins and padding, for example). I haven’t found this to be necessary.

I used the code above and tested it (example here) in Google Chrome, Firefox, and Internet Explorer and they all seemed to work fine.

Like I mentioned before, this is technically against the Blogger T.O.S., so you’re following this advice at your own risk. I doubt Google would notice, though, and if your site is popular enough to draw Google’s attention you should probably have moved onto a self-hosted blog anyway.

So what happens when you’re web host’s database gets fried, and much to your chagrin you don’t have a backup?

Well, hopefully that will never happen. Hopefully your web host backs up its databases regularly. But that doesn’t mean you should trust them – you should do your own backing up.

Now, you could go into phpmyadmin and do this manually. You’d then have to store the backup on your hard drive, clear out the old ones, and make sure you’ve got the most recent ones. Manageable, but annoying.

One of the Most Useful WordPress Plugins… Ever.

So get a WordPress plugin to do it for you: WordPress Database Backup.

I snagged this when I set up this blog, and I must say: It is awesome.

In the latest version of WordPress, I click on Tools -> Backup in the dashboard to get to the WordPress-DB Backup settings.

From there, you can either manually backup the DB and store it on your computer, or set the plug-in up to automatically backup the database at a regular interval. I’ve got it set up to backup the database every day and e-mail me the backup file.

Every day around midnight, I get an e-mail containing a thoroughly compressed .sql file with the current backup. All of my current content (~3.6mb unzipped) is about 500kb when it’s compressed. At that rate, I can leave it in my gmail archives forever and probably never have to worry about running out of space.

With the combination of WordPress DB Backup and Gmail, I can easily store and sort my backups. I never have to worry about cleaning them up to make more space. And the chances of my web host’s database server and Gmail blowing up at the same time are kind of slim. I’d say that’s some pretty comforting security.

So what are you waiting for? If you aren’t backing up your database on a daily basis, grab this plug-in and set a schedule. If you don’t have a Gmail account, go sign up for one. It’s free, and I doubt you’ll ever run out of the 7gb+ storage space it provides.

The redirects were being done by the .htaccess file and mod_rewrites. If anyone besides the Feedburner bot came to the feed’s URL, they would get redirected to the Feedburner feed.

It seemed to work fine. I double checked each of the feeds by following the links, and I was automatically redirected to the Feedburner feed. What could be wrong?

I just checked one of the category specific feeds, and didn’t show any of the posts from the past week. Odd.

As it turns out, the Feedburner bot was also being redirected. But the bot was only being redirected for the category feeds. For some reason, the mod_rewrite was working fine for the sitewide feed – allowing the bot through, and redirecting other people to Feedburner – but it was malfunctioning on the category specific feeds.

To be honest, I have no idea why it didn’t work, so I just scrapped the idea and worked out something else. I kept the one redirect for the sitewide feed, and I hard-coded the Feedburner URLs into the template for the category specific feeds. Not the most elegant method, but it works.

Turns out it wasn’t quite as easy as I hoped. There’s a WordPress plugin available to redirect your feed to Feedburner, but this only redirects the main feed and the comments feed. No dice for categories.

I found a few people suggesting an alternative: .htaccess rewrites. I never liked working with .htaccess, mostly because I never liked working with regex. But what are ya gonna do?

An .htaccess Alternative to the Plugin

I found an example of a .htaccess solution at Persihable Press.

For a full explanation, head over to the original article. But in the meantime, here’s the .htaccess code he suggested:

# temp redirect all wordpress feeds to feedburner
 
 RewriteEngine on
 RewriteCond %{REQUEST_URI}      ^/?(feed.*|comments.*)        [NC]
 RewriteCond %{HTTP_USER_AGENT} !^.*(FeedBurner|FeedValidator) [NC]
 RewriteRule ^feed/?.*$          http://feeds.feedburner.com/perishablepress         [L,NC,R=302]
 RewriteRule ^comments/?.*$      http://feeds.feedburner.com/perishablepresscomments [L,NC,R=302]

As I understand it, this is more or less a three step process.

First, the regex catches all requests for a URI that includes feed or comments (i.e. your RSS feed). Then, it checks if the user agent is FeedBurner. The FeedBurner bot is allowed to access the original feed, but everybody else should be tossed over to the Feedburner site.

Finally, it sends the user to the appropriate Feedburner URL, based on the request URI.

Adding Category Feeds

That, of course, does the same thing as the plugin. It redirects the site feed and the comments feed, but it doesn’t help you redirect your categories.

For me, each parent category is like it’s own site, so that doesn’t help. I’d like you to be able to subscribe to the “Nerds at Work” feed about web development without being bored by all my ranting on education.

Luckily, somebody commented on the original article and left a suggestion as to how to redirect the category feeds. I used that to create my own .htaccess file, and everything seems to work hunky-dory.

You don’t need to re-write any of the conditions, because that regex will already flag the category feeds. All you need to do is add a few extra rewrite rules, based on the new URIs and provide the appropriate Feedburner URL.

In general, that rewrite rule should look like this…

RewriteRule ^category/nerds-at-work/feed/?.*$
  http://feeds.feedburner.com/thislifeofbrian-work [L,NC,R=302]

Replace ‘nerds-at-work’ with your own category slug, and replace the full URL with the URL to your Feedburner feed.

I had some trouble with this at first, but I think the problem was due to positioning. In the end, I added all of the category specific re-write rules after the general rewrite rule. When I placed them first, it didn’t work. Might just be that I’m a regex/htaccess newb, though.

Here’s the full .htaccess file that I’m using, including what WordPress generated for the pretty-urls.

# Redirect Wordpress Feeds to Feedburner
 
RewriteEngine on
RewriteCond %{REQUEST_URI} ^/?(feed.*) [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(FeedBurner|FeedValidator) [NC]
RewriteRule ^feed/?.*$ http://feeds.feedburner.com/thislifeofbrian-sitewide [L,NC,R=302]
RewriteRule ^category/nerds-at-work/feed/?.*$ http://feeds.feedburner.com/thislifeofbrian-work [L,NC,R=302]
RewriteRule ^category/nerds-at-play/feed/?.*$ http://feeds.feedburner.com/thislifeofbrian-play [L,NC,R=302]
RewriteRule ^category/teach-them-well/feed/?.*$ http://feeds.feedburner.com/thislifeofbrian-teach [L,NC,R=302]
RewriteRule ^category/life-of-brian/feed/?.*$ http://feeds.feedburner.com/thislifeofbrian [L,NC,R=302]
 
# BEGIN WordPress
 
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
 
# END WordPress

Good luck, and hopefully you’re more experienced with htaccess/regex than I am.

Initially, I agreed with the old print-proponents. Print publishing calls for two spaces after each period. When I type up documents to be printed, I follow this standard. It’s a habit, and I don’t know if I can break it.  I already started typing this post in that way…

Arguments against the double-space suggest that it’s pointless. Browsers eliminate a second space and only display one space, so why use two?

Not a very strong argument, in my opinion. But now, I think I’ve come up with a better one.

I’m not sure of the cause of the problem – browser or blogging platform or maybe the theme. However, I’ve had display issues with posts on this site when I use double spaces after period.

I use Google Chrome as my main browser, and WordPress is the blogging platform. Due to one or the other, the second space is displayed as a non-breaking-space if it is the first character in a line. This causes all kinds of funky, annoying display issues when I use two spaces after each period.

I guess it’s time to cut out that extra space.

It’s also time to edit this post and remove them… because I used double-spaces out of habit. Doh.

Rather than let these articles languish forever in obscurity, it seems best to add them to the archives of this site.  This has the added benefit of driving some search engine traffic to the site, and helping it get indexed by the search engines much faster.

Using a 301 Redirect, I can automatically direct people to the new location of an article and alert search engines that the article has moved.

You can use some fancy .htaccess editing to redirect a whole site from one domain to another, but this depends on the url structure of the site remaining the same.  I can’t guarantee that, and in fact I’m deliberately changing the url structure to better organize the posts into categories and sub-categories.  So I need to be able to re-direct the articles on a page-by-page basis.

Post-by-Post 301 Redirect in WordPress

For WordPress, I found a great plug-in to do this – Angsuman’s Permanent Redirect.

Like most WordPress plug-ins, installation is simple.  Download and extract.

Usage is equally simple.  For each post that you want to redirect, create a custom field called “redirect.”  Enter the new url of the post as the value of the custom field.

That’s it.  I’ve already gone through one site, ported over 100+ posts, and set each one to re-direct to its new address at Life of Brian.  It took me a few hours, but I think it was time well spent.  I’ve already seen a decent amount of search traffic coming to that section of the site, despite the fact that it’s only been live for a few days.

Post-by-Post Redirects in CMS Made Simple

Although WordPress is now my CMS of choice, I designed an older site with CMS Made Simple.  I did a hefty amount of customization to the site, and CMSMS gave me a lot of freedom in writing custom extensions to add to the site’s functionality.

For now, I want to rescue all of the posts/articles on the site and store them in the new education portion of Life of Brian.  I’m not sure if there was a plug-in available to do this, but I was easily able to enable post-by-post redirects for any content page.

Here’s how…

Step One: Create a Blank Template

We’ll be using a the php header() function to redirect the page, and this should appear before any other output is sent to the user’s browser.

In my old version of CMSMS, I went to Layout -> Templates in the admin section, and clicked on “Add New Template.”  I called it redirect.  I then deleted everything in the main content area, and entered a single line…

{content}

Step Two: Create a User-Defined Tag

A user-defined tag is a snippet of php code that you can insert into the content section of any content page in CMSMS.

Go to Extensions -> User Defined Tags in the Admin area.  Then click on “Add User Defined Tag.”  I called my tag “redirect” and entered the following php snippet:

header("HTTP/1.1 301 Moved Permanently");
header("Location: " . $params['url']);

Use the Tag to Redirect a Page

Now, we can edit any content page on the site and add a custom redirect.

Navigate through the admin area to the page you want to redirect. Change its template to the “redirect” template we created.

Then, add the following snippet as the first line in the content.

{redirect url="http://new-domain.com/newurl/to-redirect"}

Just add the URL you want to redirect to inside the quotations, and you’re good to go. This calls the user defined tag we created and passes it the URL as a parameter. The tag then outputs the HTTP redirect header, and the user’s browser will seamlessly travel to the new site.

To use Google Analytics, you need to place some javascript on your website. A commonly asked question in forums is, “How do I add Google Analytics to my WordPress template?”

Where the Analytics Code Goes

When you sign up for Google Analytics, Google provides you with a short piece of javascript to place on your site. The code should look like this.

><script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-2894597-3");
pageTracker._initData();
pageTracker._trackPageview();
</script>

According to Google’s instructions, this needs to be placed at the very end of your site – just before the closing body tag. To do this, we need to find the closing body tag on the WordPress template.

Look In Footer.php

As we previously discovered, a WordPress template is made up of a series of files. Three basic files – header.php, sidebar.php, and footer.php – help build the components of the page.

If your WordPress template follows normal conventions, the closing body tag should be in the footer.php file.

Go to your themes directory of the WordPress installation, navigate to your current theme, and open footer.php. You should see something like this at the end.

<?php wp_footer(); ?>
</body>
</html>

Add a blank line before the closing body tag. Simply copy and paste the javascript code that Google provides on that blank line, save the file, and you’re good to go.