CMS for NodeJS: Using Crafter CMS Javascript SDK on the Server with Node JS

In this blog, we will focus on the language-specific bindings for Javascript, the Crafter CMS Javascript SDK applied on the server side with Node JS. A deep dive on the Javascript SDK and architecture can be found in this blog post: Introducing Crafter CMS Javascript SDK

Pre-requisites for Using the Library

  • NPM / Yarn installed
    • The SDK releases are published to Node Package Manager (NPM.)  Example: https://www.npmjs.com/package/@craftercms/content
    • NPM will help you easily download the proper dependencies.  You can all so use NPM or Yarn to build and execute your application.
    • In our example, I will use Yarn to manage my package.json file and to assist me in building my application.
  • Access to a running Crafter Engine instance and site.

Building a Simple Javascript Application

The point of our application in this blog is to demonstrate how to include and use Crafter CMS’s Javascript SDK in an application and to use it to retrieve content from a running Crafter Engine instance.   We’re going to keep the application extremely bare bones in order to illustrate that this library is independent of any specific frameworks or platforms such as Node.js, React, Angular6, Vue etc.

For those looking to get right into the meat of the integration, use of the SDK starts at Step 4.

Step 1: Create a basic structure and build for the app

The first thing we want to do is to create a directory for our application source.  I will call my directory simple-node. Inside that directory add a file called package.json with the following content:

{
 "name": "simple-node",
 "version": "1.0.0",
 "description": "Simple Node JS Server that will use Crafter CMS Javascript SDK",
 "main": "server.js",
 "scripts": {
 "test": "echo \"Error: no test specified\" && exit 1"
 },
 "author": "",
 "license": "ISC",
 "dependencies": {
 "@craftercms/classes": "^1.0.0",
 "@craftercms/content": "^1.0.0",
 "@craftercms/models": "^1.0.0",
 "@craftercms/search": "^1.0.0",
 "@craftercms/utils": "^1.0.0",
 "express": "^4.16.3",
 "url-search-params-polyfill": "^5.0.0",
 "xmlhttprequest": "^1.8.0"
 },
 "proxy": {
 "/api": {
 "target": "http://localhost:8080"
 },
 "/static-assets": {
 "target": "http://localhost:8080"
 }
 }
}

This file describes our application, how to build it and what is needed to build it.  In the content above we can see:

  • The application metadata.
  • The application dependencies we are requiring are the various Crafter CMS Javascript SDK dependencies ( “@craftercms/content”: “^1.0.0”, “@craftercms/search”: “^1.0.0”, etc.)
  • The application build/dev dependencies that help us compile the application for distribution ( “webpack”: “^4.17.1”, “webpack-cli”: “^3.1.0”.)
  • Configuration for your Crafter CMS endpoint.

Step 2: Perform an initial build

Run yarn in your application directory.  This will download all of your dependencies.

Step 3: Create an application Javascript

Note that in our package.json we’ve listed server.js listed as the main for the application.

Create a server.js file and place the following content in the file:

console.log('server is starting');

var express = require('express');
var app = express();
var server = app.listen(3000, listening);

app.get('/', test);

function listening() {
 console.log('listening...'); 
}

function test(request, response) {
 response.send('Hello World!');
}

app.use(express.static('website'));

 

Now run the application by typing: node server.js

Finally, access your application via the browser at http://localhost:3000

 

Step 4: Calling Crafter CMS API’s with our application

Now that we have a very basic, working application it’s time to use the Crafter CMS Javascript SDK.

Crafter Engine Instance

In order to use the Crafter CMS APIs, you will need a running Crafter Engine instance with a project set up that you have access to.  It’s easy to get started. Here are some helpful links on getting things set up:

Import the APIs into your application javascript

Add the following code at the very top of your server.js script file.  Here we are declaring the classes we will use and indicating where they are imported from (the SDK.)

var classes = require('@craftercms/classes'),
    content = require('@craftercms/content'),
    crafterConf = classes.crafterConf,
    ContentStoreService = content.ContentStoreService;

XMLHttpRequest = require("xmlhttprequest").XMLHttpRequest;

Configure the SDK for your Crafter Engine endpoint base URL (server name, port etc)

Now that you have declared the Crafter CMS SDK services you want to use you are almost ready to start retrieving content.  Before we can, we need to make sure the SDK APIs know where Crafter Engine “endpoint” / server is and what site to pull the content from.  To do that we have two options:

  • We can create a configuration object and pass it with each call
  • Or we can explicitly supply the endpoint configuration with each call

Since we’re going to use the same endpoint and site, we’ll set up a configuration object and pass it when we call the APIs.  To configure the endpoint we add the following code to our script after the import statements:

crafterConf.configure({
 baseUrl: 'http://localhost:8080',
 site: 'editorial'
});

The configuration above states that our API calls will reference the site in Crafter Engine that has the “editorial” ID. By default, the configuration assumes that Crafter Engine is running locally on port 8080. To change this, add the following:

baseUrl: “YOUR_PROTOCOL//YOUR_DOMAIN:YOUR_PORT ”

crafterConf.configure({
 site: 'editorial',
 baseUrl: "https://mydotcomsite"
});

If you want the system to assume that the app and the API endpoints are on the same server you can set base URL to an empty string (“”)

Call a Crafter CMS API and get content

Make the code changes:

Now that the library is imported and configured, we’re ready to use it.  Let’s add the code to our example to make a request for content and put it on the screen for the user.   Below is the entire server.js script for our application with changes:

console.log('server is starting');

var express = require('express');
var classes = require('@craftercms/classes'),
 content = require('@craftercms/content'),
 crafterConf = classes.crafterConf,
 ContentStoreService = content.ContentStoreService;

XMLHttpRequest = require("xmlhttprequest").XMLHttpRequest;

var app = express();
var server = app.listen(3000, listening);

app.get('/', test);

crafterConf.configure({
 baseUrl: 'http://localhost:8080',
 site: 'editorial'
});

function listening() {
 console.log('listening...'); 
}

function test(request, response) {
 ContentStoreService.getItem('/site/website/index.xml')
 .subscribe(item => {
  var htmlTitle = item.descriptorDom.page['hero_title'];
 response.send('Hello World: ' + htmlTitle);
 });
}

app.use(express.static('website'));

What we’ve done is replace the code in the test function that was hardcoded to write “Hello World” on the screen for the user with the code that calls Crafter CMS for content and write the retrieved content on the screen instead.

Let’s take a closer look at the API call; ContentStoreService.getItem

  • The first parameter is the path of the content item we want to return.  The example uses the home page of the editorial site.
  • The second parameter is our configuration object which supplies the site and endpoint base URL configuration.
  • Lastly, you will note the subscribe operation.The SDK makes asynchronous calls to the Crafter Engine component of Crafter CMS.  Subscribe allows you to supply the code you want to execute when the call returns.  In our example, this is where we create an element, get our content value (hero_title) from the returned response and then update the application with the content.

Test the application

After you have made your changes, stop the Node server (Ctrl+C) and restart it. Once it’s restarted, reload your application in the browser to see content coming from your Crafter CMS site:

 

Congrats!  Your application’s content is now externalized and managed in the CMS.

Step 5: Update your content using the CMS

Now that our code is complete our content authors can update the content at any time via the CMS and we don’t need to rebuild or redeploy the application.  Let’s use Crafter Studio to update the content for our app.   You can find detailed how-to help here:  Creating and working with your First Crafter Site

In Crafter Studio, find the content you want to edit

In our case, the content we’re consuming is the hero title.  Let’s make an edit to that content:
In your site’s content preview, turn on the editing pencils and click the pencil for the Hero Title (as shown above.)


Note that the author has a preview of the content.  This is something very different and ultimately much better than what you see with other Headless CMS systems.

With Crafter, it’s always possible to provide the user with a preview of the content they are editing regardless of the front end framework.  Preview capability is key because it makes editing content easier for authors.

Make a content change and save

After you click the pencil for the Hero text make the change and then click the Save and Close button at the bottom of the form.  You will see your update in the CMS right away.

Refresh the example application

