Work on the new web site is well advanced, we’re implementing it completely in HTML5 and it’s looking good. We may open it up to beta testers very soon.

I’ll be posting here more often from now on in the run-up to release day.

Yesterday we were made aware of a piece of malware that specifically modifies GoLive-generated JavaScript files, including MenuMachine JavaScript files.

Anirban Banerjee from stopthehacker.com explains:

Hackers are choosing to insert malicious code directly into local copies of menumachine scripts which are linked to compromised sites. This is primarily being done by harvesting client side ftp credentials using a backdoor trojan which then proceeds to hand over the credentials to a bot which in turn pumps in the infected code.

The trojan affects MenuMachine JavaScript files as well as the GoLive CSScriptLib.js file used for GoLive Actions support. The page at stopthehacker.com has an example of the modified code.

I must point out that unless your local machine is compromised, there is no way that this can affect you. This is not a vulnerability in MenuMachine itself. Your site cannot be modified unless the trojan has gained access to your local machine, in which case you have other problems. Your site cannot be affected by other machines on the internet.

I highly recommend that you have a look at the MenuMachine files in your site. If any of them contain this line at the end then your computer and your site are compromised:

function(hVAxp){var v120='va@72@20a@3d@22@53

As far as I am aware this issue can only affect Windows machines and if you’re running Windows then I highly recommend that you install anti-malware software immediately if you do not already have it in place and also make sure that you are completely up to date with Windows updates. This also applies to you if you run Windows in a virtual machine on your Mac.

This is certainly an unexpected development, if we discover any further information I’ll let you know.

His first thought is to use a SnowSpeeder, a fast flying craft that would be ideal for scouting a vast area for life. However, he is told that the speeders are not available because the technicians are having trouble adapting the machines to the extreme temperatures.

Like the SnowSpeeder technician, I’d like to let you know that it’s been difficult adapting the concept of MenuMachine from a plug-in to a full-blown application. There have been many unforeseen issues that we’ve come across, each one adding to the time taken to get MenuMachine out the door.

In many ways, GoLive was an ideal environment for our plug-in. It was self-contained, had great site and link management capabilities and a great SDK that we could use to develop against.

With a standalone application, we can’t rely on having any of this. There is no site management, so we have to build it. There is no link management, so we have to build it. We need to provide the ability for users that don’t have a supported editor to place the menu on their pages.

We also have to work with several very different plug-in APIs, one for each of the HTML editors we need to support. Each one of these is totally different and offers different challenges.

For example, Dreamweaver has a mature plug-in API (where “mature” means “ancient and crusty”), and the support for binary (compiled) plug-ins is pretty rudimentary. Panic’s Coda has a nice SDK, although it’s new and fairly limited. MacRabbit Espresso has a sophisticated SDK but it’s also very new and limited. The list goes on.

At the same time, we need the new version of MenuMachine to create menus that are more sophisticated than MenuMachine 2’s, while also offering great accessibility and flexibility.

All of this takes time. We are trying to build an app that will be fairly bulletproof, and will generate menus that will work in the vast majority of users’ pages. We are doing our best to do this.

We want MenuMachine to be reborn just as much as all of you and we are getting there. The light is at the end of the tunnel. We’re working very, very hard.

I am working on fixing the problem at present but it may take a day or so before it’s up and running again. If you have sent us a support query in the last week or so and have not had a response, I apologize profusely. We will respond to your enquiry as soon as is humanly possible.

Update July 2, 2009: We have moved to a new support platform, (FogBugz, if you’re interested), which should mean that support is back to normal. We’re handling the support queries that have slipped through the cracks on a case by case basis. Please let me know if you have any problems with the new system, although hopefully you won’t really notice a difference. Please also let me know if you have a support issue that has not been responded to.

If you have contacted me about the beta, please be assured that you are on the list but do not be alarmed if you are not in the very first round of outside testing.

I can tell you that we are currently working extremely hard on getting it out the door.

We did hope to have it ready by the end of this quarter but unfortunately due to several unfortunate and non-development-related problems we have not been able to meet that estimate. We are currently looking at a release by mid-year.

http://code.google.com/p/tabsterforcoda/downloads/list

All Tabster does is map Tab and Shift-Tab to Command-] and Command-[, which allows you to indent blocks of text using the Tab key and outdent them by using Shift-Tab. Users of other editors that use these key combinations for block indenting will find this makes switching to Coda a lot easier.

The plug-in requires Mac OS 10.5 and is open source under the MIT license. Source code is inside the bundle and at Google Code.

Enjoy.

Update: Some users with non-English keyboards were reporting issues when pressing certain symbol keys. Version 1.02 should resolve this problem.

Update 2: Will Cosgrove from Panic pointed out some issues with the key press handling in another plug-in, Wrapster, that apply to Tabster also. I have modified the Tabster code to make things safer.

Update 3: I’ve fixed a bug introduced in 1.2 which caused shift-arrow to trigger Tabster. I’ve revved the version to 1.3 and moved the project to Google Code.

Update 4: Added a minor fix that works around an issue on Snow Leopard where the plug-in would stop working after a period of time.

Smart symbol wrapping is a neat feature for coders. The way it works is that you select some text in the editor and then press a particular symbol key, such as a square bracket. This key press is intercepted and the selected text is automatically wrapped in a pair of square brackets. Smart symbol wrapping handles all the various types of paired symbols, such as braces, parentheses and several other types of symbols such as quote marks.

I decided to write a Coda plug-in using the Cocoa API to implement this feature, which turned out to be reasonably straightforward. The resulting plugin, Wrapster, can be downloaded here.

Please note that you must be running Mac OS 10.5 (Leopard) in order to use this plugin.

The plug-in is open source and released under the MIT License. You can find the source in the plug-in’s bundle wrapper by selecting the plug-in in the Finder and choosing “Open Package Contents” from the Finder’s contextual menu.

The plugin uses a simple property list file (WrapOptions.plist, again in the wrapper) to configure the replacement characters so you can add to or modify the replacements that ship with it, which are:

{ } [ ] ( ) < > " '  “ ” ‘ ’ `

The WrapOptions.plist file contains a comment with instructions for how to edit the file.

You can enable and disable Wrapster in the Plug-Ins menu in Coda.

In terms of implementation, the only slightly tricky thing was finding a way to detect key events before Coda gets hold of them. It turns out that the only way to do this without having access to the internals of Coda is to use an Event Tap, which allows the plugin to capture the raw events posted from the keyboard before Coda’s NSApplication instance gets a chance to process those events. This does mean that in order to use the plug-in, you need to enable “Access for assistive devices” in the Universal Access System Preferences pane, as shown below. If you don’t do this, Wrapster cannot get access to any key events.

The Universal Access Preferences pane

I hope you find this plug-in useful. It certainly has served its purpose for me, I’m pretty familiar now with the Coda SDK and what can be done with it. The guys at Panic have done a great job with the API which is simple and well thought out.

I’d love to hear your feedback about the plug-in (good and bad!).

Update: It seems that Wrapster was preventing Command-] and Command-[ from working. I’ve updated it to version 1.1 and it will now not replace the text if either the Control or Command keys are down, it will just pass the key press through to Coda.

Update 2: Justin on the coda-users mailing list pointed out that Wrapster would activate if text was selected in the page and you entered one of the special characters in the search field. I’ve fixed this now with version 1.2, Wrapster will now only activate when you are actually editing text. Get the update here.

Update 3: Thanks to Rainer Brockerhoff who alerted me in the comments to a more efficient way of handling the Quartz Event Tap that Wrapster uses to capture key events. I’ve updated Wrapster to 1.2.1 and incorporated his suggestions. There is no real need to update to this latest version unless you just absolutely must have shiny new stuff .

Update 4:Thanks to Will Cosgrove from Panic who pointed out that one of the Apple methods I was using to intercept key press events is buggy and can cause a hang in the window server (this means a total UI lockup, very bad!). I have modified the code to make things safer. All users should update to the new version 1.3.

Thanks for all your comments regarding other editors, we are certainly looking at all the options that you have suggested. Someone mentioned that it would be nice to have support for GoLive 9. We are not going to be targeting GoLive with the initial release as it simply doesn’t make business sense for us to pour development resources into a discontinued product. I’m not saying we won’t support it (I personally would like to see a GoLive extension, since I’ve spent a lot of time in that environment!) but it won’t be in the initial release.

Back to the main topic. When we were designing the new version of MenuMachine, we wanted to provide users with a choice of multiple menu types. MenuMachine 2 allowed users to select vertically-expanding or cascading menus, but we realize that there are many more menu types that users might like to create, and there are also new menu types that we wanted to implement for the first time.

For this reason, menu types in MenuMachine 3 have been implemented as plugins to the main application. This means that we can easily add new menu types to MenuMachine without having to alter the base application code. We anticipate shipping MenuMachine 3 with a variety of useful menu types and we then expect to release new menu types as we are able to develop them. This means that MenuMachine 3 should become more powerful and useful over time.

We have also implemented our external editor support using a plug-in architecture. This will allow us to easily add support for other editor platforms. We will definitely be supporting Dreamweaver at launch and if we have time the initial release might support some other editors. We anticipate creating editor support modules for BBEdit, TextMate and possibly Coda and Espresso initially, with more to follow. If you have any suggestions for editors that you’d like to see support for, please let me know either via email or in the comments.