This section describes how to use Locomote.sh to create, build and publish content.
Locomote.sh is a file-based CMS, meaning that all content managed by a Locomote.sh system is represented using files. This includes obvious things like HTML pages, images, stylesheets, JS files etc., but can also include data in the form of JSON files.
Because all content is represented using files, Locomote.sh uses git to manage those files. Git is a natural choice to use with a file-based CMS. It provides all the tools needed to for adding and modifying files to a system; It provides a history of file changes, with the ability to undo changes or see when a change was made and by whom. and because it's the most commonly used version-control system, most developers are already familiar with it, and know how to use it. This means that unlike other headless CMSs, you don't need to learn an API from scratch in order to start interacting with Locomote.sh - if you know basic git commands, then you already know everything you need to know about working with content in Locomote.sh.
The following diagram gives an overview of the content management lifecycle:
A content repository in Locomote.sh is a standard git repository that is used to store content. A single content repository is normally used to host a single website or PWA. However, it is possible to build websites or PWAs which combine content from multiple content repositories.
The content in a content repository is composed of both the published content and the source content that the published content has been generated from. In order to protect the source, and to provide a clear separation between source and public content, the two things are normally kept on separate branches of the same content repository. So source content is usually kept on the default master branch of the content repository, whilst the published content, generated from the source, is kept on a branch named public.
In this setup, only the contents of the public branch can be accessed over the public web. The contents of the master branch are considered private and cannot be loaded over the web.
In order to publish content, it needs to be put onto the public branch. This is normally done using Locomote.sh's build tool, but can also be done via git, e.g. by adding content directly to the public branch, or merging from another branch.
The normal Locomote.sh setup actually includes a third branch - named test - which as the name suggests, is used to test content before it is published. By default, build tools will read source content from master and write the build result to test, from where it can then be merged into the public branch once reviewed. This progression of content - from master to test and then to public is called the build workflow and is discussed in more detail later.
Every content repository has a unique public URL which allows content within that repository to be accessed over the web.
For example, using the hosted Locomote.sh server at https://cms.locomote.sh/dashboard/, the standard public URL is formed by appending the
locomote.sh domain name with the Locomote.sh account name, prefixed with a tilde
~, followed by the content repository name.
For example, if the account name is "
acme" and the content repository name is "
products" then the public URL would be:
The public URL loads content from the public branch of the named content repository.
Other public branches can be accessed by appending the branch name to the public URL.
So for example, to access the test branch, append "
test" to the URL:
A lot of the examples in this documentation use the hosted Locomote.sh server as a convenient way to get a content repository up and running, but it should be possible to adapt the examples to run against a self-hosted server or a locally running content server.
Read the following sections to learn more about content management in Locomote.sh: