Web Content Management

Chapter 11. APIs and Extensibility

The customization of a CMS is accomplished on two levels. There’s templating, which is fully expected in almost every implementation and is handled by a combination of HTML and templating code. Then there are deeper customizations to change or add to the operation of the CMS itself. These customizations are normally done in the native language of the CMS (PHP, C#, Java, etc.).

Editors might assume that the extensibility of the CMS applies only to developers, but it actually has a significant impact on the entire team. When developers respond to an editor’s request by saying, “We can’t do that,” it’s often because the extensibility of the CMS has failed them in some way, and they simply have no way to accomplish what the editor wants to do.

Some systems have elegantly designed methods of accessing content and limitless ways of manipulating it, while others are clunky and frustrating and almost seem to be working against the developers, rather than with them. Some systems are designed from the ground up to be programming platforms that incorporate and cooperate with code developed by the integrator. Other systems are closed off from this to some degree, either intentionally due to architecture limitations (multitenant SaaS, for example), or because of the product design.

Ultimately, the extensibility of a CMS can be traced back to a core question: did the vendor expect anyone to extend it? I’ve worked with CMS vendors who were surprised ...