Tag Archives: technology

Freaking Friday

It’s rant time.

Today I’m raging against technology. (Come share your tech woes too!) When you’re your own tech support, tech woes are even tougher. That’s why I set up a testing site just like this one to try out new plugins and themes. Unfortunately, I let that site lay around much of the time until I have something big to test—so when I do have something big to do, usually my test site doesn’t match up with my current site.

Actually, one computer was harmed in the making of this post. Not like this though.

So the tech woes began several weeks ago, when I took the time to update my WordPress software and search out all the plugins that I have running on my main site to look for any conflicts. Updating my WP was the usual headache, since recent builds added a new bit of code that conflicts with my site layout. That cuts off my access to the backend of WordPress, but I know how to fix it (thank you, Google).

Except that the same fix that worked on my main site was not working on my test site. After an hour, I finally just cut and pasted the code from the fixed file on my main site into the not-so-fixed file on the test site.

Fixed.

Relatively speaking, it wasn’t too frustrating to try to search out 30+ plugins, even for the numerous plugins that I installed five years ago—or five weeks ago—that had disappeared without a trace from WordPress’s database. (Oooookay?) It was just time consuming.

After a weekend of work, my “test” site was ready to start testing. I downloaded the plugins I wanted to try out and scheduled some time over the next few weekends to evaluate them. And the following Saturday, I pulled up my test site to get started.

500: Internal server error.

Ookay. I quite like my webhost, Bluehost, but everyone has some downtime, right? I logged into the admin area of my test site just fine and got to work configuring the various options for the first plugin I was testing. After about an hour of exploring, I was really ready to see the results.

500: Internal server error.

I deactivated the new plugin.

500: Internal server error.

I deactivated all my plugins, and the test site loaded fine. After a couple hours—HOURS—of experimentation, I determined that it wasn’t a single one of the new plugins causing trouble. It wasn’t a single one of the old plugins causing trouble.

Instead, every. single. one. of the THREE new plugins threw a 500 Internal server error when it was activated. As did every. single. one. of FIVE plugins that were currently running successfully on my regular site.

smash it with a hammer.So not only could I now NOT test any of those plugins, I couldn’t use the plugins that made my regular site work. Clearly something was wrong with the setup of my test site. Short of totally reinstalling WordPress, nothing was working. (In the meantime, I also tried to take care of a minor tax thing and had to spend 15 minutes convincing the designed-without-ever-even-thinking-about-an-actual-humanoid-user site that yes, in fact, I do know my own name and social security number.)

Oh, and then my webhost went down.

At this point, I’d spent six hours working on my test site, just in that one day. (It might have been four to six more hours the weekend before.) And nothing to show for it.

Okay, fine. There has to be a better way to run a test site, right? Of course. I Googled around and finally settled on using a lightweight version of WordPress + database on my computer as a test environment. But once again, I have to match my test site to my real one to check for plugin/theme conflicts.

The easiest way to do this would be to use a plugin made to export or copy your site, right? You’d think.

I tried one. It spends 5-10 minutes processing processing processing—FAIL. Second shot processing processing processing—

(— . . . ? Not even an error message?)

So I try the next one. The first time I run it, instead of spitting out the URL of the backup result (after a similar processing period), it reloads the page and breaks my CSS so nothing displays properly. I try again; same result.

did this to a computer once. nice.I swear, I only did it twice.

After a third plugin does nothing, I have to go old school. I’ve hardly used FTP (file transfer protocol) since WordPress added the ability to install plugins and themes directly, but I dug out my web host’s web-based FTP app and tried to copy the entire file of themes, plugins, etc., onto my computer for the offline WordPress.

An hour of heavy processing later, I see that the files being prepared for download—not even transferring yet—are a little repetitive. In fact, it appears that plugin #2 actually made a backup of my site successfully, even if it wasn’t able to tell me about it.

In fact, the plugin made several backups of my site. Recursively. So at this point, the file transfer protocol was preparing to download a clone of a clone of a clone of my site.

I canceled the operation, deleted the cloning/backup plugins, and came back to try the FTP again. The file transfer began and the file names being transferred scrolled past.

Next time I walked by my computer, the connection had been lost.

Fine. Fine. Fine. I decided to resort to an actual program on my computer to use the file transfer protocol, an FTP client, even though it’s been probably a decade since the last time I used one. Of course, I had to download a new one. I picked one of the recommended clients from my webhost’s list and downloaded it. I went through the installation process. I clicked “Finish/Launch [the program].”

Nothing. No new program loaded. No new shortcuts on my desktop. No blinking programs in the Start menu. After refreshing my memory of the name of the program, no results in program searches, except the installer. Which I’d just run—apparently unsuccessfully.

I broke down. And tried it again. (Read that together or separately.)

Finally—FINALLY—the FTP client did install and did start. And then I opened the program and was told for the VERY first time that this was a trial version, only good for 29 days.

I was afraid to even try the transfer.

And I was right. Three . . . four . . . five . . . twenty-four . . . twenty-five . . . forty-nine . . . fifty connection attempts later, fail, fail, fail. I look at my host’s further instructions for setting up the FTP client connection. It has specific configurations for three different recommended FTP clients.

Not the one I happened to pick.

How does one throw THE ENTIRE FREAKING INTERNET against the wall until it breaks?

yessss

(The happy ending to this part of the tale : I picked a different FTP client, downloaded, installed and connected in about five minutes, and was able to transfer ALL my plugins, themes, uploads, etc., in about an hour—including two service interruptions. I also got to find out the clone of a clone . . . continued to the fourteenth recursion, comprising thousands of files. I could kiss you, FileZilla.)

Should I even mention that this last week, my computer—which I spent all this time setting up my test site on—decided not to boot anymore?

Fortunately, a friend diagnosed a corrupt stick of RAM, but until I replace it, my laptop is down to 2G 1G of memory. (HOW DID WE SURVIVE LIKE THIS?!)

Oh, and should I mention that my ISP is crapping out every other minute or so?

Face. Palm. Head. Desk. Wall. Die.

Please make me feel better and share your technology woes.

Photo credits, respectively: Tara Hunt, Sarah Baker, Brandon Wood, stuartpilbrow