One such advantage I noticed is that Squarespace users can log in from any page on their blog, just by pressing the escape key.

By default, WordPress requires that you either memorize the admin page URL, or list an ugly “Login” link i the blog’s template. I never liked the idea of having a login link for a site that only I should ever be logging in to, so for years I have omitted the login link from my site.

This means that when I’m reading comments or something on my site, and am not logged in, I have to do a silly dance before I respond or moderate a comment:

1. Go to the URL bar in my browser.
2. Change URL to /wp-admin/
3. Enter the proper login credentials.
4. Hit back button to get back where I was.
5. Reload the page to see the comment form as a logged-in user.

This ends today. My QuickLogin Plugin for WordPress is a drop-in solution that, when activated, gives your WordPress blog the same delicious escape-key behavior that Squarespace offers. Now when I am browsing my own blog and want to log in, I just press the escape key. After I authenticate, I’m automatically returned to the reloaded page I was viewing.

There are good arguments for this, at least on the face of things. They can be packed into a nutshell: it may reduce the security risks of having these access points opened by default.

But in my opinion, there are also good arguments to be made for rejecting the change as a damaging and misguided solution.

First, and obviously near to my heart, is the fact that this marginalizes remote clients. For users who would find value in a remote client, this decision will put one more roadblock in their way. Historically, the remote editor interface is already compromised such that remote editors do not have access to all the same functionality as the web interface. With this change in place, things get even worse. While a screen-scraping application will easily log in and authenticate a fragile WordPress session via the web interface, the well-behaved API clients will be refused access by default. All in the name of improving security.

Second, and probably most important, is that this is not a fundamental security improvement. Consider a bank with two sets of automated cash machines: one for drive-through cars, and one for walk-up pedestrians. Two vastly different sets of customers are being served securely by different interfaces, yet the transactions are secure because they ultimately travel through the same bottlenecked safeguard. A fundamental design consideration on the part of the bank is that these two classes of customer are equally important, and each deserves unfettered access.

WordPress’s decision to shut off remote access by default is analogous to a bank offering unrestricted drive-through access to its cash machines, while requiring pedestrians to ring a bell and wait for a security guard to open the door to the machines.

Also worth considering: if a service is disabled by default for security considerations, what message does that send to people who choose to, or who are encouraged to turn the service back on? It sets up a perception of insecurity which may not even be warranted. If the remote publishing interfaces are insecure, they should be fixed, not merely disabled!

A Real Solution

If I’m so smart, what should WordPress be doing instead? A real security improvement would be bottlenecking all access to the blog’s vital authorized content, and making sure that the remote APIs and the web interface all go through the same interface.

In my opinion, an entire class of problems with WordPress (and other blogging systems) stems from this interface bifurcation. Establishing a single interface to WordPress would be comparable to the “pin code + card” interface at your bank. You pass through it by car, on foot, and even at the counter when they ask you to swipe before doing any transaction.

If you’ve only got one “real API” that touches the critically important data, then you’ve only got one door to secure. Furthermore, when all views into the blog are required to share the same API, suddenly none of them is deprived of functionality that the other has.

Imagine if the API that the web interface uses to access all features of a blog could be just as easily employed by MarsEdit or any other application you authorized. The end result would be lots less work “playing catch up” for the XMLRPC and Atom developers, and more time focusing on innovative and cool features for all blog users.

If this sounds like a pipe dream, it’s worth pointing out that one very popular web service is already employing this strategy, and it works brilliantly. Flickr, Yahoo’s incredibly popular photo sharing site, is built on the very same APIs it makes available to clients. This results in some truly incredible Flickr-enabled applications and web services. And you don’t see any sign of Flickr disabling access to their API, because there’s too much at stake.

If your web service only provides one, first-class API through which all access flows, then you’ve only got one point to secure, you’re likely to have feature parity across interfaces, and the risk of marginalizing one interface is dramatically decreased.

