After almost three years of blogging here at Perishable Press, I had an epiphany about my author comment links. Way back when, after installing WordPress in a subdirectory called “/press/”, I decided to set the URL for my Administrative User Profile’s website as “http://perishablepress.com/press/”. After all, it seemed to make sense at the time, plus it really didn’t seem to matter; nobody was going to see my personal profile information anyway, right?

Wrong.

Three years later, I finally realize that it does matter. The URL that you enter as your profile’s website address is the URL that will be used for every author commentator link on your site. Yes, I know what you’re probably thinking, “what an idiot! I thought everybody knew that!” Well, no, obviously not everybody. It may have occurred to me momentarily or subconsciously at some point along the way, but it wasn’t until just a few days ago that the light bulb finally flashed.

So what’s the big deal? First and foremost, one of the most highly visible and prevalent links to your site comes from your own author commentator links. These links are used to represent your site for every one of your own comments. Other commentators and visitors recognize the link, note the location, and possibly use it when linking back to your site. Thus, it is important to represent your site by linking to the optimal URL in your author commentator links.

Continue Reading

Just a quick WordPress snippet for future reference. I recently explained how to disable comments, pingbacks, and trackbacks via SQL. Here’s a good way to do it via PHP:

<?php 
function close_comments( $posts ) {
	if ( !is_single() ) { return $posts; }
	if ( time() - strtotime( $posts[0]->post_date_gmt ) > ( 30 * 24 * 60 * 60 ) ) {
		$posts[0]->comment_status = 'closed';
		$posts[0]->ping_status    = 'closed';
	}
	return $posts;
}
add_filter( 'the_posts', 'close_comments' ); 
?>

You can run this script as a plugin, through your theme’s functions.php, or through a custom user-functions.php file. Simply set the desired number of days by changing the number “30” to whatever you would like. As is, this script will close comments, pingbacks and trackbacks on all articles posted more than 30 days ago.

Several months ago, I changed my email address to stop spam. Since then, I have been updating every instance of my old address that I can find. In WordPress, I edited all of my theme files and updated my profile information in the “Users” admin area. Several days later while digging through the comments table in the WordPress database, I realized that the user-profile update is only pro-actively effective. There were still hundreds of instances of my old email address associated with comment-author information in the comments table. No big whoop for some, but the devastating inconsistency of it all would have kept me from a good night’s sleep (or maybe that was the caffeine..).

Continue Reading

After investigating some unusual 404 errors the other day, I found myself digging through the WordPress Admin trying to locate the “Subscribe to Comments” options panel. As it turns out, administrative options for the Subscribe to Comments plugin are split into two different areas. First, the S2C plugin provides configuration options under “Options > Subscribe to Comments”, which enables users to tweak everything from subscription messages to custom CSS styles. New to me was the other half of the S2C administration area: the Subscription Manager! Carefully hidden under “Manage > Subscriptions”, the Subscription Manager provides several useful ways to filter your email subscribers:

Continue Reading

Continuing my quest to stop comment spam without using plugins, I have decided to disable comments on “old” posts. In my experience, over 90% of comment, trackback and pingback spam occurs on posts that have been online for over a month or so, just long enough to be indexed by the search engines and picked up by spammers. Especially for older posts that have managed to acquire a little page rank, the frequency of spam attempts is far greater than it is for fresher content. Throw dofollow comment status into the mix, and say “hello” to a hellish number of spam attempts on established pages. Thus, my evolving anti-spam strategy now includes discussion management, which involves periodic closing of feedback on older posts. In this article, we will examine currently available methods of managing comments, and then proceed with a versatile toolbox of SQL queries for complete discussion management.

Continue Reading

Recently, while dealing with the dreaded white screen of death, I found myself unable to login to the WordPress Admin area to manually disable all of the plugins used here at Perishable Press. In the past, I have dealt with this situation by simply deleting all plugin files from the server, however this time, time was of the essence — I had only a few minutes with which to troubleshoot, diagnose, and ultimately resolve the deadly white-screen syndrome. Fortunately, after a few minutes of digging through the WordPress Codex, I had discovered enough information to successfully complete my mission. Now that the fiasco is over, I want to share a simple technique for quickly disabling and (re-)enabling your entire set of WordPress plugins.

Continue Reading

In this article, I present a simple method for dramatically decreasing the size of your WordPress database by partially emptying old data from the WP-ShortStat table via the following SQL command:

DELETE FROM `wp_ss_stats` ORDER BY `id` ASC LIMIT n

That is the point of this entire article, which dips into just about everything one might need to know before employing such strategy. If you are familiar with SQL and understand the purpose and functionality of this command, feel free to grab, gulp and go. Otherwise, read on for the full story..

A little context, please..

Many WordPress users enjoy the convenient statistics provided by one of the excellent ShortStat plugins. WP-ShortStat keeps track of many essential types of data: recent referrers, search queries, referring domains, keywords, locations, browsers, and many more. Over time, the copious amount of statistical data collected by WP-ShortStat increasingly inflates the size of your WordPress database.

Continue Reading

After switching Perishable Press to its current home at A Small Orange, I began noticing an unusual problem with referrer data displayed in Mint. Specifically, the first item recorded in the XXX Strong Mint data panel — for both “Most Recent” and “Repeat” views — displayed several thousand hits for various site resources, all from the following IP address:

127.255.255.255 
zxw59eit.emirates.net.ae

Apparently, this particular location represents an invalid “loopback address.” The requested resources appear valid, indicating typical traffic patterns, but the loopback address is not the actual referrer. This issue was preventing Mint from accurately recording mountains of vital referral data.

