I recently did some time in Microsoft Excel, preparing large CSV files for import into WordPress. Each of these CSV files contained data for 1000 WordPress users. Here is a screenshot showing the structure of the file:

Conceptually, the idea is simple: import the data to create actual users for a WordPress-powered site. The trick is to clean the data as much as possible to ensure valid username and password information. Once the data is good, importing is easy using a plugin.

Here is a step-by-step tutorial that combines WordPress and Excel techniques to register users en masse from a CSV file.

Continue Reading

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

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

..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.”

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

Several months ago, we encountered some problems with our hosting company and decided to switch servers. Then, after spending countless hours transferring our army of domains, the new server crashed and our databases were deleted. Further, after the transfer we quickly realized the inferior technological quality of our new host. Thus disgusted, we transferred everything back to our old server and hoped for the best.

For the past several months since then, our original server has been running as well as could be expected, all things considered. All functions were running smooth, the error logs were empty, and all was well and good in cyberspace. Then, suddenly, about two weeks ago, someone gained access and indiscriminately hacked every index file on the server. Expectedly, this created chaos, crashed websites, and left our hard-working server techs scrambling to fix the hole and secure the server.

Immediately after the attack, we began repairing our websites, uploading files, restoring databases, and troubleshooting errors. Then, just as we began to make some progress, the entire server crashed, wiping out all traces of every domain on the server. Deluged with "help tickets" from many customers, our hosting company responded with a form letter indicating the problem and reaffirming us of their support (copied verbatim):

Dear Velued Customer,

today we have experienced 4 hours of downtime due to broken cPanel/RHEL update. Everyday we receive updates from cPanel and RedHat, they are automatically installed on the server. Those are critical patches, software updates etc. Today's nightly upgreade broken whole server due to incompatibility in Bind (Name servers) library. All techs have been working on the issue, it took us some time to locate the problem. In the meantime we find out that more hosting companies has such problems. Finally we were able to fix the issue and the servers are back to normal. If you experience any problems accessing your domain names it may be because you tried to access the server when DNS was down and your local ISPs DNS server couldn't cache the IP address. It may take few hours until your local ISP's DNS server refresh the DNS zone.

You can check that your web site is up and working properly through 3rd party proxy server ie. www.the-cloak.com

The issue affected ALL hosting companies which uses cPanel, for more information regarding the issue please check cPanel forums at:

http://forums[…].com (edited)

We understand your frustration and how it harmed your business however we would like to assure you that we are here 24 hours a day and 7 days a week and if there is anything wrong we will do our best to fix the issue as soon as possible.

Please accept our appology and we hope to offer you best hosting services possible.

Best regards,
Customer Service Manager

Apparently, during the process of cleaning up the aftermath of the server attack, it became necessary to upgrade various components of cPanel and other server software. Unfortunately, the upgrade produced conflicts and subsequently crashed the entire system. Ahhh yeah. Thanks for that form letter.

Several days later, after great stress and concern, the domains were once again online and accessible, enabling customers access to (once again) begin work on the restoration process. Things were finally looking up..

Well almost. After all of our websites had been restored and the dust had settled, several key applications were no longer functional. After an unsuccessful troubleshooting session, we broke down and submitted a help ticket. As it turns out, two vital PHP functions, passthru() and exec(), had been disabled due to security concerns. In other words, thanks to the cracking exploits some mindless showoff, the generous scripting privileges customers once enjoyed have now been restricted.

The good news is that, aside from the loss of a few key functions, everything else is once again up and running considerably well. Looking back, we see how the difficult, stressful, even frustrating events serve as priceless learning experiences. Indeed, managing websites is definitely a challenging endeavour, requiring great patience, flexibility, and determination.

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.

Recently, every website on our primary server was simultaneously attacked. The offending party indiscriminately replaced the contents of every index file, regardless of its extension or location, with a few vulgar lines of code, which indicated intention, identity, and influence.

Apparently, the attack occurred via Germany, through a server at the University of Hamburg. This relatively minor attack resulted in several hours of valuable online education. In this article, it is our intention to share experience with website attack recovery. This article is aimed at website developers, designers, and administrators.

Continue Reading

After successfully migrating our domains to a new server at WebHostingBuzz.com, we continued writing articles, uploading, embellishing, and fine-tuning everything. Everything seemed fine. At first…

Continue Reading

As you may have read, we recently transferred our websites to a new server. Although the overall process went smoothly enough, several learning opportunities unfolded during the transfer of our humble Perishable Press website…

First, the setup. Perishable Press is a WordPress-powered website. On our previous server, we were running a Fantastico-installed WordPress version 2.0.2, upgraded from version 2.0. Permalinks were enabled and everything was running smoothly. Our database was only 13MB in size and around 12MB of that was disposable statistics information from WP-ShortStat and Bad Behavior. The crucial part of our database was a friendly 1MB in size.

Continue Reading