I noticed over the past few weeks that even though I had updated to the latest WordPress release, which is supposed to be free of vulnerabilities, I was repeatedly having spam links injected into the footer.php file in my theme. Frustrated, I went to some of my friends on the WordPress team, and they pointed me at a great article from Donncha O Caoimh:

Unfortunately for some who did upgrade, it was too late. The hacker slimeballs may have known about the security issues before we did and went about their merry way breaking into blogs and websites, grabbing usernames and passwords, and planting backdoor scripts to log them in again at a later date.

In this article, Donncha gives an extremely thorough and authoritative treatment of the problem. If you have been the victim of this nasty attack, or even if you don’t know whether you have, it would be worthwhile to review the article and see how your WordPress install stands up to the scrutiny suggested there.

In my customer support for MarsEdit, I have been seeing these security problems pop up quite a bit lately. The so-called “spam injection” attacks often inject spam links at the oblivious expense of how these links might mess up the XMLRPC interface which blog clients such as MarsEdit use to interact with your blog. It’s gotten to the point where error messages from the blog such as “Parse error. Not well formed.” are almost certain to be symptoms of such a spam injection attack. Updating to the latest WordPress almost always fixes the problem immediately.

Matt’s advice is pretty basic: update to the latest WordPress, and check your posts for signs of tampering. But it’s nice to have advice “from the top,” so to speak. I will be glad to see this wave of blog-attacks pass us by as more and more users get updated to the latest release of WordPress.

I commented on the post, suggesting that what WordPress would really benefit from is some kind of automated updater, so that users can easily update without having to worry about whether they’re doing it right or whether they’ll mess up their blog. The great news is Matt replied saying that they are in fact working on such a feature for 2.6.

Looking forward to a built-in automatic updater for WordPress! But in the mean time, be sure to stay current so you avoid the nasty attacks that are going around.

There are loads of changes, which you can read about in the announcement blog post. Among the most interesting changes for MarsEdit users is the addition of more intelligent “post status” information for blog editor clients. Practically speaking, this means the problems I described in my MarsEdit 2.1 announcement will no longer be an issue for WordPress 2.5 users.

But… Ugh, it looks like I messed something up and MarsEdit 2.1.2 doesn’t accurately detect these statuses on WordPress posts. I will try to get a 2.1.3 out soon that fixes this so we can put the post status problem with WordPress behind us for good.

Recently there has been an increase of new MarsEdit buyers who cite as their motivation a frustration with the WordPress web editor. I respect and admire the WordPress team. In fact, their web interface is among the best out there. But even in the best of circumstances, it’s hard to compete with the usability of a desktop app. And when something goes bad, it becomes downright impossible.

Currently the situation is especially bad for people who use WordPress with Safari. For whatever reason these two pieces of software have fallen slightly out of accord. It’s common to hear tales of people who use Safari for “everything but WordPress.” In short, WordPress has a reputation for messing up or even eliminating parts of your post when using the web-based editor in Safari. I know, because I see the comments of my customers and would-be customers on the web. There is a chorus of confirmation for this problem.

I look forward to WordPress and Safari ironing out their differences. I don’t relish earning customers purely out of frustration with the competition. I prefer to attract customers by exceeding baseline functionality than by my competitors failing to meet it. But if you’re tired of doing battle with the WordPress editor in Safari, or any other browser for that matter, it’s a good time to remember that MarsEdit is here for you.

I welcome those users who arrive out of desperation, and am hopeful they will find much more than baseline functionality to be delighted with in MarsEdit.

Update: Lloyd Budd, who is the quality lead for WordPress, has coincidentally written today on the very subject of Safari and WordPress. He predicts that major improvements are in store with WordPress 2.5:

“With Safari 3 and WordPress 2.5 you should finally have a great experience if Safari is your preferred browser.”

This is great news for everybody. I think your experience will be greater still in MarsEdit, but happy WordPress customers are great for the blogging industry in general.

