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:

http://www.squarespace.com/process/service/PostInterceptor

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:

   http://five.squarespace.com/process/service/PostInterceptor

   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.

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 com.red-sweater.FastScripts 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 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

Enjoy!

Michael B. Johnson wondered out loud on Twitter about the possibility “focusing” on a single calendar in Apple’s default Calendar app for the Mac:

In Calendar on the Mac, is there a way to “mute” or “invis” all calendars but one? I have a sparse calendar, and many non-sparse ones…

— Michael B. Johnson (@drwave) January 16, 2013

In a nutshell, he wants to be able to go from his “usual” setup to zeroing in on just one calendar, and then back to the usual setup.

Folks chimed in with suggestions that almost hit the nail on the head, but not quite. For example if you hold the command key while clicking the enabled checkbox next to a calendar, it will toggle all your calendars on or off. So getting to the state of focusing on just one is fairly routine: just toggle them all off and then click one back on.

The problem is when you’re done focusing on the one calendar, unless your usual configuration is to leave all calendars checked, you’ll have a tedious task of checking each of the (possibly many) calendars you want to enable again.

This is a strictly theoretical problem for me, because I only have a few calendars, and frankly I don’t use any of them all that much. But Michael says he has around 25 calendars, about 20 of which he keeps enabled routinely. That could certainly get annoying!

When I see a problem like this that seems “unsolvable,” I become very curious whether there is a scripting based solution. Unfortunately the AppleScript dictionary for Calendar doesn’t seem to expose the “enabled” attribute of calendars. You can access the color or title of a calendar, but not the equivalent value of clicking that checkbox next to the calendar’s name.

I found a marginal solution in GUI Scripting, which I can use to inspect the various rows of the Calendars source list, to determine whether a named calendar is enabled or not, and to toggle its checkbox based on my own criteria. If this is the kind of thing that interests you, you might want to give the solution a look. Note that the script is designed to work on Mac OS X 10.8, and apparently does not work well on 10.7.

Click to download Toggle Calendar Focus.

What happens when you run the script?

If there are two or more calendars selected… the script assumes that you want to focus in on the single calendar that is highlighted in the Calendars source list. It checks the box for that calendar and unchecks all others. Before doing this it saves the names of all checked calendars to a temporary file.

If there is only one or no calendars enabled… the script assumes you would like to toggle “back to normal.” That is, it systematically checks the boxes next to all the calendars that were saved off above, and unchecks all others.

So in practice, you would select a calendar to focus on, and run this script to turn off all other calendars. Then, when you’re ready to go back to normal, just run the script again.

There are a variety of tools for running scripts like this but naturally I recommend my own FastScripts, which is free until you want more than 10 keyboard shortcuts. If you put the script in the Calendar-specific scripts folder:

[Home] -> Library -> Scripts -> Applications -> Calendar

Then it will appear in the FastScripts menu only when Calendar is the front-most app. You can also assign a keyboard shortcut that will only be active in Calendar.

I hope this solution is useful or inspires you to think about how you might tweak it to suit your own needs.

Update: the original version of this script required opening and editing a list of calendar names that should be “gone back to” when done focusing on a single calendar. The current version of the script instead assumes that when it’s focusing in on a calendar, it should save the list of all checked calendars, and restore that list when it toggling back.