Limit number of posts with WordPress
One of the first things I noticed when I started to setup WordPress was that there was no way to control the number of posts displayed on the index page from the admin panel. Yes, there is the “Show at most” option, but this is a site-wide variable and works to treat all of your pages the same — I didn’t want that.
So, as things sometimes go on this site, I didn’t plan to post a workaround to this (it’s kind of trivial), but I’ve had a few people ask me how to do it and so I thought I’d explain it here both for them and for future Google traffic.
Why I Wanted This
All of this stems from the fact that I don’t usually like “next 10 posts” / “previous 10 posts” links and didn’t want them on my website. Rather, I like whatever archives page the user is on (be it yearly, monthly, or daily) to display all of the posts for that particular time span. This can be achieved rather easily by setting the “Show at most” option to something very large (i.e., a number at least as large as the number of posts on your “largest” page). The problem is that this number will also be used to control the number of posts on your index page.
The Fix
To limit the number of posts on your index page while allowing all other pages to look to the “Show at most” setting, you simply need the following lines of code.
<?php static $ctr = 0;
if ($ctr == "X") { break; }
else { ?>
You’ll want to place this code directly inside the main loop you use to display the posts on your index page. The regular PHP and/or HTML that actually forms these posts should be placed inside the open “else” shown in the above code. You should then close the “else” with a curly bracket (”}”). Change the “X” in my example to the number of entries you want displayed.
Because you need to increase the “ctr” variable by one each iteration through the loop, you’ll need to put the following code right before the loop is terminated.
<?php $ctr++; } ?>
It’s that simple. After this code is up and running, your index page will display the first X entries and your archive pages will display the number of posts as defined by “Show at most.”
Mobile jellyfish
This is a screenshot from my latest phone, the i-mate SP3i. I’m putting it up here because I’ve had a few friends express some interest in using the jellyfish picture as their background after seeing it on my last couple of phones. You have to admit, it does look pretty damn good as a mobile phone wallpaper. I use the same picture for my desktop background as well; it’s probably my favorite photo from the entire Monterey, Carmel, and Big Sur set.
Feel free to download the original (2048×1536) picture and do with it what you like.
i-mate SP3i
I’ve received quite a few e-mails asking when I plan to put up a review of the i-mate SP3i. I really can’t say. I’m incredibly busy at the moment and so I’m really not sure if I’ll get around to doing a full review; if I do decide to do one it won’t be for a while. I certainly don’t mind answering questions though if there is something specific you want to know.
I will say this: if you know you want a Windows Mobile smartphone and have your eye on the SP3i, buy it. I don’t have anything negative to say about the phone itself — it’s awesome (though I do have some issues with Windows Mobile; surprising, I know).
Quickly, a few things I really like about the phone:
- Best mobile speaker I’ve ever used (very, very loud); this includes regular use, speakerphone, and gaming
- Best T9 implementation I’ve ever used
- Best Arkanoid-type game I’ve ever seen, on any platform (it ships with a package of 9 games and all of them are excellent)
- Very solid construction
- Perfect form-factor and weight
- Great battery life
- Brilliant screen (just about everyone I’ve shown the phone to has commented on it)
TextWrangler
TextWrangler is the best free GUI text editor I’ve ever used and certainly worthy of being the progeny of the almighty BBEdit. I can’t say that there’s anything I haven’t been able to accomplish with it, either through native features or some AppleScript voodoo. I use it for everything — the code that runs this site, the posts you see on this site, law school, side projects, personal notes, Mac OS X config files, etc — I currently have 17 open documents in my TextWrangler drawer. It’s great.
Maintaining URIs between Movable Type and WordPress
When I moved to WordPress I made the decision to change the layout of my archived URIs. To be honest, I was going to make this move under Movable Type as well, but just hadn’t got around to it. This modification amounts to nothing more than changing a uri_that_looks_like_this/ to a uri-that-looks-like-this (dashes and no trailing slash). The reasons for this aren’t worth going into right now, but if you’re interested, feel free to e-mail me.
If you initially followed my steps for future-proofing your site in Movable Type and are moving to WordPress and want to keep a similar archive structure, then follow the steps below. Even if you didn’t use my future-proofing method for MT, but are still thinking about moving to WordPress, you can probably figure out what changes would be needed to the following code to make it work for your particular setup (assuming the archive structure you used under both CMSs is based, at least in part, on the titles of the posts).
Step One
The first thing you are going to want to do is to create a new MT template which contains the following code (perhaps modified for your particular situation).
<MTEntries lastn="10000">
RewriteCond %{REQUEST_URI} <$MTArchiveDate
format="%Y/%m/%d"$>/<$MTEntryTitle dirify="1"$>/$
RewriteRule .* archives/<$MTArchiveDate
format="%Y/%m/%d"$>/<$MTEntryTitle dirifyplus="pld"$> [R,L]
</MTEntries>
Realize that the rewrite lines above should each be one long line (i.e., no line breaks).
The above code will traverse all of your Movable Type entries and create the appropriate conditions and rules for each of them, the idea being that each individual entry will get a separate RewriteRule that will direct it to the new [slightly altered] URI.
Step Two
Build this template.
Step Three
Copy the contents of the resultant file into your root .htaccess file or the one in the root of your archives directory — shouldn’t really matter. Either way, be sure to include these rules before the htaccess rules that WordPress creates (and needs to work), else the server will act on those earlier rules and never get to these.
That’s it — now all of your old MT archives should forward to the new URIs.
Beware
I noticed that Movable Type’s “dirify” function and the “dirifyplus” plugin remove dashes within a title and so if you used either of these to make your directory structure (which this little guide assumes), you’ll need to go through your entries, find those that have a dash in the title, and then reinsert that dash in the RewriteRule portion of that particular address (else, the link will be unreachable).
I’ve moved to WordPress
After spending more time hacking up the source than I had ever anticipated, this entire site (both public and private) has been completely moved over to WordPress (from Movable Type). Those of you out there who have made such a transition realize what a large undertaking it can be and my case was certainly no exception; starting out with WordPress and using a default template is one thing, but transparently moving over a complicated, customized, content-heavy weblog is an entirely different matter altogether.
Like everyone else it seems, I’ve been rather impressed with WordPress and can’t wait to delve deeper into it and contribute to the community that has sprung up around it. I put a lot of time and effort into writing tutorials, HOW-TOs, and general tips and tricks for Movable Type and plan do the same for WordPress as soon as I get efficient with it (on a related note, I think I’m going to compile my Movable Type ‘how-to’ entries and present them in a single post here for those who are just getting started with that system).
The Transition
The goal was to keep everything looking and working exactly the same as before, and for the most part, I accomplished that. After familiarizing myself with the basic layout and structure of the CMS, I looked at the source of various themes to further wrap my head around this monster.
After getting the initial site-wide template up and running I spent a fair amount of time hacking htaccess files. I was kicking and screaming there for a while — fixing one thing was breaking something else and on more than a few occasions I thought I had fixed everything only to find something not working quite right as I started to dig around. Sometime in the next few days I’ll put up a post outlining my mod_rewrite solution. That said, everything should be good to go now (and all old URIs should seamlessly redirect), but if you notice any problems, please let me know.
All that’s really left to do is to modularize with PHP includes; I think I had twice as many template modules in my Movable Type installation than I had actual templates (I like to simplify and condense!).
Movable Type total word count
Every so often curiosity gets the better of me and I want to find out (and publish) the total number of words I’ve put into the posts on this site (you can now see this at the top of my main archives page). Unfortunately, and quite surprisingly, each time I’ve looked for this functionality I’ve come up empty (and yes, I’m aware of MTWordStats, but it’s broken, at least for me); Movable Type still doesn’t count the words of individual entries for you, much less give you a function that returns a weblog-wide total.
I came up with a quick and very simple solution.
The first thing you’ll need to do is download and install the WordCount plugin, which returns the number of words in a given post. To get the total number of words throughout your weblog, you’ll need to run this plugin over all of your entries. To do that, insert the following code at the top of the template you’re going to use to display the total.
<MTEntries lastn="10000">
<?php $tWords = $tWords + "<$MTWordCount$>"; ?>
</MTEntries>
To display this total, place the following code in the template where you want the number shown (make sure that this code appears somewhere below the above code).
<?php echo number_format($tWords) ?>
Yep, that’s it.
We’re getting there
I love being able to take out my mobile phone, fire up a browser, log into my TiVo account, tell it to record a show for me that I’ve just been made aware of, and then receive, on my phone, a confirmation e-mail within the hour from TiVo (after it’s talked to my machine at home) to let me know that the show will or will not be recorded.
Instrasite searching with Google
I doubt many of you have noticed (especially the regular readers of this site), but I reworked the search section about a month ago so that it now uses Google for intrasite searches. I never mentioned it here because I didn’t really see the point, but I’ve had a couple people ask me how to do it and so I thought I’d explain it a bit here.
The reason I handed over searching to Google in the first place was because of the way Movable Type returns search results; not only does it refuse to remove the trailing filename but it also likes to place anchor tags at the end of it. Technically, there is nothing wrong with this as it still gets people to the page they were looking for, but it just “looks” ugly and people end up linking to me with malformed URIs. This never really bothered me until I implemented future-proofed URIs here (and wrote up a HOW-TO on how to set this up in Movable Type). My URIs are “clean” and I wanted my search results to follow suit. Yes, I could have just hacked up the MT code but this way was much quicker and also allows us to search using a syntax we’re quite familiar with.
Setting Up Your Site
This certainly isn’t rocket science and anyone with a rudimentary understanding of HTML forms and the Google syntax could figure it out, but for those among us who are a little less motivated, I’ve put my form below.
<form method="get" action="http://www.google.com/search">
<input type="text" name="q" maxlength="255" class="search"name="search">
<input type="hidden" name="sitesearch" value="http://justinblanton.com">
<input type="hidden" name="q" value="-intitle:archives">
<input type="hidden" name="q" value="-intitle:referrers">
<input type="hidden" name="q" value="-intitle:links">
<input type="submit" name="sa" VALUE="Search">
</form>
I’m going to assume that most of this is pretty self-explanatory, but for the sake of completeness, I’ll elaborate some. The “sitesearch” input element tells Google to search only within the given site. You’ll notice that I go a bit further and include a few “intitle” restrictions; if I didn’t do this, the user would get the same document multiple times (because of the index page and monthly/individual archives). I recommend playing around with the search on your site to decide what input tags you will or won’t need — this will obviously vary greatly from site to site and will be based in large part on your site’s structure.
This method isn’t exactly perfect and there will be certain circumstances where the results, without further tweaking, are completely useless. For example, if you search for “gadgets” on this site, you will see that Google returns nearly every page under my domain. This is because I have the word “gadgets” in the menu on the right. There isn’t much that can be done about this except maybe narrowing your search. Perhaps in the future Google will allow you to restrict searches to divs within a document’s markup. *shrug*
When time permits, I think I’m going to use the Google API to do intrasite searches so that I can style the results to look like the rest of my site (i.e., the user won’t realize that the search was done off-site).
On the acquisition of Bloglines by Ask Jeeves
Russ took the words right out of my mouth.
I use it constantly and incessantly and if it went away or was changed drastically, I would be very unhappy.
In other words, please don’t fuck it up.
Where to put my BlogAid money?
Please e-mail me with any suggestions you might have about where I should donate the money I generated for the BlogAid project. I have a couple of places in mind, but any feedback would be great, especially if you have first-hand knowledge of the organization and their work. Thanks.
Let this post also serve as a reminder to all of those who agreed to participate in the effort that our contribution is due.