Update 2: For some reason this post ended up with comments disabled. I don’t know yet if it’s a bug in MarsEdit, WordPress, or the author. I have enabled them, now. I welcome your opinions!

I have been happily using WordPress as the infrastructure for this blog since its inception, almost one year ago. Since I’m perhaps slightly geekier than than the average WordPress customer, I have been wanting to get to know the sources a bit better and possibly make my own tweaks or write plugins to suit my particular needs. I also like to keep up to date with the latest versions of the software. The problem is that these activities are at odds with each other. See, if you don’t tweak anything, updating is a simple matter of “un-tarring” the package file over your existing installation and visiting the “update.php” URL. But if you’ve made any sneaky changes, you’re liable to overwrite them when you clobber a source file with the updated version.

This situation has led me to an unfortunate state of moaning about having to install WordPress updates. This is bad, because often the small updates contain security fixes, which are exactly the kind of thing I should want to install immediately. Furthermore, I’d like to stop editing WordPress with vi on the server, and searching the source base with grep. I’m proficient with these tools, but I have a Mac! It’s better at such things.

I need absolute WordPress control. Specifically, I need to be able to:

1. Install WordPress updates with ease and confidence.
2. Hack on WordPress and test results on my Mac before updating the live blog.
3. Do so in a way that meshes with my regular work habits.

How do I address this? The problem screams for Subversion and Xcode, so that’s what I will throw at it. By integrating my WordPress hacking with Apple’s Xcode, I can treat the technical underpinnings of my blog just like I would any other code project. I spend so much of my day “building and running” that it’s distracting when any technical project does not fit in with that process.

Step 1: Get Things Under Control

Source control, that is. I decided that I needed a single repository where both my live web site and local Mac could access the same WordPress sources. That means I need an SVN server accessible from both locations, as well as Subversion client tools in each location. Luckily DreamHost comes standard with Subversion support (minor gripe: they’re stuck on version 1.1!). If your web host doesn’t offer Subversion, you might be out of luck for this particular round of magic.

Typically with Subversion repositories, the “mainline” of the project is identified as a subdirectory of the repository called “trunk.” In my case, I don’t control the mainline of WordPress, so I’m choosing more clear identifications. My repository is “all branches,” if you will, so I’m not including any folder called trunk, though “official” is the closest thing to being that:

% svn ls file:///home/jalkut/svn/opensource/wordpress/
hacking/
official/
redsweater/
redsweater-assets/

What I’ve done here is take advantage of the “smart copying” in Subversion. I started the repository out with “official,” containing the latest 2.0.3 release of WordPress. I then copied that in the repository to “redsweater” and carefully copied all of custom bits and pieces in. If you do this right, only the customized parts take up repository disk space. Everything that’s the same is shared in the database. The custom bits include the database configuration, custom themes, installed plugins, images, etc.

Where possible, I took advantage of a feature in Subversion called “svn:externals.” This lets you specify points in the project hierarchy that, when encountered, will trigger a checkout from a different repository. It’s sort of like an NFS Mount-Point right in Subversion. In the mysterious “redsweater-assets” repository folder above, I’ve added folders for most of my custom elements. So when I checkout “redsweater” and Subversion gets down to the “themes” section, it notices that it needs to checkout my custom theme from the redswetaer-assets/themes repository folder. This technique works great in almost every area of WordPress, except for the plugins directory. Because svn:externals can only specify a directory, it breaks down when one would hope to use it to plop individual files down into a checked out directory. I imagine this limitation comes from the fact that every folder in a working directory has a single “.svn” folder for tracking the entries at that level. Therefore, a directory of assets from mixed repositories would be tricky.

Even with the svn:externals shortcomings, the setup works pretty well now. I have a “redsweater” branch that I can integrate changes into, and then update my web site directly from the command line. At any time, I can examine the differences between my customized branch of WordPress and the official release I last integrated with. Comfort!

Step 2: Integrate with Xcode

