Hide Blog Post Date In Your WordPress Theme

While visiting Lynn Terry’s Clicknewz blog, I noticed something that I hadn’t really given a lot of thought to: is there a reason to NOT display a blog post’s date? (Off-Topic Warning – Lynn writes a fantastic blog on Internet Marketing with posts like Taking Daily Action: Huge Goals, Little Steps – you really should check it out if you’re interested in making money on the net)

Anyway, Lynn doesn’t display post dates on her blog posts except for some of the archive listings. After checking out quite a few other blogs, I see that somewhere around 25% of bloggers do NOT put dates on their posts.

After communing with the great and powerful Google, I found this post by Darren Rowse of ProBlogger: Dates on Blog Posts – Should You Have Them? where he discusses the question at length.

I’m not going to get into the question of whether you should or shouldn’t display the date on your blog posts other than to say that personally, I find it annoying when I can’t find a post date. Knowing when a piece was written adds a certain relevance to my consideration of the post content.

One of the suggestions Darren made was to display the date only on recent posts:

Dates on Recent Posts But Not on Older Ones – I saw one blogger do this last year (I’m afraid I don’t remember who it was). They had hacked WordPress so that dates appeared on recent posts (within the last 3 months) but anything older than that did not have time stamps either on the post or comments. This meant that the blogger benefited from new posts looking new and took the potential distraction of old posts away from readers. I don’t know exactly how the blogger did it but presume they set up a rule that looked at the date of authorship and then determined whether the date would be displayed or not.

The ‘hack’ that Darren mentions is actually pretty easy, if you’re comfortable modifying your theme files. Using WordPress’s new “twentyten” theme that comes packed with WordPress 3.0, I’ll show you exactly what you have to do to show the post dates on single posts only if they’re fresher than 3 months old. 3 months is an arbitrary figure, by the way, so adjust it to whatever spins your prop.

Note: the new twentyten theme wraps up the post meta information ( date, author, etc.) into a function. When you disable this function, you’ll lose that line completely, exactly like Lynn’s posts.

I recommend that you do NOT use the built-in theme editor in WordPress, especially when you’re messing around with PHP coding. One misplaced semi-colon and you could render your blog DOA. Then the only cure is to use an FTP client and replace the screwed-up theme file. If you MUST use the built-in editor, be certain that you have a clean backup of the file you’re working on!

So, step one: locate the single.php file within the twentyten theme folder and make a backup.

