Earlier today I put a link to the Fargo 2 beta in the message of the day, and I just posted an announcement to the smallpicture-web list. The next phase of the beta is underway. Thanks for your help and patience in the first part of the beta!

Lots of little cleanups and fixes.

1. The problem Andy DeSoto reported has been fixed. The site URL in his setup was missing a closing slash. People will do that, so we look for it, and add it when computing the URL, if it wasn't there.

2. The Render icon in the left margin now only renders the cursor page, none of the subs or parents, and does it immediately without waiting to run in the background thread.

3. Did a small optimization in the CMS and did some performance testing. This thing flies. I can't believe how fast it renders. Big thing however is that in the current implementation includes really can slow things down. If you're seeing really slow rendering that may be why.

4. Fixed a bug in presentation nodes now they render properly.

5. Fixed a lot of problems in the Kim Parker website, which now works. It's our basic demo site, so if it had problems so would our first users.

6. The default type is now blogHome. You can of course override it by putting a directive either in your cmsPrefs file or at the top level of a website. This is again for the first-time user experience.

7. Fixed a bug where the Next arrow on a post would be disabled even though there is a next node. This would happen for index pages that don't have a type att. They do have next nodes, so I had to add an exception to the storyVisit routine for those nodes.

8. The Bloatware site was redone, and static-ized. It's the fictitious company that Kim works for.

I've got the back-end working in node.js on a new server running on EC2.

I've got people I can ask questions of about running node.js on my own server.

Fargo 1.42 seems to be running pretty smoothly.

There is one thing I want to take a look at -- performance. Some sites, notably the Fargo Docs site, are very slow to render. So slow that I think there's a bug in there, or something that desperately needs optimizing. I want to find out what's going on before proceeding. It's hard to know what the ramifications are until we get to the bottom of it.

• Update: I was using includes in the Fargo Docs outline. Not a lot of them, but three of the big sections were linked to docs that I was editing in the OPML Editor. I had to undo the includes for another reason, and then the performance improved dramatically.

On the other hand, this site is very nice and peppy! Weird.

Please review the about page for the public beta. Comments welcome.

Anyway -- net-net, I think we'll be in public beta on Fargo 2 before the SuperBowl.

Yehi!

More powerful Render Page command

• When you choose Render Page from the File menu, Fargo not only builds the parents and the bar cursor headline, it now builds any documents subordinate to the bar cursor headline.

• This means, for example, I can build just the Content Management section of the Fargo Docs, without having to rebuild each page manually, or building the entire site. Both were time-consuming and annoying. Fixed.

Render icon in the left margin

• The Render Page command is a biggie, and it deserves a little advertising in the left margin. I chose the Share icon from Font-awesome.

• There were other possible choices, for example the world icon, to indicate that it's being published to the web.

• I went with Share because that seemed closest to where this command is today, and where it's likely to go in the future.

Interesting story to go with this change

• As you may recall, Dropbox went down just after I had made a change to the CMS on the 11th, and wasn't able to test it. I was going on a trip to New Orleans the next day, so I commented the change, just to be safe (it almost worked, but not quite). The fix was easy, and now the new version is deployed.

Cleaned up breakage after changes in implementation of index type and the addition of blogHome type. Now we can have typed nodes that have subs that are typed (i.e. index nodes and blogHome nodes).

Generating URLs to these objects becomes more complex in these places:

• When generating URLs in blogHome pages.

• When the user clicks on the Eye icon.

• When generating URLs in index pages.

Have a look at the new Example 16 to see what I'm talking about. That's where the breakage revealed itself. I pointed to the examples page, so you could see how a link to Example 16 is different from the links to other pages. That's because it has subs that are docs.

I suspect that Jeffrey saw it as well in his index pages that were subordinate to blogHome pages.

However, I think it all should work now. Really ready to go on vacation and put all this behind me.

Jeffrey had a good question.

Suppose the home page of my site is a blogHome page.

Now I want to have an index on one of the lower-level pages.

There was no way to do this. Either the top page is an index, or none of the pages are.

This is obviously not a good thing.

Now, if you set the type of any page to index it will render as an index page.

You don't have to supply an index type template, because at the same time I added a bit of code that says that if a page has a type for which there is no template, use the outline template. This solves a bunch of other problems too, and can't result in breakage (something I'm starting to worry about) because there were no pages that rendered without a template previously.

I also changed the defaults for index pages so that the stories and dates would be off by default. These features were there in a vain effort to get the index type to do what blogHome type does. Now that we're not trying to do that, it made sense for the defaults to be set up for the simple case.

It was easy to see why there was no RSS feed or rendering happening when you have auto-save turned off, it wasn't doing it. This is of course because I always have autosave turned on. I suspect we'll find many other problems like this in the weeks to come.

Anyway, I'm typing this with autosave off, and the console window open, and nothing is happening, as you would hope. Now I'm going to choose Save from the File menu and see what happens.

Everything is rendered and the feed is built. I'd say the problem is licked.

Note to testers: See why it's important to say what you did? Somewhere in that narrative would have been "I chose Save from the File menu" and that would have pointed me right at the problem, because it isn't something I ever do.

Bloghome sites need titles

• It was wrong to remove the titles from the blogHome template.

• It's just the home page of the site that doesn't need the title.

• It's assumed that the menu "brand" will contain the site name.

• All the other pages point to this page.

• I made this work through a runtime JavaScript when the page loads.

Crumbtrail review

• The crumb trail was broken on pages other than the story page.

• I radically simplified the code.

• It works now.

This post explains how Fargo 2 connects with the naming system.

There are three points of connection, two for the Name Outline command in the File menu, and one for the rendering process in the CMS.

This documentation is here so you can see how the process works. Don't call these endpoints, they're just for Fargo to call. Thanks.

1. Is the name available?

• URL: http://namer.smallpicture.com/ajax/isNameAvailable

• Param: name, a string

• Returns: An HTML snippet suitable for display saying whether the name is available.

2. Grab this name

• URL: http://namer.smallpicture.com/ajax/newOutlineName

• Params: url of the associated OPML file, name, both strings

• Returns: JSON struct indicating whether it worked.

• Note: It's a JSONP call, the routine name is getData.

3. This outline updated

• URL: http://fargoajaxsupport.smallpicture.com/ajax/pingPackage

• Params: url, a string

• Returns: Nothing worth looking at (at this time).

• Note: The URL is what was returned by the grab this name call. The OPML file must contain a <head> element, linkHosting, that points to a package file. You can see what one looks like in the #hosting folder of the Fargo app folder.

• More docs will be forthcoming, for sure.

Starting the transition of Scripting News to the new CMS. Reviewing the original site and what Fargo produces, and hacking at the differences.

• I archived the outline for 2013, I'm not going to try to convert anything before 2014. The OPML is preserved and the static web pages are exactly where they belong.

• I had already archived the 2013 entries for the Fargo blog in this outline. Again, I'm not re-rendering these pages. They are as they are.

Problem with Render Page command, getPathToBarCursor is not defined. (The name of the routine had changed, but the code did not.)

Took the <h2> title out of the blogHome template. It's not supposed to be there. (Look at the current Scripting News home page, no title.)

A new Overrides panel in the Outline Settings dialog, with one initial item in it, type. You can say what type the + icon in the left margin creates. So globally you could have it be outline, and in just one website it could be a custom type.

The Name Outline command works once again. It now turns on the two rendering preferences in the CMS panel of the Outline Settings dialog. Named outlines that don't render don't make much sense.