Fargo's CMS is the continuation of a series of content systems developed at UserLand, going back to the mid 1990s.
The first was the website framework, which grew out of the 24 Hours project.
There were thousands of people doing websites with it.
The first blogging software was developed in Frontier's CMS.
I used it for Scripting News, and Jorn Barger, among others, used it for his first blog, Robot Wisdom.
UserLand developed XML-RPC, RSS and OPML to create networks of software and content.
The website framework led to Manila and Radio UserLand, and almost 20 years later -- Fargo.
I'm writing this for the people who used one of these earlier systems at a programming level. I want to show how this is an evolution of the ideas in the earlier systems, even though it's a wholly new codebase, written in JavaScript and running in the browser, hooking up to file storage using Dropbox, and flowing the content to the public web through software running in node.js
Here's the outline behind the Kim Parker blog website. It's a simple example site that shows how the basic ideas of Fargo's CMS hang together.
The Frontier CMS used the hierarchy of the object database to project values over the content as it was rendered. So a #template, for example, could be overridden by placing another #template at a deeper level.
The same hierarchy works in Fargo but there is no object database. But each outline acts like an object database. It can contain lots of documents, each of which is rendered onto its own HTML page.
In Fargo, as in Frontier, any headline node can have as many attributes as you want to put on it. These attributes also act like #directives.
Frontier had a pagetable, and so does Fargo, and it's built in exactly the same way.
In Frontier, all values used in rendering a page come from the same "root" or object database. Values from other databases can be included, but only through scripts that you provide that run as the page is rendered.
In Fargo, we made this richer.
Default values come from an OPML file that I maintain. Every copy of Fargo loads this file when the app initializes. This is where the default templates come from. There are global glossary elements that are available to all page renderings. In the 90s I played around with the idea of a global glossary, but it never came together. It works perfectly in Fargo, and it's not just a global glossary, it's a global everything. It took a long time to figure out how to do it, but it's in there now.
After that Fargo loads a file from your Dropbox folder called cmsPrefs.opml. It works exactly like my global file, but it's only broadcast for your own renderings. This lets you set up structures, scripts and values that are shared for all the pages you render on your system. You can override anything I have put in the globals file.
The attributes from the file you're rendering content from.
Frontier's website framework had three types of "filter" scripts -- firstFilter, pageFilter and finalFilter. Fargo only has finalFilter, however if there is a need for a firstFilter script it will support it.
Glossaries in Fargo exactly as they did in Frontier.
Fargo supports includes everywhere, support is baked into the framework at a very low level and they are transparent. This gives you an easy way to share definitions with other users. However, be careful, includes can slow down your rendering, significantly.
Review the docs for Fargo's CMS for other features that are new in this framework.