When developing the colorful Quintessential Theme (opens in new tab), I initially planned on displaying five random posts from each of my most popular tags and categories in the super-slick sliding-panel sidebar. Because I am running an older version of WordPress, however, this task proved to be quite the educational experience.

In newer versions (from 2.5 I think) of WordPress, the query_posts() function enables users to display posts in random order using the orderby=rand parameter. This would have made my life easy, as I could have included the following code for each of my random post lists:

This would have been great, but the random-post ordering doesn’t work for my particular version of WordPress. As it turns out, for older versions of WordPress that are missing the incredibly useful orderby=rand parameter for the query_posts() function, there is an unofficial plugin available in the WordPress Help Forums that imparts the orderby=rand functionality to the query_posts() function, thereby enabling users of pre-2.5 versions of WordPress to implement their own random post loops.

For those of you who would like to setup some random post loops on your own site, here’s how to do it in two easy steps. (Remember, this is only necessary if the above method does not work for your particular version of WordPress.)

Numero Uno: Upload and activate the plugin

Copy & paste the following code into a file named “random-posts.php” (or whatever), upload it to your /wp-plugins/ directory, and activate it via the Plugins panel in the WordPress Admin:

Numero Dos: Include and customize the template code

Once the plugin is in place, create multiple tag-specific and category-specific random-post lists by placing the following code after the main loop in your theme template file (e.g., the sidebar.php file):

Before uploading, make sure you customize this code according to your needs. Old heads feel free to knock the boots, while newer chaps may benefit from the following information:

As mentioned in the code comments, replace the “tag=whatever” parameter with the name of the tag for which you would like to display random posts.

To display random posts from a specific category instead of a specific tag, simply replace the tag=whatever parameter with category_name=whatever and change the name to your chosen category.

Adjust the other query_posts parameters as needed to accomplish your post-display goals. For example, you may also want to display the post excerpt for each post item by including the the_excerpt() tag.

Note that this code is essentially the same as that given for newer versions of WordPress; the only difference being that you use the orderby=rand parameter for newer versions of WordPress (where the plugin is not required), and random=true for older versions (where the plugin is required).

Placing additional query_posts() loops after the main loop may result in unintended paging and/or plugin issues, so make sure to place it after the main loop.

To create multiple lists of random posts, simply create multiple instance of this loop and change the category or tag parameter names to suit your needs.

Time to chill

That concludes this brief retro-tutorial. Although it may not be of much use to those treading the perpetual “upgrade” treadmill, it will hopefully provide some relief for randomizing posts in older WordPress versions.

Check it out

Comments

Very handy tutorial, Jeff! I often forget the query_posts() function such that I use conditional tags in the post loop itself – which isn’t a very good thing, I know :) Now I can specify to display posts of certain tags or from certain categories without needing to use conditional tags. Oh, and I didn’t know that the older versions of WP lacks an orderby variable, it’s nice that you’ve given some thought to those who are still using the older version (although I’d personally recommend an upgrade, if they’ve hacked the WP inside out then, well, too bad :/ ).

You might also want to highlight that there should not be two loops on the same page – i.e. using the code in single.php and page.php, as far as I know (do correct me if I’m wrong, because I’m not that well-versed), will lead to conflict issues. This method is viable when it is used to modify the main page loop only. For other pages, it’s better to create a separate WP_query object and use it instead.

Out of necessity, I have “hacked the WP inside out,” so I continue to dabble in these archaic methods. I have been using WordPress since version 1.5, and way back then, WordPress was not as “evolved” as it is today. Many functions simply didn’t exist, there was significantly less documentation, and us early adopters frequently had to hack our way around in order to make things work as intended.

Along the way here at Perishable Press, I have implemented almost 20 working themes, each with their own special functionality, plugins, and so forth. To get everything working, I have had to hack plugins, themes, and even the core itself. Believe it or not, many of the “hacks” that have been implemented were actually needed to work around changes made to the WordPress core.

For awhile there I did try to stay current, but many updates would break a million things on my site, so I eventually threw in the towel and decided to stick with my current version. This is not an excuse as to why I am using an older version, but rather a look at “why” staying current is sometimes more difficult than it sounds.

For the record, I am working diligently (albeit slowly) behind the scenes on a complete overhaul that will eliminate all hacks, streamline functionality, and enable me to stay current with all the latest and greatest versions of WordPress. Run the treadmill, if you will.

Moving on to your concerns about proper usage and multiple instances of query_posts(), the Codex makes some good points, but I have found the information provided on this topic to be somewhat oversimplified and incomplete. I don’t have the time to explain fully in this reply, but suffice it to say that query_posts() is generally safe to use for multiple loops when placed after the primary/main loop. I repeated and emphasized this information in the article, but by all means, you should probably do whatever the Codex tells you unless you really know what you are doing.

Hopefully, I am not sounding too snooty here, although I certainly have a tendency to come across that way. ;) Just trying to explain! :)

Thanks for the reply, Jeff! I guess most people proficient with PHP, database and WordPress would have optimized their WP installation for better performance and security. I hope you didn’t misinterpret my first comment as “people who hack their WP inside out are at a disadvantage for not upgrading to the latest version of WP”.

Yea, upgrading WP will definitely break a lot of stuff! I believe that you don’t need to upgrade to newer versions since your modified version is probably a lot faster, usable and efficient.

I see. I’ve tested the query_loop() function again and you’re right. I encountered the conflict problem previously because I’ve placed the secondary loop ahead of the main/primary loop. Thanks for the clarification, Jeff :)

Jeff, I stumbled upon your site from the WordPress Codex, trying to figure out a way to display multiple posts from different tags/categories. You have, in roughly 4 minutes, done what I’ve been trying to do for the last 3 hours. I came up with the above idea while at work today and was all like “aw this is gonna be SWEET if it works” but couldn’t put that idea into fruition. Lo and behold, you have led me not into temptation but delivered me from the evils of code-writers-block.

I’m so glad to have found this post of yours today…I’ve been googling for the past days on how to randomized my photoblog homepage site with no luck…I still can’t believe that I’ve solved my problem by just adding ‘&amp;offset=0&amp;orderby=rand’ with the query posts() function =D

@ddeconin: That’s interesting – I always understood WordPress to treat all associated (included) files to be part of that particular page view, such that conditionals within the sidebar, footer, and everything else would return “true” for the same thing, whether single-view or otherwise. In other words, I wonder why the footer is returning true for category when called from within a single-view template. Seems weird to me, like maybe there is something that is interfering with normal functionality.

Projects

About the site

Perishable Press is the work of Jeff Starr, professional developer, designer, author, and publisher with over 10 years of experience.
Check out some of Jeff's books and projects, follow on Twitter, or learn more »

Fun fact: Perishable Press has been online since 2005, and features over 800 articles and more than 11,000 comments. More stats »