The Subversion infrastructure goes a long way toward calming my nerves about integration and updates. I can carefully stage any update by first updating and testing it on my local machine. That’s cool, but it’s not really good enough. I want to be able to hack the heck out of it on my local machine (Note: You need to install a PHP-compatible Apache server before you can really do this on your Mac). Furthermore, I want to possibly be able to maintain a separate, highly experimental copy of WordPress for days, weeks, or months while I continue to serve (and perhaps update) the more stable version of the blog from my site. It’s time to look at the “hacking” branch that I hinted at above.

The hacking branch started life as a copy of the redsweater branch. I want it to closely mimic my real blog, but I want to have freedom to mess around with it big time. So the first thing I altered after copying the branch over was the wp-config.php. Instead of pointing to my live database, I pointed to a local MySQL database on my Mac (yet another custom install, sorry!). This database contains a subset of my live blog’s content. The idea is it’s a totally safe sandbox for me to work in. I can add comments, posts, pages, etc. I can delete everything and start from scratch. I can even post drafts of my entries from MarsEdit to see how they’ll really look when they finally go live. The ultimate preview! One of the things I’ve noticed so far in hacking on WordPress is that I need to provoke different situations before I can play around with the behavior. For instance, if I want to tweak the spam-filtering behavior, I have to first cause a spammy comment to appear on the blog. I don’t like doing this on the live blog, but fake spam comments are fine in my sandbox.

What else does the hacking branch contain? This is where it gets fun. The branch contains an Xcode project file, and supporting shell scripts to facilitate a streamlined development process. First I added all the WordPress sources to the project, for easy global search & replace. It’s amazing how much faster you can get to know the project when you get a “birds-eye view” from Xcode:

I find that I understand a project much better even by doing simple tweaks like globally replacing something so that it behaves differently. When I can observe the changes, it connects my test changes to the project’s design as a whole.

Next up I attacked the problem of “fixing the workflow.” What does it mean to “build & run” a WordPress project in Xcode? I decided that building WordPress means “copying the files into my local web server directory,” and running it means “opening a suitable URL in my web browser.” To that end, I added a single target to the Xcode project, “Install Local,” which is a simple copy files build phase target. It takes all the specified files and plops them over to the “blog” subdirectory of my local test server:

Sweet! Now when I want to try out my changes, I can just press Cmd-B to build and then load up my localhost URL in Safari. But the scenario isn’t quite complete. When I build an application in Xcode, I don’t have to navigate to the Finder, find the resulting product, and double-click it. Why should I have to go manually reload this web page? With Xcode custom executables, I don’t. I added a couple shell scripts to my “hacking” tree that, when specified as custom executables, simply cause the local blog to open up in the default browser. This trick is accomplished with some simple AppleScript bridging:

#!/bin/sh
osascript -e "open location \"http://localhost/blog/\""

For every commonly debugged location in the blog, you can just pop another custom executable into the project with a slightly different blog URL. Then you select the desired executable from Xcode and “run” the project to see how your results are shaping up.

Now I can make changes, build, run, examine the results, and even use Xcode’s built-in Subversion features to review what I’ve changed!

If you want a head start at making your own WordPress hacker’s paradise, you can download and plop my WordPress Xcode Project files into your own local WordPress “hacking” directory. It should work just fine with a standard 2.0.3 copy of the sources. The archive includes the Xcode project itself as well as a couple example “executable” scripts.

I have been pumping up DreamHost since I moved over to them a couple weeks ago. They’re still awesome, but the honeymoon did end a little bit when I got an email from them notifying me that I was exceeding my daily CPU usage allotment. Hmm? I had never even considered this before. I guess I just took for granted that servers were good and fast and they made it all work. I didn’t consider that with a virtually unlimited bandwidth quota, I would have to watch my step with how hard the server was working to fill that pipe.

I’ve been oblivious to web performance considerations, for the most part. This wake-up call from DreamHost inspired me to finally take the problems by the horns. When your site only gets a half-dozen hits per day, who cares how well it performs?. But as my traffic continues to increase, I’m starting to look at things more and more like a webmaster.

