Changing WordPress Auto-Save and Revisions Settings

The WordPress  team did a great and wonderful thing when they included auto-save and revisions for posts/pages. If you’re in a collaborative environment, referring to previous revisions can be a useful tool. And auto-save? If you haven’t had a computer crash in the middle of writing a blog post, you’re probably in the minority 🙂

On the flip side, most of us don’t need to see countless revisions that we may have made. Fix a typo? One more revision. The list can get pretty long.

And really – do we really need an auto save once every minute? I don’t know about you, but I don’t type that fast…

Fortunately, as for most annoyances in WordPress, there is a relatively easy fix for both auto-saves and post/page revisions. You’ll need to edit your wp-config.php file (for those of you who installed WP by hand, that’s the file where you entered your database information).

FTP into your WordPress installation on your server, then download the wp-config.php file to your computer. Immediately, before you do anything else, make a backup copy. Always always always keep a backup copy of files you edit. An error as tiny as a misplaced comma can render your blog unusable.

Changing the AutoSave interval

You’ll need to add the following line to your wp-config.php file:

define('AUTOSAVE_INTERVAL', 180 );  // # of seconds between saves

Change the ‘160’ number to whatever autosave interval you want. I usually use 180, or 3 minutes.

Change the post Revisions settings

Unlike AutoSave, you can actually turn post/page revisions off if you really want to. Or, you can specify the number of revisions you want to keep.

To turn revisions off, add this line to wp-config.php:

define('WP_POST_REVISIONS', false );

If you want to keep revisions on, but limit the number that WordPress saves, use a number instead of the keyword false:

define('WP_POST_REVISIONS', 6);

There. Pretty simple, eh? Save your wp-config.php file, then upload it back to your server. Your changes will take effect immediately.

WordPress Plugins – Using the Options Table Properly

Note: if you’re not a WordPress plugin developer, this probably won’t interest you.

I ran across this again today, hence my rant:

I installed a plugin from the WordPress Plugin Repository ( the place that hosts WordPress plugins so you can download them ), THEN looked through the code. This small specialty plugin added 17 options to the options table!

WP developer peeps, there is no excuse for this. By adding so many options, you clog up the options table. Unless you specify the option as an autoload, you’re using a database read every time you call get_option(). What a waste!

What should you do instead? Glad you asked!

Combine your options into an array. Easy smeasy. WordPress will store your options array as serialized data. Return get_option() to a variable at the start of your script, giving you easy access to all its components.

The WordPress core is getting sizable enough that responsible developers need to optimize their code as much as possible. Eliminating unnecessary database reads/writes is a good first step.

If you need an example, leave a comment and I’ll post one.

EDIT: as requested, here’s a couple of examples. First, what many developers do but shouldn’t:


$myoption1 = "ted";
$myoption2 = "fred";
$myoption3 = "jed";

update_option( 'myoption1', $myoption1);
update_option( 'myoption2', $myoption2);
update_option( 'myoption3', $myoption3);

Notice how the above uses 3 different options: myoption1, myoption2, myoption3. These take up 3 rows in the database, and require 3 different calls to get_option() when the data is needed. Now, 3 isn’t very many – but consider when your plugin uses 30 or 40 different options or presets ( some of mine do ). The potential to clutter up the database and cause a slowdown in your page load times is huge.

Here’s how you should code your options:


$myoptions = array( 'option1' => 'ted', 'option2' => 'fred', 'option3' => 'jed');
update_option( 'myoption', $myoptions );

And that’s all there is to it. The update_option function recognizes that you are passing an array and serializes the values for entry in the database. When you need to retrieve the options, simply call get_option into an array variable, and access from there. One call, 40 options. Lotsa overhead saved 🙂


$myoptions = get_option( 'myoption');

/*
now, $myoptions['option1'] = 'ted', $myoptions['option2'] = 'fred', and so on.
*/

Free Month Web Hosting from HostGator

I don’t put my stamp of approval on too many things, but I do need to tell you about the hosting that I use and highly recommend – HostGator.

I have been on the web for over 10 years now, and seen a lot of hosting companies come and go, and used several. Never have I had the experience that I have had with HostGator. It’s been, in a word, fantastic.

Remember to use the coupon code "ILIKEWORDPRESS" for your first month free!

Support

Number one, their support has been great. I have experienced a handful of isolated problems over the last 3 years I’ve been with them, and all were handled promptly, professionally, and FAST. There’s nothing worse than having a client call in the middle of the night crying, “my site is down!” In those situations, I need the problem handled quickly, and HostGator has never let me down.

