
WordPress: Related Post Tweaking
If you’re using WordPress, one of your required plugins should be the Related Post plugin. That said, I noticed that the volume of keywords that were being posted with my Daily Reads were really skewing the Related Post results.
As well, I was really surprised that the Related Posts plugin only provided a list of related posts before the post that you’re reading! What if you changed your mind (as I often do!)… shouldn’t you also provide posts that were released after the original but still related?
As a result, I made some minor tweaks to the plugin. First, in order to reference posts both before and after the current post, I modified line 91 from:
. "AND post_date >= '$now' " to (UPDATED: 11/15/2011): . "AND post_date != '$now' " . "AND post_date <= CURDATE()"
Second, the Daily Reads on my blog are posted automatically by Del.icio.us under a specific Author (so that I'd never change the password and break the automated posting). To do this, I just added another query parameter to omit that author from the posts that were searched by inserting the following line after the previous:
. "AND post_author != 4 "
I found the author number simply by looking it up in my Users. I'd rather not make things complicated by joining to another table - it could reduce the speed at which these results are displayed and slow down the load time. That will lead to folks getting frustrated and leaving.
The Benefits of Displaying Related Posts
Related Posts is a fantastic tool for any blog. Related posts strengthen Search Engine Results by magnifying the keywords through links, an important element of Search Engine algorithms.
Related posts are not just a SEM tool, though. Related posts are a retention tool that will keep users in your site. They may not find what they were looking for where they landed - but if you provide them with additional references, they may stick around!
Cool trick. I hadn’t realized Related Posts only picks previous blog entries… I’ll have to go edit the plug-in. Thanks for the heads up and instructions 🙂
…and a happy new year!
Good hack – although personally I use Simple Tags for related posts based on tags, but I totally agree that related posts are a must.
wow.. this is a neat trick. Even though I do not have wasabi related posts plug-in, i have Simple Tags plug-in for related posts and I am guessing it must be using the same postdate < condition. Thanks for the tip, let me check my plug-in code and see if I can tweak it to give better results.
Chandoo, Simple Tags doesn’t use a postdate condition – I believe it creates the related posts live, with each page view (unless you have the cache turned on). That’s not the most efficient thing for the server, but it does mean that it will get the best matches, whether they were posted before or after the post being viewed.
Doug – sorry for going off topic a little…
No worries, Stephen! You guys have my curiosity! Now I have to go check out Simple Tags!
Great post! But I do want to pick a few nits.
Your justification for “(not) joining to another table” because:
is offbase and an example of premature optimization which inhibits maintainability, and it’s a shame to see people with a sizable audience recommend such things because it spreads misinformation.
The SQL join you speak of, assuming your have reasonable indexes in place will increase your response time by at most microseconds. You’d have to have tons and tons of traffic before anyone would notice even a half-second difference. Now yes, if you force yourself you can write so really braindead SQL code that will perform terribly, but an additional join on keyed data is not an example of that.
Also, rather than advocate hacking someone’s published plugin, I’d really like to see you advocate enhancing it and then working to get your enhancement included in the actual plugin itself. As is, you might get some amateur coders to apply your changes and then later upgrade to the new version of the plugin and they loose the changes but can’t figure out what went wrong. Your change is benign, just a loss of functionality, but some hacks can cause a site to break if a future revision of the core plugin is used over top of the hacked one.
JMTCW. Keep up the good work otherwise. 🙂
Hi Mike!
Thanks for responding – I’m not sure I agree, though. I didn’t prematurely optimize… in fact, I found the best way to get all the functionality I needed with no need to make additional changes. In my book, that should be every developers target.
I also said that it could affect performance. I didn’t bother testing or trying because it wasn’t necessary given the manner that I optimized the plugin. Once again – I got 100% of the functionality I needed without doing a join or adding indexes, etc. That’s the right solution in my book.
I do agree with you on your other notes, though. I am leery of republishing plugins, feels like I’m getting exposure off of someone else’s work. I referenced the author’s blog on this – so perhaps he’ll take these into consideration as features for future release.
PS: Fixed the editing! 🙂
@Douglas: I?m not sure I agree, though. I didn?t prematurely optimize? Once again – I got 100% of the functionality I needed without doing a join or adding indexes, etc.
Well, I guess that’s the difference between someone who is viewing programming from perfective of profession and a craft vs. someone who is a practioner just trying to get something done (and I don’t mean that perjoratively; on some mailing lists I play the letter role against the former. 🙂
It’s similar to how an accountant or lawyer tells a business owner “I wouldn’t do that” and the business owner, not steeping in all the ramifications that the professionals are aware of as being *potential* ignores their advice because it seems like too much effort, and plows ahead. God knows I’ve been that business owner in the past and have plowed ahead against all advice, though much to my chargin later. 🙂
@Douglas: I am leery of republishing plugins, …
No, that’s not exactly what I was saying. What I was saying is that since it’s open-source you can contribute your changes back to the original author it they’ll accept, and you can do it proactively by contacting and offering. I currently work as a marketing consultant and website implementor for niche print publishers and use Drupal for web technology, and the Drupal community is always contacting plugin authors (Drupal calls them “modules”) and offering to help improve other’s modules.
Just a thought.
P.S. Thanks for the editing fix.
Good points, Mike!
I may tinker with the plugin to add that option of “Only display Posts Prior to the Post Displayed”. I think the second option is a little more proprietary for my blog, but I’ll check and see it it may be of interest to the author.
@Douglas: I think the second option is a little more proprietary for my blog…
Yeah, I agree. Good deal though!
Crud on the prior comment’s formatting! I wish you had comment preview! ‘-)
Some day!
Doug – I may be missing something here. It seems that
AND post_date <= '$now'
doesn’t prevent posts made after that particular post from being included, so much as it prevents inclusion of posts that you may have set to be published in the future.
Hope that makes sense and thanks for the great blog.
Scott,
That’s a great find! that I’m sure everyone (who writes in advance) will appreciate.
I’ll update the query in the post.
Doug
@Mike: Well, I guess that?s the difference between someone who is viewing programming from perfective of profession and a craft vs. someone who is a practioner just trying to get something done
Interesting distinction. While it would be nice to have everything running at the absolute best it can be, in many cases that seems impractical. I strive to find a balance in my programming between how I would like something to run and how much $ or time it will take to get it there.
I strive to do the minimum it takes to accomplish the purpose I’m try to achieve. To spend more time would not be cost effective.
In short, unless that loss in efficiency was noticeable in my blog I would not spend the extra time, If it’s noticeable than I would decide whether the additional time would be worth the result. Perfection is not always the best solution.
@Dwayne: I strive to do the minimum it takes to accomplish the purpose I?m try to achieve. To spend more time would not be cost effective.
Of course if always doing the minimum means that you don’t learn better techniques causing you to repeat the minimum many times in the future rather than allow you to avoid it, then you’ve made a false achievement. Yes, many tasks don’t need extra effort but I’ve witnessed many people take shortcuts like this in the past and they were some of the least productive and/or least value-creating people I knew (some of them were unfortunately my employees, hence why I really noticed their lack of productivity.)
@Dwayne: In short, unless that loss in efficiency was noticeable in my blog I would not spend the extra time, If it?s noticeable than I would decide whether the additional time would be worth the result. Perfection is not always the best solution.
I think you missed my points. First I was saying that Doug was optimizing for unnoticable efficiencies, not me, but more importantly if you are going to implement a hack that can cause future maintainability issues for goodness sake don’t publish it for other’s use without at least telling them of the kind of maintainability problems it might cause for them later.
The irony of your comment is that taking the quick and easy route often ends up costing you a lot more time in the future when you install a security update for your WordPress, loose your hacked functionality and want it back. Now you have a haystack with a missing needle and you now need to figure out where the needle used to be.
Spend extra time on performance? Bah, generally not needed. Spend extra time on maintainability? Yes, it often pays for itself in the long run.
Wrapping up, yes it’s human nature to dismiss warnings for things that have never caused oneself pain. Feel the pain once and you’ll be a lot more likely to heed those warnings from others who have already felt that pain.
One thing I should say; I do think Doug’s hack would be a good addition to WordPress, at least as a user option. It does seem rather silly to limit related posts to only those that came before.
ALSO, I would like to ask Doug to post about how his daily posts are posted from del.icio.us; that would be an interesting topic.
Hi Mike!
I agree with you… and here’s how to do the daily posts from Del.icio.us. Enjoy!
Heh. Good one! I guess I should have googled for it first.
BTW, I sent you a personal email about me being in Indy Feb 16-19 about a week ago but have not heard back. Did you get? (feel free to delete this part of my comment.)
Great post, I will do the tweak on my plugin thank you again!