Researching this issue reveals that the underlying problem involves the switching of a Mint installation between a 32-bit server and a 64-bit server. Installing Mint on either type of server without switching to the other should not trigger this problem. It is the switch from one to another that results in the generation of the loopback address.

Continue Reading

Recently, I needed to find and replace all instances of “http://website” in the wp_comments table of the WordPress database. Fortunately, SQL provides a simple way to find and replace data with its wonderful UPDATE function.

General Example

Using the SQL UPDATE command is straightforward. Here is the general syntax:

UPDATE table_name SET field_name = replace( field_name, 'string_to_find', 'string_to_replace' ) ;

Simply replace the table_name and both instances of field_name with your specific information, and then edit string_to_find, and string_to_replace with the desired values. This is pretty standard stuff, but it is always a good idea to backup your database before executing commands. To run a “Find and Replace” via phpMyAdmin, simply login, select your database, and enter the command via the SQL tab. Copy, paste, and go!

Continue Reading

Recently, after researching comment links for an upcoming article, I realized that my default <input> values were being submitted as the URL for all comments left without associated website information. During the most recent site redesign, I made the mistake of doing this in comments.php:

...

<input class="input" name="url" id="url" value="[website]" onfocus="this.select();" type="text" tabindex="3" size="44" maxlength="133" alt="website" />

...

Notice the value="[website]" attribute? It seemed like a good idea at the time — I even threw in a nice onfocus auto-highlighting snippet for good measure. I ran the form with this in place for around eight weeks before finally noticing multiple comments using this for their site URL:

Continue Reading

This post exists entirely for the sake of tweaking time functionality in Apache, PHP, SQL, and WordPress..

Immediate findings:

• Date/time limit into the past for WordPress: December 13, 1901 @ 15:45
• WordPress will display December 13, 1901 @ 15:45 properly for all functions except wp_get_archives
• All dates prior to 12/13/1901 in MySQL will display as December 31, 1969 @ 19:00 in the WP Admin > Post Timestamp panel
• SQL timestamps of 0000-00-00 00:00:00 display as 0 via $wpdb->get_col("SELECT DISTINCT YEAR
• SQL timestamps of 0000-00-00 00:00:00 display link as the current year when permalinks are enabled
• An SQL timestamp of 1000-00-00 00:00:00 displays link as "1000" and links to the post
• An SQL timestamp of 1000-00-00 00:00:00 displays correctly in archive view, but incorrectly in Admin and post view
• An SQL timestamp of 1950-00-00 00:00:00 displays as November 30, 1949 @ 00:00 in WP Admin Post Timestamp panel and elsewhere in WordPress
• An SQL timestamp of 1950-01-01 01:01:01 displays properly in WP Admin, and elsewhere
• 0001-01-01 01:01:01 displays as January 01, 2001 @ 01:01 in Admin, links to "1" in archives (404 error)
• 1000-01-01 01:01:01 displays correctly in archive, as December 31, 1969 @ 15:59 in Admin and post view
• 3000-01-01 01:01:01 displays correctly in archive, as December 31, 1969 @ 15:59 in Admin, and 404 as post view
• 2050-01-01 01:01:01 displays correctly in archive, as December 31, 1969 @ 15:59 in Admin, and 404 as post view
• January 19, 2038 3:14:08 AM GMT is the latest date that will appear correctly in the WP Admin
• No posts with future date will appear in post view
• An SQL timestamp of 1900-01-01 01:01:01 displays correctly in daily, monthly, and yearly archive views
• An SQL timestamp of 1900-01-01 01:01:01 now displays January 18, 2038 @ 19:14 in Admin
• My head hurts..

More to come.. (much, much later..)

DB Export Settings Backing up your database as often as possible is essential. For WordPress, as well as for other applications, plugins and other scripts that help automate the task are easily obtainable. However, for several reasons, it is a good idea to understand the process of manually creating a backup copy of your database. This brief tutorial¹ should help cement the process into a solid reference. We are assuming that you have an SQL database and have access via phpMyAdmin.

Before reading through the gory details written below, check out the screenshot to the left (click on the image). That picture is literally worth a thousand characters. Another way to avoid the forthcoming verbose explanation is to skip the next paragraph to the neatly summarized list.

First, open phpMyAdmin and select from the dropdown menu the database you wish to backup. If there is only one database available, select it by clicking on its name. Now, along the upper-right row of tabs, click on the "export" tab. From that screen, under the subcategory "Export", click on "select all" and make sure that the "SQL" option is selected. Then, under the SQL Options/Structure category, make sure "Structure", "Add DROP TABLE", "Add AUTO_INCREMENT value", and "Enclose table and field names with backquotes" are checked. Finally, under the "SQL Options/Data" category, make sure "Data", "Complete inserts", and "Use hexadecimal for binary fields" are checked. The "Export type" should be set to "INSERT". Finally, check "Save as file" and do not change the "File name template". It is advisable to save both a compressed copy and a zipped copy. Click "Save" and you are done.

1. Open phpMyAdmin, select database, click on "Export"
2. Within the "Export" screen, click on "Select All" and select "SQL"
3. Then check "Structure", "Add DROP TABLE", "Add AUTO_INCREMENT..", and "Enclose table.."
4. Also check "Data", "Complete inserts", and "Use hexadecimal.."
5. Check "Save as file", select a compression format, and "Go"!

Footnotes

• ¹ This brief tutorial is merely a hybrid of personal experience and Podz' priceless Backup your data tutorial.