Features

What a hosting company can do for me is important. I need technical goodies, I need plenty of bandwidth and storage space, and I don’t need to be nitpicked over how many databases I use. HostGator shines in that department. Unlimited storage, unlimited domains, unlimited bandwidth, unlimited MySQL databases. Of course, ‘unlimited’ doesn’t always mean unlimited. If your account starts hogging server resources, you’ll garner some attention.

That said, I’ve never had it be an issue. On one of my Baby accounts, I run 35 sites. Admittedly, they’re not high-volume super popular sites, but they get their share of traffic.

Special Deal for ILikeWordPress.com readers

HostGator has allowed me to offer you a special deal! Use the coupon code “ILIKEWORDPRESS” and get your first month’s Baby plan hosting for only $0.01!! That’s right – ONE PENNY. How cool is that?

Go ahead and get signed up – click any of the links to go to HostGator, or one of the banners, and remember to use coupon code ILIKEWORDPRESS at checkout for your discount!

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.

Protect Your Email Address From Spammers

So you’ve started a new blog, and now the worst has happened – the spammers have your email address. You know, the one that’s on every post where you’re listed as the author.

You can do what a lot of people do to combat the dreaded email harvester. Give them a throw-away address to chew on, and when the spam gets too bad close that account and start another. Throw-away addresses are the free accounts – Hotmail, Yahoo, GMail.

But that’s a pain.

Why not just make it so the spam bots can’t find your email address in the first place? Fortunately, it’s pretty easily done, using a built-in WordPress function: antispambot(). This function takes the email address enclosed in the parentheses, converts it to HTML entities ( the &#xx characters ) and returns the value.

How do you use it? Again, pretty simple. Somewhere in your templates, if the template author chose to display your email address at all, is a call to the WordPress template tag the_author_email(). This tag, as you might suspect, outputs the post author’s email address. Open your single.php template (the most likely template to display the author’s email address ) in your fav text editor, and search for the tag. Once you’ve found it, you’ll make the substitution. Change the_author_email() to the following:

echo antispambot( get_the_author_email())

Nothing to it, right?

Those of you with sharp eyes will notice we’re using a slightly different function to get the author’s email address – get_the_author_email() vs. the_author_email(). The difference is that the latter actually outputs the email address to the screen, and we don’t want that. We want to pass the email address to the antispambot() function rather than print it to the screen, so we use the get_the_author_email() function which returns the value rather than echoing it. Small but important distinction.

Graphic Design Book Blowout! Over 70% Off Retail!

I am done completely with print design and design in general. Because it’s also spring-cleaning time for my office in preparation for a move, these books really need to find a new home. I would prefer to sell them as one package, but let me know if there’s one or two that you want.

There are almost $250 worth of books here, all in good shape. They have been read, though, so they’re not pristine.

Buy-it-now price: $75 + $10 shipping, total $85. Hit the preloaded PayPal button below or at the end of the post. Yes, you can use credit card or debit card.

Or – give me an offer. I’d like to see these go to someone who can use them and will appreciate them.





Graphic effects and typographic treatments. Jim Krause, $22.99 USD. ISBN 1-58180-046-0

Brochure, poster/flyer, web design, advertising, newsletter, page layout, stationery ideas. Jim Krause, $22.99 USD. ISBN 1-58180-146-7

An index of 150+ concepts, images and exercises to ignite your design ingenuity. Jim Krause, $24.99 USD. ISBN 1-58180-438-5

Over 1100 Color Combinations, CMYK & RGB Formulas, for print and web media. Jim Krause, $23.99 USD. ISBN 1-58180-236-6

A graphic designer’s guide to designing effective compositions, selecting dynamic components & devloping creative concepts. Jim Krause, $24.99 USD. ISBN 1-58180-501-2

375+ pages of design ideas, edited by the famous David E. Carter, $29.99 USD. ISBN 0-06-008763-3

Design and Typographic Principles for the Visual Novice, Robin Williams, $14.95USD. ISBN 1-56609-159-4

The Non-Designer’s Type Book, Robin Williams, $24.99USD. ISBN 0-201-35367-9

Everything you need to know to create dynamic layouts. Graham Davis, $21.99USD. ISBN 1-58180-260-9

Design principles, decisions, projects. David Dabner, $23.99USD. ISBN 1-58180-435-0





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