Blog posts by martin-ottosen2024-03-01T14:48:34.0000000Z/blogs/martin-ottosen/Optimizely WorldHeadless forms reloaded (beta)/blogs/martin-ottosen/dates/2024/3/headless-forms-reloaded-beta/2024-03-01T14:48:34.0000000Z<p>Forms is used on the vast majority of CMS installations. But using Forms in a headless setup is a bit of pain since the rendering pipeline is based on ASP.NET MVC. We do have an extension to our Content Delivery API that includes the generated forms HTML in the json model for a page, but if you want the frontend to control the look & feel of the rendered form, you’re fighting an uphill battle. Better then if Forms could just expose the raw forms configuration with a handy front-end SDK with a good default rendering.</p>
<p><span style="background-color: #bfedd2;">Note: This feature is in</span><span style="background-color: #bfedd2;"> Beta, you are welcome to use it, but we do have more changes coming before the official release. Beta packages will be removed once official packages are released.</span></p>
<h1>What's in it?</h1>
<ol>
<li>Forms 5 <a href="https://nuget.optimizely.com/package/?id=EPiServer.Forms">[package]</a> <a href="https://docs.developers.optimizely.com/content-management-system/v1.2.0-forms/docs/forms">[docs]</a></li>
<li>New REST API <a href="https://dev.azure.com/EpiserverEngineering/netCore/_artifacts/feed/headless_forms_beta/NuGet/Optimizely.Headless.Form.Service/overview/">[beta package]</a> <a href="https://docs.developers.optimizely.com/content-management-system/v1.2.0-forms/docs/set-up-headless-optimizely-forms-api">[beta docs]</a></li>
<li>(optional) Graph integration <a href="https://dev.azure.com/EpiserverEngineering/netCore/_artifacts/feed/headless_forms_beta/NuGet/Optimizely.Headless.Form.ContentGraph/overview/">[beta package]</a> <a href="https://docs.developers.optimizely.com/content-management-system/v1.2.0-forms/docs/integrate-optimizely-graph-with-headless-optimizely-forms">[beta docs]</a></li>
<li>(optional) generic JS SDK <a href="https://dev.azure.com/EpiserverEngineering/netCore/_artifacts/feed/headless_forms_beta/Npm/@episerver%2Fforms-sdk/overview/0.1.0">[beta package]</a> <a href="https://docs.developers.optimizely.com/content-management-system/v1.2.0-forms/docs/javascript-sdk-for-headless-optimizely-forms">[beta docs]</a> <a href="https://github.com/episerver/content-headless-form-js-sdk/tree/develop/src/%40episerver/forms-sdk">[repo]</a></li>
<li>(optional) react specific SDK <a href="https://dev.azure.com/EpiserverEngineering/netCore/_artifacts/feed/headless_forms_beta/Npm/@episerver%2Fforms-react/overview/0.1.0">[beta package]</a> <a href="https://docs.developers.optimizely.com/content-management-system/v1.2.0-forms/docs/install-headless-optimizely-forms-javascript-sdk-for-the-client-app">[beta docs]</a> <a href="https://github.com/episerver/content-headless-form-js-sdk/tree/develop/src/%40episerver/forms-react">[repo]</a></li>
</ol>
<p>As a quick example I created the worlds least interesting form using a boilerplate Alloy MVC site, which yes is not headless, but that’s the point really. This is just good-old-forms under the hood.</p>
<p><img src="/link/a8f0d1e500e441709ed0fa81b4ba46ba.aspx" width="1000" alt="" height="699" /></p>
<p>With a reference to <a href="https://pkgs.dev.azure.com/EpiserverEngineering/netCore/_packaging/headless_forms_beta/nuget/v3/index.json">the headless forms beta feed</a> we can add the new REST API and optionally swashbuckle:</p>
<pre class="language-javascript"><code><PackageReference Include="EPiServer.Forms" Version="5.8.0" />
<PackageReference Include="Optimizely.Headless.Form.Service" Version="0.1.0" />
<PackageReference Include="Swashbuckle.AspNetCore" Version="6.5.0" /></code></pre>
<p>Getting the new endpoint setup is pretty easy, we need to add a service to startup.cs for the new API and optionally a service + some configuration for swagger:</p>
<pre class="language-csharp"><code>// Enable OpenAPI documentation
services.AddSwaggerGen();
//Configure the API headless forms API
services.AddOptimizelyHeadlessFormService(options =>
{
// Enable swagger docs for headless forms API @ /_form/v1/docs/openapi.json
options.EnableOpenApiDocumentation = true;
options.FormCorsPolicy = new FormCorsPolicy
{
AllowOrigins = new string[] { "_" }, //Enter '_' to allow any origins, multiple origins separate by comma
AllowCredentials = true
};
});</code></pre>
<p> </p>
<pre class="language-csharp"><code>// Configure swagger UI to use the headless forms API spec
app.UseSwagger();
app.UseSwaggerUI(options =>
{
options.SwaggerEndpoint("/_form/v1/docs/openapi.json", "Optimizely Headless Form API V1");
});</code></pre>
<p>With that we get nice local documentation of the API available at <span style="text-decoration: underline;">/swagger/</span>. In production you would probably want to configure OIDC for access to endpoints and docs.</p>
<p><img src="/link/f5167624812e4b59b980474296a0e526.aspx" width="1000" alt="" height="442" /></p>
<p>To get the full form configuration you pass in the GUID of the form container in <span>UUID N format</span><span> i.e. without any “-“ separators </span></p>
<pre class="language-javascript"><code>GET /_form/v1/form/2df32b30ade54eb3970e4ab5170fb5ff
{
"key": "2df32b30ade54eb3970e4ab5170fb5ff",
"properties": {
"title": "test",
"allowToStoreSubmissionData": true,
"showSummarizedData": false,
"confirmationMessage": "Thank you, come again!",
"allowAnonymousSubmission": false,
"allowMultipleSubmission": true,
"showNavigationBar": true,
"focusOnForm": true
},
"formElements": [
{
"key": "2697b674ec554f7a817ea1f977fc2204",
"contentType": "TextboxElementBlock",
"displayName": "New form element",
"properties": {
"validators": [
{
"type": "RequiredValidator",
"description": null,
"model": {
"message": "This field is required.",
"validationCssClass": "ValidationRequired",
"additionalAttributes": {
"required": "",
"aria-required": "true"
}
}
}
],
"label": "Name",
"placeHolder": "firstname lastname",
"conditions": []
},
"locale": "en",
"localizations": {}
},
{
"key": "3aa836ec620146cf8291263c51b4b44f",
"contentType": "SubmitButtonElementBlock",
"displayName": "New form element",
"properties": {
"validators": [],
"label": "Go!",
"conditions": []
},
"locale": "en",
"localizations": { "label": "Submit" }
}
],
"locale": "en",
"localizations": {
"allowAnonymousSubmissionErrorMessage": "You must be logged in to submit this form. If you are logged in and still cannot post, make sure \"Do not track\" in your browser settings is disabled.",
"allowMultipleSubmissionErrorMessage": "You already submitted this form.",
"malformstepconfigruationErrorMessage": "Improperly formed FormStep configuration. Some steps are attached to pages, while some steps are not attached, or attached to content with no public URL."
}
}</code></pre>
<p>Installing the Forms to Graph integration of course requires Optimizely Graph, and will simply add a new property “FormRenderTemplate” to the Graph model for a FormContainerBlock exposing the exact same json object available from the REST API.</p>
<pre class="language-javascript"><code>query MyQuery {
FormContainerBlock {
items {
FormRenderTemplate
}
}
}</code></pre>
<p>If we want to upgrade to a completely decoupled frontend we can use the react sample from <a href="https://github.com/episerver/content-headless-form-js-sdk">the new forms SDK repository</a>, but I think that warrants it’s own blog post.</p>
<p>Besides any notes you may have here or at <a href="https://feedback.optimizely.com/?category=6852085523081599129">feedback.optimizely.com</a> for this beta release, we have plans to update the current authorization system for form submitters and refine the SDK to give you a better looking starting point.</p>Tag Helpers in CMS 12/blogs/martin-ottosen/dates/2023/3/tag-helpers-in-cms-12/2023-03-20T13:39:47.0000000Z<p>Microsoft <a href="https://www.hanselman.com/blog/aspnet-5-vnext-work-in-progress-exploring-taghelpers">introduced the TagHelper back in the primordial soup of ASP.NET vNext</a> which became <a href="/link/be8077bc415c4afca844daf0fb0e83bb.aspx">.Net 5, then .NET Core then .Net 5</a> you know the drill…</p>
<p>In the initial release of CMS 12 our focus was to bringing our HTML Helpers with us to make it easier to migrate from CMS 11, but <a href="https://learn.microsoft.com/en-us/aspnet/core/mvc/views/tag-helpers/intro">Tag Helpers</a> are neat, they help simplify razor code by promoting a more html-oriented syntax, and available in the new <a href="https://nuget.optimizely.com/package/?id=EPiServer.CMS.AspNetCore.TagHelpers">EPiServer.CMS.AspNetCore.TagHelpers package</a> available on the nuget feed. The <a href="https://www.nuget.org/packages/EPiServer.Templates">EPiServer.Templates package</a> has also been updated to rely on Tag Helpers instead of HTML Helpers</p>
<p>Here is a quick lap around the updated alloy sample and new Tag Helpers:</p>
<p>First things first, we need the updated Alloy template. Using powershell or a terminal window:<br /><code>dotnet new -i EPiServer.Templates</code></p>
<p>Then we need to create a new project in an appropriate folder using the Alloy template (still in powershell or similar):<br /><code>dotnet new epi-alloy-mvc</code> </p>
<p>Here is a quick comparison of the razor implementation before / after Tag Helpers</p>
<p><strong>Alloy StartPage with HTML Helpers<br /></strong><code><div class="start"><br /></code><code> @Html.PropertyFor(x => x.CurrentPage.MainContentArea, new { CssClass = "row" })<br /></code><code></div></code></p>
<p><code></code></p>
<p><strong>Alloy Startpage with Tag Helpers<br /></strong><code><div class="start"><br /></code><code> <div epi-property="@Model.CurrentPage.MainContentArea" class="row"><br /></code><code> <div epi-property-item class="block" epi-on-item-rendered="OnItemRendered" /><br /></code><code> </div><br /></code><code></div></code></p>
<p><code></code></p>
<p>So instead of the @Html.PropertyFor which magically generates a nested div structure for the content area + elements. The Tag Helper implementation is much more explicit, each content area item will be rendered in a div with class=block. The items will be contained in a single div with class=row.</p>
<p><strong>If you prefer a list, you just change the markup as appropriate.</strong><br /><code><div class="start"><br /></code><code> <ul epi-property="@Model.CurrentPage.MainContentArea"><br /></code><code> <li epi-property-item epi-on-item-rendered="OnItemRendered" /><br /></code><code> </ul><br /></code><code></div></code> </p>
<p>The “epi-property” attribute specifies which property to render. If the property is a content area, we can specify a template for rendering each content area item. Alternatively, if we are happy with the default output, we can be less specific:<br /><code><div class="start"><br /></code><code> <div epi-property="@Model.CurrentPage.MainContentArea" /><br /></code><code></div></code> </p>
<p>Or we can specify a deeper html structure.<br /><code><div class="start"><br /></code><code> <div epi-property="@Model.CurrentPage.MainContentArea" class="row"><br /></code><code> <div class="children-class"><br /></code><code> <p class="grand-children-class"><br /></code><code> <a epi-property-item class="content-area-item" /><br /></code><code> </p><br /></code><code> </div><br /></code><code> </div><br /></code><code></div></code></p>
<p>There are a lot more details around the <a href="https://docs.developers.optimizely.com/content-cloud/v12.0.0-content-cloud/docs/rendering-properties-with-tag-helpers">Optimizely Tag Helpers</a>, and of course <a href="https://learn.microsoft.com/en-us/aspnet/core/mvc/views/tag-helpers/intro">Tag Helpers</a> in general. Hope you take it for a spin, and drop a comment if we missed something important 😊</p>Deploying your CMS 12 upgrade on DXP/blogs/martin-ottosen/dates/2022/6/deploying-your-cms-12-upgrade-on-dxp/2022-08-09T08:44:26.0000000Z<p>Deploying changes to a DXP cloud service is easy [<a href="https://en.wikipedia.org/wiki/Wikipedia:Citation_needed">citation needed</a>] you can use the <a href="https://docs.developers.optimizely.com/digital-experience-platform/v1.3.0-DXP-for-CMS11-COM13/docs/deployment-api">deployment API</a> or <a href="https://www.powershellgallery.com/packages/EpiCloud/1.2.0">PowerShell module</a> to push packages through your environments directly, or <a href="https://docs.developers.optimizely.com/digital-experience-platform/v1.3.0-DXP-for-CMS11-COM13/docs/deploying-code-changes">setup an Azure Devops pipeline</a> or similar CI/CD tool once and for all.</p>
<p><img src="/link/6cec254ced7140b5a6549b51ed104103.aspx" alt="process.jpg" /></p>
<p>If you are <a href="https://docs.developers.optimizely.com/digital-experience-platform/v1.3.0-DXP-for-CMS11-COM13/docs/migration-to-cms-12-commerce-14">upgrading to CMS 12 or to Commerce 14</a>, the underlying infrastructure changes a bit, so there is an extra step and a new “Project Migration” tool available in <a href="https://paasportal.episerver.net/">the portal</a> which guides you through the transition. Read on for a high-speed run-through of the tool and the process as it looks right now.</p>
<h1>STEP 0 – PLAN</h1>
<p>The “Project Migration” tool creates a set of brand-new environments that you can use in addition to your current environments during migration. Eventually when you feel ready for it, you will move traffic to the new project, and the old project will be reclaimed.</p>
<p><img src="/link/627cee63ff9e4439aebdea831b8ba99a.aspx" alt="migration-process.gif" /></p>
<h1>STEP 1 – NEW ENVIRONMENTS</h1>
<p>To get started with this process, click the “Project Migration” tab and “Start migration”. Don’t worry about impacting your live site, nothing dangerous is happening here.</p>
<p><img src="/link/260d72a14ea64f649ecce4bba087f578.aspx" alt="dxp-migration---begin.gif" /></p>
<p>Once this part of the process is complete, you get a link to a new project - “teor2mstr” in this example - and the option to copy over content from your current environments.</p>
<h1>STEP 2 – DEPLOY YOUR CODE</h1>
<p>With the new environments in place, it’s time to put them to use. You may want to setup a new deployment pipeline and a dedicated branch to target the new environments, since you are probably going to deploy many iterations of your upgrade before going live, and the new project will be your permanent home once the migration is done. The “old” environments remain unchanged and completely functional, and you can deploy changes to both throughout this transition.</p>
<p><img src="/link/579768265b4347e48286650c8d3d1faf.aspx" alt="dxp-migration---deploy.gif" /></p>
<h1>STEP 3 – GOING LIVE</h1>
<p>Once you have an upgraded code package running in the new production environment, and you completed whatever test procedures you have, it’s time to start moving traffic over. You don’t have to move everything all at once; you can start with integration and preproduction before taking the plunge, and you can copy content from the current live environments as many times as you need, to make sure everything is up to date. When you want to move traffic over, you put the old environment in maintenance mode as part of the process..</p>
<p><img src="/link/e1f6759311b040cd99fe3cd31538fd70.aspx" alt="dxp-migration---go-live.gif" /></p>
<p>I hope this lap around the new migration tool was useful, for more details around transitioning DNS records, maintenance mode options and more, check out the docs <a href="https://docs.developers.optimizely.com/digital-experience-platform/v1.3.0-DXP-for-CMS11-COM13/docs/migration-to-cms-12-commerce-14">here</a>.</p>
<p> </p>
<h1>FAQ</h1>
<ul>
<li>What happens to the old project?<br />The project you are currently using will continue to work as-is until after you’ve gone live with the new project. After going live, we retain the old project for some time (currently seven days). When the retention period expires, the old project is deleted.</li>
<li>Can we take the opportunity to rebuild the website while migrating?<br />That’s up to you, our general advice would be to avoid biting off more than your can chew, take the shortest path to CMS 12 and iterate from there.</li>
<li>How long can I keep both projects running?<br />Please abort the migration if the project stalls for some reason. You can always restart the migration again later. If the migration isn’t completed within 5 months, we reserve the right to reclaim to abandon the migration on your behalf.</li>
<li>Do I have to pay extra for the migration environments?<br />At this point there is no additional cost involved in migrating the service.</li>
<li>Any changes to the infrastructure?<br />The new environments are using to newer, faster instances, and origin shield is on, beyond that, everything should be completely familiar.</li>
<li>Any changes to the process?<br />Web Deploy is no longer supported, so new packages must go through the <a href="https://docs.developers.optimizely.com/digital-experience-platform/v1.3.0-DXP-for-CMS11-COM13/docs/deployment-api">deployment API</a></li>
</ul>
<p> </p>JS SDK and Optimizely jamstack/blogs/martin-ottosen/dates/2021/12/js-sdk-and-optimizely-jamstack/2021-12-17T13:56:16.0000000Z<p>With <a href="/link/cd87b60aadd34c32951524bc3dec9d04.aspx">CMS 12</a> we introduced long awaited support for <a href="https://dotnet.microsoft.com/download/dotnet/5.0">.Net 5</a> not just because it’s faster or adds cross platform support but because <a href="https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/">.NET Core is the future of .NET</a>. Incidentally, a faster and cross platform CMS is also good news for folks whose interests runs more along the lines of JavaScript, APIs and Markup. The latest CMS 12 addition exposes new capabilities through REST APIs and with it the <a href="https://github.com/episerver/content-delivery-js-sdk">JS SDK</a> which is now officially released.</p>
<h1>The JS SDK</h1>
<p>The JS SDK has a few pieces to it:</p>
<ol>
<li>A Node.js CLI for managing your content definitions [<a href="https://github.com/episerver/content-delivery-js-sdk/tree/master/src/%40episerver/content-definitions">GitHub]</a> [<a href="https://www.npmjs.com/package/@episerver/content-definitions">npm</a><a href="https://github.com/episerver/content-delivery-js-sdk/tree/master/src/%40episerver/content-definitions">]</a><a href="https://www.npmjs.com/package/@episerver/content-definitions"></a><br />
<pre class="language-c"><code>npx content-definitions push manifest.json</code></pre>
</li>
<li>A typescript client for fetching content from the CMS [<a href="https://github.com/episerver/content-delivery-js-sdk/tree/master/src/%40episerver/content-delivery">GitHub</a><a href="https://github.com/episerver/content-delivery-js-sdk/tree/master/src/%40episerver/content-definitions">]</a> [<a href="https://www.npmjs.com/package/@episerver/content-delivery">npm</a><a href="https://github.com/episerver/content-delivery-js-sdk/tree/master/src/%40episerver/content-definitions">]</a><a href="https://www.npmjs.com/package/@episerver/content-delivery"></a><br />
<pre class="language-javascript"><code>getContent('...', { select: ['heading', 'body'] })
.then((content) => {
// Content was successfully loaded
});</code></pre>
</li>
<li>A decoupled Vue.js sample site running on Node.js and CMS 12 [<a href="https://github.com/episerver/content-delivery-js-sdk/tree/master/samples/music-festival-vue-decoupled">GitHub</a><a href="https://github.com/episerver/content-delivery-js-sdk/tree/master/src/%40episerver/content-definitions">]</a><a href="https://github.com/episerver/content-delivery-js-sdk/tree/master/samples/music-festival-vue-decoupled"></a></li>
</ol>
<h1>APIs</h1>
<p>This is not an exhaustive list of APIs, but a good starting point for many decoupled content applications:</p>
<ol>
<li>Content Delivery API [<a href="https://nuget.optimizely.com/package/?id=EPiServer.ContentDeliveryApi">package</a><a href="/link/4ddd243ee9b84b6ba1b15573b9574619.aspx">]</a><a href="https://nuget.optimizely.com/package/?id=EPiServer.ContentDeliveryApi"></a>, [<a href="/link/19575b81cd774e2d9edc96bf8873c703.aspx">spec</a><a href="/link/4ddd243ee9b84b6ba1b15573b9574619.aspx">]</a><a href="/link/19575b81cd774e2d9edc96bf8873c703.aspx"></a>, [<a href="/link/6ffa5cb8173a414eac25740deeafdbc8.aspx">docs</a><a href="/link/4ddd243ee9b84b6ba1b15573b9574619.aspx">]</a><a href="/link/6ffa5cb8173a414eac25740deeafdbc8.aspx"></a></li>
<li>Content Definitions API [<a href="https://nuget.optimizely.com/package/?id=EPiServer.ContentDefinitionsApi">package</a><a href="/link/4ddd243ee9b84b6ba1b15573b9574619.aspx">]</a><a href="https://nuget.optimizely.com/package/?id=EPiServer.ContentDefinitionsApi"></a>, [<a href="/link/d46530a2a4c645b99430de69fa01f25d.aspx">spec</a><a href="/link/4ddd243ee9b84b6ba1b15573b9574619.aspx">]</a><a href="/link/d46530a2a4c645b99430de69fa01f25d.aspx"></a>, [<a href="/link/5f89188b3a094afe8f00b4a557436b31.aspx">docs</a><a href="/link/4ddd243ee9b84b6ba1b15573b9574619.aspx">]</a><a href="/link/5f89188b3a094afe8f00b4a557436b31.aspx"></a></li>
<li>Content Management API [<a href="https://nuget.optimizely.com/package/?id=EPiServer.ContentManagementApi">package</a><a href="/link/4ddd243ee9b84b6ba1b15573b9574619.aspx">]</a><a href="https://nuget.optimizely.com/package/?id=EPiServer.ContentManagementApi"></a>, [<a href="/link/d29cac74b46e4def85fecf2630669868.aspx">spec</a><a href="/link/4ddd243ee9b84b6ba1b15573b9574619.aspx">]</a><a href="/link/d29cac74b46e4def85fecf2630669868.aspx"></a>, [<a href="/link/4ddd243ee9b84b6ba1b15573b9574619.aspx">docs]</a></li>
</ol>
<p>Btw check out <a href="/link/42b7913c321d4886b468000231d9baa4.aspx">this</a> useful list of .NET packages and status with respect to .NET 5.</p>
<h1>How to get started</h1>
<p>The simplest way to get acquainted with the SDK is to clone the repository and <a href="https://github.com/episerver/content-delivery-js-sdk/tree/master/samples/music-festival-vue-decoupled#setup-and-run">setup the sample site</a>. The sample site is based on CMS 12 and uses the new Content Definitions API and a <a href="https://nuget.optimizely.com/package/?id=EPiServer.OpenIDConnect">simple in-process OIDC server</a> based on <a href="https://github.com/openiddict/openiddict-core">OpenIddict</a> meaning no need for an external identity provider to get things going, but makes it easy to transition to Azure AD or some other OIDC capable provider once you near production.</p>
<p>The decoupled sample site demonstrates how you can build completely decoupled applications without breaking preview or on-page-edit. Note, at the time of writing on-page-edit is not working in updated chrome browsers, but we expect to have a solution for that soon, which should work with the approach used in this sample.</p>JS SDK public preview/blogs/martin-ottosen/dates/2021/7/js-sdk-public-preview/2021-08-18T13:44:14.0000000Z<p>Maybe you noticed we <a href="/link/1bc8e0286e4348c8b0d527ca35b5cfe9.aspx">announced the public preview</a> for CMS 12 a few months ago? CMS 12 natively supports .Net 5 and with it a more portable CMS which no longer requires Windows or IIS. If you like Node.js this is good news, since you can more easily work with your favorite IDE and OS and just run the CMS in the background e.g., in a terminal window in Visual Studio Code. Along with CMS 12 we are releasing a brand-new open-source JS SDK now available in preview on <a href="https://github.com/episerver/content-delivery-js-sdk">GitHub</a>.</p>
<h1>What’s in the box</h1>
<p>The JS SDK has a few pieces to it:</p>
<ol>
<li><a href="https://github.com/episerver/content-delivery-js-sdk/tree/master/src/%40episerver/content-definitions">A Node.js CLI</a> for managing your content definitions.</li>
<li><a href="https://github.com/episerver/content-delivery-js-sdk/tree/master/src/%40episerver/content-delivery">A typescript client</a> for fetching content from the CMS.</li>
<li>A decoupled Vue.js <a href="https://github.com/episerver/content-delivery-js-sdk/tree/master/samples/music-festival-vue-decoupled">sample site</a> running on Node.js and CMS 12 (preview)</li>
</ol>
<h1>How to get started</h1>
<p>The simplest way to get acquainted with the SDK is probably to clone the repository and <a href="https://github.com/episerver/content-delivery-js-sdk/tree/master/samples/music-festival-vue-decoupled#setup-and-run">setup the sample site</a>. The sample site is based on CMS 12, and includes a preview of the new Content Definitions API which we are hoping to ship over the summer together with the final version of CMS 12. The current sample site uses OpenID Connect in the platform directly i.e., no need for an external identity provider to get things going.</p>
<h1>Documentation</h1>
<p>The SDK modules and samples each have a README in the project roots, which is a good starting point, but the documentation here on world for Content Definitions API is not complete or published yet, but thanks to the <a href="https://github.com/advanced-cms/advanced-reviews">external reviews feature</a> you can sneak a peek at the preliminary documentation here:</p>
<ul>
<li><a href="/link/5f89188b3a094afe8f00b4a557436b31.aspx">Overview</a></li>
<li><a href="/link/68286ca6371944db80dc09318fdfdadb.aspx">Getting Started</a></li>
<li><a href="/link/b3b486d761cf4a1abf16ff9003c093fb.aspx">API Fundamentals</a></li>
<li><a href="/link/4409bce3f12a4e3cab16339973b84ca9.aspx">Content Definitions Manifest</a></li>
<li><a href="/link/d46530a2a4c645b99430de69fa01f25d.aspx">API reference</a></li>
</ul>
<p> </p>.Net 5 public preview/blogs/martin-ottosen/dates/2021/6/-net-5-public-preview/2021-07-01T10:52:32.0000000Z<p><span>As you probably know, we have been busy working on CMS 12 / Commerce 14, the</span><span>of which has been to support .Net 5 as the underlying framework for our entire Content and Commerce platform. We’ve had a lot of great feedback from the <a href="/link/be8077bc415c4afca844daf0fb0e83bb.aspx">closed beta</a> and are pleased to announce our first public milestone for this release.</span></p>
<p><span>It is available <a href="https://github.com/episerver/netcore-preview">here on GitHub</a> for the duration of the public preview. If you want to take the preview for a spin, here is what you need to know:</span></p>
<ul>
<li><span>No production support and no hotfixes</span></li>
<li><span>Stable APIs</span></li>
<li><span>Final packages will be distributed via <a href="https://nuget.episerver.com/package/?id=EPiServer.ContentManagementApi">the normal nuget feed</a></span></li>
<li><span>Please report any feedback to the public preview via <a href="https://github.com/episerver/netcore-preview/issues">GitHub</a></span></li>
<li>
<div>Not yet supported to deploy/run in DXP</div>
</li>
</ul>
<p>With those caveats in mind, to get started you probably want to install the project templates and CLI tool as explained in <a href="https://github.com/episerver/netcore-preview/">the preview repository</a> and create a new site from there e.g. starting from a blank site:</p>
<pre class="language-csharp"><code>dotnet new epicmsempty --name ProjectName</code></pre>
<p><span>We intend to follow this with two releases; a fully supported release for new customers targeted in Q3, followed by a General Availability for all customers</span><span> in Q4. (The primary reason for the gap between the two is to support and enable easy migrations via self-service tooling and assisted migrations).</span></p>
<h2>Why are we doing this?</h2>
<ul>
<li><span>Building the <strong>most advanced</strong> Digital Experience Platform</span></li>
<li><span>To fully support the <strong>latest</strong> technologies from Microsoft</span></li>
<li><span>.Net Framework was designed for one machine, whereas .Net 5 is designed from the ground up for <strong>high performance web applications and microservices in the cloud</strong></span></li>
<li><span>Benefits of .Net 5 include</span>
<ul>
<li><span>High Performance</span></li>
<li><span>Scalable</span></li>
<li><span>Cross Platform</span></li>
<li><span>Specific Services for web, data and AI/ML</span></li>
<li><span>Open Source</span></li>
</ul>
</li>
<li><span>Enables customers and partners to optimize the speed of the experience you deliver, the gains can be massive, ranging from 30% to 1200% in some situations (not Optimizely specific)</span></li>
<li><span>Developing microservices architecture has the potential to improve the speed of delivering and rolling out new functionality</span></li>
<li><span>Enables better headless support - .Net SDK (delivery core), <a href="https://github.com/episerver/content-delivery-js-sdk">JS SDK</a> all abstracted from the CMS</span></li>
</ul>
<h2><span>DXP on Linux </span></h2>
<p><span>We expect that as more developers start to work with .Net 5, Linux will become the hosting platform of choice, which is why we've decided that to exclusively run CMS 12 and Commerce 14 on Linux on our DXP. This decision allows us to support a single environment type for our service, but also gives flexibility in how you develop or run CMS 12 / Commerce 14 if you choose to maintain your own infrastructure. </span></p>
<p><span>Customers using CMS 11 / Commerce 13 or earlier versions will not be affected, and will stay on the Windows-based environments until they choose to upgrade.</span></p>
<p><span>You can still develop on either Windows and deploy to Linux instances for testing and production, which we expect to be a normal pattern for development.</span></p>Pushing content to Optimizely CMS/blogs/martin-ottosen/dates/2021/4/pushing-content-to-optimizely-cms/2021-04-22T11:00:28.0000000Z<p><span>If you want to integrate external content sources into Optimizely CMS you are spoilt for choice, in fact it can be hard to figure out which approach to take. You could build a <a href="/link/0e40676706014332860dcf0b238445be.aspx">content provider</a>, which provides the deepest integration, but is also the most complicated option. You could also use the import / export UI to handhold content packages between systems, and the service API has an <a href="/link/a37de7012a044c3ba81c73dc3a7f397e.aspx">endpoint for importing product content</a>. You could of course also build your own controller or scheduled job to push or pull content using the .Net <a href="/link/f740e08490ca41cd95d376d0335aee61.aspx">content repository</a> or <a href="/link/4c9fe5c2ebd64518ac4a6cc6aee55ff3.aspx">dynamic data store</a> for simple objects you don’t need to interact with through the edit UI.</span></p>
<p><span>You could also take a look at the content management API which provides a handy REST API for basic content management tasks:</span></p>
<p><img src="/link/4272c5f476dd4469acf6424b6f94494b.aspx" /></p>
<p><span>Want to create a new content object? Either PUT or POST the whole thing as JSON. Using PUT will upsert the object, replacing any existing object with matching id in one go.</span></p>
<pre class="language-javascript"><code>{
"name": "Alloy Track",
"language": { "name": "sv" },
"contentType": ["ProductPage"],
"parentLink": { "id": 5 },
"status": "CheckedOut",
"metaTitle": "Alloy track",
"pageImage": {
"id": 152,
"workId": 0,
"guidValue": "59e22d5b-b238-4185-85f8-338f4f29c93d",
"providerName": null,
"url": "/globalassets/alloy-track/alloytrack.png"
}
}</code></pre>
<p><span> </span></p>
<p><span>The PATCH endpoints let you specify only the properties you care to change, and leaves the remaining properties as they are, which is e.g., useful for publishing a draft object:</span></p>
<pre class="language-javascript"><code>{
"language": { "name": "en" },
"status": "Published"
}</code></pre>
<p><span>You could of course just publish an object immediately by setting “status”: “Published” while creating or upserting and object using POST or PUT.</span></p>
<p><span>If this has piqued your interest, there are more capabilities and usage examples to be found in the <a href="/link/9777402b645a4a329dadd03a3ebbca38.aspx">API fundamentals</a> section, and a downloadable swagger specification in the <a href="/link/d29cac74b46e4def85fecf2630669868.aspx">REST API reference</a>.</span></p>
<p><span>You may need to install or update <a href="https://nuget.episerver.com/package/?id=EPiServer.ContentManagementApi">the nuget package</a> first and maybe check out the <a href="/link/e1b2ae60e0474073a2bf92c5e50742ab.aspx">getting started</a> section on world.</span></p>ASP.NET Core beta program/blogs/martin-ottosen/dates/2019/12/asp-net-core-beta-program/2019-12-17T12:11:33.0000000Z<h1>TL;DR</h1>
<p>By popular demand we are working hard to bring ASP.NET Core support to Episerver in 2020. The first official beta drop is planned for the beginning of the year, if you want to see how things are shaping up and help us build a stack that works for you, sign-up for the closed beta <a href="/link/7bacc8bb22da4605b819d8be4c968674.aspx">here</a>.</p>
<h1>Upgrade path</h1>
<p>If you’ve been following the evolution of .NET Core you probably saw <a href="https://devblogs.microsoft.com/dotnet/introducing-net-5/">the announcement</a> earlier in the year that Microsoft are consolidating all the different critters in the .NET zoo with .NET 5 which is really just the next version of .Net Core.</p>
<p><img src="/link/78eea16f079f4895811b43e1727ee40d.aspx" width="647" alt="core-timeline.gif" height="229" /></p>
<p>It has been a confusing few years in the .Net world, but it seems clear now that <a href="https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/">.Net Core is the future of .NET</a> which begs the question if / how / when to transition to .Net Core. If you already have a significant investment in ASP.NET 4 it probably makes sense to stay there, we will continue to support you, and add new features for the foreseeable future. If you are managing multiple sites, you can choose to host some on ASP.NET Core and some on ASP.NET 4 or move all your sites to ASP.NET Core.</p>
<h1>In two minds</h1>
<p>Instead of porting the entire platform to ASP.NET Core, we are building a small, fast delivery platform powered by a REST layer. The delivery platform is built to serve site visitors and depends on content from the current platform which serves editors (and ASP.NET 4 sites).</p>
<p><img src="/link/8e9b7eb184054fa7af568f14ad9a7661.aspx" width="602" alt="core-split-brain.gif" height="276" /></p>
<p>This style of decoupled architecture is <a href="/link/c5155ba3e4f84986a46a7a968ad16a55.aspx">old news</a>, but until now this separation of concern only existed at the infrastructure level, with the Delivery Core we are making the cut deeper, and giving you a platform that is optimized for delivery from the ground up. We have to rethink a couple of things to make this work really well, but for current Episerver developers everything will feel very familiar; if you define your models in .Net classes, you still get nice <a href="https://docs.microsoft.com/en-US/aspnet/core/mvc/overview?view=aspnetcore-3.1#strongly-typed-views">strongly typed views</a>, but also <a href="https://docs.microsoft.com/en-US/aspnet/core/mvc/overview?view=aspnetcore-3.1#tag-helpers">tag helpers</a>, <a href="https://docs.microsoft.com/en-US/aspnet/core/razor-pages/?view=aspnetcore-3.1&amp;amp;amp;amp;amp;tabs=visual-studio">razor pages</a>, <a href="https://docs.microsoft.com/en-US/aspnet/core/blazor/?view=aspnetcore-3.1">blazor</a> etc. etc. etc. For editors everything still works as normal, we are including support for previews, on-page-editing etc. across the two stacks.</p>
<h1>Platform agnostic</h1>
<p>Historically we have thought of .Net as the principal API layer for developers building sites on Episerver. With ASP.NET Core we are taking a more platform agnostic stance, by building out our <a href="https://nuget.episerver.com/?q=EPiServer.ContentDeliveryAPI&amp;amp;amp;amp;amp;s=Popular&amp;amp;amp;amp;amp;r=All&amp;amp;amp;amp;amp;f=Episerver">existing REST APIs</a>, effectively putting the new delivery platform on level with java, js python and other stacks.</p>
<p><img src="/link/e64362f8872e492ab4f3191267c0c760.aspx" width="526" alt="core-rest-layer.gif" height="378" /></p>
<h1>Mi casa es su casa</h1>
<p>The “Delivery core” wants to be part of your preferred .Net stack, so we will be moving most of the “Delivery core” to github and invite you to contribute more directly in shaping that part of the platform. We still expect to distribute everything as semantically versioned nuget packages. If you want to get a foot in the door early, and help us shape the initial release you can sign-up for the closed beta <a href="/link/7bacc8bb22da4605b819d8be4c968674.aspx">here</a>.</p>
<p><img src="https://github.githubassets.com/images/modules/logos_page/GitHub-Mark.png" width="413" alt="" height="413" /></p>