Log Deprecated Calls v1.2

A new update to my Log Deprecated Calls WordPress plugin.

The newer versions based on Strider Core has had some “teething pains”, for which I apologize; but I believe I’ve worked them out for the most part. Perhaps my primary error was prematurely removing the Strider Core based version from Beta; but this latest should be fully functional.

The primary fix on this one is the settings page — it was not saving properly due to an obscure bug that I fixed by switching to the WordPress Settings API. In the process I may have uncovered a bug in the API, actually. I’ll have to take a closer look to see if it’s really a bug or just a conflict in the way I was using it.

The next pending update is to make more efficient use of the database. Currently I only recommend using the plugin in the short-term while debugging — which you probably do anyways, but if not it can create a very large table. That fix is next on my plate, and then I think I’ll be quite satisfied with what I’ve made here.

It’s a bit odd and — yes — humbling to look at my own code from several years ago. Even just recently I’ve learned some new concepts after reading the excellent book Clean Code — which was almost worth it just for the advice that you make smaller functions and make them each do One Thing Only. It helped in this latest bugfix, as the bug traced back to a function that inappropriately did TWO things. In the process of validating the form before saving it, a function was actually saving the option to the database as soon as it validated — but this was in turn causing the WordPress API to start the validation over again, which saved the setting, which restarted the validation, which saved the setting…. and so on. Once I cleanly separated the act of determining default options from saving default options, the problem was quickly resolved.

The main cause of this is that this plugin has become my main testing ground for the Strider Core framework I’m designing — and in the course of abstracting out some of the repetitive code that goes in all my plugins, some oddities crept in.

Posted in Codecraft | Tagged , , | Leave a comment

Review: Dash for OS X

I recently discovered a very cool app for OS X called Dash. It’s basically an offline popup for any kind of programming or tech documentation you can think of. You can choose from a large number of coding docsets and cheatsheets — pretty much any modern programming language (sorry, no FORTRAN) and a good number of applications. You download them to your local drive so access becomes instantaneous. There are even modules to access the various topics on StackOverflow, with both online and offline versions. (I imagine the offline versions of those can get pretty big.)

Personally I’ve loaded up everything from the entire LAMP stack, to Vagrant, to WordPress, and cheat sheets for ASCII Tables and Regular Expressions. One module I’ve found particularly handy is one that lets you search and read local Man pages. Documentation installed with XCode is automatically included in the accessible content. (Even if installed, you can turn docsets on or off in the interface.)

There are even customizable search shortcuts: so if I want to search the PHP docs for the page on Arrays, I can simply type “php:array”. If I want to search within that page, I just hit space and keep typing, e.g. “php:array index”

The author has even set up a Git project so that users can submit their own Docsets or cheat sheets. I wanted a cheat sheet for MacPorts, so I made one. The author added it to the official list, so now the sheet I made is easily available to anyone who uses the app.

It’s worth mentioning that the author is also very attentive to support issues. I had a problem with the Man page module not searching all the Man pages installed on my computer. He responded quickly, and ended up helping me resolve issues that really went beyond the scope of his app.

Dash is surprisingly deep for what seems like a simple concept. The elegant search function, flexible sourcing, and integration with a large number of third-party apps make it a real winner. I can’t imagine going without it now that I’ve used it for a short while — simply outstanding.

If you work with computers a lot, and especially if you use the command line or do programming, I would highly recommend Dash. It’s worth checking out.

Posted in Codecraft, GUI Goodness, On the Front Lines | Tagged , , , | Leave a comment

Elegant Design: A Case Study

In the past I’ve discussed elegant UI design on this blog, commenting especially how the best plugin design is to integrate the plugin’s function in a way that the end user would never realize that what they’re doing comes from a plugin at all.  There was a trend in the earlier days of WordPress that plugin developers would all dump their interface screen under the “Plugins” menu in the Admin area, because — duh — it’s a plugin.  No, I argued — that’s exactly wrong.  Does your plugin do something with comments?  Put it under Comments.  Does you plugin affect the appearance of the site?  There’s an Appearance menu for that.  Is it purely a Settings screen?  Great — use the Settings Menu.

Today this seems like pretty basic stuff, and most plugin authors seem to get the idea.  But today I came across a particularly striking contrast between Old plugin design and New, and I thought it was worth mentioning.  The plugins in question are PageMash, by Joel Starnes, (last updated six years ago), and Simple Page Ordering, by Jake Goldman and 10up.

Both of these plugins serve the exact same purpose: they allow you to order your site’s Pages via drag and drop.

First, let’s look at pageMash.