Wow! Those changes in the CMS look great (if I do say so myself :D!)  Now it’s time to see the changes in our application.  Simple, just refresh your application in the browser. No code updates required!

It’s really just that simple!  A few lines of code allows us to create applications with content, configuration and other strings that we can update at any time without needing to update or redeploy our application code.

What about the full API, workflow and publishing?

This blog is meant only to cover the basics of using the Crafter CMS SDK with Node JS. A deep dive on the Javascript SDK and architecture can be found in this blog post: Introducing Crafter CMS Javascript SDK.

Conclusion

Crafter CMS’s Javascript SDK gives front end and full stack developers who work in Javascript and Javascript related technology a native programming API to work with that makes building content-rich applications much easier to do.

When we stop an think about it, almost every application has content in it.  If that content is easy to update and updating the content can be done by non-technical users at any time without a build or deployment everybody wins:

  • The content in the application is richer and much fresher
  • Developers spend time developing rather than making non-code related updates
  • Removing non-feature related deployment distractions gives us more time and makes our teams more agile.
  • Our business users can make their changes at any time which makes the business more agile.

Headless CMS capabilities provide non-technical users with the ability to update, workflow and publish an application’s content at any time without the involvement of developers and IT.

Crafter CMS’s headless capabilities go beyond traditional headless CMS systems by providing authors with an in-context preview for content editing and giving developers the freedom to use whatever front-end technology they want.

CMS for SPAs (2of 4): Save the Content Authors

In Part 1 of the series CMS for SPAs: Are Single Page Applications and Headless CMS a Slam Dunk?  we looked at the trend toward Single Page Applications (SPA) and Headless Content Management Systems (CMS) in general. SPA applications are becoming the de facto way to build web-based applications and sites. Headless CMS is a decoupled, API-first approach to content management that aligns neatly with SPA architecture. Further, the decoupled nature of the architecture makes content more reusable (multi-channel) and completely divorces development from the CMS allowing for greater freedom and agility for developers. While these can be seen as major wins, several developer and DevOps issues remain while others have been created. Further, most of the headless CMS solutions available today set content authors back nearly 20 years in terms of content editing and workflow tooling and practices.

In this installment, we’ll focus on the various ways content authors have been impacted by headless CMS and how Crafter CMS addresses these issues to provide authors with true headless CMS support for SPA applications.

Authors Forced into the Wayback Machine

Clumsy tools and processes for editing, reviewing and testing content offered by headless CMS platforms have content authors, the primary stakeholder of CMS platforms, wondering if they fell asleep and woke up back in the early 2000’s. Let’s take a look at some of the issues facing authors in the Headless CMS space.

Preview and In-Context Editing

Authors are accustomed to easy-to-use tools that enable them to visually locate, edit and publish content in websites or applications. Many headless CMS platforms provide no way for authors to preview their work prior to publishing it. Authors are forced to change content via content entry forms that are completely disconnected from the presentation.  In order to see what the content will look like on the website or in the application, they must publish the content. No author should be forced to work with slow and clumsy deployment iterations just to ensure their content fits and looks good on destination channels. That’s a major step backward.

Some CMS vendors and practitioners argue that by completely obscuring the presentation from the authors, content gets created in a fashion that is naturally more reusable. That’s not necessarily accurate. Content is more reusable when stored and transmitted in a fashion that is divorced from presentation — but that does not mean authors should be forced to ignore how their content will be presented on key channels. As the saying goes: “the medium is the message.” To most authors, the layout is just as important as the content itself. Authors need tools in their headless CMS that are on the level of the tooling they have become accustomed to with more traditional CMS platforms.

Delivering Editing and Preview tools for SPAs

Crafter CMS gives authors a full, interactive in-context preview and editing experience within SPAs. Authors have exactly the same tooling they have become accustomed to with traditional CMS.

Crafter’s preview capability can sit in front of any web-based application. The specific technology does not matter. Crafter’s preview and editing tools are front-end agnostic. One of the key reasons Crafter is able to do this is that Crafter CMS has always separated authoring and delivery into distinct but integrated components. We’ve been assuming a decoupled architecture for years.

Authors are the main users of any CMS and their needs must be properly addressed. A solid authoring experience with true in-context editing and preview is table-stakes for any headless CMS.

Personalization of Headless / API based Content

Another area that Headless CMS platforms have impacted authors is support for targeted/personalized content. Content authors need to be in control of the rules that drive the right content to the right people at the right place and time.

To support personalization your headless CMS must support the following two capabilities:

  • The ability to design, configure or code business rules behind the services.
  • The ability to preview content and functionality driven by personalization rules prior to publishing.

To date, most headless CMS platforms are simple repositories of content that are retrievable by API call. These systems offer no ability to create rules that can be executed based on the request parameter variations and characteristics of the requester.

Further, based on the previous section, we already know that most Headless CMS platforms don’t support pre-publishing preview of content — let alone the ability to preview content and experience as it would appear in different scenarios. There is little point in writing rules or variations of content without the means to properly test them prior to publishing.

Delivering Personalization for SPAs

Crafter CMS provides excellent support for targeted and personalized content even when content is delivered in a headless environment. Authors can configure scenarios and simple rules via the UI or leverage sophisticated rules built-in scripting languages by the development staff. Further, Crafter CMS provides rich preview tools that allow authors to impersonate different users and other types of content consumers within the authoring tools so that content and scenarios can be properly tested well before they are published.

The Need for Real Versioning and Branching

Most CMS platforms (traditional and headless) support some kind of basic versioning.  For the most part that support extends only to a single content item. Each item has its own history.  There is no way to look at the entire content collection at it existed at a specific point in time. That can be a major challenge for authors if they need to reference a previous campaign or support an audit.  The ability to maintain a version history is paramount and rudimentary versioning is typically not enough.

Another key feature that is missing from CMS platforms is the ability to support branches.  Branches allow us to work on different variants of the content at the same time. A branch not only allows concurrent work but it also enables us to sync up variants when it’s appropriate.  This extraordinarily important to authors who are supporting a re-branding or a major content overhaul. Most CMS systems can’t support that without content freezes and manual “double publishes”

Delivering Real Versioning and Branches

Crafter CMS’ repository is based on Git. Git provides authors using Crafter with a versioning system that is multi-file — meaning that an author can see the entire content collection at any moment in time in its history.  Git also provides support for branches which means that authors using Crafter can support difficult operational scenarios like re-brands without any content freezes or extra publishing.

Content freezes and Other Business Interruptions

New features, design refreshes, and integrations are a way of life for today’s customer-focused market. Agility and innovation at scale and speed are key to winning in this competitive landscape. Wherever you have innovation you will find developers and development process along with its procedures, tools, and environments. Businesses want innovation without disruption. Unfortunately with most CMS platforms, due to their architecture, business disruptions are exactly what content authors and other business users end up with. Outages and complicated deployment processes along with content freezes are realities for most innovative organizations use CMS.

When we look at the reason for the disruptions to the business activity we find that the development and testing process requires that we maintain independent testing environments and that we do code deployments. It’s during this maintenance activity that authors are often told to “hold off” or “stay out of the system.” Content freezes waste time and money and they hurt the business. SPAs and Headless CMS platforms do nothing to solve this problem.

In order to get content to lower environments like Dev, QA, and Test we have to take an export of Production. Authors need to stop working during exports. Imports on the lower environments are no fun either. Every environment needs to be painstakingly and individually updated. When coding is complete it has to be rolled out. Once again authors need to refrain from using the system. Complicated deployment procedures and models can take hours, days and in some cases even weeks. More valuable time and money are wasted.

Uninterrupted Business Activities with SPAs

Crafter CMS has an architecture that is different from other CMS platforms. Crafter is designed and implemented with repository technology specifically designed to handle these processes with minimal effort and friction. Crafter CMS leverages Git at its repository layer. In contrast to CMS platforms that rely on databases or JCR repositories that rely on exports and imports that require outages to sync data between environments, Crafter’s repository is meant to be distributed and as such it natively supports syncing between related stores. We call this push button process “Code Forward, Content Back”™ Crafter CMS allows developers along with their tools and process to live and work in harmony with content authors. This enables collaboration together without interruption and with much less friction so that a greater level of innovation and ongoing operations can all take place at the same time.

Conclusion

The net-net of it is simple. Regardless of any improvement in content reusability or ease of development, authors need to be able to do their jobs easily and efficiently without interruption. New tools and approaches need to move the ball forward, not back. Unfortunately for authors, headless CMS has lost major ground.

Some of these shortcomings can be overcome with time but all of the shortcomings we looked at here are architectural in nature. Architecture changes are the most difficult and time-consuming to make. You don’t have to wait for your current headless CMS to correct course. Crafter CMS is an open source headless CMS with the right architecture to take full advantage of the benefits of SPA applications provided to end users and developers while giving authors the tools, process and uninterrupted service they need to succeed.

What has your experience been working with SPAs and your CMS?

CMS for SPAs (1 of 4): Are Single Page Applications and Headless CMS a Slam Dunk?

From web-based applications like Gmail, Instagram, and Google Maps to websites like The New York Times and Facebook; real-world examples of Single Page Applications (SPA) are everywhere you look. Developers have been turning to SPA frameworks and architectures to create better, more usable, richer applications for their users.

Nearly every Content Management System (CMS) out there purports to support SPA frameworks and architectures. In this blog series, we’ll look at SPA use in the CMS space to learn more about what’s working, what’s not and what we can do about it. Let’s jump in.

SPAs are web-based applications built with rich UI frameworks that run client side and use partial page updates rather than full page refreshes to update data, content, and UI. SPAs have several advantages:

  • Great user experience: SPAs make the user experience more fluid with rich UI interactions that leverage asynchronous calls to the server for data and partial page refreshes.

  • Clean architecture: SPAs architecture promotes a clean separation of the frontend application and backend services and data. This approach makes development faster and more flexible.

  • Great frameworks: There are a lot of great frameworks that make developing SPAs faster and easier including React, Angular, Vue and others.

In the CMS space, SPA applications have been a win for developers but content authors have taken a major hit.


Developers have been keen to adopt SPA technology and CMS vendors have quickly responded with support for Headless CMS (also known as Content as a Service [CaaS]) support.

This shift has been highly promoted by CMS vendors because it has a number of advantages with respect to content management. Returning content as JSON or other presentation-less formats makes content more reusable within and across delivery channels. More importantly, by removing the consuming application from the CMS, the approach seems to solve one of the major challenges in the CMS space: development. It’s no secret that most developers have little interest in working within the toolsets and constraints of a CMS. Developers want control over their tools, frameworks, and process. CMS platforms are notoriously framework laden and don’t integrate well with DevOps tools and process.

The headless approach completely and neatly decouples development and content production workflows. On the surface, the headless approach appears to be a perfect evolutionary step for CMS. New delivery channels and integration opportunities show up all the time. In a customer experience driven market, anything that aids development and reduces time to market is seen as a winner.

However, the reality is that decoupling the CMS from the consuming application does not solve long-standing challenges such as refreshing content in lower environments — in fact, it complicates them. Worse, complete decoupling creates new problems. While software development and content production workflows are best divorced, their products: the code and content are not. There is a time/version specific relationship between the data model, the content and the code at any given moment. To illustrate the point: it’s often not possible to “point” an older version of an application at a newer version of the content and vice versa. It’s extremely difficult to troubleshoot or perform legal and regulatory audits without this capability. Yet, with the clear benefits of better products, a cleaner deployment architecture and faster, easier development in mind, the remaining issues are either unrecognized or a compromise many developers are willing to take. For developers, the SPA and headless approach have largely been a win.

The ironic and unfortunate “dirty little secret” in the CMS space of late is that the biggest losers of the headless CMS movement have been the content authors; CMS’s main stakeholder.

Today’s headless CMS options have the following drawbacks for authors:

  • There is no preview. Authors are used to in-context editing and preview. With headless, they are back to working in forms with no preview and are left to hope and a cumbersome process to ensure that the content will present properly.
  • There is no personalization. Marketers want to be able to target and personalize their messaging to the audience. Most headless CMS platforms don’t give them the capability to describe and execute targeting rules much less test and preview the various scenarios.
  • DevOps are still not supported: Despite investments in new technology, tools and process content authors see zero improvements in DevOps activities related to feature releases. Content freezes and outages are still commonplace during feature deployments with headless CMS.

It doesn’t have to be that way! With the right CMS architecture and platform content authors, developers and DevOps can work together on SPA based sites and applications at speed with the tools and processes they are accustomed to (like in-context editing) without stepping on each other’s toes.

A Better Approach to SPAs, CMS and DevOps

Crafter CMS is an open source CMS platform that takes a completely different approach to headless CMS, SPA development and DevOps. Crafter CMS has a very different architecture from traditional CMS platforms that are monolithic and rely on SQL databases and JCR repositories.

Crafter’s architecture is modular, flexible, and completely elastic with a repository and deployment design that is shared-nothing and based on Git. This architecture enables Crafter CMS the flexibility to support content authors, developers and DevOps to collaborate together to build and release new experiences with minimal friction while using the tools and workflows that work best for them.

Crafter CMS is an API first CMS that is:

  • UI agnostic and can support development and editing and preview for any UI framework
  • Capable of supporting rich, personalized headless CMS content
  • Git-based to support your development frameworks, tools, and process in a way that separates development and content production workflows without needing to separate the deployable (code and content) artifacts.

Conclusion

SPA applications combined with decoupled, headless CMS offer significant advantages in terms of end-user experience, development, and deployment. However, it’s clear that headless is not a silver bullet. Completely divorcing the CMS and the consuming application or site creates significant challenges for DevOps, support and other departments. More importantly, the SPA/headless pairing has left authors out in the cold by taking away the process and tools they have become accustomed to over the past decade.

These shortcomings can be addressed with a new breed of CMS architecture. What’s needed is a flexible headless CMS that support proper authoring tools and process regardless of front-end technology. Moreover, we need a CMS that embraces and integrates development tools and process rather than shunning them. That’s exactly what we’ve set out to do with Crafter CMS. Stay tuned for our next blogs in this series where we’ll dive deeper into these concerns and their solutions.

What has your experience been working with SPAs and your CMS?

Introducing Crafter CMS Javascript SDK

Crafter CMS is a headless CMS that provides all of it’s services and capabilities to consumers via RESTful APIs. This enables developers to easily build content support (externalized management of content, strings, media, etc) into any application written in any programming language.

Crafter CMS also supports language-specific (e.g. Java, Groovy, Javascript, .Net, etc) and framework-specific (Angualar6, React, Vue, etc) bindings.  These bindings make the programming model not just simple but native to the language or framework. Using RESTful APIs is easy but native bindings further reduce programming time and complexity by simplifying and reducing the code required to get the job done.

In this blog, we will focus on the language-specific bindings for Javascript, the Crafter CMS Javascript SDK.  These bindings can be used in any client side (e.g. a browser-based application) or server-side (e.g. Node.js) applications.

The High-level Architecture

Before we get into the specifics of the Javascript SDK let’s quickly review the architecture.  Below is a diagram that illustrates how the SDK works in your Javascript application with Crafter Engine and other Crafter CMS components to deliver managed content to your application.

You can learn more about the overall architecture of Crafter CMS here.  In the diagram above we illustrate the following:

  • Authors work in Crafter Studio (a web-based application) to create and manage content.  Crafter Studio provides authors with the tools they need to make updates, perform workflows and publish.  Approved updates can be published to Crafter Engine(s) for content delivery at any time via the UI without any technical assistance.
  • Crafter Engine exposes content, navigation, and structures via RESTful services that are available over HTTP(s).  Content and data are returned to the caller as JSON.
  • The caller in this architecture is Crafter CMS’s Javascript bindings library which is making requests on behalf of the application.
  • The Crafter CMS Javascript SDK provides the application code with Javascript based interfaces and classes to interact with.  There’s no need for the application code to concern itself with REST, JSON and other lower level concepts.

Pre-requisites for Using the Library

  • NPM / Yarn installed
    • The SDK releases are published to Node Package Manager (NPM.)  Example: https://www.npmjs.com/package/@craftercms/content
    • NPM will help you easily download the proper dependencies.  You can all so use NPM or Yarn to build and execute your application.
    • In our example, I will use Yarn to manage my package.json file and to assist me in building my application.
  • Access to a running Crafter Engine instance and site.
    • You may need to configure the site due to CORS (Cross-Origin Resource Sharing constraints within browsers) to allow requests from your application if the app and Crafter Engine are running from different base domains.   We’ll explain this further later.

Building a Simple Javascript Application

The point of our application in this blog is to demonstrate how to include and use Crafter CMS’s Javascript SDK in an application and to use it to retrieve content from a running Crafter Engine instance.   We’re going to keep the application extremely bare bones in order to illustrate that this library is independent of any specific frameworks or platforms such as Node.js, React, Angular6, Vue etc.

For those looking to get right into the meat of the integration, use of the SDK starts at Step 4.

Step 1: Create a basic structure and build for the app

The first thing we want to do is to create a directory for our application source.  I will call my directory simple-js. Inside that directory add a file called package.json with the following content:

{
 "name": "simple-js",
 "version": "1.0.0",
 "description": "Simple JS app that will use Crafter CMS Javascript SDK",
 "main": "index.js",
 "author": "Russ",
 "license": "MIT",
 "dependencies": {
 "@craftercms/classes": "^1.0.0",
 "@craftercms/content": "^1.0.0",
 "@craftercms/models": "^1.0.0",
 "@craftercms/search": "^1.0.0",
 "@craftercms/utils": "^1.0.0"
 },
 "scripts": {
 "test": "echo \"Error: no test specified\" && exit 1",
 "build": "webpack"
 },
 "devDependencies": {
 "webpack": "^4.17.1",
 "webpack-cli": "^3.1.0"
 }
}

 

This file describes our application, how to build it and what is needed to build it.  In the content above we can see:

  • The application metadata.
  • The application dependencies we are requiring are the various Crafter CMS Javascript SDK dependencies ( “@craftercms/content”: “^1.0.0”, “@craftercms/search”: “^1.0.0”, etc.)
  • The application build/dev dependencies that help us compile the application for distribution ( “webpack”: “^4.17.1”, “webpack-cli”: “^3.1.0”.)

Step 2: Perform an initial build

Run yarn in your application directory.  This will download all of your dependencies.

Step 3: Create an application Javascript

Note that in our package.json we’ve listed index.js listed as the main for the application.  Let’s create the src directory and create an index.js in the src directory.

I’ll use the Unix touch command to create the index.js.  This creates an empty file.

Once the file is in place you can run a yarn build command.   This will create a dist folder with a compiled main.js.  The main.js file contains a minified, concatenated set of your dependencies and your script.js code (which is currently empty.)

Step 4: Create an application HTML

Now that our application is building, let’s create a page we can load in a browser and add some basic logic.

In your simple-js directory add a file called index.html with the following content:

 <!doctype html>
 <html>
   <head>
     <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
     <title>Getting Started</title>
   </head>
   <body>
     <script src="./dist/main.js"></script>
   </body>
 </html>

As you can see, all this HTML does is declare the head and body of our page and call the main.js script file.

To make our application a little more interesting, let’s add some basic logic to our script.js file.  Add the following code the src/script.js file:

function component() {
  var element = document.createElement('div');
  element.innerHTML = "Hello World";
  document.body.appendChild(element);
}
component();

Now rebuild your application using the yarn build command and open the index.html file in your browser to see your application running.

Step 4: Calling Crafter CMS API’s with our application

Now that we have a very basic, working application it’s time to use the Crafter CMS Javascript SDK.

Crafter Engine Instance

In order to use the Crafter CMS APIs, you will need a running Crafter Engine instance with a project set up that you have access to.  It’s easy to get started. Here are some helpful links on getting things set up:

CORS: Cross-Site Scripting rules

