Leveraging the Revision System

Barebones CMS offers web developers a powerful, translation-level revision system. Using it is entirely optional, but it does offer the ability to simplify a lot of traditional processes for smaller web development organizations.

There are many different ways to use the revision system but I will be covering only two of them. Feel free to ignore these approaches and do whatever you or your organization needs. The goal here is to present a basic overview of the system.

Test Server on Live Environment

A lot of web developers either have a test server environment or dream of having one. The benefit of a test server is obvious: Being able to test code changes before pushing them out to the production environment. However, there are a number of downsides to having a separate test server that tend to crop up once it starts being used:

These problems can be overcome. However, the revision system in Barebones CMS obsoletes the traditional need for a completely separate test server environment while, at the same time, making a test environment accessible to everyone in the organization.

Creating a 'Test' branch in the revision system.
Creating a 'Test' branch in the revision system.

Each language of each page in the Barebones CMS gets its own revision system. Each page that needs to have changes tested will need to be set up accordingly. To do this:

Viewing the revisions in the revision system.
Viewing the revisions in the revision system.

Once the branch is created, your browser will redirect to the newly created branch where you can begin editing. You can edit this branch in the future. To do this:

Copying the current revision to the live page.
Copying the current revision to the live page.

Once the page is ready, use the 'Copy to Live Page' feature in the Page Options menu. You can backup the Live Page into its own revision prior to copying with the dialog that appears.

A good approach is to only edit the 'Test' branch and then use the 'Copy to Live Page' feature when the changes are ready to go live. However, whatever approach is used, the entire web development team should be trained to and agree to doing the same things. This creates a consistent revision system environment.

Pages within the revision system are not accessible from the public side. This approach presents its own set of problems (e.g. testing forms) but can also be overcome. The tendency to fix bugs on live pages will still be there, but be more subdued. The rest of the aforementioned issues should simply vanish because the page is already on the live server in the correct location.

Temporary Backup of the Live Page

A common scenario for a small web development team without a test server that needs to make major changes to a webpage is to create a backup of a page on the live server. The backup is given some name at the time that seems sensible. Then the person either edits the backup file or the live page. For the backup filename, I have seen every single variation on the theme: 'index_backup.php', 'index_yymmdd.php', 'index_mmddyyyy.php', 'index_username.php', etc.

The problem with the approach is time. After the modifications have been made, the intentions are to go back a week later and delete the backup file. While the intentions are noble, the deletion of the files never actually happens. The end result of a few years of this approach is that each directory gets cluttered with useless backup files.

Creating a revision.
Creating a revision.

If a web development team is used to this approach and doesn't really want to change. Barebones CMS offers a reasonable solution. Before making major changes to a page, create a revision in the revision system that will serve as a backup should anything go wrong. To do this:

This allows you to have a backup of the live page without the clutter.

© CubicleSoft