I’ll start with the most obvious element of this plugin: had I not just told you what it does, would you have guessed what a plugin called “pageMash” does from the name?  I wouldn’t have.  This illustrates a quandary in software design — the struggle between giving your product a distinct name, and giving it a name that identifies its purpose.  That could actually serve as an entire post — if not a book.

So let us, for the sake of discussion, assume that the plugin name was well chosen.  The author, however, overused the name throughout the interface.  After activating pageMash, there is a singular addition to the Admin menu: under “Pages”, there is a “pageMash” menu.  Even if that’s a great name for the plugin itself, it is a poor name for a menu item — something that is meant to help users find what they’re looking for.  How about “Page Order” instead?

We click on pageMash, and are taken to a page with the following title: pageMash – pageManagement.  Well, I suppose “page management” does a little better job of telling us what the page does, but even at that point the unorthodox capitalization and spacing looks clunky and unpolished.  It’s a perfect example of an interface designed by a coder, because that type of capitalization and mushing-words-together is commonplace in code.  It even has a name: camelCase.  Programmers commonly use it for variable names and such.  I assume most people reading this know this already, but I don’t assume all my readers are programmers; which really just leads to my next point: camelCase would be perfectly fine, I think, if we could assume that all of the users of the plugin are programmers.  One of my own plugins — Log Deprecated Calls — is really only useable by plugin and theme developers, and probably only used in development environments.  Although I didn’t do it, such geeky conventions would have been a safer bet because of the audience.  But pageMash is exactly the opposite — you can assume the many (or most) users of that plugin are going to be writers and editors.  Not the admin installing the thing, but the people using it day-to-day, are likely to be non-technical “content” people. So this breaks the rule I mentioned previously on multiple levels.  From the menu to the page headers, the interface of pageMash screams “add-on”.  There’s just no way this is a part of WordPress itself.

Now, I realize I’m being hard on the developer, and I don’t really mean to be.  The plugin’s function — especially for its day — is quite excellent.  You have a list of pages. You drag and drop them into the order you want, and click the “Update” button.  There’s a short paragraph at the top of the page explaining this, and at the bottom of the page is a “Show Further Info” link that expands a longer help text.  It’s pretty straightforward, and it works.  Before this plugin came along, the only means I had to order pages in WordPress was to type numbers into a little blank next to each page in the list.  It was clunky and extremely tacked-on.  PageMash fixed that.

Now lest fast-forward several years.  Just today I discovered 10up’s Simple Page Ordering plugin.  Any guess what they called the menu item?

Trick question.  There isn’t a menu item.  The interface is so cleanly and tightly integrated into WordPress that you’d never guess it was a plugin.  You simply go to the normal Pages admin page, and you can drag and drop the page order right there.  Need help?  It’s integrated into the existing Help tab and the top of the page.  There’s not even a Save button. Drag, drop, done.

I’m reminded of Steve Jobs — arguably one of the greatest UI designers in the history of computing.  He famously hated buttons.  When designing new devices the first iterations always had buttons, and he’d come swooping in and get rid of them.  Think of the iPhone: there’s Power and Home — that’s it.  And it works, because the device is designed so that you can just look at it and figure out how most of it works.  It’s instinctive.

Simple Page Ordering accomplishes this same elegance.  It’s so beautifully designed and coded that there’s literally no interface beyond simply doing the thing.  “Gee… I want to move this page down.”  Click. Done.

I can’t think of a better example of the design principles all programmers should aspire to.

Posted in Codecraft, GUI Goodness | Tagged , , , , | Leave a comment

Log Deprecated Calls plugin 1.1.1

Hi again. Another bugfix update — this time for an error on new installs (didn’t affect people upgrading from an old version).

More to come. Still need to fix a bit of weirdness when saving prefs, but I wanted to get the install fix out ASAP, so here it is.

I hope to get this on the WordPress plugin repository fairly soon, but there’s some weird bit of politics I need to figure out first (which I may get into further on another post.) If it doesn’t end up in the repo, I do have preliminary work going on adding a self-rolled update mechanism that I hope will integrate seamlessly with the built-in WordPress system.

Go get it! …and enjoy.

Posted in Codecraft | Tagged , | Leave a comment

Update to “Log Deprecated Calls” plugin

I’ve released an update to my Log Deprecated Calls plugin for WordPress. This is the original plugin for plugin and theme developers to help you identify outdated functions you might be calling from WordPress.

Version 1.1 is out now. Note this is not (yet) in the WP repository, so it’s a manual upgrade. Fixed a couple bugs, including one that actually stopped the plugin from working somewhere between its last update and now — so if you use this, it’s an important update.

Go get it! And enjoy.

Posted in Codecraft | Tagged , | Leave a comment


This blog has been in a slump for the past couple years.  Or… Perhaps more of a hibernation.  What can I say? Life intervened.

