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.

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!

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!

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.

Today a MarsEdit customer wrote with a more specific request: he would like to easily insert links to whatever page he happens to have open in Safari, while also using the title of the page as the link text. This is the kind of specialized feature that is less likely to show up as a built-in feature of MarsEdit, because if I added all the specialized features that might be handy here and there, it would quickly become overwhelming. But it’s the kind of thing where I’m very grateful for MarsEdit’s scriptability. Within a few minutes, I was able to share with this customer a script that does just what he wanted.

Click to download: Paste Safari Link script.

If you want to attach a keyboard shortcut to the script, you could use FastScripts, or you can add the script to MarsEdit’s Scripts folder, and then assign a keyboard shortcut using System Preferences:

1. From MarsEdit’s script menu, select “Open Scripts Folder”.
2. Drag the “Paste Safari Link” script into the folder.
3. Open System Preferences
4. Navigate to Keyboard, Keyboard Shortcuts, and select Application Shortcuts.
5. Add a new shortcut for MarsEdit, specifying “Paste Safari Link” as the menu title.

When invoked, the script will insert a link to the active Safari page’s URL, using the page’s title as the text of the link. If you want to use different text as the title of the link, the just type and select it in MarsEdit before invoking the script.

Folks who use FastScripts or another utility to script iTunes will be pleased to know that much of its scriptability is unchanged. I’m able to use my variety of scripts for playing and pausing, showing track information, etc., without any issue. But some subtle things have changed, including support for minimizing or maximizing the iTunes window. My friend Gabriel Roth framed the problem on Twitter:

@danielpunkass Seems iT11 breaks the AppleScript “minimized” property—it now means “shrunk in the Dock” rather than “in mini player state.”

— Gabriel Roth (@gabrielroth) November 29, 2012

I scratched my head about a proper workaround for this. Indeed, not only does the minimized property behave differently than documented in the scripting dictionary, the new “MiniPlayer” is an independent window from the main window. Although they seem to toggle between one another, you can actually select and make both visible from the “Window” menu in iTunes.

My first thought was to simply hide one window while making the other visible. This would be a fine solution except another bug in iTunes 11 apparently prevents the new MiniPlayer window from being exposed to the scripting object hierarchy.

So the compromise is to resort to UI scripting. By simulating the selection of iTunes’s own “Switch” menu item, we can rest assured that the toggle will happen as naturally as possible given the constraints we are facing.

Download the Toggle iTunes MiniPlayer script if you interested in hooking up a hotkey or otherwise automating display of the iTunes 11 MiniPlayer.

Update: Doug Adams (of Dougscripts.com fame) pointed out in the comments that my original solution was less ideal because scripters on non-English systems would need to open and modify the script to search for the correctly named item. I was able to update the script to search instead for the item by its keyboard shortcut alone. This should make the script more immediately useful to users of iTunes 11 regardless of the primary language they run their Mac with.

After shipping MarsEdit 3.5.7 earlier today I discovered a major, crashing bug that affected only certain customers with non-US keyboard layouts including Spanish, French, and Swedish. I made changes affecting the handling of different keyboard layouts in 3.5.7, and neglected to test those changes with an extensive enough variety of keyboard layouts.

It always feels terrible to ship a serious, crashing bug. It’s even worse in the context of the Mac App Store where developers have no direct control over the approval and release of new versions of the software. After waiting 14 days for 3.5.7 to be approved, I was excited to release it as soon as it was ready. But once you approve an app for release in the Mac App Store, there’s no going back. I can’t “wind back the clock” to make 3.5.6 available again.

I decided to remove MarsEdit from sale on the App Store until Apple approves 3.5.8. Of course this means I will not be able to make any new sales until that time, but it also means I will avoid causing unnecessary grief for afflicted customers. When you remove an app from sale it also removes any updates that may be available, withholding them from existing customers. In this case, that is exactly what I want, or at least it’s as close to what I want as is possible.

Here’s hoping I didn’t screw anything else up today.

Update: After submitting the bug fix version to Apple earlier today and requesting an expedited review, I received a notice from Apple that they would try to expedite it to review within 1 or 2 business days. Luckily they ended up putting it into review and approving it tonight, so “everything is back to normal again. Phew.

MarsEdit 3.5.7 is now available on the Mac App Store and directly from the Red Sweater Store. This is a free update for licensed MarsEdit customers.

This update includes long-awaited support for recognizing and setting the post statues “Private” and “Pending” on a WordPress blog. This is especially important because previous to 3.5.7, edits by MarsEdit to a private or pending post would cause WordPress to assume that the post should be changed to “Published” status, potentially revealing private information.

