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>SubscribetoComments”, 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:
Continuing my quest to stop comment spamwithout 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 dofollowcommentstatus 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.
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.
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 excellentShortStatplugins. 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.
..And we’re back. After an insane week spent shopping for a new host, dealing with some Bad Behavior, and transferring Perishable Press to its new home on a virtual private server (VPS), everything is slowly falling back into place. Along the way, there have been some interesting challenges and many lessons learned. Here are a few of the highlights..
The tide may be turning for A Small Orange
I am certainly not alone when I say that shopping for a new hosting provider and transferring websites is one of my least favorite aspects of web development. In my experience, switching hosts requires waay too much time and rarely unfolds without significant problems. Nonetheless, when service and/or support turns sour, upgrading to a better host is well worth the effort. In my case, A Small Orange just wasn’t working out.
Everything was going fine for the first several months — excellent service, fantastic support, and consistent, reliable server uptime. However, during the last several months, server uptime frequently dipped below the 98% level, an unacceptable amount of downtime, especially since it generally happened during critical times: peak hours or while I was trying to work on the site. When I finally submitted a support ticket addressing the “unacceptable levels of downtime,” ASO support staff put my mind at ease by moving my site to a “a more stable server.”