At any rate, I’m back, and I’ve been up to a few things.  First and foremost, there are updates to multiple plugins.  Graceful Pull-Quotes and Quiz both have updates.  I expect to be doing some more work on these and other projects in the near future.

Strider Core has been resurrected and is back in business.  The possibilities intrigue me — I was unsure of things for a while, but I still think it’s a viable concept as an almost self-updating framework for plugins.  Let’s see where it goes!

Finally — I haven’t ever talked about it much on this blog, but some of you may be familiar with a plugin called Spam Karma.  It’s not my creation, but by a twist of circumstance I became one of the project owners when its creator decided to make it open source.  It hadn’t had much in the way of updates since that happened, but I intend to make some progress in that direction.  I’ve been interested in it for a while, but as I say… Life intervened.  Time to pop the hood and take a good look.  It’s a beautiful system and could use a tune up.

Stay tuned. Things are happenin’.

Posted in 'Nuff said, Webcraft | Tagged | Leave a comment

Salvaging ebooks from Stanza for iPhone or iPod.

I’m a long-time user of Stanza on the iPhone, so I was surprised and a bit dismayed to discover that Stanza does not work with the new iOS 5.

As much as I love the program, it’s always possible to switch to a different program, but I had a different problem: many of my ebooks had been downloaded directly within the app itself, and I didn’t have copies anywhere else. Some of these, in turn, were no longer available for download. (A good example of this are books from sites such as the Baen Free Library.)

I took a look at iTunes sharing as a possibility for rescuing the books, but Stanza doesn’t share the books for downloading from the phone. I then spent some time figuring out what did work, and here’s what I found:

First off, you need an app that lets you look at the file directory on the iPhone. I used an OS X app called PhoneView, though I have no doubt there are others. (Incidentally or not, my iPhone is NOT jailbroken!)

  1. Within PhoneView, select “Stanza” in the “Apps” list.
  2. Go into the .Stanza folder. (If it’s not visible, go into Preferences and check the “Show Entire Disk” checkbox.)
  3. Within .Stanza, your books are in the “Library” folder. Copy this folder to the hard drive of your computer.
  4. I’ve noticed that the directories can be shown a bit differently depending on the program you’re using to view them. to be clear: within Stanza’s directory, you’re looking for this folder: /Documents/.Stanza/Library/
  5. Quit PhoneView.

Okay, now you have a folder on your computer that contains a whole bunch of numbered folders: “0”, “1”, “2” and so on. These contains your books, which unfortunately are still a bit inconvenient. Your books are the files that have no extension, e.g. “30”. All you really need is to add file extensions to the filenames, but first you have to figure out what extension to add (and the name of the book is helpful too!).

What I did was to open the files in a text editor. (On a Mac you can use the free TextWrangler; on Windows, you might try the free Notepad++.) You’ll see a whole lot of gobbledegook, but the file format can probably be determined by text found in the first line of the file. Generally, the name of the book is ther very first thing in the file, or close to it.

  • If you see “epub”, or (in the case of TextWrangler) it opens up as an “xml container”, you’re looking at an Epub file. Close the file and add “.epub” to the end.
  • If you see “PNRdPPrs”, that’s a Palm Doc file. Add “.pdb” to the filename.

Stanza reads a whole lot of file types, although these are the only two I’ve encountered. Also likely are .mobi files, and I’ll update this article as I come across other format hints. But suffice it to say that after adding the file extensions, the files will work in another e-reader capable of reading that format.

I also use a program called Calibre to organize my ebooks, and conveniently it can also convert between formats — so if you want to put an Epub or Palm book on your Kindle, say, Calibre can convert it for you.

Posted in On the Front Lines | Tagged , , , | 2 Comments

How to Close a WordPress Site

I recently was asked to close down a site I had put up using WordPress. I didn’t want to just delete the whole thing, as I figured somebody might want it put back up in the future. There are several easy ways to do this, but I think I’ve found the best.

My first impulse was to add an exit; line to index.php. The problem there is that it doesn’t close off the wp-admin section. I could comment out the database password in config, but that leaves a “Could not connect to database” message. I wanted every aspect of the site gone. Then it struck me: One file that absolutely every single call to WordPress must pass through is wp-config.php.

So if you want to “disappear” a WordPress site quickly and easily, just open up wp-config.php and add the following right after the opening PHP tag:


If you want to put up some kind of “goodbye” message in HTML, you can do something like this at the top of that file:

?><!DOCTYPE html>
<html><body><p>This site is closed.</p></body></html>


Even more briefly, of course, you could stick a short message inside a die() statement. The HTML gives you a bit more flexibility though.

Hope somebody finds this useful. 😉

Posted in 'Nuff said, Webcraft | Tagged , | 10 Comments