Tag Archives: FTP

When Software Fails; or, Don’t Believe Everything the Wizards Tell You

Today’s sheepish lesson learned entails a return to discussion of my Omeka installation process.  It’s sheepish because I persist in believing that I can use the relatively stable set of tools that have been developed by others to help ordinary historians do our work online.  And because computing machines still remain more of a black box to me that I might wish.  And finally, I read the former as a strength and the latter as a weakness.  I should probably give myself a break.  But back to the lesson.

Omeka installation requires the use of FTP (file transfer protocol), one of the older processes that I remember from the early 1990s.  I used to like watching the little dog animation that ran when you used Fetch…. But the point is that in order to show your work on the web if you are using a more recent version of Omeka than the one-click install that my hosting service offers, you need to be able to upload the application via FTP.  I’ve done it before, and I should certainly be able to do it again.

There are plenty of FTP client applications now (however much I might miss the little Fetch dog), and I learned from the pros at the Roy Rosenzweig Center for History and New Media that FileZilla is a good one.  The hosting service I use also offers WebFTP through an application called AjaXplorer.  In fairness, I should note that the hosting service cautions users against relying on WebFTP as one’s only tool for this purpose.

In fairness because the webhost recently installed a new version of AjaXplorer that fails to see some users’ repositories.  Like mine.  When I ran into this problem a couple of weeks ago, I emailed the webhost’s support and learned I was not alone.  Which was a relief.  Sort of.

I had used FileZilla before, so I didn’t panic.  And since I wanted to proceed cautiously and limit the possibility of frustrating mistakes, I opened up documentation for FileZilla and FTP as well as  for Omeka.  Which was a big mistake.

Because FileZilla recommended running their very helpful Configuration Wizard to assure that the application would work smoothly on my machine.  That seemed like a reasonable recommendation, so I followed it.  And that’s where I got massively, frustratingly stuck and remained so for over a week.

Because the Configuration Wizard’s test repeatedly found a problem with an abrupt loss of the test connection and recommended that I adjust settings and try again.  And again.  And still again.  Ad infinitum.

And here was my real mistake.  I believed the Wizard.

So I spent hours trying various fixes.  Turning off my firewall.  Turing it back on, holding my cursor in the right place on the screen and quickly clicking “Allow” to give the application access to my machine.  Reading up on FTP and trying to figure out what the problem could possibly be.  Getting frustrated and going off to do something else.

Day after day, for many days.

I thought the problem might be the new Mac OS, so I read a lot of Apple Support discussions about the incompatibility of Mavericks (please) with various software.  Everything I saw on the forums seemed to indicate that FileZilla was working for others just fine.

So yesterday, when I didn’t really have time to carry out the full installation anyway, I decided that I would just try to connect to the remote server using FileZilla.  If it was working for other people, I finally reasoned, maybe it would work for me.

Maybe the Wizard was wrong.

I launched FileZilla, typed in the server name, my user name, and my password.  And I connected just fine.  No unexplained lost connection.  No problem at all.

The Wizard was wrong.

So my lesson, learned through massive frustration over the past two weeks, is this:

Do not believe everything the Wizards tell you.  Sometimes, they are wrong.

 

 

 

 

2 Comments

Filed under Applications, devices