Blogger Auto-Configuration Failures

June 19th, 2013

Recently something changed in the format of Blogger blogs such that MarsEdit’s method of “auto-configuring” is now failing. This does not affect existing configurations in MarsEdit, but any new Blogger blog added to MarsEdit will fail to connect with a cryptic “Invalid Blog ID” error.

I’ve added a workaround of the problem to the Red Sweater Forums. The long and short of it is the “API Endpoint URL” and “Blog ID” fields in MarsEdit’s configuration need to be manually corrected.

I am working on a permanent fix for the next update to MarsEdit.

Squarespace 5 Workaround

May 7th, 2013

As I noted last year, when Squarespace released version 6 of their popular web hosting service, they opted not to continue supporting 3rd party blog editors such as MarsEdit.

Luckily for fans of MarsEdit who were already hosting with Squarespace version 5, they left support in place, and it has remained mostly functional for the past several months.

A few weeks ago, the API support for Squarespace 5 stopped abruptly, but then resumed. Last week, the service stopped again, and has yet to be restored.

I have been in touch with Squarespace through their regular support channels, but they do not yet seem to appreciate the scope of the problem. In short: all Squarespace customers who rely upon 3rd party editors (not just MarsEdit) that use the API interface, were met with a sudden stoppage of functionality for those apps. The reason? The API through which the service is provided suddenly stopped working and instead redirects to a 404 landing page:

To seamlessly restore API service for all Squarespace 5 customers, they need to “flip the switch back on” for this API, so that it connects customers with 3rd party clients in to their sites.

Squarespace’s customer support team has been patient while I try to explain the scope of the problem, and did share with me a workaround that I believe will allow all MarsEdit customers to “fix” their configurations in MarsEdit, regardless of whether they ultimately decides to fix the problem for all customers. To get things back to normal for your Squarespace 5 blog in MarsEdit:

  1. Open MarsEdit
  2. Click the Squarespace blog icon in MarsEdit’s main window.
  3. Select Blog -> Edit Settings from the menu bar at the top of the screen.
  4. Change the API Endpoint URL to:

    Note that this is identical to the malfunctioning URL with the exception that the “www.” has changed to “five.”

  5. Close the settings window and Refresh the blog to confirm it works.

Note that because of another nuance of Squarespace’s API, if you are configuring a Squarespace 5 blog from Scratch in MarsEdit, you will be met with a confusing error message when it first tries to connect: “Internal Server Error.” This indicates that you need to manually enter your username and password. Select the blog in the main window again, and then choose Blog -> Enter Password from the menu bar.

Fire & Forget Scripting

May 3rd, 2013

It’s hard to believe FastScripts is just over ten years old. When I first started developing the app, one of my primary goals was to improve upon the relatively slow launch and execution time of scripts when using Apple’s own built-in script menu. At the time, my analysis suggested that the sluggishness was primarily due to the time spent loading the script from disk into memory, and in launching a separate helper app to carry out execution of the script.

To avoid this slowness, FastScripts adopted a strategy in which scripts are loaded into memory once, and kept ready to fire again at a moment’s notice. This, combined with support for global and application-specific keyboard shortcuts, opened a whole new world of opportunities for streamlining workflows with frequently reused scripts.

The approach comes with some drawbacks, however. For example, FastScripts can only run one script at a time. So if a script takes a long time to finish, it can be very frustrating to be locked out of the ability to run other scripts. Another issue is that occasional issues with Apple’s AppleScript support make it possible for a script to hang indefinitely or even crash. If this happens in the context of FastScripts running a script, then obviously it’s FastScripts itself that ends up hanging or crashing.

For a long time I have considered the possibility of changing FastScripts so that it runs scripts in a separate process. It already does this by necessity for shell scripts such as Ruby or Python, but I have clung to the belief that doing so for AppleScript would eliminate one of the app’s major advantages.

I use FastScripts myself to run a variety of extremely terse scripts. For example I have scripts that open favorite web sites, activate specific applications, or simply play and pause iTunes. It would be extremely frustrating if any of these scripts exhibited even a slight delay.

I am no longer convinced that the decade-old strategy of avoiding on-the-fly loading and running of scripts is providing any significant performance advantages. Macs have gotten faster in so many respects: faster RAM, faster disks, and faster and more numerous CPUs.

I have been experimenting myself with a version of FastScripts that runs every AppleScript in a separate process, and have experienced no noticeable delays. And now when I do occaionally run a script that takes several seconds, or even minutes to run, I can fire it off with FastScripts confident that it will be ready to immediately run another script.

If you are a FastScripts user and this sounds intriguing, the good news is you can try it out today. Just make sure you’re up to date with version 2.6.5 from the Mac App Store or direct from the FastScripts home page. Because I’m still tentative about the performance, by default FastScripts continues to run scripts with the old, in-process behavior. To enable the new separate-process functionality, just set this “secret” preference key in the Terminal:

defaults write RSScriptingPreferSeparateProcesses -bool YES

If you do try this out and you also find performance is unaffected, please let me know in comments below. On the other hand, if you see a significant slowdown, that would be useful to know as well. And in case it’s not obvious, you can revert to FastScripts’s old behavior by re-running the line above with “NO” in place of “YES”. I will consider defaulting to separate-process execution in a future update, assuming performance is good across the board.

In adding this functionality to FastScripts, I also considered that performance might not be great for all users, but there would nonetheless be cases where running a separate process would be preferable. For example if you have one script that you know will always take a long time to complete, you might want FastScripts to only bother with a separate process for that script. You can instruct the app to run it in a separate process by implementing a custom AppleScript handler in the script itself:

on redSweaterScriptingPrefersSeparateProcess()
	return true
end redSweaterScriptingPrefersSeparateProcess

Now when FastScripts runs the script, you won’t have to wait around for it to finish. Just fire and forget!

MarsEdit 3.5.9: Significant Bug Fixes

April 5th, 2013

MarsEdit 3.5.9 is now available. This is a free update for licensed MarsEdit customers. The update will be submitted to the Mac App Store today and will be available there when Apple approves the update.

This is quite a significant update, in spite of it being entirely composed of “bug fixes.” I’m still working a major update to MarsEdit that will accommodate the Mac App Store’s sandboxing requirements. Until that is ready, I’ll keep fixing bugs in the app but will not be able to add significant features.

MarsEdit 3.5.9 changes:

  • Fix a bug from 3.5.8 that disabled draft support for Squarespace 5
  • Fix a bug where uploaded images were not resized correctly on Retina Macs
  • Fix a bug where the preview window could sometimes show the wrong blog’s theme
  • Fix a bug that caused malfunctioning Screen Capture and Image import services in rich editor
  • Fix a bug that caused unpredictable behavior with Paste contextual menu item
  • Fix a bug that prevented URLs with apostrophes from being linked in rich text mode
  • Fix a bug that could lock up the app if close box clicked on authentication panel
  • Fix a bug that prevented favicons from being downloaded from some blogs
  • Fix a bug where switching quickly to HTML Text mode after opening a post could clear the content
  • Fix a bug where images would sometimes fail to load in main window preview
  • Fix a bug where unchecking all categories for a post would not update categories correctly
  • Fix a bug where ExpressionEngine authentication failures did not prompt the login panel to appear
  • Fix a bug where the last change to an image’s name or size did not “stick”
  • Fix a bug where some errors would display as simply “(null)” instead of with meaningful text
  • Fix a crashing bug that could occur while editing the preview template
  • Fix a bug that caused drawing defects in some preferences text fields