5

We are in process of migrating the Java Vigenette CMS on to sitecore platform. One of the thing that current content authors have been doing is below for short lived sites:

  1. Get the zipped HTML site from Digital Agencies.
  2. Content authors then simply extract it on CMS and site is up and running. (with no developer involvement)

We had a look at sitecore experience accelerator, which isn't going to fit.

We are thinking of simply unzipping the file on to media library and do and redirect setup.

Has anyone got better idea/experience?

5
  • Is it purely static html files? Dec 13, 2016 at 6:43
  • 2
    Could you please clarify how this is Sitecore-related? Why do you need to host these HTML files as part of your Sitecore instance? Dec 13, 2016 at 7:04
  • So that we dont need to worry about hosting, deployment
    – Nil Pun
    Dec 13, 2016 at 8:04
  • 3
    Just write a desktop application that allows the users to upload the zip file, unzip it and store the files on disk. Storing in the media library will just add extra overhead and stress on the Sitecore server. Pointless for just static html files IMO.
    – Richard Seal
    Dec 13, 2016 at 14:18
  • 1
    I agree completely, @RichardSeal. That's why my recommended solution is the File System one in my answer :) Dec 13, 2016 at 16:03

2 Answers 2

6

This can a tricky situation with a lot of possible soltuions, and I have had to work through this several times before, myself. SXA definitely isn't right for this solution, but one of the below might be.

Pre-Implementation Considerations

  • Will the client want/need to modify the HTML in the Content Editor, i.e. will they need to modify it on their own
  • Does the client have experience with HTML, where they can control their HTML as needed, or will an RTE be required?
  • Will you need to content manage any of the page around the HTML, i.e. will you be using a Sitecore controlled header or footer, etc.

To RTE or Not to RTE

Sitecore Rich Text Editor is great...until it isn't. First off, you should only consider using it if you are going to manage other content on the page. Don't use an RTE for the entire page. From the standpoint of content entry and formatting rich text content, Sitecore's implementation of the Telerik editor does a pretty decent job and even lets you add your own HTML. If you client will need to modify the HTML on their own but doesn't have the HTML knowledge to do this without a GUI then the RTE is going to have to suffice.

However, Sitecore's RTE also has many problems for managing HTML content. First off, the RTE will change your HTML as it sees fit, in order to best approximate what it thinks your editors want. This means that if you have scripts that are dependent on the HTML then you risk those scripts breaking, you could risk your styles being broken or CSS bugs being introduced, and so on. Basically, this works well for a well-defined and bounded section of content being managed for a page with a consistent overall design and structure, but it doesn't work all that well for an entire page being managed.

To @TamasTarnok's point, yes, disabling scripts in your RTE field is a possibility, but it wouldn't be my recommended approach since you can't disable scripts for just those fields that you want to use to store the HTML content of a page. Rather, you have to disable the scripts for all fields. There is a reason why Sitecore disables scripts in this field by default. If you can avoid it, I wouldn't change it. If, however, your client does need the ability to modify the HTML content on their own and cannot do so without an RTE GUI then this option is worth consideration.

The Multiline Text Field Type

The Multiline Text field type would be my recommended approach, if you plan to content manage other components on the page. As with the RTE, don't use an MLT for an entire page. It is meant specifically for what you are looking to do: managing raw HTML/script markup. This field will work great OOTB with no additional modifications, so long as your client either doesn't need to modify the HTML content on their own or else knows HTML well enough to modify the content without a GUI.

With this approach, you are guaranteed that the HTML content you enter in the field will not be modified or manipulated and will be exactly what renders out on the front-end. Additionally, you don't have to make a solution wide change that affects all of your site's RTE fields.

File-System Based Solutions

If you aren't going to be content managing (i.e. controlling components, like the header, footer, etc.) any of the page around the HTML (which I think is the case for your solution) then I would go with a file-system based solution. The idea here is that you already have the HTML files and all you really need to do is upload them to your web root.

I would create a custom admin tool for your Content Authors to upload the files and store them at the desired path. You could even manage the unzipping of the files for only a few minutes (or seconds, if you don't need to look up the System.IO.Compression namespace) of additional effort.

Be sure to keep the following in mind:

  • If they need to be able to delete HTML files, they should have a mechanism to do that (can simply allow them to specify a path to an HTML file in the root and delete the file at that path)
  • You may want to have a warning display if they try to overwrite an existing file
  • If they need to be able to modify the HTML/content at will themselves, and uploading new files to overwrite the old ones isn't a feasible option then this might not be the way to go
  • If you have scaled environment with separated CM and CD servers, you will need to set up a sync process or have your file upload copy the files to the CD server(s) as well (or something similar)
  • If you want to support publishing, you will also need a custom mechanism to do so, as well
5
  • Multiline Text is also a good point! I suggested the RTE because maybe they want to insert the pictures from Sitecore for these fields and it's really hard with Multilne Text field because of the image hashing. Dec 13, 2016 at 13:57
  • Very true @TamásTárnok. TBH, I think the OP is actually looking to "host" HTML files that someone else is writing and managing, so I don't think a field approach will necessarily be the most desirable Dec 13, 2016 at 13:59
  • true, nice summary +1! Dec 13, 2016 at 14:03
  • If you're uploading files/deleting via the CM instance then you need to set up some sort of sync process to your CD servers. Publish process get's thrown out the window.
    – jammykam
    Dec 13, 2016 at 14:27
  • Very true, @jammykam. I'll add that Dec 13, 2016 at 14:35
2

I would create a template for it, which only contains one Rich Text field and then render this field into the layout. In the HTML view of the Rich Text field they can copy/paste the HTML from the agency. To enable javacript in Rich Text fields you need to enable it.

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <settings>
      <setting name="HtmlEditor.RemoveScripts">
        <patch:attribute name="value">false</patch:attribute>
      </setting>
    </settings>
  </sitecore>
</configuration>
3
  • It will have couple of html pages with own menu items
    – Nil Pun
    Dec 13, 2016 at 11:35
  • @NilPun then you can create an empty Layout for it. That means the whole HTML will come from this Rich Text field. Dec 13, 2016 at 11:36
  • +1 For the setting and additional option, but I wouldn't disable that setting if avoidable and I also would try to avoid managing an entire page from an RTE field, especially when that HTML will almost certainly be modified by the Telerik RTE in ways that are not necessarily predictable each time it is modified Dec 13, 2016 at 14:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.