Editor Configuration Contributor

Tags and content disappearing from web content 

Web content is a pretty general way to characterize a piece of structured content that can be easily reused in Liferay. It is only natural that people will use it for their specific needs to solve their own problems in different ways. In this small article, we will see how to change a key aspect of editors to solve an issue that emerges exactly because people have varied requirements for their systems. More specifically, we will discuss what is going on when tags and content appear to be disappearing from web content after we save it.

The key point here is that one cannot add any arbitrary piece of content in a web content item. At a first glance, this may look like a bug or something undesirable when creating content to be published. But one needs to realize that there are several actors using those web based editors in a system, some might not even be aware they are generating HTML code behind the scenes. If everything was allowed, one could intentionally or unaware of their actions be polluting the system with lots of garbage generated outside the system, when copying and pasting, for instance. Syntax errors would be a constant and security issues would definitely come to life depending of who has access to the editor and/or how it is used, XSS would come up as easily as creating the content itself.

However, some systems do have especial requirements and one might need to change how the editor works to avoid the removal of certain pieces of content during the clean up phase that will take place after we save web content items.

Let's say we need the ability to include forms in web content items, or maybe something less dangerous like classes for HTML tags. The following example shows how to create a contributor that will add an exception for creating web content items to address those types of requirements. Particularly, this example will include forms as allowed inside instances of the Alloy and CK editors.

@Component( immediate = true,
			property = {
					"javax.portlet.name=" + JournalPortletKeys.JOURNAL,
					"javax.portlet.name=" + JournalContentPortletKeys.JOURNAL_CONTENT,
			service = EditorConfigContributor.class )
public class FormEditorConfigContributor extends BaseEditorConfigContributor {

	private final static String allowedContentForm = "form[*](*); input [*](*);";

	public void populateConfigJSONObject( JSONObject jsonObject, Map< String, Object > inputEditorTaglibAttributes, ThemeDisplay themeDisplay, RequestBackedPortletURLFactory requestBackedPortletURLFactory ) {

		StringBundler sb = new StringBundler(  );

		sb.append( allowedContentForm );

		jsonObject.put( "extraAllowedContent", sb.toString( ) );


The idea is simple, the editor's configuration is provided inside the JSON object, which will receive the new rule for allowing the HTML tags we need following the editor's syntax. Here, we are adding an exception for allowing forms and input elements.

More Blog Entries


Adel Adel 1 Year Ago

Hello Victor, Thank you for this work! I think the best way to visualize the logs is with a tool like ELK Stack.

Can you give us a tutorial on integrating liferay into ELK Stack and NGNIX. Thank you again for the work you do.

Victor L. Soares 1 Year ago in reply to Adel Adel .


Sure thing! we actually have an ELK stack on our way in our roadmap, we do use internally but have not made a full distribution image yet. The next image (02/22) will come with log4j2 as tomcat's default logging mechanism to make ELK easier as well. After the release we will publish extra content on logging. ELK however is on the roadmap for 2 releases from now. (you get updates like that if you have our docker subscription for our liferay images, but we will publish guides in the blog too) 

Adel Adel 1 Year ago in reply to Victor L. Soares .

It's awesome ! I am impatient.

Thank you for your quick reply!