Open single.php in your fav text editor. The section that holds the meta display code begins on line 25 and looks like this (disregard the line #s in the examples that follow):

<div class="entry-meta">
  <?php twentyten_posted_on(); ?>
</div><!-- .entry-meta -->

What we’re going to do is to insert a test – is the post less than 90 days old? If so, display the post particulars. If not, leave it blank.

To do that, we’ll use a simple ‘if’ statement, comparing the date 90 days ago with that of the post. We will use PHP’s useful strtotime() date conversion function to make things easy:

<?php
if ( strtotime( get_the_date() ) > strtotime( "90 days ago" ) ) {
?>
<div class="entry-meta">
 <?php twentyten_posted_on(); ?>
</div>
<?php
 }
 ?>

The strtotime() function converts whatever is in the parentheses to a Unix timestamp. The function get_the_date() is a new WordPress 3.0 function that fetches the post date and returns it in the format specified in your preferences.

And there you have it – no more dates on posts older than 90 days old.

Cleaning Up the Aftermath of a Hacker Attack

The same project that led to the post Loading WordPress From index.php involved cleaning up after a hacking incident. In fact, that’s what the initial work order was for.

This blog was hit recently by the same attack that has been in the news for the last few days. Lorelle on WordPress wrote some things about it:

There are two clues that your WordPress site has been attacked.

There are strange additions to the pretty permalinks, such as example.com/category/post-title/%&(%7B$%7Beval(base64_decode($_SERVER%5BHTTP_REFERER%5D))%7D%7D|.+)&%/. The keywords are “eval” and “base64_decode.”

The second clue is that a “back door” was created by a “hidden” Administrator. Check your site users for “Administrator (2)” or a name you do not recognize. You will probably be unable to access that account, but Journey Etc. has a possible solution.

This blog was different in that there were no other admin accounts created. The same code was appearing in permalinks ( and was, indeed, shown in Settings -> Permalinks ).

Another symptom of this type of general attack are posts that are filled with spam links enclosed within HTML comment tags. You’ll not see them, but Google does.

Looking a little deeper, I found evidence of another previous hack job. The server error log contained hundreds of these entries: Read more

Loading WordPress From index.php

One of WordPress’ strengths is its attention to SEO-related issues in its core files. One of those issues is the problem of having the home page of the blog indexed twice in the search engines; once under the actual address, http://domain-name.com/index.php, and the other as the plain domain name: http://domain-name.com. Note that this is a different problem than the trailing slash problem ( http://domain-name.com/ vs. http://domain-name.com ) which WordPress also takes care of.

WordPress handles the index.php problem by rewriting requests for http://domain-name.com/index.php to http://domain-name.com. All well and good, and beneficial for most sites.

But that rewriting/redirecting caused some problems on a site I was working on yesterday, and once I figured out how, it was a relatively easy fix. Read more

Don’t Subscribe To My Post Comments If You’re a SpamArrest Customer

On this and other blogs, I have a recurring pain in the butt issue. Some people subscribe to a comment thread, and upon every comment following, I get a challenge email from SpamArrest when the notification of a new comment email is sent.

Here’s news: I don’t click the verify link. As a matter of fact, I don’t even GET the verify link. All of those verification emails go straight to my trash can. I realize this might not be very reader-friendly, but I simply don’t have time to open up every email and click those stupid links, even if I were inclined to.

So please – if you’re a spamarrest customer and you want to subscribe to a comment thread, put ilikewordpress.com on whatever kind of whitelist they have so you can get the subscription notifications. Otherwise, you won’t get any notices from this site about updated comments.

Protecting Your WordPress Blog From Hackers, Crackers, and Jerks

The last few days have seen a rash of hacker attacks on WordPress blogs, with isolated reports going back a month or more. Without exception, as far as I can tell, the successful attacks were on blogs running outdated older versions of WordPress. The latest exploits involve hidden admin users and permalinks polluted with javascript code, outlined in these posts on the WordPress support forum:

http://wordpress.org/support/topic/307652
http://wordpress.org/support/topic/297639
http://wordpress.org/support/topic/307518

WP 2.8.3 and 2.8.4 are NOT vulnerable to this exploit. If you’ve been hacked any time in the last month, and you’re running pre-2.8.3 software, the monkey’s on YOUR back. If you were hacked and running up-to-date version of WP, send the details to security@wordpress.org please.

If you’ve been lax and haven’t upgraded to the latest version, don’t do it until you’ve determined whether or not you’ve already been invaded. If you have, clean it up first, then upgrade. (Be sure you read the “Beyond Upgrading” section at the end of this post) Read more

Using My Way Links To Build Incoming Traffic

This isn’t strictly WordPress related, but if you are an avid blogger and use your blog(s) for income, then you might want to check out Jonathan Leger’s My Way Links program.

One thing that we’re all looking for as bloggers is traffic. Lots and lots of traffic. To get that traffic, we have to rank well in search engines for the things we write about. One of the biggest boosts to that ranking is incoming links, meaning links on other sites that link to pages or posts on your site.

Those can be difficult to get. For a lot of us, it’s not all that important. We’re content to let the community decide the worth of what we write, and link back to us every once in a while.

If you depend on your blog for income, you can’t afford to do that. A lot of your time is spent on SEO strategies. That’s where the My Way Links program comes in. You can build a variety of incoming links from authority sites at a quicker pace than you normally would be able to. You’ll want to use it in moderation of course, but a tool like this is invaluable when it comes to getting high-quality inbound links that will help get your blog found in the Big G.

I wrote a short note about this on TheFastLane blog also, entitled SEO Linking Strategies. You might want to check it out also.

Using PHP Short Tags in Plugins Is a No-No

I had a client call up over the weekend in a panic because her blog disappeared.

“Help! All I see is a blank screen!”

“What’s the last thing you did?” says I.

“Updated my theme files,” says she.

So after an hour’s worth of troubleshooting, I found the problem:

Plugin and theme developers: please do us all a favor and do NOT use the short PHP opening tag (<?) instead of the full length tag: <?php.

Just because you have your development server set up to recognize short tags doesn’t mean that production servers do. In fact, many if not most of them don’t.

Just a request. Yeah, I suppose I make some money fixing this stuff when you do that. But I’d rather not.

Bloggers: if you upload a plugin or theme and you get a fatal error saying “Unexpected $end in filename.php at line xx”, this is one of the first things to check.

Unfortunately, if your web server isn’t set up to allow short PHP tags and also doesn’t display errors (production servers shouldn’t display PHP errors or notices) you might just get the dreaded blank white “I’m dead” screen.

Just something to be aware of.

Dealing With Duplicate Content Issues on WordPress Comments Pages

I saw a tweet today about WordPress comment page duplication issues related to SEO. While the word is still out as to just how much damage it does or doesn’t do to your ability to get found by the Great G, this specific problem is relatively easily fixed — and not by disabling the paged comments feature that the Wizards of WordPress have so kindly coded for us (you ever had a post with 300 comments? you’ll understand what I mean…).

All it takes is a little bit of code in the functions.php file in your theme. If you’re uncomfortable editing your theme files or don’t know how, leave a comment and I’ll whip up a little plugin. This may be a good time to learn to edit your files, though 🙂

This little bit of code doesn’t affect anything but WordPress comment pages. If you use WordPress for something other than a plain-vanilla blog, you may need the horsepower of Yoast’s Canonical URLs plugin for WordPress.

So in your functions.php file, insert the following code (I split the echo lines up for clarity, normally they’d be all on one line):

function canonical_for_comments() {
 global $cpage, $post;
 if ( $cpage > 1 ) :
  echo "\n";
  echo "<link rel='canonical' href='";
  echo get_permalink( $post->ID );
  echo "' />\n";
 endif;
}
add_action( 'wp_head', 'canonical_for_comments' );

Make sure you paste the code before the last ?> characters at the end of the file.

For those of you who care, here’s a quick explanation of what the above code does — you’ll get a short intro into the behind-the-scenes functioning of WordPress.

When a visitor navigates beyond the first page of comments, the variable $cpage contains the page # that’s being displayed. The $post variable contains all of the information about the post. The function tests to see if we’re on a comments page greater than 1, if so, it spits out the <link rel=…./> characters. But where does it spit them?

That’s controlled by the add_action line. We’re telling WordPress that when it’s building the head section (‘wp-head’), to add our special ‘canonical_for_comments’ function.

Simple, easy schmeezy.