Apart from that there are a number of minor improvements and bug fixes including performance fixes for WordPress that should cause publishing and refreshing to be somewhat faster. Folks who use keyboard layouts with non-Roman characters will appreciate a fix to a bug that caused keyboard shortcuts to stop working when switched to e.g. a Thai or Greek layout.

Complete change list below:

MarsEdit 3.5.7

• Improve performance when publishing to WordPress
• Support for WordPress Private and Pending post statuses
• Use Mac localized sorting for better organizing in posts lists
• Fix behavior of formatting keyboard shortcuts in non-Roman keyboards
• Fix a bug that caused dates to incorrectly display as e.g. “Tomorrow” when they should be “Today”
• Fix handling of bookmarklet requests when the app is not yet launched
• Fix a graphical glitch in the Media Browser introduced in 3.5.6
• Avoid a crash with Tumblr when exceeding their daily photo posting limit

While I was under the hood, so to speak, I addressed a long-standing issue with Tumblr where edits to posts would cause Tumblr to reset the date of the post to the current date and time. I am now working around the issue by explicitly restating the published-on date when I submit an edit to Tumblr.

Another date-related fix is in MarsEdit’s handling of dates that are set on draft posts. Previously, to change the date for a post e.g. to the future, you would have to edit the date and immediately send it to the blog. The “edited date” is now saved with the local draft in MarsEdit so if you’re working on a post that is slated to be “scheduled” you can set the date to the future early in your edits.

Here is the complete list of minor fixes that went into this update:

MarsEdit 3.5.6

• Restore Tumblr support by adapting to their latest API changes
• Adapt to Flickr’s recent requirement to use OAuth for authentication
• Add support for 10.8 user notifications
• Fix an issue where Flickr browser’s number of photos shown didn’t match popup selection
• Fix an issue where some embed and object HTML attributes were being stripped in rich editor
• Fix an issue where edits to Tumblr posts caused publish date to reset to current time
• Fix an issue where editing a post’s date didn’t save properly in local drafts

I’ll be particularly interested to hear if folks run into any trouble with Tumblr after updating. Thanks for your patience while I worked through this issue.

It came as a surprise when Squarespace 6 was released earlier this year, that support for 3rd party editors such as MarsEdit was dropped from the service. I had some cordial correspondence with staff at Squarespace, who explained that because of the laudable flexibility of the new version, it’s difficult to provide access to the content with one of the standard blogging APIs that MarsEdit uses to connect to Squarespace 5 and dozens of other services. Of course, as a developer with customers who depend on this support, I was disappointed to learn this.

I have been holding out hope that Squarespace will eventually address the shortcoming. The two possible solutions that leap to my mind are:

1. Somehow get support for one of the standard APIs working with their new engine.
2. Implement an entirely new API, unique to Squarespace, that I could consider implementing support for.

I lean strongly in the direction of #1. Obviously it would be a lot less work for me, and I’m generally cautious about taking on the burden of developing support for yet another all-new, custom API with all of its own nuanced behaviors.

But option #1 would also be better for Squarespace, in that support would be instantly restored to MarsEdit and any other 3rd party clients using the Squarespace 5 API. These XMLRPC APIs, based on the venerable MetaWeblog, are not great. But they are ubiquitous, and implementing support for one of these standards opens the doors to dozens if not hundreds of clients on every conceivable platform.

So I’ve been waiting, and when disappointed customers ask me what can be done to help, I encourage them to drop a line to Squarespace requesting restored support for their XMLRPC-based API. I don’t know if this has had any real impact, but in any case it doesn’t appear to have shifted the status quo. On Twitter today, customer Rob Wells asked Squarespace about the status of such support, starting a conversation that culminated in Squarespace underscoring that they don’t have any near-term plans:

@redsweater @robjwells It is not on our roadmap to provide XML-RPC.

— Squarespace (@Squarespace) September 18, 2012

To Squarespace’s credit they have been polite and receptive to feedback about this. In a follow-up tweet, they gave some cause to remain optimistic about future developments:

@redsweater @robjwells We’ll keep you guys up to speed on any new developments.

— Squarespace (@Squarespace) September 18, 2012

Whatever the future holds for Squarespace, it’s safe to assume that 3rd party editors will not be supported by Squarespace 6 in the near future. In the mean time, users who already have Squarespace 5 sites should keep their site as it is if they want to continue using MarsEdit. New customers who are intrigued by Squarespace but want MarsEdit support can still start a new Squarespace 5 site by signing up at the classic site.

And although Squarespace has given a pretty definitive answer for the time being, if you ask me it’s always worth letting them know how you feel. If Squarespace 6 support for 3rd party editors is something you’re dreaming of, let them know how important it is to you.