What's the difference between built-in and custom?

You’ll see a dichotomy in the upcoming chapters between built-in and custom.

Any CMS comes “out of the box” with a specific featureset, but many systems let you enable new functionality to suit your specific situation. Developers can usually enable this functionality by writing code against specific application programming interfaces (API) – provided by the CMS.

An API is a collection of “access points” in the CMS where external developers (meaning, your developers, not the developers who created the CMS) can attach their own code to fit the CMS to their specific situation. A good API is one that’s clear, logical, and provides sufficient attachment points for developers. A poor API is one that’s unnecessarily complicated, confusing, and/or doesn’t provide access to the features a developer wants to work with.

Unfortunately, the line between what’s built-in and what’s custom gets blurry and is idiosyncratic to the system, because what one system considers basic configuration would be considered wildly custom by another.

For example, some systems are modeled from programming code, and this is completely expected and not considered custom. Other systems are modeled from a user interface (UI), and if anyone is writing code, then they’re doing something custom.

There might also be a dichotomy between code and configuration. Custom code usually means executable, programming code in the language of the CMS itself that executes in the same process. Changing code usually involves a complete redeployment of the CMS to the production environment. Configuration is anything short of code, which can mean changing text in some structured markup file (XML or YAML, for instance), or clicking your way through a provided interface.

What is custom, in relation to a specific CMS? It could be a change that –

• Is created in an underlying programming language of the CMS itself, and which executes in the same computing process
• Involves file configuration that has to be deployed to the production environment
• Cannot be completed from the administrative interface
• Prevents the system from being automatically upgraded
• Requires a developer to complete
• Requires the production computing process to be restarted
• Requires testing in a separate environment

And some of these definitions just raise more questions and need for more definitions –

• What is a “developer” in the context of this system?
• What is a “deployment”?
• What is an “environment”?

I’m not even going to try to answer or define those, because they’re hopelessly specific to whatever system you’re working with. For example, some systems don’t have environments at all, which deeply affects what we might call a deployment.

In the end, what’s “custom” is often based on the expectations of the system.

Each system has a level of expected development to implement it. Anything over and above that development is some vary degree of “custom” ranging from mild to heroic. Some systems are designed to be extended – they come with multiple extension points and a well-documented API – while other systems are hermetically sealed.

It’s just not an exact definition. I’ll try to make the distinction clear when it comes up, but know the dichotomy is very much relative to your particular CMS and its implementation patterns.