Changing Primitive Field Type From Text to HTML

Issue

Developers have this request when there is a requirement to modify a document field type, for example from "Text" to "HTML."

Possible Reasons

• When there is a requirement to modify the primitive field type from Text to HTML.
• This change of field type from one to another can be made in any environment.

Regarding HTML type fields, there are two types of HTML fields in Bloomreach Experience Manager: formatted text and rich text. Formatted text fields only allow simple text editing, and do not support links or images. Rich text fields allow all possible markup, including links and images. 

Solution

 Writing a groovy script is the best approach to achieve this, if manual data transmission is not necessary.

It requires:

• Deployment of a new version, introducing the new field in the doc type by yaml bootstrapping
• After deployment, running a Groovy script to change the structure of existing document instances

The HTML field is node and bean returns a wrapper bean, HippoHtml instead of string. Therefore, you need to modify frontend code (ftl templates, or react/angular etc. in case you are using SPA).

 String propertyName = "yourproject:stringproperty";

        if(document.hasProperty(propertyName)) {

Property property = document.getProperty(propertyName);

String value = property.getString();

property.remove();

// same name as html node:

Node htmlNode = node.addNode(propertyName,"hippostd:html");

htmlNode.setProperty("hippostd:content", value);

Node contentNode = htmlNode.addNode("hippostd:html");

contentNode.setProperty("hippostd:content", value);

return true;

   }

The tree structure of HTML field like :

<sv:node sv:name="bloat:introduction">

<sv:property sv:name="jcr:primaryType" sv:type="Name">

<sv:value>hippostd:html</sv:value>

</sv:property>

<sv:property sv:name="hippostd:content" sv:type="String">

<sv:value>SOME HTML

 Alternative Solution

The method for adding a new field (name should be different) is a similar process, and you also need to change the templates.

The only distinction would be that, in the event of a new name, you can keep your previous values and your frontend will work as is and you can add frontend changes later.