Friday, July 1, 2016

User/anonymous generated content in Sitecore

User generated content from site visitors might be as simple as a comment on a news article, or more complex such as the submission of structured content (a community venue listing for example). The only question then becomes how to handle the user/anonymous generated content in Sitecore.

There are many different options available for getting content entered by users into Sitecore and a lot of it comes down to the server/network infrastructure and even the amount/load of data being entered. Of course on single server environments you could simply add an item directly to the master database. However with scaled environments where the master connection is not available on content delivery servers there are about adding content.

Web forms for marketers

The web forms for marketers module is a simple way to allow site visitors to enter data into a form and then have that create the content items in Sitecore. This can further be expanded to use workflow which ensures the content is approved before being published along with the use of event handlers for any other business logic. 

Please note that on scaled environments, WFFM uses a custom service to communicate from content delivery to the content management server. Some secure server environments may require port 80 be opened between the servers (which can be locked down to specific IP addresses).

Sitecore item web API

The Sitecore item web API is an HTTP rest-style web service (that outputs JSON) which allows you to manipulate Sitecore content. This would allow content to be created on content delivery server(s) servers by utilising the item web API on the content management server. It would be as simple as creating a new item in a given location of a given template, then approval workflows could be used to get the item back to the web database.

Item handlers can also be used to add more business logic onto this user generated content.

It's important to note that the sc_database parameter should be set to master to ensure the content goes into the correct location.

This is arguably a more legacy option (compared to Sitecore.Services.Client), however it will do the basic manipulation of items needed for user generated content creation in Sitecore.


The Sitecore.Services.Client is available on both the server side and client side of Sitecore. It is configurable/extendable and allows for client - server item manipulation in a clean and consistent way.

Effectively you will be able to use this service (either via client-side JaavScript or Restful API direct) to manipulate (CRUD) content via connecting to the CM instance. It has the features offered via the item web API, however allows for a bit more power when it comes to custom business objects and should save item over writing your own API.

Custom SQL database

In some cases creating a custom database in SQL Server (perhaps mapped in code using entity framework) is the cleanest solution. This option is generally better when using a Sitecore item does not make sense, especially in cases where there are large amounts of data/business logic. The benefits include: less load on Sitecore CMS, ability to have custom database/table structure, ability to use stored procedures and functions (more decoupled business logic) and of course the ability to index the relevant fields at the database level.

An example of where I have used this concept before is with registration of public users, the custom SQL Server database was used to store rows of user registration/password reset requests. It made more sense in SQL because the code would only query a single line item at a time, and once we deal with large amounts of users it could affect Sitecore performance.

Additional Sitecore database

Much like Sitecore already has core, master and web databases it's actually possible for you to add your own custom one. This blog post, goes over the concept of adding an additional Sitecore database called products. The benefit here is that content delivery servers will be able to access this database and it one of the cleanest solutions in terms of custom code needed. The real draw card however is in terms of search indexing of the content in this database, you can target it and allow for fast data access via Lucene. 


MongoDB is an option for storing user generated content with Sitecore, and all servers in a scaled environment will have access to it. This would be ideal for larger amounts of data, particularly that which is written constantly. It means however that code will need to be written to handle the CRUD of data along with ensuring backups/MongoDB replication is configured correctly.


There are a number of different options for creating user (anonymous) generated content in Sitecore and the decision will often come down to network/server architecture and the level of requirements. A high level overview of a number of options has been discussed above, and more research may be required to implement a solution in your Sitecore implementation. 

I didn't discuss it in this article, but custom services are also an option, and they can wrap around any of the options above,

No comments:

Post a Comment