Brian Milby reminds that the Name Outline command needs attention.
Now, if you click OK with a name that's less than 4 characters, Fargo beeps and puts up a message in red saying the name is too short. You can click Cancel if you want to close the dialog.
The prompt is shorter, mentions the CMS, and links to the docs section on content management and Fargo in a Workgroup.
An important part of the process of developing the new CMS was coming up with a strategy for hosting Fargo sites that was likely to work for users, and didn't have me hosting your sites. Believe it or not, that took almost as much time as doing the new CMS (which was a from-scratch rewrite, not a port).
We looked at several approaches. The discussion is in the archive of the Fargo2 mail list if you want to see what we considered.
What we're left with is two ways to do it, but one way that I think will work better than the other, especially in the short term.
Syncing from the html sub-folder was the first method I implemented. It still works. The problem is that there are no services that are a perfect match for this capability. Part of the problem is a Dropbox limit. An app can have access to your entire dropbox folder, or to an app folder. You can't give access to an app to a single sub-folder nested inside another app's folder.
Eventually we stumbled across the Pages service from GitHub, which is a pretty close match to the ideal service that would fill in for Fargo's ability to generate a folder of static HTML files. There's a howto that explains.
It's possible that better solutions will come along. Or Dropbox will add the ability to share a folder between two apps, making an almost-ideal solution possible. The best solution would be for Dropbox to let you put a domain name on a folder, and it could manage the serving. That would rule, and make any other approach look nowhere near as good.
When it became clear that syncing wouldn't provide an easy-enough answer for most Fargo users, imho -- I bit the bullet and wrote a web service in Node.js that Fargo could hook directly into, and it would manage the storage of people's HTML in an S3 bucket, beta.fargo.io.
By calling it beta.fargo.io, I hoped to signal that it's a temporary solution.
The Fargo Publisher app is on GitHub, it's available under the MIT License, the most liberal open source license. My hope is to establish the protocol that Fargo uses as a basis for interop among a group of implementations, and encourage people to start services to host their own content, and to offer hosting to other users.
That's one of the reasons I wanted to come up with an approachable how-to for deploying Fargo Publisher. With the generous help of Eric Kidd, we now have that how-to for Heroku, which is a subsidiary of Salesforce.com. They seem really reliable, and for a low-volume server it's free. Can't argue with that!
Once you have a Fargo Publisher server up, it's a simple matter to get your copy of Fargo beta to talk to it. Visit the main Settings dialog, off the System menu in the upper right corner of the screen, click on the CMS tab, and change the server from pub.fargo.io to the name of your server. Your changes should start flowing through that server immediately. This is still a beta, so there may be problems, but now is the time to shake them out.
Here's a screen shot of the dialog.
See also: Why Fargo 2 technology is interesting.
And: Heroku How-to.