If you are following this blog step-by-step you are likely running Crafer Engine on localhost and you are loading your HTML file from local disk (e.g. file:///Users/rdanner/code/simple-js/index.html.)

From a browser’s perspective, “http://localhost/…” and “file:///…” are different host domains.  A browser, by default, will stop you from making AJAX calls from code loaded in one domain to a different domain unless the receiving domain gives the browser an OK with the proper HTTP headers. This browser behavior is a protection against CORS (Cross-Origin Requests / Cross Site Scripting) type attacks.

In Crafter CMS, you can set up the proper headers for the receiving server (Crafter Engine) to support this example by taking the following steps:

  1. In Crafter Studio, for your site/project, go to Site Config (found in the Sidebar)
  2. Select the Configuration tool.  In the drop-down select the Engine Site Configuration option.
  3.  Add the following configuration and click the Save at the bottom of the screen.
    <site>
     <!-- CORS Properties -->
     <cors>
       <enable>true</enable>
       <accessControlMaxAge>3600</accessControlMaxAge>
       <accessControlAllowOrigin>*</accessControlAllowOrigin>
       <accessControlAllowMethods>GET\, POST\, PUT</accessControlAllowMethods>
       <accessControlAllowHeaders>Content-Type</accessControlAllowHeaders>
       <accessControlAllowCredentials>true</accessControlAllowCredentials>
     </cors>
    </site>

Import the APIs into your application javascript

Add the following code at the very top of your index.js script file.  Here we are declaring the classes we will use and indicating where they are imported from (the SDK.)

import { ContentStoreService, NavigationService, UrlTransformationService } from '@craftercms/content';
import { crafterConf } from '@craftercms/classes';

Configure the SDK for your Crafter Engine endpoint base URL (server name, port etc)

Now that you have declared the Crafter CMS SDK services you want to use you are almost ready to start retrieving content.  Before we can, we need to make sure the SDK APIs know where Crafter Engine “endpoint” / server is and what site to pull the content from.  To do that we have two options:

  • We can create a configuration object and pass it with each call
  • Or we can explicitly supply the endpoint configuration with each call

Since we’re going to use the same endpoint and site, we’ll set up a configuration object and pass it when we call the APIs.  To configure the endpoint we add the following code to our script after the import statements:

crafterConf.configure({
 site: 'editorial'
});

The configuration above states that our API calls will reference the site in Crafter Engine that has the “editorial” ID. By default, the configuration assumes that Crafter Engine is running locally on port 8080. To change this, add the following:

baseUrl: “YOUR_PROTOCOL//YOUR_DOMAIN:YOUR_PORT ”

crafterConf.configure({
 site: 'editorial',
 baseUrl: "https://mydotcomsite"
});

If you want the system to assume that the app and the API endpoints are on the same server you can set base URL to an empty string (“”)

Call a Crafter CMS API and get content

Make the code changes:

Now that the library is imported and configured, we’re ready to use it.  Let’s add the code to our example to make a request for content and put it on the screen for the user.   Below is the entire index.js script for our application with changes:

import { ContentStoreService, NavigationService, UrlTransformationService } from '@craftercms/content';
import { crafterConf } from '@craftercms/classes';

crafterConf.configure({
 site: 'editorial'
})


function component() {

   ContentStoreService.getItem("/site/website/index.xml", crafterConf.getConfig()).subscribe((respItem) => {
      var element = document.createElement('div');
      element.innerHTML = respItem.descriptorDom.page['hero_title'];
      document.body.appendChild(element);
    })
}

component();

What we’ve done is replace the code in the component function that was hardcoded to write “Hello World” on the screen for the user with the code that calls Crafter CMS for content and write the retrieved content on the screen instead.

Let’s take a closer look at the API call; ContentStoreService.getItem

  • The first parameter is the path of the content item we want to return.  The example uses the home page of the editorial site.
  • The second parameter is our configuration object which supplies the site and endpoint base URL configuration.
  • Lastly, you will note the subscribe operation.The SDK makes asynchronous calls to the Crafter Engine component of Crafter CMS.  Subscribe allows you to supply the code you want to execute when the call returns.  In our example, this is where we create an element, get our content value (hero_title) from the returned response and then update the application with the content.

Compile the code

Once you have updated your code, rebuild the application.

Test the application

After you compile, if you refresh your application you should see content from your Crafter CMS project show up in the updated app!

Congrats!  Your application’s content is now externalized and managed in the CMS.

Step 5: Update your content using the CMS

Now that our code is complete our content authors can update the content at any time via the CMS and we don’t need to rebuild or redeploy the application.  Let’s use Crafter Studio to update the content for our app.   You can find detailed how-to help here:  Creating and working with your First Crafter Site

In Crafter Studio, find the content you want to edit

In our case, the content we’re consuming is the hero title.  Let’s make an edit to that content:
In your site’s content preview, turn on the editing pencils and click the pencil for the Hero Title (as shown above.)


Note that the author has a preview of the content.  This is something very different and ultimately much better than what you see with other Headless CMS systems.

With Crafter, it’s always possible to provide the user with a preview of the content they are editing regardless of the front end framework.  Preview capability is key because it makes editing content easier for authors.

Make a content change and save

After you click the pencil for the Hero text make the change and then click the Save and Close button at the bottom of the form.  You will see your update in the CMS right away.

Refresh the example application

Wow! Those changes in the CMS look great (if I do say so myself :D!)  Now it’s time to see the changes in our application.  Simple, just refresh your application in the browser. No code updates required!

It’s really just that simple!  A few lines of code allows us to create applications with content, configuration and other strings that we can update at any time without needing to update or redeploy our application code.

What about workflow and publishing?

Good question!  Most of the time you want a review and approval process before content updates to applications are made public.  We call this process workflow and publishing. Crafter CMS has workflow and publishing capabilities right out of the box.

To keep our example as simple as possible I kept the architecture simple and we pointed our application directly to Crafter Studio and the preview server on localhost, port 80.

In the configuration above, the API will see updates immediately.    The architecture in the High-Level Architecture section above shows a typical production topology in which updates go through approval workflow and publishing.  Once the content is approved and published it is then available to the application.

Getting to know the SDK API

In our example application, we consumed a single service method from the SDK.  Now that we know how to use the SDK let’s take a look at the various services and service methods the SDK provides:

Service Description
Content Service
(@craftercms/content)
This package contains services for retrieving content and navigation using APIs offered by Crafter CMS.

  • Get a content object and its associated content attributes
  • Get a tree of content objects (children, trees etc)
  • Get dynamic navigation and breadcrumb structures
  • Execute URL transformations

API Specification and examples:
https://www.npmjs.com/package/@craftercms/content

Search Service
(@craftercms/search)
This package contains tools for integrating your application with Crafter Search.

  • Create Crafter Search query objects
  • Execute Crafter Search queries

API Specification and examples:
https://www.npmjs.com/package/@craftercms/search

 Conclusion

Crafter CMS’s Javascript SDK gives front end and full stack developers who work in Javascript and Javascript related technology a native programming API to work with that makes building content-rich applications much easier to do.

When we stop an think about it, almost every application has content in it.  If that content is easy to update and updating the content can be done by non-technical users at any time without a build or deployment everybody wins:

  • The content in the application is richer and much fresher
  • Developers spend time developing rather than making non-code related updates
  • Removing non-feature related deployment distractions gives us more time and makes our teams more agile.
  • Our business users can make their changes at any time which makes the business more agile.

Headless CMS capabilities provide non-technical users with the ability to update, workflow and publish an application’s content at any time without the involvement of developers and IT.

Crafter CMS’s headless capabilities go beyond traditional headless CMS systems by providing authors with an in-context preview for content editing and giving developers the freedom to use whatever front-end technology they want.

 

Integrating Crafter CMS with BitBucket for Better DevOps

Content authoring and software development are both a major part of producing today’s digital experiences. Unfortunately, development support is not something traditional CMS platforms handle very well at scale. Crafter CMS, a 100% open source CMS platform that includes a Git-based repository designed to handle not only authoring but also DevOps seamlessly.

Many development teams use cloud hosted developer platforms like Bitbucket to assist with their development process.   Crafter’s Git based CMS supports developers working against remote repositories like Bitbucket, Gitlab, Github, and others.

By supporting this kind of architecture, Crafter provides a very simple way to flow code forward from a developer and her team all the way up through the CI/CD process to production.  We also support a very simple way for any developer or any environment to easily update itself with the latest content from production.  DevOps and CMS have never been easy — until now. Crafter CMS’s CODE FORWARD, CONTENT BACK™ process makes this process simple and allows you to leverage awesome platforms like Bitbucket to support your team with the tools they know and love.

In this article, I’ll show you how to create a new project in Bitbucket and then start a new project in Crafter CMS in a way that connects to Bitbucket as an upstream remote repository so that Bitbucket can be used to support your development process with your CMS related development! 

Create a New Project and Connect it to BitBucket

Step 1: Create a Project in Bitbucket

Figure 1: Create a project in Bitbucket 

  1. Create project
  2. Enter your project name
  3. Choose your security level
  4. Do not initialize the repository with a readme
  5. Click create site

Once your repository is created you will see a screen similar to the one below.  You want to make note of the Git URL for the site.  You will need this URL in the next step.

Figure 2: New Project in Bitbucket 

Step 2: Create Your Project In Crafter Studio

Next, you want to log in to Crafter Studio as the admin user. The admin user has the rights to create new projects (called sites.) Click Create Site.

Figure 3: Create site via Crafter Studio

Clicking Create Site will present you with the Create Site dialog. This dialog changes depending on what you choose. Below is an example of the dialog filled out in a way that creates your project locally, set the Bitbucket repository as its upstream remote and pushes the initial project contents to the upstream repository.

Let’s walk through each part of the dialog:

Figure 4: Create Site Dialog in Crafter Studio, populating a bare upstream Git repository.

  1. The first thing you need to do is give your site an ID. The ID itself doesn’t matter in a sense. It doesn’t need to match anything per se, technically speaking the only requirement is that it’s unique. That said, it’s a best practice to provide an ID that is meaningful/recognizable to the team. If your website is called Sweet.com a good ID might be “sweetdotcom”
  2. Next, because you plan to connect this project to an upstream repository you want to click the plus (+) on “Link to upstream remote Git repository” This will open a number of new fields.
  3. In the “Remote Git Repository Name” field you want to provide a repository name that makes sense. It’s common to use “origin” or “upstream.”
  4. In the “Remote Git Repository URL” field you must provide the link to the Git repository discussed in Step #1:  https://russdanner@bitbucket.org/russdanner/mysweetdotcom.git
  5. Provide your credentials in Git Remote Repository Username and Password
  6. Choose the option: “Create site based on blueprint then push to  remote bare repository.” This means that Crafter Studio will create a new site based on the blueprint you choose, link the remote repository as an upstream and then once the blueprint is installed in the local Repositories it will be pushed automatically to the upstream remote.
  7. Choose your blueprint. There are several out of the box blueprints provided by default. Choose one of these or one of your own. For our example, we’ll choose Editorial which is the simple Article style website/project template.
  8. Click Create. Crafter CMS will create the local repositories, Solr core and internal data structures required to support the project and install the blueprint. Once complete it will connect to the upstream and push the contents of the Sandbox repository to the remote.

Figure 5: Site is created and the contents of the sandbox are automatically pushed to the upstream repository.

Step 3: Check Bitbucket to Make Sure Your Site is There

Go back to your Bitbucket project and refresh the screen.  You will see the contents of your CMS project in the repository.

Your project is there!

Pushing and Pulling from the Remote Repository

Crafter Studio helps you manage and interact with your remote repositories via the user interface and via API.  Using Crafter Studio’s remote repositories console, you can add any remotes to the project you like and sync with them via pull and push operations at any time.

Now you are ready to set up your entire development process and CI/CD automation.

To learn more about how this is configured check out these blogs:

Creating a Project in Crafter CMS Based on an Existing Bitbucket Project

Let’s consider for a moment that you’re a new developer joining the team. The topology above is already set up and you just want to get a local environment up and going. Simple. Follow these instructions.

  1. Install Crafter Studio locally (Source build or Binaries bundle)
  2. Login as Admin
  3. Click Create Site
  4. Fill out the Create Site Form as in a similar fashion described in Step 2, except this time you chose the option to create your site based on an existing upstream repository. This can be your team’s branch or your own fork. The exact workflow is up to you.

 

Conclusion

Platforms like Bitbucket that support agile development and CI/CD are helping bring best practices to the enterprise with easy to use tools that make implementing these activities simple.

Crafter CMS’s Git-based repository and DevOps integration make it simple to build CMS and content related projects while adhering to DevOps best practices and leveraging today’s best development platforms.

“Code Forward, Content Back” is a trademark of Crafter Software Corporation

Integrating Crafter CMS with GitHub for Better DevOps

Content authoring and software development are both a major part of producing today’s digital experiences. Unfortunately, development support is not something traditional CMS platforms handle very well at scale. Crafter CMS, a 100% open source CMS platform that includes a Git-based repository designed to handle not only authoring but also DevOps seamlessly.

Many development teams use cloud hosted developer platforms like Github to assist with their development process.   Crafter’s Git based CMS supports developers working against remote repositories like Github, Gitlab, Bitbucket, and others.

By supporting this kind of architecture, Crafter provides a very simple way to flow code forward from a developer and her team all the way up through the CI/CD process to production.  We also support a very simple way for any developer or any environment to easily update itself with the latest content from production.  DevOps and CMS have never been easy — until now. Crafter CMS’s CODE FORWARD, CONTENT BACK™ process makes this process simple and allows you to leverage awesome platforms like Github to support your team with the tools they know and love.

In this article, I’ll show you how to create a new project in Github and then start a new project in Crafter CMS in a way that connects to Github as an upstream remote repository so that Github can be used to support your development process with your CMS related development! 

Create a New Project and Connect it to Github

Step 1: Create a Project in Github

Figure 1: Create a project in Github 

  1. Select Blank Project to create a bare project
  2. Enter your project name
  3. Provide a project description
  4. Choose your security level
  5. Do not initialize the repository with a readme
  6. Click create site

Once your repository is created you will see a screen similar to the one below.  You want to make note of the Git URL for the site.  You will need this URL in the next step.

Figure 2: New Project in Github 

Step 2: Create Your Project In Crafter Studio

Next, you want to log in to Crafter Studio as the admin user. The admin user has the rights to create new projects (called sites.) Click Create Site.

Figure 3: Create site via Crafter Studio

Clicking Create Site will present you with the Create Site dialog. This dialog changes depending on what you choose. Below is an example of the dialog filled out in a way that creates your project locally, set the Github repository as its upstream remote and pushes the initial project contents to the upstream repository.

Let’s walk through each part of the dialog:

Figure 4: Create Site Dialog in Crafter Studio, populating a bare upstream Git repository.

  1. The first thing you need to do is give your site an ID. The ID itself doesn’t matter in a sense. It doesn’t need to match anything per se, technically speaking the only requirement is that it’s unique. That said, it’s a best practice to provide an ID that is meaningful/recognizable to the team. If your website is called Sweet.com a good ID might be “sweetdotcom”
  2. Next, because you plan to connect this project to an upstream repository you want to click the plus (+) on “Link to upstream remote Git repository” This will open a number of new fields.
  3. In the “Remote Git Repository Name” field you want to provide a repository name that makes sense. It’s common to use “origin” or “upstream.”
  4. In the “Remote Git Repository URL” field you must provide the link to the Git repository discussed in Step #1: https://github.com/russdanner/mysweetdotcom.git
  5. Provide your credentials in Git Remote Repository Username and Password
  6. Choose the option: “Create site based on blueprint then push to  remote bare repository.” This means that Crafter Studio will create a new site based on the blueprint you choose, link the remote repository as an upstream and then once the blueprint is installed in the local Repositories it will be pushed automatically to the upstream remote.
  7. Choose your blueprint. There are several out of the box blueprints provided by default. Choose one of these or one of your own. For our example, we’ll choose Editorial which is the simple Article style website/project template.
  8. Click Create. Crafter CMS will create the local repositories, Solr core and internal data structures required to support the project and install the blueprint. Once complete it will connect to the upstream and push the contents of the Sandbox repository to the remote.

Figure 5: Site is created and the contents of the sandbox are automatically pushed to the upstream repository.

Step 3: Check GitHub to Make Sure Your Site is There

Go back to your Github project and refresh the screen.  You will see the contents of your CMS project in the repository.

Your project is there!

Pushing and Pulling from the Remote Repository

Crafter Studio helps you manage and interact with your remote repositories via the user interface and via API.  Using Crafter Studio’s remote repositories console, you can add any remotes to the project you like and sync with them via pull and push operations at any time.

 

 

 

Now you are ready to set up your entire development process and CI/CD automation.

To learn more about how this is configured check out these blogs:

Creating a Project in Crafter CMS Based on an Existing GitHub Project

Let’s consider for a moment that you’re a new developer joining the team. The topology above is already set up and you just want to get a local environment up and going. Simple. Follow these instructions.

  1. Install Crafter Studio locally (Source build or Binaries bundle)
  2. Login as Admin
  3. Click Create Site
  4. Fill out the Create Site Form as in a similar fashion described in Step 2, except this time you chose the option to create your site based on an existing upstream repository. This can be your team’s branch or your own fork. The exact workflow is up to you.

 

Conclusion

Platforms like GitHub that support agile development and CI/CD are helping bring best practices to the enterprise with easy to use tools that make implementing these activities simple.

Crafter CMS’s Git-based repository and DevOps integration make it simple to build CMS and content related projects while adhering to DevOps best practices and leveraging today’s best development platforms.

“Code Forward, Content Back” is a trademark of Crafter Software Corporation

Integrate Crafter CMS with Jenkins to Automate DevOps: Code Forward, Content Back Process

Great DevOps helps us build better software products faster. One of the key elements of DevOps is automation within the development process across lower development environments.  Jenkins, Bamboo, Travis and many others platforms like them are used by DevOps teams to help automate the process of Continous Integration and Continous Delivery (CI/CD). To a large degree, real support for CI/CD and agile development is something that is woefully missing in Content Management, a core component of digital experience platforms.  The toolset and the architecture of today’s content management platforms make it difficult, sometimes near impossible to support let alone automate. How easy is it for your team to take content from the Production CMS and update content in lower environments like Dev, QA?  How easy is it to roll out new features?  Often times this process is not only laborious for the DevOps team, it also halts the content authoring process.    Crafter CMS’s, an open source CMS Git-based repository and Java/Spring and Groovy-backed stack are a game changer in this regard.  Further, Crafter integrates directly into to your CI/CD process.  In this article, using Jenkins as our example we’ll demonstrate how you can connect your production CMS to your developer workflow to facilitate Code Forward, Content Back(TM) workflow.
You can read more about this process in detail here:

Although our example is based on Jenkins, the scripts and flow used in this blog are applicable to nearly any automation

Understanding Where Code Forward, Content Back Automation Fits

The fact is that every step of your DevOps process is open to automation.  In this section, we’ll cover the common points of integration, specifically:

  • The point in the process where you want to move content from your production CMS “back” to lower environments to support development and testing.
  • The point where you want to promote code “forward” from the development process to the production CMS so it can be published.

Both of these points in the process are illustrated and addressed in the diagram below by the double-headed arrow labeled Code Forward, Content back.   With respect to the CMS, Code Forward, Content Back is the most important aspect of the DevOps automation.

Crafter CMS’s Git-based repository is the foundation of the automation.  Our automation running in Jenkins is going to leverage API’s within the authoring environment (Crafter Studio) to sync code and content with the development process.  APIs will also be used to publish code synced to authoring to the Production delivery infrastructure.

Implementing Code Forward, Content Back Sync

Now that we’ve established what integration we’re addressing here is, let’s focus on configuring it.  Take a look at the diagram below, this elaborates the previous diagram showing how the sync occurs.

Note that both the Production authoring and the Development “environment” has a repository.  In authoring, this is a local Git repository.  In development, this is most often a centrally hosted Git repository that supports workflow and review (like Bitbucket, Gitlab, Github, and others.)   You can think of the repository under authoring as the Content Repository and the repository supporting developers as the Code Repository.  These names (Content Repository, Code Repository) are simply labels to help describe their purpose and assist us in addressing them in the context of this article.

To facilitate this flow, the Content Repository under authoring/Crafter Studio declares the Code Repository as a remote. The primary way of “syncing” work between Git repositories is through pull and push operations.  Before you can push your work to a remote, you must first pull merge the updates (if any) from the remote.  Once done, you can push your changes to the remote.

Automating the Pull / Push of Code and Content

To help automate the process described above Crafter Studio, the authoring and repository component of Crafter CMS supports a set of APIs.  You can find a full listing of Crafter Studio APIs for Crafter 3.0 here: http://docs.craftercms.org/en/3.0/developers/projects/studio/index.html

These APIs are easily invoked by a script.   You can use the following example script in your own implementation:

codeforward-contentback-sync.sh

#!/usr/bin/env bash
studioUsername=$1
studioPassword=$2
studioserver=$3
project=$4
remote=$5
branch=$6

echo "Authenticating with authoring"
rm session.txt
curl -d '{ "username":"'$studioUsername'", "password":"'$studioPassword'" }' --cookie-jar session.txt --cookie "XSRF-TOKEN=A_VALUE" --header "X-XSRF-TOKEN:A_VALUE" --header "Content-Type: application/json"  -X POST $studioserver/studio/api/1/services/api/1/security/login.json

echo "Pull from remote (get code waiting to come to sandbox)"
curl -d '{ "site_id" :"'$project'", "remote_name":"'$remote'", "remote_branch":"'$branch'" }' --cookie session.txt --cookie "XSRF-TOKEN=A_VALUE"  --header "Content-Type: application/json" --header "X-XSRF-TOKEN:A_VALUE" -X POST $studioserver/studio/api/1/services/api/1/repo/pull-from-remote.json

echo "Push to remote (send content waiting to go to development)"
curl -d '{ "site_id" :"'$project'", "remote_name":"'$remote'", "remote_branch":"'$branch'" }' --cookie session.txt --cookie "XSRF-TOKEN=A_VALUE"  --header "Content-Type: application/json" --header "X-XSRF-TOKEN:A_VALUE" -X POST $studioserver/studio/api/1/services/api/1/repo/push-to-remote.json

Use of the script:

codeforward-contentback-sync.sh [USERNAME] [PASSWORD] [AUTHOR_SERVER_AND_PORT]  [SITE_ID] [REMOTE_NAME] [BRANCH_NAME]

USER_NAME is the Studio user (application account)
PASSWORD is the Studio user password (application account)
AUTHOR_SERVER_AND_PORT the protocol server name and port of Studio
SITE_ID the ID of the site
REMOTE_NAME the name of the upstream (typically origin)
BRANCH_NAME the name of the branch (typically master)

Example:
codeforward-contentback-sync.sh devops mydevopspw http://localhost myprojectID origin master

The script is quite simple.  It authenticates to Crafter Studio, performs a pull from the Remote Code Repository and then if there are no conflicts, performs a push.  These two operations move code updates forward to the production Sandbox (not yet live) and content back to the development process.  Only approved code that’s been moved to the “master” branch with the intention to release is moved forward.

Calling the Script in Jenkins

The first step is to create a project.  Give the project a clear name and select the Freestyle project then click OK to continue.

There is no Source Code Management (SCM) aspect of the project.  The most typical use case for Content back workflow is a scheduled event: Every hour, day, week etc.

 

The next step is to define build triggers.  Since you are calling APIs here and content back is most likely based on some schedule you define you want to indicate that there is no Source Code Management (SCM) aspect of the project.

Select “Build Periodically” and define your schedule.  Schedule definitions user standard Cron/Quartz configuration.

Finally, you must define that you want Jenkins to call your script:

Once you have done these steps you are ready to go.  Manually invoke this build any time you want directly through the Jenkins console.  I recommend testing it to make sure your parameters and schedule are correct.

Publishing Code That’s Been Sync’d to Sandbox

When you run the code forward, content back process code in the remote code repository is moved to the production authoring sandbox (content repository.)  This code is now staged for publishing.  It is not yet live.  Crafter Studio must publish the code, making it available to your delivery servers.  This in-and-of-itself is awesome: global, elastic deployment at the touch of a button.

So how is it done?  Crafter Studio provides an API that allows you to publish commit IDs.  You can provide a single commit ID or you can provide a list.  It’s typical as part of your release process to “Squash” all of the commits in a given release into a single commit ID.  This allows you to address all of the work as a single ID/moniker which makes it very easy to move, publish and roll back without missing anything.

These APIs are easily invoked by a script.   You can use the following example script in your own implementation:

publish-code.sh

#!/usr/bin/env bash
studioUsername=$1
studioPassword=$2
xsrf=AUTOMATED
studioserver=$3
project=$4
env="Live"
commit=$5

echo "Authenticating with authoring"
rm session.txt
curl -d '{ "username":"'$studioUsername'", "password":"'$studioPassword'" }' --cookie-jar session.txt --cookie "XSRF-TOKEN=A_VALUE" --header "X-XSRF-TOKEN:A_VALUE" --header "Content-Type: application/json"  -X POST $studioserver/studio/api/1/services/api/1/security/login.json

echo "Publishing Commit $commit"
curl -d '{ "site_id" :"'$project'", "environment":"'$env'", "commit_ids": ["'$commit'"] }' --cookie session.txt --cookie "XSRF-TOKEN=A_VALUE"  --header "Content-Type: application/json" --header "X-XSRF-TOKEN:A_VALUE" -X POST $studioserver/studio/api/1/services/api/1/publish/commits.json

Use of the script:

publish-code.sh [USERNAME] [PASSWORD] [AUTHOR_SERVER_AND_PORT]  [SITE_ID] [COMMIT_ID] 

USER_NAME is the Studio user (application account)
PASSWORD is the Studio user password (application account)
AUTHOR_SERVER_AND_PORT the protocol server name and port of Studio
SITE_ID the ID of the site
COMMIT_ID the squashed commit ID of the items coming from the release branch

Example:
publish-code.sh devops mydevopspw http://localhost myprojectID 378d0fc4c495b66de9820bd9af6387a1dcf636b8

The script is quite simple.  It authenticates to Crafter Studio and invokes a publish for the provided commit.  This op

Calling the Script in Jenkins

See configuration of sync script above.  The steps are exactly the same with the following differences:

  1. You will call the publish-code script instead of the codeforward-contentback script.
  2. You will ask the user for a parameter  value COMMIT_ID via the UI on each invocation and pass that to the command line as the COMMIT_ID parameter value

 

 

That’s it!  You can now publish your code releases via commits to your entire delivery infrastructure regardless of its size or distribution.

Conclusion

CMS platforms are notorious for refusing to play nice with CI/CD and agile development practices and process, automation and tools like Jenkins, Bamboo, Travis and others.  Databases and JCR repositories are one component of several fundamental, architectural limitations that make supporting CI/CD difficult for CMS platforms. Crafter is an open source, dynamic CMS with a unique Git based repository specifically designed to fit neatly in to your development practices and bring your authoring and development teams together in a way never before possible to improve and increase the rate and volume of innovation!

Crafter CMS: Custom Styles in Your RTE

Crafter CMS’s Rich Text Editor (RTE) applies your styles right in line.  There’s no need to save and preview before you can see your changes.  Along with that, administrators want to be able to configure what styles authors can apply.

Each RTE can be configured independently.

To configure your styles, take the following steps:

  1. Go to the Site Config console for your project.

 

To configure the RTE, within the Site Config console, select configuration and choose RTE configuration from the drop-down.

In the specific “setup” for your RTE, add the styleFormats tag with the configuration you require.  Example:

 <styleFormats>
 <![CDATA[
   [{title : 'Bold text', inline : 'b'}, 
    {title : 'Red text', inline : 'span', styles : {color : '#ff0000'}}, 
    {title : 'Red header', block : 'h1', styles : {color : '#ff0000'}}, 
    {title : 'Example 1', inline :'span', classes : 'example1'}, 
    {title : 'Example 2', inline :'span', classes : 'example2'}, 
    {title : 'Image styles'}, 
       {title : 'Circular', selector : 'img', classes : 'img-circ'},
    {title : 'Table styles'}, 
       {title : 'Table row 1', selector : 'tr', classes : 'tablerow1'}]
    ]]>
 </styleFormats>

Note the ability to create categories in the example above.  Taking time to organize the styles for authors is extremely helpful to them.

Now add style select to the toolbar

<toolbarItems1>
 formatselect, styleselect,|,bold,italic,underline,strikethrough,|,sub,sup,charmap,|,outdent,indent,blockquote,|,justifyleft,justifycenter,justifyright,justifyfull,|,bullist,numlist,|,managedImage,link,unlink,anchor,|,edithtml,|,undo,redo
 </toolbarItems1>

Once you save the configuration, open your content and test.  Your updates will be present.

Integrating Crafter CMS with GitLab for Better DevOps

Content authoring and software development are both a major part of producing today’s digital experiences. Unfortunately, development support is not something traditional CMS platforms handle very well at scale. Crafter CMS, a 100% open source CMS platform that includes a Git-based repository designed to handle not only authoring but also DevOps seamlessly.

Many development teams use cloud hosted developer platforms like GitLab to assist with their development process.   Crafter’s Git based CMS supports developers working against remote repositories like GitLab, Github, Bitbucket, and others.

By supporting this kind of architecture, Crafter provides a very simple way to flow code forward from a developer and her team all the way up through the CI/CD process to production.  We also support a very simple way for any developer or any environment to easily update itself with the latest content from production.  DevOps and CMS have never been easy — until now. Crafter CMS’s CODE FORWARD, CONTENT BACK™ process makes this process simple and allows you to leverage awesome platforms like GitLab to support your team with the tools they know and love.

In this article, I’ll show you how to create a new project in GitLab and then start a new project in Crafter CMS in a way that connects to GitLab as an upstream remote repository so that GitLab can be used to support your development process with your CMS related development! 

Create a New Project and Connect it to GitLab

Step 1: Create a Project in GitLab

Figure 1: Create a project in GitLab 

  1. Select Blank Project to create a bare project
  2. Enter your project name
  3. Provide a project description
  4. Choose your security level
  5. Click create site

Once your repository is created you will see a screen similar to the one below.  You want to make note of the Git URL for the site.  You will need this URL in the next step.

Figure 2: New Project in GitLab 

Step 2: Create Your Project In Crafter Studio

Next, you want to log in to Crafter Studio as the admin user. The admin user has the rights to create new projects (called sites.) Click Create Site.

Figure 3: Create site via Crafter Studio

Clicking Create Site will present you with the Create Site dialog. This dialog changes depending on what you choose. Below is an example of the dialog filled out in a way that creates your project locally, set the Github repository as its upstream remote and pushes the initial project contents to the upstream repository.

Let’s walk through each part of the dialog:

Figure 4: Create Site Dialog in Crafter Studio, populating a bare upstream Git repository.

  1. The first thing you need to do is give your site an ID. The ID itself doesn’t matter in a sense. It doesn’t need to match anything per se, technically speaking the only requirement is that it’s unique. That said, it’s a best practice to provide an ID that is meaningful/recognizable to the team. If your website is called Sweet.com a good ID might be “sweetdotcom”
  2. Next, because you plan to connect this project to an upstream repository you want to click the plus (+) on “Link to upstream remote Git repository” This will open a number of new fields.
  3. In the “Remote Git Repository Name” field you want to provide a repository name that makes sense. It’s common to use “origin” or “upstream.”
  4. In the “Remote Git Repository URL” field you must provide the link to the Git repository discussed in Step #1: https://gitlab.com/russdanner/sweet-dotcom.git
  5. Provide your credentials in Git Remote Repository Username and Password
  6. Choose the option: “Create site based on blueprint then push to  remote bare repository.” This means that Crafter Studio will create a new site based on the blueprint you choose, link the remote repository as an upstream and then once the blueprint is installed in the local Repositories it will be pushed automatically to the upstream remote.
  7. Choose your blueprint. There are several out of the box blueprints provided by default. Choose one of these or one of your own. For our example, we’ll choose Editorial which is the simple Article style website/project template.
  8. Click Create. Crafter CMS will create the local repositories, Solr core and internal data structures required to support the project and install the blueprint. Once complete it will connect to the upstream and push the contents of the Sandbox repository to the remote.

Figure 5: Site is created and the contents of the sandbox are automatically pushed to the upstream repository.

Step 3: Check GitLab to Make Sure Your Site is There

Go back to your GitLab project and refresh the screen.  You will see the contents of your CMS project in the repository.

Your project is there!  Now you are ready to set up your entire development process and CI/CD automation.  To learn more about how this is configured check out these blogs:

Creating a Project in Crafter CMS Based on an Existing GitLab Project

Let’s consider for a moment that you’re a new developer joining the team. The topology above is already set up and you just want to get a local environment up and going. Simple. Follow these instructions.

  1. Install Crafter Studio locally (Source build or Binaries bundle)
  2. Login as Admin
  3. Click Create Site
  4. Fill out the Create Site Form as in a similar fashion described in Step 2, except this time you chose the option to create your site based on an existing upstream repository. This can be your team’s branch or your own fork. The exact workflow is up to you.

Conclusion

Platforms like GitLab that support agile development and CI/CD are helping bring best practices to the enterprise with easy to use tools that make implementing these activities simple.

Crafter CMS’s Git-based repository and DevOps integration make it simple to build CMS and content related projects while adhering to DevOps best practices and leveraging today’s best development platforms.

“Code Forward, Content Back” is a trademark of Crafter Software Corporation

Using Crafter CMS. Github and Two-Factor Authentication

Crafter’s Git based CMS supports developers working against remote repositories like Github, Gitlab, Bitbucket, and others. Many organizations that use Github enforce a two-factor authentication for developers.  This article shows you how to create a site in Crafter when you have two-factor authentication in Github configured.

Step 1: Configure an Access Token in Github

If you are reading this article, it’s very likely you already have two-factor authentication configured and are using it with Github.  If you’re interested in setting it up you can learn more about that here:
https://help.github.com/articles/securing-your-account-with-two-factor-authentication-2fa/ 

The first step in getting Crafter Studio to work with Github when two-factor authentication is enabled is to create a personal access token.  Follow the instructions shown here to create and acquire your token:   https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/

Step 2: Create a Site based on a Remote Repository

  1. If Crafter CMS is not installed: Install it locally (Source build or Binaries bundle)
  2. Login as Admin user

Next, you want to log in to Crafter Studio as the admin user. The admin user has the rights to create new projects (called sites.) Click Create Site.

Figure 1: Create site via Crafter Studio

Clicking Create Site will present you with the Create Site dialog. This dialog changes depending on what you choose. Below is an example of the dialog filled out in a way that creates your project locally based on an upstream repository that becomes it’s remote.

Let’s walk through each part of the dialog:

Figure 2: Set up a project based on existing remote Git repository via Crafter Studio

  1. The first thing you need to do is give your site an ID. The ID itself doesn’t matter in a sense. It doesn’t need to match anything per se, technically speaking the only requirement is that it’s unique. That said, it’s a best practice to provide an ID that is meaningful/recognizable to the team. If your website is called FreshFlowers.com a good ID might be “freshflowerscom”
  2. Next, because you plan to connect this project to an upstream repository you want to click the plus (+) on “Link to upstream remote Git repository” This will open a number of new fields.
  3. In the “Remote Git Repository Name” field you want to provide a repository name that makes sense. It’s common to use “origin” or “upstream.”
  4. In the “Remote Git Repository URL” field you must provide the link to the Git repository discussed in Step #1: https://github.com/russdanner/devworkflowexample.git

  5. Provide your credentials in Git Remote Repository Username and Password
    USE THE PERSONAL ACCESS TOKEN
  6. Choose the option: “Create site based on remote git repository.” This means that Crafter Studio will create a new site by cloning the upstream repository locally and setting the upstream repository as a remote.
  7. Click Create. Crafter CMS will create the local repositories, Solr core and internal data structures required to support the project and pull in the project from the remote.