Wordpress: “Unable to locate WordPress Plugin directory”

Automatic plug-in updates are cool, but only when they work. I made attempts to understand what’s wrong with the “update automatically” feature several times, and always hit the same message after entering my FTP details: “Unable to locate WordPress Plugin directory”.

As a computer geek, I know why it needs FTP, but it wasn’t really clear what exactly it was looking for in the root of the FTP directory and why it didn’t find it. I figured that my server setup is a bit different from what they expected, and scanned the sources for clues.

Apparently, they are looking for the wp-settings.php file which is sitting in the root of the WP installation. So when they find the file, they know where to start looking for plug-ins folder. In my case, it was light years away from the FTP root, so here’s what I did:

• Created an FTP user specifically for the blog
• Made the root folder of the blog be the home directory of this user
• Fed the user name and the password to WP when it asked for the FTP again

All went very nicely and hassle-free. Now you know what to do when you see “Unable to locate WordPress Plugin directory” when attempting to update your plug-ins automatically.

Productivity Tip

Today, as I was playing with ideas after a big chunk of work, one interesting thought came, and it’s worth sharing. Everybody likes when the job is simple, straightforward and easy to do. Sometimes though times come when an assignment is … well, different.

I like to shoot these tasks first and, speaking in the context of PROgramming, like to make everything possible to never get back. If it implies writing a hundred of tests, that’s fine, just never again… you hear me? It’s not that I hate what I do, it’s that I, as a living being, hate stress.

Usually, I took the rest of the day off right after dealing with a complex or mundane to refresh the mind. It worked well, but took a lot of time and had a bitter taste of excuse to skip working hours. Today I invented something different for myself.

Here the summary of points that I (and hope you) usually keep in mind when working:

• Focus on the task
• Stop watching the clock
• Keep a clear plan of attack with very small sub-tasks to cross them out as quickly as possible
• Do whatever it takes to protect yourself from getting back (comprehensive tests suite, clear design etc)
• Make a lot of comments to give you a hand if you still need to change something later

And now something new:

• When the task is over, check in the sources, run all tests, and finish anything else that attaches you to the task, and then
• Take a coffee break and detach yourself from it and the results as if somebody else did the job and you are left with an easy part (calling the module, using freshly designed database etc)
• Start (not continue) working refreshed and, possibly, give you some easy and fun tasks to get the happy feeling of great job you always did

These are all simple steps, but I know no one who would follow them. I read many standard advices, like 50 minutes of work / 10 minutes of rest that are far from a silver bullet. They sound like a quick and dirty rule for those (or by those) who don’t really want to think WHY these breaks are important and, what’s more important, what to do during them.

With this last summary I feel I got closer to a better understanding of my own brain and how it works. Now I know how to reset that anxiety and stress to continue moving on without passively waiting for the same effect first.

Hope I induced some fresh ideas and insights. Feel free to share back.

Cheers!

Rails: When an Uninitialized Constant Hits the Vent

Last two weeks I was seeing the production server of one of my clients hit the same error over and over with no visible pattern. This second it works, the next it fails and leaves the Mongrel cluster in an undefined state somewhere between this world and hell.

The error I’m referring to is:

I need to repeat that it comes and goes under some non-obvious circumstances, and is hard to recreate. Fortunately, I found the solution and here’s what it was.

I have a directory hierarchy like below. I’m sure when you see it, it all becomes obvious and simple, but it wasn’t for me at that time as there were many files that I omitted below.

The piece of code in klass1 that failed looks as follows:

Simple, heh.

Utils.rb is a helper module which is included into MyModule, but apparently loaded only when really necessary (it’s the only explanation why it didn’t fail all the time, as you will see). When it is loaded and included, the MyModule::Utils becomes defined, and Utils::NetSession resolution starts to fail. It happens as Rails begins looking for Utils name space from MyModule, finds MyModule::Utils and doesn’t find any NetSession there. That’s pretty much all to it.

The solutions are:

• Either rename utils.rb (which I did in favor of utilities.rb), or
• Use “::Utils::NetSession.new” (which is not safe as one day you can forget about the leading “::”, and get back to roots)

Hope this helps someone like me fighting the way through these extremely infrequent but painful Rails gotchas.