Some time ago I was chatting with John Gruber about the merits of WordPress vs. Moveable Type. He pointed out that WordPress, with its dynamic content generation, was a lot less likely to stand up to a major traffic burst than Moveable Type with its static generation. Frankly, it was the first time I’d even considered the issue – and it scared me so much it almost made me want to jump ship from WordPress. How could it be so inefficient? Basically every WordPress blog comes standard with a complete and utter inability to stand up to being slashdotted? Given the amount of traffic Daring Fireball must receive, it’s no surprise that John’s thought about this problem a lot.

But what was I going to do? Switch from WordPress? Please, no! Thankfully, the amazing WP-Cache WordPress plugin basically fixes all that. By saving a static copy of every dynamically generated request response, it achieves the best of both worlds by allowing content to be dynamically generated, but letting it stick around for a while on disk for future servings. Today I installed and activated the plugin. When the cache is on, every request that is answered gets appended with an HTML comment describing whether the request was cached or dynamically created, and how long the original dynamic creation took. I was curious to know how much time I was saving on the cached copies, so I hacked the plugin to also print a timestamp when the cached version is served. The results are pretty impressive. For example, on one entry I just looked at from my browser:

<!-- Dynamic Page Served (once) in 0.453 seconds -->
<!-- Cached page served by WP-Cache in 0.002999 seconds -->

In other words, it went from almost a half-second to almost no time at all. A huge reduction, most of which I assume would be spent as CPU time in the dynamic case. Curious about whether the cache saved you any time just now? Just look at the source for this web page or RSS feed, at the very bottom you’ll see a comment about the dynamic generation time. If it was cached, you’ll see a second comment about that. I haven’t exactly figured out everything that stimulates a cache flush for a particular URL, and it’s possible that the flushing is a little overly-cautious, but at least it’s not serving stale data.

Being so pleased with the caching success, I was in the mood to keep improving things. A reader pointed out a problem a couple months ago, which I’ve been meaning to look into. They had installed the latest beta of NetNewsWire and noticed in that application’s “Bandwidth Statistics” window, my blog was at the top of the heap for bandwidth used. The problem? A combination of my notoriously long posts, a fairly large “item count” for the feed, and a flaw in WordPress 2.0.2 that causes it to not properly return 304 (Not Modified) responses to clients who ask politely whether there have been any changes. So every time NetNewsWire refreshed, it would grab the full text of my last 10 posts!

Today I searched the web and found out that the 304 issue was in fact addressed, and the change is so simple I could type it in to the sources myself. Yee haw! I made the change and rushed over to NetNewsWire to try it out for myself. Alas, it still wasn’t working. The problem now? WP-Cache doesn’t seem to have any mechanism for supporting such a response, and since it essentially “takes over” when serving a cached copy, WordPress never gets a chance to respond. I’m not 100% sure I did this right, but I managed to hack up the WP-Cache plugin so it looks for the “If-Modified-Since:” header and, if it the specified date is not earlier than the cached copy, returns a 304 response. Seems pretty straightforward, but I’m nervous enough about it that I’ll postpone sharing the code until it’s had a chance to simmer.

These changes should have a positive effect on both my bandwidth (for whatever it’s worth) and CPU usage. But more importantly to you, they mean faster page loads in your browser, and faster subscription refreshes in your aggregator. And hopefully I’ll fall out of first place in your NetNewsWire bandwidth abusers list!

Update: My changes to WP-Cache seem pretty stable in that they’ve been running on my blog for a week or so. If anybody is interested you can download the modified file here. The only change is to the phase1 script. The mods add support for 304 responses even on cached items, and for printing the elapsed time of page load even when cached.

Let me know if you have any feedback!

Update: If you are using PHP5, you will want to make a minor tweak to WP-Cache to fix a “blank pages” bug. See this page for more information.