Publishing Barebones CMS Extensions

So you have written an awesome extension to Barebones CMS and you would like to allow users to install your extension through the Barebones CMS distribution platform? This guide will help you through the process of getting your first extension published right here on the Barebones CMS website.

Note that you do not have to publish an extension to use an extension privately in your own projects. This guide is for those who want to publish an extension to the public Barebones CMS distribution platform so that other Barebones CMS users can benefit. Privately developed extensions carry all the security risks of custom-built, non-vetted software by non-vetted developers. Use such software at your own risk! All Barebones CMS extensions on this website are written and maintained by developers who have been vetted by CubicleSoft. End-user application security is mission-critical for most businesses, so this process is absolutely necessary.

Extension Overview

All published extensions on the Barebones CMS distribution platform must fall into one of these four types of extensions:

What won't work are "mods", or modifications, to the core product. Extension deployment is designed to be a very simple extraction operation. Modifying the core is also not recommended as it makes upgrading very difficult. There's usually a way to do something without modifying the core product - even if that means starting a discussion in the forums to request additional features in the core.

All published extensions are hosted on public repositories such as GitHub (preferred). A public repository allows users to more easily contact the author through the dedicated issue tracker for the extension.

Published extensions also have the following requirements:

Each of these will be discussed later on in this guide. If you have any questions about the process, your best bet is to use the forums. This guide is only meant as a general overview of the process.

Vetting Authors

CubicleSoft vets the authors of extensions before they are even allowed to submit their extension. The vetting process involves a rigorous analysis of your skill set as a software developer. CubicleSoft expectations include professionalism, high quality work, and consistency in authorship. The reason for the vetting process is that users will be implicitly trusting that all published extensions are properly secured against a wide variety of remote attacks.

One of the key contributing factors of rejecting authors is the use of free e-mail services such as Yahoo, GMail, or Hotmail/Live. Authors may not be anonymous when publishing extensions that other people will be using. Anonymity has no business in business.

Finally, all authors must agree to the transfer of copyright and ownership of an extension to CubicleSoft after 395 days of no updates. Read the Terms and Conditions to learn more. This is the part of the process that turns some people away, but it is a necessary solution to a real problem.

Being lenient and patient is part of the process as well. These qualities of the individual must extend to all aspects of extension development and deployment.

Extension Compatibility

All new extensions and new versions of extensions must work with the latest release of Barebones CMS. This is mostly just common sense but it has to be said.

The Extension License

Let's talk a moment about licensing. Licenses are a difficult topic to broach for many because many developers have a favorite license. Barebones CMS operates under a MIT or LGPL license and gives the licensing option of one of those two (fairly liberal) licenses to the user. Users are encouraged to donate financially to the Barebones CMS project.

Published extensions must have a suitable license. The Barebones CMS approach is the preferred licensing scheme. The MIT license by itself is also acceptable. Other licenses will be considered but are much more likely to result in the rejection of the extension. If the license is the only thing holding an extension up from being accepted, CubicleSoft may directly contact you about it.

All licenses must have the equivalent of NO WARRANTY and NO LIABILITY phrasing in it. This is the part of the legal language (aka legalese) that protects both yourself and CubicleSoft from lawsuits.

The 'package.json' File

There is one required file, located at the root of the extension, that must exist. 'package.json' (without the quotes) defines the extension ID, extension version, and a list of files that will be deployed. The file might initially look like:

{
	"id" : "",
	"version" : "1.0",
	"files" : {
		"support/*" : "support",
		"widgets/*" : "widgets"
	}
}

The contents of the file are in the JSON format. The extension ID isn't known until the extension is uploaded for the first time and must be an empty string. The initial version is usually 1.0. The 'files' object maps source files and directories to destination files and directories. There are several special destinations that are recognized by the installer that may end up remapped to the user's installation define()'s:

Appending '*' to a source path will match files in the ZIP file that match the path. From the example, everything in "support/" in the ZIP file will be copied into the SUPPORT_PATH directory. The wildcard option simplifies package file management.

Once the extension ID is issued, the 'package.json' is updated with the ID, the ZIP file regenerated (GitHub makes this easy - push to origin master and then download the ZIP file), and then upload the updated ZIP file.

The Screenshot

Every extension must have a screenshot. A good screenshot will represent the extension's features well and garner more downloads.

Manual Installation

Each published extension must include instructions on installing the extension manually. Not all hosts support the "Manage Extensions" feature of Barebones CMS (e.g. no ZIP file extraction functionality). Manual installation is not as slick as the automated installation method but it is a necessary part of every extension so that each extension results in a consistent user experience.

What's Next?

If you want to see an example Barebones CMS extension, try modeling your extension after the CubicleSoft developed Flash Object (SWF) shortcode extension.

Once you have all the pieces put together for your extension as described in the earlier sections, apply to be an author. The full publishing cycle can take several days to complete and CubicleSoft may request changes be made prior to approval. Approved authors get access to submit extensions for publishing. Once the extension is approved, it will show up on the live website.

© CubicleSoft