Customizing the Editorial Interface
It’s often helpful to customize the editorial interface to add implementation-specific functionality. Editors might need additional links, buttons, and reporting information directly in the interface from which they edit content.
These customizations might be global to all editors. For example, seeing Google Analytics data alongside content is often helpful. In other cases, editors might be able to customize the interface just for themselves, by adding gadgets or widgets to provide information they find helpful that others might not.
In many cases, developers will seek to turn off functionality that’s not being used to avoid confusion and the need for support. Streamlining the editorial interface as much as possible is helpful, even more so when this can be done on a per-editor basis. As discussed earlier, different editors have different needs, and the ability to display a specific feature for just a few power editors reduces the chance of inadvertent error, and likely makes all editors less nervous about making a mistake.
Customizing Rich Text Editors
Here are some common customizations:
- Enabling or disabling of buttons on the interface
- Customization of styling information, such as the list of classes or block elements that can be applied
- Configuration of HTML validation or “cleaning” processes, which enforce allowable HTML tags and remove invalid markup
- Enabling or disabling of access to the HTML source
- Customization of various pop-up interfaces, such as the image or table insertion interface
- Styling the contents of the rich text editor to match the final site output
It’s assumed that most of the content in a CMS installation will be stored in the CMS repository itself. However, this doesn’t have to be the case.
Some systems will allow for the abstraction of parts of the repository. The code to actually gather the data for content objects is swappable and can be delegated to other code and other sources. Custom code can allow some data to come from other storage sources, and be presented and manipulated just like content that actually lives in the repository. This might happen for only specific content objects or locations in the geography.
An organization maintains its news releases in Microsoft SharePoint. The support team also wants these releases displayed on the website. The CMS repository might be abstracted so that a section of the geography (the children of the News page, for example) will actually retrieve content in real time from SharePoint, presenting this information as if the news releases actually resided in the repository itself. Visitors (and perhaps even editors) might never be aware that this content isn’t actually stored in the repository.
Technical writers store product code samples as Markdown files in Git. The CMS repository might be abstracted to connect to Git in real time and list the files contained within it as child content objects of a Code Samples page.
Users of the Unix operating system might recognize this as the concept of “mounting a filesystem.” In Unix, a completely separate filesystem (System B, we’ll say) can be mapped to what appears to be a simple directory in System A. Users navigating through System A might enter a certain directory, and – unbeknownst to them – actually be browsing the filesystem on an entirely different machine.
Repository abstraction is essentially the same thing: a section of the repository might “mount” some other system to provide data. Data exchange between the CMS and the source system takes place silently in the background. Some systems can even write data back to the external source, so an editor might change an object in the CMS and not realize he’s actually changing data in a completely separate system, somewhere else entirely.
Clearly, this is an advanced feature, and there’s a judgment call to be made as to when this is more appropriate than simply importing the content to the repository and updating it when it changes. Depending on an external data source for real-time access raises issues of performance, network latency, security, and stability. However, in cases where external data might be accessed outside the CMS – by making a direct database query using SQL, for instance – abstracting the repository to present that data as content can increase consistency and simplify templating.
One of the drawbacks of bringing new software into an organization is having a new set of credentials to manage, and for users to remember. One of the easiest ways for users to feel that a system is an integrated part of their organization is to allow them to use the same credentials they use for other systems. Adding yet another set of credentials creates password fatigue, which usually results in sticky notes containing passwords attached to the sides of monitors.
Many CMSs will allow their systems to either be integrated with common methods of authentication, or be swapped entirely for a custom system. Integration with Microsoft’s Active Directory is common, as is more generic LDAP integration. Some systems have OAuth, OpenID, or Facebook Connect integration, allowing users to log in by authenticating against their Google or Facebook accounts.
In the event an organization is using a less well-known or even custom authentication system, code can sometimes be developed and provided to the CMS to handle authentication tasks. In these cases, it’s clearly incumbent on the implementing developers to provide well-tested code, as the CMS will be only as secure as this code allows. The CMS will communicate only with this custom code, and will assume it’s authenticating users in a secure and rigorous manner.
Note that pluggable authentication and shared credentials does not necessarily mean single sign-on. To achieve single sign-on, your editors sign into one system and are seamlessly authenticated across multiple other systems – your CMS included, hopefully. Even if you hook your CMS up to your Active Directory provider, the editors will still need to enter their credentials, but they’ll be the same credentials that they use everywhere else, which is helpful in itself.
Many systems will provide a web service interface to allow remote interaction with the CMS over HTTP. Systems vary by (1) the specific web service protocol used, and (2) the depth of the interaction allowed.
SOAP (Simple Object Access Protocol) was the standard web service protocol for years, but that position has been usurped by REST (REpresentational State Transfer) . Likewise, XML has long been the dominant serialization format, but is being displaced by JSON. Most systems will offer some combination of the two variables (XML via SOAP or JSON via REST, or occasionally vice versa).