With all the excitement surrounding Red Sweater’s acquisition of MarsEdit two weeks ago, it’s hard to believe there is yet another product rapidly approaching its public unveiling.

The name of the product is “Black Ink,” and it’s coming very soon! I just need to put some finishing touches on the registration system, and fix a couple small bugs. The image above is not the actual icon (thankfully) but the red pen comes directly from the shiny new icon, which is waiting patiently to make its debut.

Curious? I’ll give you a hint, it’s not a blog editor :) And it’s not a news aggregator. It’s a classy yet fun application, so it will fit perfectly in the Red Sweater lineup of products. I think it will be a good product to provide balance over the next several months to the work I’m going to be doing on MarsEdit. I’ll be putting a lot of time into MarsEdit, but also spending time on Black Ink and my other applications to “keep things fresh.” I find this kind of multi-tasking makes me overall a lot more productive.

Stay tuned!

I am aware that some customers are chomping at the bit to buy MarsEdit, but have not been able to do so because they don’t have a credit card. While most Americans can’t imagine life without one, they aren’t so popular in some countries.

So for all of you with PayPal accounts but no credit card, I’m pleased to announce that the Red Sweater Store now supports PayPal for purchasing MarsEdit. Go ahead and test it out :)

I’ve recently seen two bug reports about the behavior of the MarsEdit “Bookmarklet,” the little link that you can stick in your browser’s toolbar to easily “reblog” stuff that you find on the web. The gist of the problem is that special characters end up getting junked in transition so that they show up as useless parts of escape codes in MarsEdit. That’s no fun for anybody.

Following a lead from Takaaki, who reported one of the issues, I found what appears to be a sane workaround. The bookmarklet needs to use “encodeURIComponent” instead of “escape” to sanitize the input strings for the “magic URL” that sends the page to MarsEdit. (Read more about the various escaping mechanisms and when to use them).

The best part about these bugs is I can release a fix without updating MarsEdit itself. The behavior of MarsEdit seems to be perfect when the bookmarklet is altered to use the proper escaping function. So if you’ve run into this problem, please give the new bookmarklet a try:

Post with MarsEdit (drag link to bookmark bar)

And be sure to let me know if there are other issues which should be addressed in the bookmarklet for the next MarsEdit release.

Anybody running WordPress should be aware of the recent security breach at WordPress HQ, that caused a pretty troubling “tainting” of the 2.1.1 release distribution. The funny thing here is, if you updated to 2.1.1 early enough, or if you got the sources directly from the Subversion repository, you’re “safe.” Well, relatively safe. They apparently added some more security fixes to 2.1.2, so it’s a good idea to upgrade anyway.

If you run WordPress, you’ve probably discovered that upgrading can be somewhat tedious – especially if you have custom changes. The problem is you need to apply all the modified files to your blog directory, without destroying anything custom you’ve popped in there yourself. Assuming you haven’t modified any core files the process is a simple matter of updating the core files while leaving your custom files, e.g. themes and plugins, alone.

For a long time I did these updates by unzipping the release files directly to the affected directory. It turns out that the unarchiving process was “non-destructive” in the sense that it wouldn’t overwrite an entire directory just to update one file. So that worked pretty well. But then one day lurking in the IRC #wordpress channel, I learned a great tip, which is to use Subversion directly to export the release onto your blog directory.

I use Subversion myself for all my web files, so it’s easy to “play with fire” and run a command like this:

svn export --force http://svn.automattic.com/wordpress/tags/2.1.2/ ./

What this does is spray all the files from a particular release (in this case 2.1.2) into my blog directory. Since I’m also running svn, I then have the luxury to “svn status,” “svn diff” etc, and compare the changes. I then test the upgrade and commit the changes to my personal svn repository when everything looks OK.

This technique has essentially cut my “time to upgrade” for WordPress down to about 2 minutes – and I don’t have to deal with downloads, packages, etc. The only downside I can imagine is that if WordPress removes a file, I’ll have a stale copy of it. I suppose I should look into an improved technique that would consider this – but it hasn’t been a problem yet.