Blog posts by John-Philip Johansson2020-05-26T14:51:25.0000000Zhttps://world.optimizely.com/blogs/john-philip-johansson/Optimizely WorldAnother step for Episerver CMS Labs - User Telemetry in more add-ons<p class="informationBox"><strong>TL;DR:</strong> When you upgrade BlockEnhancements or install our Labs in the future, you will see a new NuGet dependency called EPiServer.Telemetry.UI. It's the telemetry code from BlockEnhancements that we extracted and made available to our other experiments.</p>
<p>Previously, <a href="/link/f136e054d84149fd810de14ea328234b.aspx">we blogged about adding User Telemetry</a> in our first Labs add-on, BlockEnhancements, to learn more about what is used and what isn't. As noted in the <a href="/link/487e09260da244f69c5a0ad6fbdaa75d.aspx">Introducing Episerver CMS Labs</a> blog post, this will be key for us to uncover what is truly useful for our users when we create various experimental Labs add-ons.</p>
<p>We <a href="/link/dc1ef494ed2547f58cef226182d205a4.aspx">noticed in our initial data set</a> that there is still a lot to learn about what our users really enjoy with BlockEnhancements, and we're working on that. In the meantime, we have also released some other really interesting Labs where we explore other parts of the CMS that we would like to change:</p>
<ul>
<li><a href="/link/dbbcb8c637ae4dcc80685dd99ca3ae05.aspx">EPiServer.Labs.ContentManager</a></li>
<li><a href="https://nuget.episerver.com/package/?id=EPiServer.Labs.GridView">EPiServer.Labs.GridView</a></li>
<li><a href="/link/66a8407520064afe9ebcddfe4f6aab9b.aspx">EPiServer.Labs.ConfigurationManager</a></li>
</ul>
<p>To be able to understand the users of these new Labs add-ons, we had to make the telemetry functionality from BlockEnhancements available to the other Labs add-ons as well. To do this, we extracted the telemetry functionality into its own <a href="https://github.com/episerver/EPiServer.Telemetry.UI">open-source</a> <a href="https://nuget.episerver.com/package/?id=EPiServer.Telemetry.UI">NuGet package</a>. We will continue to maintain a public list of what we track (on the <a href="https://github.com/episerver/EPiServer.Telemetry.UI">EPiServer.Telemetry.UI Github repository</a>), and we will continue to report our findings through blog posts.</p>
<p>We are looking at ways on how to make this functionality more useful for other teams across Episerver, and eventually to you, our partners and community. For now, anyone can take a dependency on that package to start tracking but unless they're part of the CMS UI team, or at least within Episerver, the data won't be available.</p>
<p>To help us out, remember to opt in to the telemetry collection if you're using any of our Labs and are happy with it (or even if you're not!). <span>We will enable this on DXP environments, but if you're self hosted, you can enable Telemetry with this configuration:</span></p>
<pre class="language-csharp"><code>public void ConfigureContainer(ServiceConfigurationContext context)
{
context.Services.Configure<TelemetryOptions>(options => options.OptedIn = true);
}</code></pre>
<p>Everything we collect is anonymized and we only collect what we need. One question we've had internally is how "responsive" our design needs to be, especially if you've had the chance to look at <a href="/link/dbbcb8c637ae4dcc80685dd99ca3ae05.aspx">our cool new Content Manager Labs</a> that <em>works on a mobile phone</em>. Cool right? Is it used? How often do editors edit on the phone? Should we invest more in that, or was it one of those ideas that are cooler on paper than in reality? Now we can find out. The Telemetry add-on will be added to ContentManager and that will help us answer those questions. For now, these are the screen sizes we collected from BlockEnhancement:</p>
<p><img src="/link/19fb919874e94dd4ab66203fc092f624.aspx" alt="imageo8oe.png" /></p>
<p>That's not a lot of clients or users, so please enable the Telemetry and use our Labs, so we all can learn and build more things our users love. 🚀</p>2020-05-26T14:51:25.0000000ZBlog postThe Next Step for Episerver CMS Labs - User Telemetry in BlockEnhancements<p>As of <a href="https://nuget.episerver.com/package/?id=EPiServer.Labs.BlockEnhancements&amp;v=0.7.1">EPiServer.Labs.BlockEnhancements 0.7.0</a> it will support sending some telemetry data to help the CMS UI team determine which of the many great improvements should be fully supported, with all the complicated combinations of Languages, Content Approval, Project Mode, and more. This telemetry technology and how we work with it in CMS UI will move into the main CMS UI package in the near future. Opting-in on self-hosted instances is optional. DXP hosted instances will have this enabled.<br /><br /><em>Help us do this right. </em>We want to learn about how the CMS UI is used, while respecting our users privacy. See the <a href="https://github.com/episerver/EPiServer.Labs.BlockEnhancements/blob/master/README.md#telemetry-information">Telemetry Information section</a> and the <a href="https://github.com/episerver/EPiServer.Labs.BlockEnhancements/pull/44/files">code on Github</a>. Create issues there with your concerns or post here on this blog post. If you prefer to write in private you can reach me at jp.johansson@episerver.com</p>
<p>As you might have read in <a href="/link/487e09260da244f69c5a0ad6fbdaa75d.aspx">Introducing Episerver CMS Labs</a> there are certain improvements that are just too big to do right away without knowing if we're going to hit the mark. We introduced Labs to validate potential features before implementing them fully and we're very happy with the feedback we've received from our first Labs: <a href="https://github.com/episerver/EPiServer.Labs.BlockEnhancements">BlockEnhancements</a>. I have personally heard from many Sales Architects, Trainers, PMs, and EMVP's; how it has completely changed the experience of working with blocks. That's wonderful!</p>
<p>You might also notice that I didn't mention Editors or Marketers; the ones that work all day in our UI, the ones we build all of this for. Which of the six main features are making them happy? All of them? One of them? None of them? Does the inline publish from the <a href="https://github.com/episerver/EPiServer.Labs.BlockEnhancements#inline-block-editing">Inline Block Edit</a> (<a href="/link/182680364c024f7094b9610881370e6f.aspx">v0.5.0</a>) fit into a workflow of "edit, then publish" in such a way that the <a href="https://github.com/episerver/EPiServer.Labs.BlockEnhancements#inline-publish">Inline Publish from the Assets Pane</a> (<a href="/link/c256bf3bdc2743f0aa6179e8c9c76fb9.aspx">v0.1.0</a>) is no longer needed? Does <a href="https://github.com/episerver/EPiServer.Labs.BlockEnhancements#smart-publish">Smart Publish</a> (<a href="/link/7b4798fad30047b3b8ad90098b4569a9.aspx">v0.2.0</a>) work so well that <a href="https://github.com/episerver/EPiServer.Labs.BlockEnhancements#inline-publish">Inline Publish from the Content Area</a> (<a href="/link/c256bf3bdc2743f0aa6179e8c9c76fb9.aspx">v0.1.0</a>) is no longer used? And does anyone ever try to publish anything less than "everything" when the Smart Publish dialog shows up for configuration? It's really hard to tell.</p>
<p>Until now. With <a href="https://nuget.episerver.com/package/?id=EPiServer.Labs.BlockEnhancements&amp;v=0.7.1">EPiServer.Labs.BlockEnhancements 0.7.0</a> we will finally get some of those answers. It will enable us to use AppInsights to track feature usage and give a high level answer to some of our questions, as you can see here:</p>
<p><span class="prd-w-img"><img src="/link/f5a33bf6ad0e4441abae58c22e4cc13a.aspx" alt="image3ls4.png" /><br /></span></p>
<p><em><span class="prd-w-img">(This is how the data looks after CMS UI and QA has verified the UI functionality for this release)</span></em></p>
<p>We plan to fully support one of the main publishing paths from BlockEnhancements, and we need some data to see which one. Perhaps we learn that despite the positive remarks neither really hit the mark and we need to do more Labs.</p>
<h2>Privacy</h2>
<p>The CMS UI team is very interested in what our users use and do not use. What should we improve, what should we remove, what ... So many questions. 😄 But just gathering data and then trying to find questions that can be answered with the data is perhaps more fun than useful. Instead, we will start with a question and only add the <em>minimum</em> of tracking events to answer that question in a reasonable way.</p>
<p>We know from meeting users that they can have different preferences due to previous experiences. We also know from experience that sometimes a feature is used very differently from what we intended due to modifications on the partner/client end. To be able to filter data to determine outliers we will use <strong>anonymized id's</strong> for users and clients.</p>
<p>We are mainly interested in aggregated data, which you can see in our dashboard above. We will enable this on DXP environments, but if you're self hosted you can enable Telemetry with the configuration:</p>
<pre class="language-csharp"><code>public void ConfigureContainer(ServiceConfigurationContext context)
{
context.Services.Configure<TelemetryOptions>(options => options.OptedIn = true);
}</code></pre>
<p>We're trying to be as transparent as possible so please take a look at in the <a href="https://github.com/episerver/EPiServer.Labs.BlockEnhancements/blob/master/README.md#telemetry-information">Telemetry Information section</a> where all the tracked events are carefully detailed.</p>
<p>We're looking at how we can share this data with you and how it can be useful for add-ons, both 1st and 3rd party ones. We're taking it slow to make sure we do this right and respect everyone's concerns around privacy. We will start with something simpler, perhaps some blog posts from the team with what we learned - would that be of interest to you?</p>
<p>This is just a first step into being a bit more data-driven in our UX decisions. We plan to include this technology in the main CMS UI product. While this is in BlockEnhancements you can see every tracked event detailed in the Readme, and see it in the code as well. What we track in CMS UI will be of the same level of detail, but won't be as easy to be as transparent with. Help us do it right in BlockEnhancements so that we're all happy and confident with this in CMS UI. We tried to make it as clear as possible for you to review the code in this <a href="https://github.com/episerver/EPiServer.Labs.BlockEnhancements/pull/44/files">Github pull request</a><span>. Create issues there with your concerns or post here on this blog post. If you prefer to write in private you can reach me at jp.johansson@episerver.com</span></p>2020-02-25T14:01:22.0000000ZBlog postIntroducing Episerver CMS Labs<p class="informationBox">Episerver CMS Labs are CMS add-ons that solve a big problem in a small way, where the "happy paths" of a user flow are tested and fixed, while other paths and scenarios are left aside. The Labs are open sourced on Episerver's GitHub account so that you can contribute fixes to the scenarios that block your use cases. The main purpose of Labs is to validate potential features before implementing them fully and supporting all of Episerver CMS' complex features.</p>
<p>Episerver CMS is a complex application. Any feature added needs to work together with all existing features. This creates a lot of moving parts that must be taken into consideration when designing a new feature; it has to work from a user experience point of view as well as a technical architecture one. Supporting language management, content approvals, and projects, are the three most time-consuming aspects of CMS to support in any new feature.</p>
<p>The release method, by publishing a NuGet package that needs to be installed, means that clients tend to be some minor version away from the latest. This means some feedback on anything new can be very quick from our engaged community, especially EMVPs, which is great, but the main work in form of bugs and support cases, which might show us how a feature <em>should have</em> been arrive very late - often when we've moved on to another feature. This also means that we need to release without any known bugs, as users will have to live with them until their installation is upgraded.</p>
<p>Those two aspects mean that when we need to tackle a very big problem, it is hard for us to validate our ideas "in the wild" without doing a fully fleshed-out and working solution. To counter this, the Episerver CMS UI team is experimenting with "Labs" add-ons. These are open sourced add-ons released on the Episerver NuGet feed, and the main user paths are verified with QA, but leaving out most complex scenarios and edge cases. They will focus on a complex usage area each, and can include one or more proposed solutions. We encourage the use of these add-ons, and appreciate feedback. Ultimately, we will gather usage data from them to properly validate which solution will make it into the main CMS UI product, or released as a fully-supported CMS add-on.</p>
<p>Our first Labs is Block Enhancements (<a href="https://nuget.episerver.com/package/?id=EPiServer.Labs.BlockEnhancements">NuGet</a>, <a href="/link/c256bf3bdc2743f0aa6179e8c9c76fb9.aspx">blog post on v0.1.0</a>) and has been well received, from what we currently can gather. The download numbers are respectable for such a new package. :) Each release has been well met in the comments section (blog posts on <a href="/link/7b4798fad30047b3b8ad90098b4569a9.aspx">v0.2.0,</a> <a href="/link/fbee8ede4f184b169b48d22e26f641be.aspx">v0.3.0</a>, <a href="https://bartoszsekula.com/post/2019/10/13/nice-improvement-for-the-inline-editing-feature">v0.4.0</a>, and <a href="/link/182680364c024f7094b9610881370e6f.aspx">v.0.5.0</a>). It focuses on simplifying block publishing, and shows seven (!) ways to tackle that complex usage. Without supporting Content Approval sequences and Projects... Now we're reaching a point where we need to understand which of these seven ways should be supported fully, as supporting all of them would take a <em>very</em> long time and potentially bloat the user experience, as we do not know how they overlap or replace each other in a user's regular work day. We are still considering the different ways we can get this understanding. Either way, it's an exciting time!</p>
<p><strong>For Labs to be a succesful way for us to validate solutions, they need to be used. So <a href="https://nuget.episerver.com/package/?id=EPiServer.Labs.BlockEnhancements">download </a><a href="https://nuget.episerver.com/package/?id=EPiServer.Labs.BlockEnhancements">EPiServer.Labs.BlockEnhancements</a> now and help us out <a href="https://github.com/episerver/EPiServer.Labs.BlockEnhancements">in the GitHub repo</a>!</strong></p>
<h2><span>Legal notice</span></h2>
<p><span>There are a few things you should expect from each release:</span></p>
<ul>
<li><span>Functionality may be added, removed, or change.</span></li>
<li><span>Labs projects have not been through the same quality assurance process as the versioned products and, in some cases, may show unexpected behaviour.</span>
<ul>
<li><em>The Episerver CMS UI team notes that:</em>
<ul>
<li><em>the scenarios in the Readme of each CMS Lab's repo will be verified and supported us</em></li>
<li><em>the Labs add-on may or may not work with other add-ons, we are not testing them</em></li>
<li><em>any such issues found, such as scenarios outside of the the Readme, can be fixed by the community by submitting a Pull Request on the Github repo</em></li>
</ul>
</li>
</ul>
</li>
<li><span>The software may not work on all environments.</span>
<ul>
<li><span><em>The Episerver CMS UI team notes that:</em></span>
<ul>
<li><em>Although it should work on base installations of CMS UI in Chrome and Firefox</em></li>
</ul>
</li>
</ul>
</li>
<li><span>There is no Episerver support; however, we will gratefully receive all feedback</span>
<ul>
<li><span><em>The Episerver CMS UI team notes that:</em></span>
<ul>
<li><em>Issues created on Github will be triaged, and if accepted, fixed by us</em></li>
</ul>
</li>
</ul>
</li>
</ul>
<h2>Existing packages with the same name</h2>
<p>There are some packages that have been previously released with the Labs monicker, such as "EPiServer.Labs.LanguageManager" and they will still be around. The CMS UI team will make it clearer by prefixing future packages with "EPiServer.CMS.Labs", and consider republishing "EPiServer.Labs.BlockEnhancements" as "EPiServer.CMS.Labs.BlockEnhancements".</p>2019-11-19T15:35:33.0000000ZBlog postMaking Blocks editable in a Content Area without Razor<p>To get an editing overlay on On-Page Edit (OPE) for a content area is quite easy. It's like any other editable property: add the <span class="classLib">data-epi-edit="PropertyName"</span> attribute (CMS UI 11.16.0, earlier versions require three attributes, see <a href="/link/34fc7f9c974e4ed4a67c93374dab565f.aspx">blog post</a>). Depending on your markup you might have to put the attribute on a parent element, otherwise the overlays might get shifted due to styling.</p>
<p>Example from MusicFestival's <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/components/pages/LandingPage.vue">LandingPage.vue</a>:</p>
<pre class="language-markup"><code><div v-epi-edit="'MainContentArea'">
<ContentArea :model="model.mainContentArea"></ContentArea>
</div>
</code></pre>
<p>This enables the content area overlay, but not for the contents in it. You can still work with it using the content area menu that shows up when clicking the content area. It allows re-ordering, dragging and dropping content, and creating new blocks.</p>
<p><img src="/link/64e3c7a8050d4cc1a59c5714cb7d13df.aspx" alt="blobid0.png" /></p>
<p>If you want a nicer experience, similar to when using the <span class="classLib">@Html.PropertyFor()</span> helper in Razor, then you just need to add the block id to each block as a HTML attribute: <span class="classLib">data-epi-block-id="TheContentLink"</span>.</p>
<p>Example from MusicFestival's <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/components/ContentArea.vue">ContentArea.vue</a>:</p>
<pre class="language-markup"><code><div :key="index" v-for="(block, index) in model" class="Grid-cell" :class="getDisplayOption(block.displayOption)">
<BlockComponentSelector :data-epi-block-id="isEditable ? block.contentLink.id : null" :model="block"></BlockComponentSelector>
</div></code></pre>
<p><img src="/link/fa0c51ce4f194ad1bca2e310f350ac8c.aspx" alt="imagen31q.png" /></p>
<p>If you're using the <a href="https://nuget.episerver.com/package/?id=EPiServer.ContentDeliveryApi">ContentDeliveryAPI</a> add-on then the block id is available on the block's <strong>contentLink.id</strong>. As you can see above, the blocks are rendered by a ContentArea Vue.js component by iterating over the blocks given by the page's <strong>model.mainContentArea</strong>. The block overlay is only used when rendered in a content area, so it's not necessary to always set it (which would have been the case if we added the id in <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/components/BlockComponentSelector.vue">BlockComponentSelector.vue</a> instead).</p>
<p>One non-obvious detail might be the conditional to only render the <span class="classLib">data-epi-block-id</span> when the variable <span class="classLib">isEditable</span> is true. This is to avoid rendering the property in View mode. It's a good idea to avoid leaking details about your CMS or server to your site visitors. :)</p>
<h2>Read more</h2>
<p>Developer Guides:<a href="/link/60371278b0b348a4a2b95c1bccc16ed9.aspx#editingdataattributes"></a></p>
<ul>
<li><a href="/link/60371278b0b348a4a2b95c1bccc16ed9.aspx#editingdataattributes">https://world.episerver.com/documentation/developer-guides/CMS/editing/#editingdataattributes</a></li>
<li><a href="/link/f80257067ca542288c0b74d4db6ae0c5.aspx">https://world.episerver.com/documentation/developer-guides/CMS/editing/on-page-editing-with-client-side-rendering/</a></li>
</ul>
<p>MusicFestival has been updated: <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/components/ContentArea.vue">https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/components/ContentArea.vue</a></p>2019-02-04T12:04:24.0000000ZBlog postOne OPE attribute to rule them all: data-epi-edit (CMS UI 11.16.0)<p>In <a href="https://nuget.episerver.com/package/?id=EPiServer.CMS.UI&v=11.16.0">CMS UI 11.16.0</a>, we're making it easier for everyone doing client-side rendered websites to mark up their HTML.</p>
<h2>Before 11.16.0</h2>
<p>In <a href="/link/4552b6ecd7504771b9f3aae5832cb3a6.aspx">a previous post</a>, I explained how to make an element editable in On-Page Edit when rendered by a client-side framework (e.g. React, Angular, Vue, etc). It was necessary to add three attributes:</p>
<pre class="language-markup"><code><span data-epi-property-name="YourProperty" data-epi-property-render="none" data-epi-property-edittype="floating">{your JS framework decides how the value is actually rendered}</span></code></pre>
<p>This is slightly verbose. Although you <em>could</em> wrap it in some helper method in your JavaScript framework of choice (like we did in the <a href="https://github.com/episerver/musicfestival-vue-template/blob/4a0815f1a020d17d548479c6b058e5f4a6e1a152/src/MusicFestival.Vue.Template/Assets/Scripts/directives/epiEdit.js#L27-L29">MusicFestival sample site</a>), it would require less "magic" or less reading of our <a href="/link/f80257067ca542288c0b74d4db6ae0c5.aspx">documentation</a> if there was only one attribute for frontend developers to remember. That's why we're introducing <span class="classLib">data-epi-edit</span>. It does not have any specific behavior to learn about. It's equivalent to setting the properties above, and setting any of those properties as well will simply be ignored.</p>
<h2>With 11.16.0</h2>
<p>It's now enough with one simple attribute:</p>
<pre class="language-markup"><code><span data-epi-edit="YourProperty">{your JS framework decides how the value is actually rendered}</span></code></pre>
<h2>One note</h2>
<p>We recommend that you don't render any <span class="classLib">data-epi-*</span> attributes in View mode, as to not give too many details about the internal workings of your site. That's what @Html.PropertyFor() and @Html.EditAttributes() do when using Razor views. When taking over the rendering on the client-side, this responsibility moves over as well. One way is to use the global <span class="classLib">epi.beta.isEditable</span> property (CMS UI 11.11.0, see <a href="/link/fab5b0bbe59547c98c873b041c2696fb.aspx">blog</a> or <a href="/link/f80257067ca542288c0b74d4db6ae0c5.aspx">documentation</a>) to toggle the rendering off and on, as we've done in MusicFestival (see <a href="https://github.com/episerver/musicfestival-vue-template/blob/4a0815f1a020d17d548479c6b058e5f4a6e1a152/src/MusicFestival.Vue.Template/Assets/Scripts/epiMessages.js#L40-L49">here</a> and <a href="https://github.com/episerver/musicfestival-vue-template/blob/4a0815f1a020d17d548479c6b058e5f4a6e1a152/src/MusicFestival.Vue.Template/Assets/Scripts/directives/epiEdit.js#L32-L41">here</a>).</p>
<h2>Learn more</h2>
<p>Documentation: <a href="/link/f80257067ca542288c0b74d4db6ae0c5.aspx">https://world.episerver.com/documentation/developer-guides/CMS/editing/on-page-editing-with-client-side-rendering/</a></p>
<p>MusicFestival has been updated to use this in the Vue directive v-epi-edit: <a href="https://github.com/episerver/musicfestival-vue-template/blob/129be15ae4a/src/MusicFestival.Vue.Template/Assets/Scripts/directives/epiEdit.js">https://github.com/episerver/musicfestival-vue-template/blob/129be15ae4a/src/MusicFestival.Vue.Template/Assets/Scripts/directives/epiEdit.js</a></p>2019-01-29T08:27:38.0000000ZBlog postTips and tricks for a great On-Page Editing experience in SPAs and other client side rendered sites<p>To get access to the new features explained in this blog post, you will need to enable beta features. This is done by following the following documentation. <a href="/link/cb1c889682ca4002870a5dfb6482d674.aspx">Beta features</a></p>
<p>To demonstrate some concepts useful when creating a SPA with working OPE, we are releasing a new SPA template site on Github, called MusicFestival, together with a <strong>series of blog posts</strong>. Don't be discouraged that the SPA is written in <a href="https://vuejs.org/">Vue.js</a> if you're using React, Angular, or something else, as these concepts will work in any client side framework.</p>
<p><a href="/link/5ccbe4dbd38c4d76a6dc81e838c70f9d.aspx">Introducing a new SPA template site: MusicFestival</a></p>
<p>When creating a SPA, you are no longer bound by certain limitations on a server side rendered site, but it's important to remember that the site still lives in a Content Management System (CMS) and that there is a human editor whose job it is to edit the site. These editors learn the concepts in the CMS user interface and feel happier when they are able to feel productive. By following these tips and tricks, you can allow your editors to have a nice editing experience, while keeping all the productive niceness of writing a site by focusing mostly on the frontend without having to focus too much on what CMS is being used behind the API.</p>
<p>A more in-depth look at what you need to think about when doing client side routing is available in this blog: <a href="/link/fab5b0bbe59547c98c873b041c2696fb.aspx">Routing in a SPA with a working On-Page Editing experience (CMS UI 11.11.0)</a>.</p>
<p>This blog will instead focus on examples on what you can do with your site to improve the editors On-Page Editing (OPE) experience.</p>
<p>In CMS UI 11.11.0, we introduce some useful properties on the injected <code>epi.beta</code> property. In the template, we <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/epiContext.js">make them available to all components as <code>$epi</code></a>, which is <a href="https://vuejs.org/v2/cookbook/adding-instance-properties.html">a Vue.js instance property</a>. You'll see it used throughout the examples.</p>
<h2>Routing links vs edit links</h2>
<p>As is mentioned in <a href="/link/fab5b0bbe59547c98c873b041c2696fb.aspx">the routing blog</a>, you will want to render different HTML depending on if you're in edit mode or view mode. To simplify this, we created a Link component that does this.</p>
<pre><code><template>
<!-- Editmode -->
<a v-if="$epi.inEditMode" :href="url">
<slot></slot>
</a>
<!-- Viewmode -->
<router-link v-else :to="url">
<slot></slot>
</router-link>
</template>
</code></pre>
<p><em><code><slot></code> allows child components to be passed by the parent component. <a href="https://vuejs.org/v2/guide/components-slots.html">See Vue.js docs</a></em></p>
<p><em>See the full source for the <code>EpiLink.vue</code> component [here]( https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/components/widgets/EpiLink.vue).</em></p>
<h3>Disabling links in OPE</h3>
<p>Certain links, such as a language selector in MusicFestival, are disabled when in OPE, because when switching languages it is more appropriate to use the CMS UI. There can be other use cases, so we created a <code>ViewModeLink</code> component. We do not change the HTML in OPE as to not affect the styling, and instead simply disable the pointer events so they aren't interactive or clickable.</p>
<p><img src="/link/f7109fce529e4cf6af4c0f5eb0ce5e00.aspx" width="866" alt="Disabling links in OPE" height="1036" /></p>
<pre><code><template>
<router-link :class="{ 'edit-mode': $epi.inEditMode }" :to="url">
<slot></slot>
</router-link>
</template>
<style lang="less" scoped>
.edit-mode {
pointer-events: none;
}
</style>
</code></pre>
<p><em>See the full source for the <code>EpiViewModeLink.vue</code> component <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/components/widgets/EpiViewModeLink.vue">here</a>.</em></p>
<h2>Editing a visible property</h2>
<p>To make an element editable in OPE, you can add certain attributes to the HTML, such as <code><span data-epi-property-name="Name"></code>. Information regarding those attributes can be found in our <a href="/link/60371278b0b348a4a2b95c1bccc16ed9.aspx">Developer guides</a>.</p>
<p>As with <code>@Html.EditAttributes()</code>, available in ASP.NET Razor views, these attributes should <em>not</em> be rendered for the site visitor in view or preview modes.</p>
<p>To make this more convenient, we created a <a href="https://vuejs.org/v2/guide/custom-directive.html">custom Vue.js directive</a> (an element property) called <code>v-epi-edit</code> that will add all required attributes to any element using that directive. It's also possible for a component to disable the editing features by having the property <code>epiDisableEditing</code> set to false. We will show a useful scenario in the section <strong>"Hiding overlays when they interfere with new overlays due to user interactions"</strong>.</p>
<p><img src="/link/a5c5481b66984ba0ad2c3f51a1196760.aspx" width="869" alt="Edit visible property" height="1036" /></p>
<p>Using it is straightforward:</p>
<pre><code><!-- This Vue.js code: -->
<h1 v-epi-edit="'ArtistName'">{{model.artistName}}</h1>
<!-- Becomes ths HTML code: -->
<h1 data-epi-property-name="ArtistName" data-epi-property-render="none" data-epi-property-edittype="floating">...</h1>
</code></pre>
<p>Its implementation is quite simple too:</p>
<pre><code>function toggleEditAttributes(el, binding, vnode) {
const siteIsEditable = vnode.context.$epi.isEditable;
const componentIsEditable = !vnode.context.epiDisableEditing;
if (siteIsEditable && componentIsEditable) {
setEditAttributes(el, binding);
} else {
removeEditAttributes(el);
}
}
</code></pre>
<p><em>You can see the implementation in <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/directives/epiEdit.js"><code>epiEdit.js</code></a>.</em></p>
<h2>Editing a non-visible or hard to click property</h2>
<p><img src="/link/13d8b50b62984e1595c202e5c9740cdd.aspx" width="869" alt="Edit non-visible property" height="1036" /></p>
<p>We also created the EpiProperty component to have a way to edit properties that might be hard to edit using the normal editing overlays, such as the background image of the ArtistDetailsPage component. It renders a <code><button></code> when the page is editable.</p>
<p>These elements should <em>not</em> be rendered for the site visitor, in view or preview modes.</p>
<pre><code><template>
<button v-if="$epi.isEditable" v-epi-edit="propertyName">Edit property: {{propertyName}}</button>
</template>
</code></pre>
<p><em>Note that it uses the <code>EpiEdit</code> directive to be editable.</em></p>
<p><em>See the full source for the <code>EpiProperty.vue</code> component <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/components/EpiProperty.vue">here</a>.</em></p>
<h2>Hiding overlays when they interfere with new overlays due to user interactions</h2>
<p>There are situations when one editable property is rendered on top of another. In the MusicFestival site, this happens when the BuyTicketBlock modal is shown on top of the Hero image on the LandingPage. To help the editor, the Hero's editable properties have their editing features disabled in those cases, so the overlays don't fight for the user's attention.</p>
<p><img src="/link/dd2990fdd05049909dcca88a629929c7.aspx" width="869" alt="Hiding selected overlays" height="1036" /></p>
<p>If you recall the <code>v-epi-edit</code> directive (the custom attribute) introduced in the section "Editing a visible property", it allows the element it's on to disable editing by setting the property <code>epiDisableEditing</code> to <code>true</code>. You can see it used <em>indirectly</em> on the Title in the Hero component:</p>
<pre><code><template>
<h1 v-epi-edit="'Title'" v-html="title"></h1>
</template>
<script>
export default {
computed: {
epiDisableEditing() {
return this.$app.modalShowing;
}
}
};
</script>
</code></pre>
<p><em>See the full source for the <code>Hero.vue</code> component <a href="https://github.com/episerver/musicfestival-vue-template/blob/master/src/MusicFestival.Vue.Template/Assets/Scripts/components/widgets/Hero.vue">here</a>.</em></p>
<p>The <code>v-epi-edit</code> directive will read the <code>epiDisableEditing</code> value set by <code>Hero</code> and disable the overlays when the site's modal is showing.</p>
<h2>Set minimum size for editing overlays</h2>
<p>Since CMS UI 11.11.0, there is a CSS injected to set the min-size so that properties with empty values can still be edited in OPE mode. This is otherwise set on the server side rendered HTML when not using <code>data-epi-property-render="none"</code>.</p>
<p><img src="/link/45456364743b46c0bf94ef4ec737a900.aspx" width="869" alt="Setting minimum size on empty overlay" height="1036" /></p>
<p>You can set your own minimum size by overriding the selector <code>[data-epi-property-name]</code>. The injected CSS is:</p>
<pre><code>[data-epi-property-name] {
min-height: 14px;
min-width: 18px;
}
</code></pre>
<h2>Related links</h2>
<p>Template site using the techniques discussed in this blog: <a href="https://github.com/episerver/musicfestival-vue-template/">https://github.com/episerver/musicfestival-vue-template/</a></p>
<p>Documentation on client side rendering in Episerver: <a href="/link/f80257067ca542288c0b74d4db6ae0c5.aspx">https://world.episerver.com/documentation/developer-guides/CMS/editing/on-page-editing-with-client-side-rendering/</a></p>2018-10-31T13:10:09.0000000ZBlog postIntroducing a new SPA template site: MusicFestival<p>To demonstrate some concepts that are useful when creating a SPA with working OPE, we have released a new SPA template site on Github, called MusicFestival, together with a series of blog posts that will be available in the coming days (a complete list is at the bottom).</p>
<p><img alt="" src="/link/9ce66625e95948c8ace78f80a2e3239f.aspx" height="691" width="1200" /></p>
<p>You might have seen the site at recent Episerver Ascend events. It was built as a showcase demo for the new Episerver <a href="/link/6ffa5cb8173a414eac25740deeafdbc8.aspx">Content Delivery API</a>, and has since then been modified to a smaller Single-Page Application (SPA) site that is intended to show how to work with On-Page Editing (OPE). It also uses the Content Delivery API with some customizations for friendly URLs and flatter JSON results. The site also uses CMS UI 11.11.0 which introduces some improvements and bugfixes for SPA scenarios.</p>
<p>The default installation contains some example bands generated by a random band name generator, so it’s possible to demo straight away.</p>
<h2>We will dig deeper in other blog posts, but you can already enjoy it on Github</h2>
<p><a href="https://github.com/episerver/musicfestival-vue-template">https://github.com/episerver/musicfestival-vue-template</a></p>
<blockquote>
<p>We are not expert Vue.js developers, so there are probably improvements you can contribute.</p>
</blockquote>
<div><span class="informationBox"><strong>Important:</strong> The template uses Vue.js but the concepts shown would be the same in React, Angular, or other client-side framework.</span></div>
<p> </p>
<h2>Blog series</h2>
<ul>
<li><a title="Routing in a SPA with a working On-Page Editing experience (CMS UI 11.11.0)" href="/link/fab5b0bbe59547c98c873b041c2696fb.aspx">Routing in a SPA with a working On-Page Editing experience (CMS UI 11.11.0)</a></li>
<li><a href="/link/800a3dfa129f416590fab542c257e7dc.aspx" title="Tips and tricks for a great On-Page Editing experience in SPAs and other client side rendered sites"><span>Tips and tricks for a great On-Page Editing experience in SPAs and other client side rendered sites</span></a></li>
<li><span><a href="/link/4a91824ea19e4f3a8fbfb7a953115f1e.aspx" title="Represent the concept of "pages" and "blocks" with matching client side components in a SPA">Represent the concept of "pages" and "blocks" with matching client side components in a SPA</a></span></li>
</ul>
<h2><span>Other blog posts</span></h2>
<ul>
<li><span><a href="/link/cc160458b8794b4eb1730db013dcf1c0.aspx" title="Using Vuex in the MusicFestival template site">Using Vuex in the MusicFestival template site</a></span></li>
<li><span><a href="/link/34fc7f9c974e4ed4a67c93374dab565f.aspx" title="One OPE attribute to rule them all: data-epi-edit (CMS UI 11.16.0)">One OPE attribute to rule them all: data-epi-edit (CMS UI 11.16.0)</a></span></li>
</ul>2018-10-30T13:38:01.0000000ZBlog postDesigning frontends for OPE without wrapping elements<!DOCTYPE html>
<html>
<head>
</head>
<body>
<p>A common scenario I have seen is that a frontend developer or designer implements a design in HTML, CSS, and maybe JS, without worrying about which CMS is used to render it. The code is then copied or moved into Episerver, most often into a Razor view, by an Episerver developer. Then everyone sees the page in On-Page Edit (OPE) and gets a little sad as some of that lovely design is broken. That makes the developers get even sadder as they have to re-do some of the design to work with the extra div elements added by OPE, but at least it will look lovely again.</p>
<p>We would like you to use the HTML structure you want. If you are rendering and handling updates purely in your client-side framework of choice, you should already be able to do this. If you are using Razor, then let us discuss two common design implementations that break, and what we can do with them. But first, let us talk about our two HTML helpers <strong>@Html.PropertyFor</strong> and <strong>@Html.EditAttributes</strong>.</p>
<h2>HTML-helpers</h2>
<p>These are helpers you can use in Razor views, but they are not required if you just want to do on-page editing. See the previous blog posts for more info.</p>
<p>The way <strong>@Html.EditAttributes </strong>works is that it adds the properties <strong>data-epi-property-name</strong> and <strong>data-epi-use-mvc="True"</strong> to the element where it is used, but only in edit mode. It can add more properties if given more parameters. The first attribute enables editing overlays and can be added by yourself to HTML outside Razor. That second attribute tells OPE to use Episerver’s property render controller<strong>,</strong> that in turn uses .NET’s DisplayFor, to render the property when its data has changed. That partial render replaces the innerHTML of the element with the <strong>data-epi-property-name</strong> attribute. This becomes an issue for <img> as we will see below.</p>
<p>Similarly, <strong>@Html.PropertyFor</strong> adds a wrapping element with the same attributes. It uses display templates for the rendered property. The element type can be configured as we will see below.</p>
<h2>Scenario 1 – Inline elements</h2>
<p>Here we will put a <strong>@Html.PropertyFor</strong> inside a <p> because we want to edit some strings and the CMS UI needs something to attach to. When previewing it looks fine, but when editing, it drops out to its own line and looses the styling (see the font).</p>
<p><img src="/link/abf3b189e56d48ac87af9a6f500df401.aspx" alt="Image example1.gif" /></p>
<p>That is because <strong>@Html.PropertyFor</strong> defaults to wrapping the editable property in a <div>, and that is not a valid child element to a <p>. So, the browser splits the texts into multiple <p>, losing track of any classes or inline styling added to the original <p>. You can see how the font changes in the animation. You can set a custom element type with an anonymous object setting <strong>CustomTag </strong>or replacing it with <strong>@Html.EditAttributes</strong> with a suitable element. We will show both ways below:</p>
<pre class="language-html"><code><!-- scenario 1 markup -->
<p class="article-about scenario">
This article originated in @Html.PropertyFor(x => x.CurrentPage.CountryOfOrigin) and was written by @Html.PropertyFor(x => x.CurrentPage.Author).
</p>
<!-- scenario 1 rendered in OPE -->
<p class="article-about scenario">
This article originated in </p>
<div class="epi-editContainer" data-epi-property-name="CountryOfOrigin" data-epi-use-mvc="True">Sweden</div> and was written by
<div class="author" data-epi-property-name="Author" data-epi-use-mvc="True" data-epi-property-rendersettings="{"cssClass":"author"}">JP</div>.
<p></p>
<!-- scenario 1 rendered in Preview -->
<p class="article-about scenario">
This article originated in Sweden and was written by JP.
</p></code></pre>
<pre class="language-html"><code><!-- solution A markup -->
<p class="article-about solution">
This article originated in @Html.PropertyFor(x => x.CurrentPage.CountryOfOrigin, new { CustomTag = "span"}) and was written by <span class="author" @Html.EditAttributes(x => x.CurrentPage.Author)>@Model.CurrentPage.Author</span>.
</p>
<!-- solution A rendered in OPE -->
<p class="article-about solution">
This article originated in <span class="epi-editContainer" data-epi-property-name="CountryOfOrigin" data-epi-use-mvc="True" data-epi-property-rendersettings="{"customTag":"span"}" style="min-height: auto;">Sweden</span> and was written by <span class="author" data-epi-property-name="Author" data-epi-use-mvc="True" style="min-height: 14px; min-width: 18px; display: inline-block;">JP</span>.
</p>
<!-- solution A rendered in Preview -->
<p class="article-about solution">
This article originated in Sweden and was written by <span class="author">JP</span>.
</p></code></pre>
<p>The main markup difference between the two solutions is that the first span (from <strong>PropertyFor</strong>) will only be rendered in OPE. Also note that all the editing attributes are only rendered in OPE. For styling with a consistent markup, the second option might be preferred.</p>
<p>You can also use the HTML attributes directly, without the <strong>@Html </strong>helpers:</p>
<pre class="language-html"><code><!-- solution B markup -->
<p class="article-about solution">
This article originated in <span data-epi-property-name="CountryOfOrigin" data-epi-use-mvc="True">@Model.CurrentPage.CountryOfOrigin</span> and was written by <span class="author" data-epi-property-name="Author" data-epi-use-mvc="True">@Model.CurrentPage.Author</span>.
</p>
<!-- solution B rendered in OPE -->
<p class="article-about solution">
This article originated in <span data-epi-property-name="CountryOfOrigin" data-epi-use-mvc="True">Sweden</span> and was written by <span class="author" data-epi-property-name="Author" data-epi-use-mvc="True">JP</span>.
</p>
<!-- solution B rendered in Preview -->
<p class="article-about solution">
This article originated in <span data-epi-property-name="CountryOfOrigin" data-epi-use-mvc="True">Sweden</span> and was written by <span class="author" data-epi-property-name="Author" data-epi-use-mvc="True">JP</span>.
</p></code></pre>
<p>Note that there is no difference between what was rendered in OPE and in Preview. If you are rendering the HTML with a client-side framework you could toggle those attributes yourself. One way to detect that you are in OPE is to render a custom flag when <strong>@PageEditing.PageIsInEditMode</strong> is <strong>true</strong>. You can see one example in our <a href="https://github.com/episerver/AlloyReact/">Alloy React example repository</a>, where we set a custom data-attribute on the <body> in our <a href="https://github.com/episerver/AlloyReact/blob/8eb4c53e47523fc3fd8ec43980d507d21a18404d/AlloyReact/Views/Shared/Layouts/_Root.cshtml#L6">_Root.cshtml</a> that we can check for in our React components.</p>
<p>Adding a <span> inside a <p> should not cause any issues, but <img> are trickier...</p>
<h2>Scenario 2 – Inline elements and images</h2>
<p>This is specific to images, or rather, the <img>. It also not tied to Razor views or HTML helpers, so using the data-epi-property-name (without handling the rendering yourself with data-epi-property-render=”none”, <a href="/link/60371278b0b348a4a2b95c1bccc16ed9.aspx#editingdataattributes">see the documentation</a>) is also affected by this.</p>
<p>In the animation below, we show three different attempts demonstrating what happens with <strong>@Html.PropertyFor</strong>, <strong>@Html.EditAttributes</strong>, and because we want to show that it can be worked around, the final polar bear is written with wrapping elements in mind.</p>
<p><img src="/link/775cac7881814f76ba61b23fe55f3eda.aspx" alt="Image example2-2-resized.gif" /></p>
<p>Setting the innerHTML when updating a property works for all elements except images. For example, <p> and <span> have text as the innerHTML so when the property has been updated, then setting the innerHTML with the new text will work. When it comes to <img>, there is no valid innerHTML so when it is set it creates invalid markup. Because PropertyFor always adds a wrapping element it will re-render the <img> properly, but the design breaks.</p>
<pre class="language-html"><code><!-- scenario 2 A markup -->
<div class="article-summary scenario">
@Html.PropertyFor(x => x.CurrentPage.SummaryImage)
<p>@Html.PropertyFor(x => x.CurrentPage.SummaryText)</p>
</div>
<!-- scenario 2 A rendered in OPE -->
<div class="article-summary scenario">
<div class="epi-editContainer" data-epi-property-name="SummaryImage" data-epi-use-mvc="True">
<img src="/EPiServer/CMS/Content/contentassets/en/21cd8489b66d40a9b9711df5158be324/spotless-panda.png,,113?epieditmode=False&visitorgroupsByID=undefined" alt="">
</div>
<p></p>
<div class="epi-editContainer" data-epi-property-name="SummaryText" data-epi-use-mvc="True">To the left you can see a "Polar Bear".</div>
<p></p>
</div>
<!-- scenario 2 A rendered in Preview -->
<div class="article-summary scenario">
<img src="/EPiServer/CMS/Content/contentassets/en/21cd8489b66d40a9b9711df5158be324/spotless-panda.png,,113?epieditmode=False" alt="">
<p>To the left you can see a "Polar Bear".</p>
</div></code></pre>
<p>We can try to use <strong>EditAttributes</strong> instead of <strong>PropertyFor</strong>, and at first it might seem to work but as can be seen in the second polar bear in the animation, the image does not seem to be replaced when the user updates that property.</p>
<pre class="language-html"><code><!-- scenario 2 B markup -->
<div class="article-summary scenario">
<img @Html.EditAttributes(x => x.CurrentPage.SummaryImage) src="@Url.ContentUrl(Model.CurrentPage.SummaryImage)" class="image" />
<p @Html.EditAttributes(x => x.CurrentPage.SummaryText)>@Model.CurrentPage.SummaryText</p>
</div>
<!-- scenario 2 B rendered in OPE -->
<div class="article-summary scenario">
<img data-epi-property-name="SummaryImage" data-epi-use-mvc="True" src="/EPiServer/CMS/Content/contentassets/en/21cd8489b66d40a9b9711df5158be324/polarbearonice.png,,81?epieditmode=False" class="image">
<img src="/EPiServer/CMS/Content/contentassets/en/21cd8489b66d40a9b9711df5158be324/spotless-panda.png,,113?epieditmode=False&visitorgroupsByID=undefined" alt="">
</img>
<p data-epi-property-name="SummaryText" data-epi-use-mvc="True">To the left you can see a "Polar Bear".</p>
</div>
<!-- scenario 2 B rendered in Preview -->
<div class="article-summary scenario">
<img src="/EPiServer/CMS/Content/contentassets/en/21cd8489b66d40a9b9711df5158be324/spotless-panda.png,,113?epieditmode=False" class="image">
<p>To the left you can see a "Polar Bear".</p>
</div></code></pre>
<p>The child <img> in the OPE view is not valid HTML and is not displayed by the browser, causing some confusion for a user as the property did in fact update when it did not look like it.</p>
<p>To be able to change this, we need to make changes to our property renderers and their use of custom display templates. However, it does not seem possible without a breaking change, needing a new major release. If this is an important issue for you that you would like us to focus on, please vote on the bug <a href="/link/1933ba72787346df9003b7a4c7d1cff8.aspx?epsremainingpath=bug/CMS-9506">CMS-9506</a>.</p>
<p>For now, you need to use a wrapping element and write the markup and stylesheet with that in mind. In our example we decided to use a CSS grid, but your solution may vary.</p>
<pre class="language-html"><code><!-- solution markup -->
<div class="article-summary-grid solution">
<div @Html.EditAttributes(x => x.CurrentPage.SummaryImage) class="left">
<img src="@Url.ContentUrl(Model.CurrentPage.SummaryImage)"/>
</div>
<p @Html.EditAttributes(x => x.CurrentPage.SummaryText) class="right">
@Model.CurrentPage.SummaryText
</p>
</div>
<!-- solution rendered in OPE -->
<div class="article-summary-grid solution">
<div data-epi-property-name="SummaryImage" data-epi-use-mvc="True" class="left">
<img src="/EPiServer/CMS/Content/contentassets/en/21cd8489b66d40a9b9711df5158be324/spotless-panda.png,,113?epieditmode=False&visitorgroupsByID=undefined" alt="">
</div>
<p data-epi-property-name="SummaryText" data-epi-use-mvc="True" class="right">
To the left you can see a "Polar Bear".
</p>
</div>
<!-- solution rendered in Preview -->
<div class="article-summary-grid solution">
<div class="left">
<img src="/EPiServer/CMS/Content/contentassets/en/21cd8489b66d40a9b9711df5158be324/spotless-panda.png,,113?epieditmode=False">
</div>
<p class="right">
To the left you can see a "Polar Bear".
</p>
</div></code></pre>
<p>See the code on our Github (in the branch blog/designing-without-wrapping-elements): <a href="https://github.com/episerver/alloy-mvc-template/compare/blog/designing-without-wrapping-elements">https://github.com/episerver/alloy-mvc-template/compare/blog/designing-without-wrapping-elements</a></p>
<p>We hope this helps you along. <img src="/Scripts/tinymce/plugins/emoticons/img/smiley-smile.gif" alt="smile" /></p>
</body>
</html>2018-05-04T14:33:05.0000000ZBlog post"domUpdated" is no longer needed (BETA) (CMS UI 11.4.0)<!DOCTYPE html>
<html>
<head>
</head>
<body>
<p>You can read more about how you enable Beta features in <a href="/link/cb1c889682ca4002870a5dfb6482d674.aspx">the documentation</a>.</p>
<p>In CMS UI 11.2.0 we introduced <a href="/link/bea7c9750d854be69972f1b705b29d07.aspx">the "beta/domUpdated" message</a> that refreshes the On-Page Editing (OPE) overlays. Based on feedback we received at presentations and <a href="https://github.com/episerver/AlloyReact/issues/2">on Github</a>, we are now watching the view for changes to DOM elements with the "data-epi-property-name" property. You no longer need to do this:</p>
<pre class="language-csharp"><code>epi.publish("beta/domUpdated")</code></pre>
<p>If the DOM changes so that there are new elements with data-epi-property-name, or existing elements change their value to another property name, then the overlays automatically gets updated.</p>
<h2>Previous considerations</h2>
<p>As mentioned in the previous post, there were two reasons to introduce a message instead of automatically refreshing:</p>
<p>1. UI becomes unresponsive as the spamming is ongoing<br />2. Memory usage increases</p>
<p>There was also a third reason:</p>
<p>3. Giving you control of when to refresh, as to minimize 1 and 2.</p>
<p>But reason 3. seems like it just lead to boilerplate code that many would rather avoid, and we had already made changes to minimize the impact of 1. and 2., so when we got the question "can't it just 'work'?" we decided to make this change. The overlays will update by themselves now.</p>
<p><img src="/link/8a23abb703094bf2b0c581dca1cb7f89.aspx" alt="Image after.gif" /></p>
<h2>Benefits</h2>
<p>The main benefit is that it's now easier for a partner to make great client-side rendered UI's that still work nicely in OPE. That also makes our communication around features like this easier, because you don't have to do anything. <img src="/Scripts/tinymce/plugins/emoticons/img/smiley-cool.gif" alt="cool" /> </p>
<h2>Code on Github</h2>
<p>Please contribute to these repos to help each other with how to work with OPE and your favourite JavaScript framework!</p>
<p>The example in our React sample repo has been updated to remove the "beta/domUpdated" code:<span> </span><a href="https://github.com/episerver/AlloyReact">https://github.com/episerver/AlloyReact</a></p>
<p>Please contribute an example to the AngularJS repo:<span> </span><a href="https://github.com/episerver/AlloyAngularJS">https://github.com/episerver/AlloyAngularJS</a></p>
</body>
</html>2018-03-13T08:04:42.0000000ZBlog postTaking more control of client-side rendering in OPE (Beta) (CMS UI 11.2.0)<p class="informationBox">This feature has changed in CMS UI 11.4.0! The event is no longer needed. Read <a title=""domUpdated" is no longer needed" href="/link/8d015a9266d54bb78a849ea0603aeb79.aspx">the blog post</a> for more info.</p>
<p>You can read more about how you enable Beta features in <a href="/link/cb1c889682ca4002870a5dfb6482d674.aspx">the documentation</a>.</p>
<p><span>Earlier, in <a href="/link/4552b6ecd7504771b9f3aae5832cb3a6.aspx">CMS UI 10.12.0, we introduced some features</a> that let you take some control over the client-side rendering in On-Page Edit (OPE). One of those tools was the "beta/contentSaved" topic that you could subscribe to to know when to update the DOM. With <strong>CMS UI 11.2.0,</strong> we address the other side of that coin, which is letting us subscribe to know when you updated the DOM and that we need to remap the OPE overlays.</span></p>
<p><span>Here we’ll go through one new topic that you can use to further improve the OPE experience while using Angular, React, or any other JavaScript framework. You can read more in the <a href="/link/60371278b0b348a4a2b95c1bccc16ed9.aspx">Editing documentation</a>.</span></p>
<p>The global JavaScript object (see "Telling OPE that you need new overlays"):</p>
<ul>
<li>epi.publish("beta/domUpdated")</li>
</ul>
<h2>Knowing when to remap the OPE overlays</h2>
<p>One common scenario is when you have an element with the property "data-epi-property-name" that will enable the OPE overlay, but since this element is not present when the OPE overlays are created, you don't see an OPE overlay for the element. This makes editing that property slightly challenging in OPE and once again you have to direct your editors to the All properties view. The <a href="/link/4675a24d3e164719a4a5cdbc58c94172.aspx">Sticky View Mode</a> can keep your editors from switching views all the time, but it would be nicer if OPE just works, right?</p>
<p><span>There are several situations where the OPE overlay doesn't match the DOM:</span></p>
<ul>
<li><span>Element is conditionally rendered by the client-side framework</span>
<ul>
<li><span>Example: A text that's only shown when the user reaches the last page in a pagination</span></li>
</ul>
</li>
<li><span>Element is replaced by another similar element but using another "data-epi-property-name" value</span>
<ul>
<li><span>Example: When loading the value was "fact1", and after user interaction the value is "fact2"</span></li>
</ul>
</li>
<li><span>Element is rendered after the page has loaded</span>
<ul>
<li>Example: Data is fetched through an API and only renders once it's done</li>
</ul>
</li>
</ul>
<p>We'll focus on the first two examples because they're easier to demo. For the user, it can look like this:</p>
<p><img alt="Image before.gif" src="/link/43c4a317465c4ef5a00e3d57ed0d0409.aspx" /></p>
<h2>Telling OPE that you need new overlays</h2>
<p>We felt that using a message to communicate, like with "beta/contentSaved", was a nice solution so we decided to create a new topic: <strong>"beta/domUpdated"</strong>. To tell the OPE view to remap all the overlays on the page, simply <strong>publish </strong>to that topic using the global "<strong>epi</strong>" object:</p>
<pre class="language-csharp"><code>epi.publish("beta/domUpdated");</code></pre>
<p><em>Note:</em> You cannot subscribe to this topic from the view because the communication only goes from and to the iframe where the page view lives. A gadget or other code on the CMS UI side would be able to subscribe though.</p>
<h2>Considerations when using an over-powered feature</h2>
<p>With the new topic, it's possible to accidentally spam messages, prefering to publish one too many than one too few. This causes a few problems.</p>
<ol>
<li>UI becomes unresponsive as the spamming is ongoing</li>
<li>Memory usage increases</li>
</ol>
<p>To solve problem 1, we added a debounce period of 100 milliseconds where each new message resets the cool down period. This causes a small (100ms) lag before the OPE overlays are remapped.</p>
<p>To solve problem 2, we had to do several performance improvements, that also improve memory usage in other scenarios, such as changing pages (context change). All in all, we've made dozen small fixes, but as we say in Sweden: "<a href="https://sv.wiktionary.org/wiki/Många_bäckar_små_gör_en_stor_å.">Many small streams make a big river.</a>"</p>
<p>In one scenario we tried, we made a Higher-Order Component in React that would publish a message on the "beta/domUpdated" topic on componentDidMount and componentDidUpdate. The problem was that we created a new wrapped component in the render method, and that lead to an exponential growth of messages every time something rendered. The lesson is that it's very easy to accidentally publish too many messages. :) As the <a href="http://marvel.wikia.com/wiki/Benjamin_Parker_(Earth-616)">great American poet Ben Parker</a> once said: "With great power, there must also come great responsibility". So try to consolidate your DOM changes to as few messages as you can.</p>
<p><span style="color: inherit; font-family: inherit; font-size: 22px;">A simple example in React</span></p>
<p>The message in "domUpdated" is simpler than the "contentSaved" because there is no message object involved. To demonstrate this we're just going to publish the message in our ThreeKeyFacts' componentDidUpdate method, but you should try to consolidate the messages so each component doesn't live its own life and spam "domUpdated" messages.</p>
<pre class="language-csharp"><code>import React from "react";
export default class ThreeKeyFacts extends React.Component {
constructor(props) { ... }
render() { ... }
next() { ... }
previous() { ... }
componentDidMount() {
// Here we do some epi.subscribe("beta/contentSaved", ...)
}
componentDidUpdate() {
if (window.epi && window.epi.publish) {
// Publishing a message on the "beta/domUpdated" topic will tell episerver UI that the DOM has changed
// and that it needs to remap its overlays.
window.epi.publish("beta/domUpdated");
}
}
}</code></pre>
<p>By publishing a message on the "beta/domUpdated" topic in componentDidUpdate the overlays now match the elements being shown:</p>
<p><img alt="Image after.gif" src="/link/a91cab64f4fb43e19d32ea7e782bbb05.aspx" /></p>
<h2> </h2>
<h2>Code on Github</h2>
<p>Please contribute to these repos to help each other with how to work with OPE and your favourite JavaScript framework!</p>
<p>The example above is in our React sample repo:<span> </span><a href="https://github.com/episerver/AlloyReact">https://github.com/episerver/AlloyReact</a></p>
<p>Please contribute an example to the AngularJS repo:<span> </span><a href="https://github.com/episerver/AlloyAngularJS">https://github.com/episerver/AlloyAngularJS</a></p>2017-12-19T12:59:55.0000000ZBlog postTaking control of client-side rendering in OPE (Beta) (CMS UI 10.12.0)
<p>You can read more about how you enable Beta features in <a href="/link/8b4432703e44486ea1af6ddec232a8c5.aspx">Fredrik Tjärnberg’s blog post</a>.</p>
<p>With CMS UI 10.12.0 we’re including some options to better support the On-Page Editing (OPE) experience for websites that want to handle the view on the client-side. This could be using a JavaScript framework such as React or Angular. The main issue is about controlling the DOM and Ted Nyberg explains it well <a href="https://tedgustaf.com/blog/2017/episerver-on-page-edit-with-angular-react-and-other-js-frameworks/">in his blog</a>. Many projects work around it by simply asking the editors to use the Properties Mode instead, which is why we previously released <a href="/link/4675a24d3e164719a4a5cdbc58c94172.aspx">"Sticky View Mode" in CMS UI 10.11.0</a>.</p>
<p>Here we’ll go through four things you can use to improve the OPE experience while using Angular, React, or any other JavaScript framework. You can read more in the <a href="/link/60371278b0b348a4a2b95c1bccc16ed9.aspx">Editing documentation</a>.</p>
<p><strong>Three HTML attributes for editing</strong> (see "Telling OPE that you’ll take over the rendering"):</p>
<ul>
<li><span class="classLib">data-epi-property-name="YourProperty"</span></li>
<li><span class="classLib">data-epi-property-render="none"</span></li>
<li><span class="classLib">data-epi-property-edittype="floating"</span> (usually default, but needed for string properties)</li>
</ul>
<p><strong>And the global JavaScript object</strong> (see "Knowing when to re-render"):</p>
<ul>
<li><span class="classLib">epi.subscribe("beta/contentSaved", callback)</span></li>
</ul>
<h2>Telling OPE that you’ll take over the rendering</h2>
<p>To stop the CMS UI from replacing the DOM when an editor changes the value of a property, add the HTML attribute data-epi-property-render="none" to the DOM element that's marked for editing with <strong>@Html.EditAttributes(m => m.YourProperty)</strong> or <strong>data-epi-property-name="YourProperty"</strong>.</p>
<p>If you’re editing a string-type you can add the <strong>data-epi-property-edittype="floating"</strong> to get a dialog with the text, instead of contenteditable replacing the DOM as the user types.</p>
<h2>Knowing when to re-render</h2>
<p>Now that OPE won't replace the DOM as the user changes property values you’ll need to do this yourself. But how do you know when when or what to change?</p>
<p>For this we’ll use the little known "epi" object that allows us to communicate between the CMS UI context and the view. Whenever a save happens we will publish the details on a topic called <strong>"beta/contentSaved"</strong>. You can subscribe to this topic to know when and what to change in your view.</p>
<p>If you based your site on Alloy you probably have this object already. To get it you need have the attribute <strong>[RequireClientResources]</strong> on your controller, or just inherit from <strong>PageController</strong> or <strong>ContentController</strong> as they'll include it. Then you’ll need to require the resources in your razor view where you include any other scripts, probably in _Root.cshtml, using: <strong>@Html.RequiredClientResources("Footer")</strong></p>
<h2>A simple string example (without JS)</h2>
<p>Let’s see how things look without JavaScript. When it comes to string property types they’re changing the DOM as you type. Besides the problems for client-side frameworks, it makes editing awkward in certain scenarios such as the placeholder text in input-elements.</p>
<p><img src="/link/7811d7e4be024ed997ff3cdcab2abd2b.aspx" alt="Image nojs-sample.gif" /></p>
<p>To achieve this we’ll add a property to the model. I’m using Alloy and the Search page, so in Models/Pages/SearchPage.cs I’m adding:</p>
<pre class="language-csharp"><code>public virtual string SearchPlaceholderText { get; set; }</code></pre>
<p>And in its Razor-view, which for me is Views/SearchPage/Index.cshtml, add this to force a reload:</p>
<pre class="language-csharp"><code>@Html.FullRefreshPropertiesMetaData(new[] { "SearchPlaceholderText" })</code></pre>
<p>And change the input element from this:</p>
<pre class="language-html"><code><input type="text" tabindex="1" name="q" value="@Model.SearchedQuery" /></code></pre>
<p>To this:</p>
<pre class="language-html"><code><input type="text" tabindex="1" name="q" value="@Model.SearchedQuery" placeholder="@Model.CurrentPage.SearchPlaceholderText" data-epi-property-name="SearchPlaceholderText" data-epi-property-edittype="floating" /></code></pre>
<p>See the code in the links below.</p>
<h2>A simple example in AngularJS</h2>
<p>Let’s use Alloy, but change the page image for Product pages so that we're showing the editor some extra info about the image. This could be useful for sites that have more image metadata or other data that depend on the selected image.</p>
<p>This is what we're going for:</p>
<p><img src="/link/7bf8fc60b9424a5c9ced5909a9df7c49.aspx" alt="Image angular-sample.gif" /></p>
<p>Originally, the view looks like this:</p>
<pre class="language-html"><code><div @Html.EditAttributes(x => x.CurrentPage.PageImage)>
<img src="@Url.ContentUrl(Model.CurrentPage.PageImage)"/>
</div>
</code></pre>
<p>We're changing it to this:</p>
<pre class="language-html"><code><div data-epi-property-name="PageImage" data-epi-property-render="none">
<img ng-src="{{ctrl.pageImageUrl}}" alt="{{ctrl.pageImageName}}"/>
@if (PageEditing.PageIsInEditMode)
{
<pre>Drag an image here to test OPE with Angular!<br/>Image name: {{ctrl.pageImageName}}</pre>
}
</div></code></pre>
<p>Note that <strong>@Html.EditAttributes()</strong> is replaced with <strong>data-epi-property-name</strong>. This enables the content overlay and allows the editor to change the value of that property.</p>
<p>Also note the <strong>data-epi-property-render</strong> that's telling the renderer that we'll be handling things for this element!</p>
<p>To get some start values, we're copying parts of the model to a global object that our Angular controller can initialize with.</p>
<pre class="language-html"><code><script>
window.pageModel = {
contentLink: "@Model.CurrentPage.ContentLink",
pageImage: "@Model.CurrentPage.PageImage"
};
</script></code></pre>
<p>The code on Github has more functionality and comments explaining them, so here I’ll just outline the important part: how to update the values when the page is being edited.</p>
<p>You could work against a service and/or have this code in the Razor view, but it’s tricky to communicate between the global scope and Angular. So I chose to have this inside the controller as it's easier to demonstrate.</p>
<pre class="language-csharp"><code>var vm = this;
vm.model = $window.pageModel || {};
// Helper method to get image URL and name through XHR and update pageImage properties.
function updatePageImage(contentLink) { … }
// Wait until the window has loaded, and then hook up our property update logic.
$window.addEventListener("load", function () {
// Subscribe to the contentSaved topic. Now the fun starts!
$window.epi.subscribe("beta/contentSaved", function (details) {
// Go through all the saved properties. Usually it's only one.
details.properties.forEach(function (property) {
switch (property.name) {
// Handle the page image property differently, because we only get the content reference but need more data for the page.
case "pageImage":
updatePageImage(property.value);
break;
// Otherwise just update the value on the model.
default:
vm.model[property.name] = property.value;
break;
}
});
});
});</code></pre>
<p><a href="/link/60371278b0b348a4a2b95c1bccc16ed9.aspx">The documentation</a> has an example of the object you might get from the event, but below is the interesting part:</p>
<pre class="language-csharp"><code>{
"contentLink":"6_164", // The content reference to this page
"properties":[
{
"name":"pageImage", // The property that changed
"value":"59" // The new value. Content references will need an extra lookup to get what you want, but string and other properties can be usable directly.
}
]
}</code></pre>
<p>See the code in the links below.</p>
<h2>A complex example in React</h2>
<p>We have an example of how to rewrite the PageListBlock in React but it's a little big for this blog post. The basic usage of the data-attributes and listening to the “beta/contentSaved” message is the same as in the Angular example above. See the code in the links below.</p>
<h2>Code on Github</h2>
<p>Please contribute to these repo's to help each other how to work with OPE and your favourite JavaScript framework!</p>
<p>A simple string example (without JS): <a href="https://github.com/seriema/AlloyNoJS">https://github.com/seriema/AlloyNoJS</a></p>
<p>A simple example in AngularJS: <a href="https://github.com/seriema/AlloyAngularJS">https://github.com/seriema/AlloyAngularJS</a></p>
<p>A complex example in React: <a href="https://github.com/seriema/AlloyReact">https://github.com/seriema/AlloyReact</a></p>2017-10-03T14:12:30.0000000ZBlog postIntroducing Group/Role support in Content Approvals<!DOCTYPE html>
<html>
<head>
</head>
<body>
<p>This feature was released in CMS UI 10.10.0.</p>
<h2>What are Groups/Roles?</h2>
<p>Groups, or Roles, are already commonly used in the CMS to manage access rights and other settings that should apply to a group of users instead of setting them individually. A commonly mentioned use case for Content Approvals is to add a group of users to a step instead of individual users. For example, adding the "Legal Department" group as a reviewer. This makes setting up content approval sequences easier as well as allowing the members of a group to change without having to change the sequence. So if there's a new hire in the "Legal Department" or someone leaves for another position, you just have to update the group and the new hire is included in the reviews (both ongoing and future reviews) and the removed user can no longer review content.</p>
<p> <img src="/link/b917986b857b4c8aa02eecf287d2cb9a.aspx" alt="Image blog-role-reviewer.gif" /></p>
<h2>What about Notifications in large groups?</h2>
<p>Adding a very large group will result in notifications being sent out to all the current members of the group on every step in a content approval sequence. This can have negative effects on the performance of the server, as well as probably annoy users. Therefore, we have added <a href="/link/234ad865e8d24900b49f5afa830343c9.aspx">a new configuration setting</a>, "ApprovalStepRoleUserLimit", that defaults to 100 users per group. Adding a group larger than this setting to a content approval sequence, triggers a validation warning, and it also limits the amount of notifications per group.</p>
<h2>What are known limitations?</h2>
<p>There can be limitations depending on the role provider used. <a href="/link/c620e944deea45d5a43e1237acec2848.aspx">See the SDK for more information.</a></p>
</body>
</html>2017-06-13T15:22:19.0000000ZBlog postIntroducing Tasks in Content Approvals (Beta)<p>This feature is released as a Beta feature in CMS UI 10.5.0 and is still under development.</p>
<p>You can read more about how you enable Beta features in<span> </span><a href="/link/8b4432703e44486ea1af6ddec232a8c5.aspx">Fredrik Tjärnberg’s blog post</a>.</p>
<h2>What are Tasks?</h2>
<p>The Tasks pane is a useful tool for editors to monitor content creation. You can filter out content depending on their status, for example, select Drafts in the Tasks drop-down to get a list with content items in status Draft only.</p>
<p><img src="/link/35ea64f12b124f6f99e0776962c007f0.aspx" alt="Image blog-tasks-tasks-menu-original.PNG" /></p>
<h2>Tasks with Content Approvals</h2>
<p>The Tasks drop-down list can now be used to display content in a certain stage of an approval sequence,<span> </span>in a way that helps the editor to know what to focus on.</p>
<p>For example, Alfred has sent two pages for review, and the approval sequence is set up to allow either Lina or Emil to approve. Lina uses the Tasks pane and <strong>Received Review Requests</strong> > <strong>Awaiting Your Review</strong> to see what content she has to review and do some work:</p>
<p><img src="/link/80f414b4a6b34c048960abdb405eb511.aspx" alt="Image blog-tasks-lina--optimized.gif" /></p>
<h2>Bonus feature: Categorized Tasks Queries</h2>
<p>As part of this release, we added grouping support to the Tasks menu. As you can see in the screenshot below that there are three main categories: "Status", "Sent for Review", and "Received Review Requests".</p>
<p>Any other query will end up in a category labelled "Other", and you can <a href="/link/4b6160d6e68849f78297fb152918c3f3.aspx">easily put them in an existing or a new custom category</a>.</p>
<p><img src="/link/b7d75460b213449eaf792fc1660bf97f.aspx" alt="Image blog-tasks-tasks-menu-new--awaiting-review.png" /></p>
<h2>Bonus feature: Optional Localization Support with IContentQuery and IContentQueryCategory </h2>
<p>Often you might end up implementing the query’s <strong>DisplayName</strong> using the <strong>LocalizationService</strong>. Like this:</p>
<pre class="language-csharp"><code>// No need for this anymore
public override string DisplayName => _localizationService.GetString("/awesomequeries/super/label");</code></pre>
<p>It’s so common that we made it simpler by allowing <strong>DisplayName</strong> to be a key and it will be used with the <strong>ILocalizationService</strong> to return the localized display name.</p>
<pre class="language-csharp"><code>// Do this instead, if you use the LocalizationService
public override string DisplayName => "/awesomequeries/super/label";</code></pre>2017-02-07T08:09:02.2370000ZBlog postIntroducing Notifications in Content Approvals (Beta)<p>This feature was released as a Beta feature in CMS UI 10.3.0 and is still under development.</p>
<p>You can read more about how you enable Beta features in <a href="/link/8b4432703e44486ea1af6ddec232a8c5.aspx">Fredrik Tjärnbergs blog post</a>.</p>
<p>You can also read more about Content Approvals in <a href="/link/dc12be0461b347888d55696f41729517.aspx">my previous blog post</a>.</p>
<p>Notifications require <a href="/link/b59adfabbe504c61ad793973b05f002f.aspx">WebSockets</a> and <a href="/link/8ead888910d54679b8952d9eeb940b6e.aspx">configuring your email server</a>.</p>
<h2>What are Notifications?</h2>
<p>Notifications were released as public beta in CMS 9.4.0 and is used by CMS UI 9.4.0 to show notifications related to Projects. A notification is sent instantly to the recipient and shows up in the UI in the "bell icon". Any unread messages will later be emailed out to the user. In CMS 10.3.0, emails can also be sent out instantly instead of waiting for the Notification dispatcher scheduled job.</p>
<h2>Notifications on Content Approval events</h2>
<p>In CMS UI 10.3.0 notifications are also used to send Content Approval-related messages, and it uses the new instant emails as well.</p>
<p>In the screenshot below, Lina has received a notification that Alfred has sent a page to be reviewed, and she is one of the approvers that should approve or decline the change.</p>
<p><img src="/link/dbde68e43e624ff7ae23dbcbd5d44be0.aspx" alt="Image blog-notifications-lina-ui.PNG" /></p>
<p>Lina also receives an email about this, as seen below.</p>
<p><img src="/link/08888dd1161f40348f2443f3a3d2a59c.aspx" alt="Image blog-notifications-lina-email.PNG" /></p>
<p>Lina decides to approve the changes and since this scenario only has one step, the page is now ready to be published. In the screenshot below, Alfred is notified about this.</p>
<p><img src="/link/6a7c1c25b046453792aa9ec314e0c507.aspx" alt="Image blog-notifications-alfred.PNG" /></p>
<p>Notifications are sent when content is awaiting approval, has been approved, declined, or aborted. Those events are available on the <strong>ApprovalEngineEvents</strong> which can be hooked into.</p>2016-12-27T13:21:27.6330000ZBlog postIntroducing Content Approvals (Beta)<table>
<tbody>
<tr>
<td>
<p>This feature was released as a Beta feature in CMS 10.1.0 and is still under development.</p>
<p><span>You can read more about how you enable Beta features in </span><a href="/link/8b4432703e44486ea1af6ddec232a8c5.aspx">Fredrik Tjärnbergs</a><span> blog post.</span></p>
</td>
</tr>
</tbody>
</table>
<h2>What are Content Approvals?</h2>
<p>Content approvals <span>is a way to make sure that content is reviewed and approved before it is published. It works as a new state (In review) between Draft and Published, which is visible in the Versions gadget. When an editor has finished working on a content item, the editor cannot publish it but has to set it as <strong>Ready for Review</strong>. One or more appointed reviewers must then approve the content item before it can be published. The reviewers are defined by an administrator in an<strong> Approval Sequence</strong>.</span></p>
<table>
<tbody>
<tr>
<td>
<p>Content approvals do not apply to blocks at this stage.</p>
</td>
</tr>
</tbody>
</table>
<p>The Approval Sequence <span>is set up by an administrator and can have any number of approval steps and any number of approvers in each step. If the page has multiple languages there has to be at least one approver for each language in each step.</span></p>
<h2><span>Bonus feature: Pluggable menu items</span></h2>
<p><span>The approval sequence overview is opened from the context menu in the page tree:</span><span> </span></p>
<p><img src="/link/57a2dad539e94edb96ad90bcdefa2af9.aspx" alt="Image Content Approval blog post - context menu.png" /></p>
<p>As a part of this release, we made the context menu pluggable. So now you can <a href="/link/54b2ad595a1340ada5f37300957b7934.aspx">easily add items to the context menu</a>.</p>
<h2>More about Content Approvals</h2>
<p>Content Approvals work with Projects but only on a per-content basis, and not for the whole Project.</p>
<p>The approvals can be driven through the Core API, but beware that it's also in Beta and will change a lot as we're continuing on Content Approval. Do take a look at the IApprovalEngine and IApprovalEngineEvents in the meantime. Use it to react to content moving through the sequence, or automatically reject or approve changes.</p>
<p>You can read more about Content Approvals in the <a href="http://webhelp.episerver.com/latest/cms-edit/content-approvals.htm">User guide documentation</a>.</p>
<p>There are more things coming with Content Approvals, but please let us know what you like or if there's anything you want us to focus on.</p>2016-11-14T13:43:16.6600000ZBlog post