MarsEdit 4.0.2: Minor Bug Fixes

December 12th, 2017

Since I released MarsEdit 4.0 last week, I’ve been grateful that no major issues have been reported. A few minor issues have been reported, and I decided to release an update now to get those problems ironed out before too much time passes.

MarsEdit 4.0.2 is available for download from the MarsEdit home page and the Mac App Store. The version jumps from 4.0 to 4.0.2 for direct-download customers, because some quick Mac App Store-specific fixes warranted a version bump last week.

Here is the list of changes common to MarsEdit 4.0.2 in both the Mac App Store and direct release versions:

  • Revise toolbar popup menus to use the same rounded button style as other buttons
  • Fix a bug that caused some error sheets in the main window to be presented in wrong location
  • Fix a crash that could occur if preferences are not writable for some reason

One fix applies only to the direct download version:

  • Fix app registration URL handling so it works even when the app was not already launched

And one fix applies only to the Mac App Store version:

  • Fix a bug in which validating an app for discount upgrade could spin forever

Let me know if you run into any problems with the update!

MarsEdit 4 Is Here

December 5th, 2017

Big news today: MarsEdit 4 is out of beta and available for download from the MarsEdit home page and the Mac App Store. This marks the end of a long development period spanning seven years, so it’s a great personal relief to me to finally release it. I hope you enjoy it.

MarsEdit 4 brings major improvements to the app including a refined new look, enhanced WordPress support, rich and plain text editor improvements, automatic preview template generation, and much more. Read more here:

What’s New in MarsEdit 4.

MarsEdit 4 also brings a new sales approach that aims to unify the trial, purchase, and upgrade experience between the Mac App Store and direct-licensed versions of the app. The app is free to download and can be used full-featured for a 14 day trial period.

After the trial expires, all features of the app continue to work except for actions that update published content on the web. This ensures that all of MarsEdit’s powerful offline features, including download/archiving of posts, can be used in perpetuity for free.

Anybody who purchased MarsEdit 3 on June 1, 2017, or later, is entitled to a free update to MarsEdit 4. Anybody who purchased MarsEdit 3 earlier than June 1 is entitled to a discounted $24.95 upgrade. This applies to Mac App Store users as well! Because MarsEdit 4 embraces the Mac App Store’s in-app purchase model, the app can use a downloaded copy of MarsEdit 3 to validate a discounted or free upgrade to MarEdit 4, as appropriate.

There’s a lot to say about MarsEdit 4 and I’ll talk more about the improvements in separate blog posts after the dust settles. In the mean time, I hope you download the app, enjoy the work I’ve done, and if you’re feeling generous, help spread the word about the release.


MacOS High Sierra Support

September 26th, 2017

I have tested all Red Sweater’s apps against macOS 10.13 High Sierra, and as far as I am aware there are no issues. All of my apps are compatible with the update. Enjoy!

WPEngine Authentication Issues

August 24th, 2017

Over the past few months I’ve received a handful of support inquiries from MarsEdit customers who have trouble logging into their WPEngine-hosted WordPress blog, after initially typing the wrong username or password into MarsEdit’s authentication panel.

Normally when MarsEdit tries to connect to a blog, it reacts to authentication failures by putting up a simple panel prompting for a username and password. In some cases, where the authentication challenge seems to be coming from a higher level than the blog itself, MarsEdit prompts with a different panel, suitable for supplying HTTP protocol-level authentication.

MarsEdit distinguishes between WordPress-level authentication and HTTP-level authentication by the simple fact that WordPress always returns HTTP status 200, even when a user is authenticated. The failure to authenticate is expressed in a valid XMLRPC response, and since the response is valid, it warrants a 200 “Success” HTTP status result.

In the process of debugging this problem, I observed that some of my customers were getting authentication failure responses from their self-hosted WordPress blogs, in which the HTTP Status Code was not 200, but 403 instead. Slowly, but surely, I came to understand that each of these affected customers was running on WPEngine.

Finally, with the help of a customer who shared my eagerness to get to the bottom of the problem, I was able to trace the behavior to a custom WordPress that is installed by WPEngine on behalf of all of their customers. It’s called the “wpengine-common” plugin. My customer was kind enough to send me a copy of the plugin files from within his WordPress installation. Guess what I found inside the plugin?

function wpe_login_failed_403() {

	// Don't 403 when the login comes 
	// through an Ajax request
	if ( defined( 'DOING_AJAX' ) && DOING_AJAX ) {

	status_header( 403 );
add_action( 'wp_login_failed', 'wpe_login_failed_403' );

This bit of code overrides the standard WordPress login failure, forcing a 403 status code when one occurs. From what I can gather, the intent is to raise the visibility of WordPress login failures so that security packages that monitor for attempts to break into sites can log the attempts and potentially warn users and/or WPEngine about the risk of an intrusion. That’s a great motive, but it has an undesirable consequence for clients of the WordPress API.

Any client of the WordPress API is liable to interpret a 403 status code as an authentication failure outside the scope of WordPress itself. It may assume there is no blog at all to connect to, or it may assume as MarsEdit does, that there is a second level of authentication required to gain access to the server, before gaining access to WordPress.

I don’t know what the ideal solution to this problem is, but it would be nice if WPEngine found another way to flag the potentially suspicious login attempts to their WordPress installations, that didn’t involve breaking the contract for how the WordPress XMLRPC API is supposed to behave. If you look again at the source code excerpt I pasted above, you’ll see there is a special case in place for “Ajax” requests. Presumably this is another use case where the unexpected 403 status response has caused trouble. In fact, if you Google for “wpe_login_failed_403”, you’ll find a number of simple WordPress plugins whose whole purpose is to disable the WPEngine 403 status behavior described here.

I am planning to work around the issue in MarsEdit somehow, but in the mean time if you are a WPEngine customer who also uses MarsEdit, you may run into problems when/if you enter your credentials wrong, or you try to connect again from MarsEdit after changing your password. You’ll see a different login panel speaking of things such as “second level of authentication”. If you run into this, you can get back on track by manually entering your correct username and password:

  1. Click the blog in the left-hand side of MarsEdit’s main window.
  2. Hold the option key down while clicking the “Blog” menu item at the top of the screen.
  3. Select the “Enter Password…” menu item.
  4. Enter your correct WordPress username and password.

As long as the username and password that are stored by MarsEdit in the keychain are correct, you should be able to connect to your WPEngine-hosted WordPress blog without any issue. Whenever they are incorrect, until I implement a workaround, or until WPEngine changes their plugin behavior, you will need to work around the problem in this manner.