Blog posts by Jacob Pretorius

Blog posts by Jacob Pretorius2025-07-21T09:45:17.0000000Zhttps://world.optimizely.com/blogs/jacob-pretorius/ Optimizely World Build a headless blog with Astro and Optimizely SaaS CMS Part 4 - SSR & Visual Builder ExperiencesFor those new to the series, you may want to read <a href="/link/033891ed66d94136a8b66d0e00ee3619.aspx">parts one</a>, <a href="/link/59abecef9d6642b9816d424de5a0a99b.aspx">two</a>, and <a href="/link/6d4fd38dc1254a36855db99902ac4f17.aspx">three</a> first. At the end of my last post I mentioned I had two more ideas to explore: <ol> <li style="list-style-type: none;"> <ol> <li style="font-style: italic;">Render some purely Visual Builder content</li> <li style="font-style: italic;">Render the whole thing dynamically rather than statically.</li> </ol> </li> </ol> Let's do that. <h2>From Static to Server-Side Rendered (SSR)</h2> I started <a href="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo/tree/main/ssr">a new server-side rendered version</a> of the demo site that builds on everything added in the <a href="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo/tree/main/static-site">static site version</a>. This means content changes in the CMS now appear on the SSR website version nearly instantly, without needing to trigger a new build on Vercel. For sites with lots of content changes, this will be a much more suitable approach compared to the webhook process we used with the static site version. The core change was changing <a href="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo/blob/main/ssr/astro.config.mjs">astro.config.mjs</a> from static output to `output: 'server'`. This change tells Astro to stop pre-building all the pages into HTML files and instead render each page on the server when a user requests it. I also had to install the appropriate <a href="https://docs.astro.build/en/guides/on-demand-rendering/#server-adapters">Server Adapter</a>, in this case `@astrojs/vercel` since this demo is running on Vercel. This is great for content-heavy sites where updates are frequent, changes reflect as soon as they are indexed in Graph.  <h2>TypeScript</h2> In the last post, I mentioned that the GraphQL integration could be improved by automatically creating TypeScript types. I thought given that I'm making more changes in the new version, I might as well add that too. By installing the `@graphql-codegen/cli` package and setting up a <a href="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo/blob/main/ssr/codegen.ts">codegen.ts </a>config file, we can now run a single command: `npm run codegen`. This command connects to our Optimizely Graph endpoint, scans our queries in <a href="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo/blob/main/ssr/src/api/apollo-client.ts">apollo-client.ts</a>, and automatically generates TypeScript types for them. When developing, this means: <ul> <li> Full type-safety: No more guessing what fields are available on a content item. </li> <li> Intelligent autocompletion: The code editor knows our schema, which makes writing queries and using the data much faster and less error-prone. </li> </ul> I updated all the page and component layouts to use the imports from our generated types e.g. <pre class="language-javascript"><code>import type { StartPage, ArticlePage as ArticlePageType } from '../gql/graphql';</code></pre> <img src="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo/blob/main/images/4/types.png?raw=true" alt="Code editor showing a string type for the article.Heading property" width="848" height="477" /> It’s a nice improvement to the developer experience and something you’d want in any real-world project. <h2>Adding Experiences and Visual Builder</h2> The SSR version now properly supports Optimizely's Visual Builder with Experiences. <img src="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo/blob/main/images/4/experience-setup.png?raw=true" alt="Optimizely SaaS CMS showing the setup of an Experience Hero component with Description, Heading, and Image properties" width="1680" height="945" /> I've included three to get started: <ol> <li> ExperienceHero: A simple, reusable full-width hero banner with a background image and text overlay. </li> <li> ExperienceCarousel: For creating responsive image grids. </li> <li> ExperienceRTE: A standard Rich Text Editor for displaying any kind of formatted text content. </li> </ol> You can find them in the components folder in the repo, e.g. <a href="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo/blob/main/ssr/src/components/ExperienceHero.astro">https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo/blob/main/ssr/src/components/ExperienceHero.astro</a>  Content editors can now compose these with Experience page type inside the CMS and see them <a href="https://opti-saas-astro-ssr-demo.vercel.app/experience/">rendered on page</a>. <img src="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo/blob/main/images/4/experience-cms.png?raw=true" alt="Optimizely SaaS CMS showing an Experience Page with the three Experience components" width="1680" height="945" /> Visual builder has come a long way already. <h2>Caching</h2> Graph responses seem to be relatively quick, but as you might expect, a server-side rendered page that has to load page content from an external source for every request won't be as performant as a static site that can instantly start streaming the response HTML. Thankfully, in-memory caching on the server is still possible. So I added a 2-minute cache for all normal page loads (non-preview mode). Only the first new Graph request will go out to Graph every 2 minutes. You can see and change the cache configuration to your needs in <a href="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo/blob/main/ssr/src/api/apollo-client.ts">apollo-client.ts</a>. <h2>Conclusion</h2> This new SSR version is a much more robust and dynamic foundation for building with Astro and Optimizely SaaS CMS. It brings the power of instant content updates and a true visual editing experience to the forefront, while making the development process more efficient with type generation. It upgrades my example from a simple blog (<a href="https://jacob.earth/blog/">like mine</a>) into something you could use for a more complex and content-rich enterprise site. Next time, I'll look at integrating <a href="https://github.com/episerver/content-js-sdk">the new beta Optimizely content-js-sdk</a>. Check out the live demo and the code for yourself <ul> <li> Live SSR Demo: <a class="ng-star-inserted" href="https://opti-saas-astro-ssr-demo.vercel.app">https://opti-saas-astro-ssr-demo.vercel.app</a> </li> <li> Github Repo (SSR Folder): <a href="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo/tree/main/ssr">https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo/tree/main/ssr</a>  </li> </ul> See you next time 😉2025-07-21T09:45:17.0000000Z

Blog post

Visualise Cloudflare Edge Logs with GrafanaOptimizely currently has an <a href="https://www.optimizely.com/beta/">open beta</a> for DXP customers to get access to their Cloudflare Edge logs. This beta has been around for a while, but I haven't seen that much posted about it, perhaps because edge logs can be kind of boring? Well, not if we visualise them with fancy dashboards! <img src="https://github.com/jacobpretorius/Opti.Edge.Logs.Grafana/blob/main/images/example-dashboard.png?raw=true" alt="Grafana dashboard showing Cloudflare Edge Logs" width="1922" height="1080" /> <h2>Tech Stack</h2> How this all works (at least during the beta phase) is that the Cloudflare edge logs are pushed to an Azure Blob Storage container owned by Optimizely, which you get a SAS link for. What you do with the logs from that storage container is up to you. I've chosen to use <a href="https://grafana.com/grafana/">Grafana</a> as it's a popular choice among the homelab crowd (guilty) because it makes it easy to visually represent pretty much anything. In order to get Grafana to "understand" our logs they need to go to <a href="https://grafana.com/oss/loki/">Loki</a> first, which you can think of as the underlying database engine. The last thing we need is to get the actual log files from the Azure storage container into Loki. There may be ways to do that automatically, such as with an ingestion pipeline from Blob Storage to Azure Log Analytics, but I like building my own stuff so I've done that instead. I've wrapped everything we need in a Docker stack to make working with it super easy. <img src="https://github.com/jacobpretorius/Opti.Edge.Logs.Grafana/blob/main/images/tech.png?raw=true" alt="Tech stack: Cloudflare logs -> Azure storage -> nodejs ingest engine -> Loki -> Grafana" width="1546" height="477" /> <h2>Setup</h2> Getting this going locally should be fairly simple. <h3>Prerequisites</h3> <ol> <li>Get access to the <a href="https://www.optimizely.com/beta-signup/?beta=Edge+logs+for+DXP+cloud+services">edge logs beta by applying for it</a>.</li> <li>Install Docker.</li> <li>Once approved for the beta, go to the <a href="https://paasportal.episerver.net/">PaaS portal </a>and create an API key for the approved project. Make sure to select "Edge Logs" as the required permission.</li> </ol> <h3>Project Setup</h3> <ol> <li><a href="https://github.com/jacobpretorius/Opti.Edge.Logs.Grafana/tree/main">Clone the git repo</a>.</li> <li>Create an `/.env` file based on my <a href="https://github.com/jacobpretorius/Opti.Edge.Logs.Grafana/blob/main/example.env">example.env,</a> replace with your values where needed. Consider changing the default Grafana username and password while you are at it.</li> <li>Open a terminal in the project directory and start the docker stack with `docker compose up --build -d`</li> <li>Grafana should now be running at http://localhost:3000</li> <li>Login as user / pass configured, or default admin/admin</li> </ol> You should have the stack running in Docker. <img src="https://github.com/jacobpretorius/Opti.Edge.Logs.Grafana/blob/main/images/docker-stack.png?raw=true" alt="The stack running in Docker" width="1920" height="1080" /> If you need to debug anything with the log ingestion, check the container for it. <img src="https://github.com/jacobpretorius/Opti.Edge.Logs.Grafana/blob/main/images/log-ingest.png?raw=true" alt="log ingestor container logs in Docker" width="1920" height="1080" /> Once done, shut down with `docker compose down` in the same project terminal to bring the stack down. <h3>Adding a Dashboard</h3> You can import the dashboard from my example above with the Grafana UI using the <a href="https://github.com/jacobpretorius/Opti.Edge.Logs.Grafana/blob/main/example-dashboard.json">example dashboard JSON file</a>. Give it a couple of minutes on initial startup to get enough data to fill all the panels. <h2>Useful Links</h2> If you want to explore the edge logs more the <a href="https://developers.cloudflare.com/logs/reference/log-fields/zone/http_requests/#cachecachestatus">Cloudflare Edge Logs docs</a> are a good reference for what the values mean so you can create your own dashboard panels from there. If you run into any issues with access to the logs you may need to check <a href="https://docs.developers.optimizely.com/content-management-system/docs/logging-options#edge-logs-streaming-using-cdn-beta">the documentation from Optimizely</a>. I've taken care of what the EpiCloud module does in my code to get the SAS link automatically as that's just easier to have it auto-refresh the SAS link when it expires. And in case you want to contribute or raise issues: <a href="https://github.com/jacobpretorius/Opti.Edge.Logs.Grafana">https://github.com/jacobpretorius/Opti.Edge.Logs.Grafana</a>  <h2>Conclusion</h2> I'm really interested to see what visualisations people come up with. So far, I've found the Traffic Type and CF Block Actions to be very nice as those aren't things we're usually exposed to. Please share your custom dashboards and panels with us 😇   <h2>Presentation</h2> I spoke about this at the London dev meetup, watch the talk below. <a href="https://youtu.be/yqtleljncDg?t=5159">https://youtu.be/yqtleljncDg?t=5159</a>2025-04-30T13:10:08.0000000Z

Blog post

Notes on Optimizely Self-Optimizing BlockWhile the free <a href="https://docs.developers.optimizely.com/content-management-system/docs/optimizely-ab-testing">A/B Testing might be dead</a>, the <a href="https://docs.developers.optimizely.com/content-management-system/docs/optimizely-self-optimizing-block">Self-Optimizing Block</a> is still alive and kicking. Here's some notes for those debugging it.   <h2>Installation</h2> You can install the self-optimising block with the non-obvious package name `EPiServer.Cms.AddOns.Blocks` from <a href="https://nuget.optimizely.com/package/?id=EPiServer.Cms.AddOns.Blocks">https://nuget.optimizely.com/package/?id=EPiServer.Cms.AddOns.Blocks</a>  Ensure you have `app.UseSessions()` in your `Startup.cs` (<a href="/link/6b52e01dc86e4b8b95d9561c17ebc70e.aspx">thanks Arjan!</a>) You will then be able to create instances of "Self Optimizing Block" using the CMS.   <h2>Missing renderer</h2> If for some reason you have a block called "OptimizingBlock" in your CMS it likely means the "Self Optimizing Block" package is no longer installed. You can verify this by going to the CMS admin > Content Types and searching for it to see if it is From code: No <img src="/link/2ae072a18962419aaebad3f8dcc2ee9f.aspx" alt="" width="444" height="250" /> If you install the package it should spring back to action and restore itself as "Self Optimizing Block".  2025-04-29T09:41:58.0000000Z

Blog post

Build a headless blog with Astro and Optimizely SaaS CMS Part 3It is finally time to explore my basic blog example powered by <a href="https://astro.build/">Astro</a> and Opti SaaS CMS. For those new to the series, you may want to read <a href="/link/033891ed66d94136a8b66d0e00ee3619.aspx">parts one</a> and <a href="/link/59abecef9d6642b9816d424de5a0a99b.aspx">two</a> first. <h2>Project Structure</h2> I've mostly kept to the standard project structure as initiated by the Astro blog template so it should be familiar to most people who have worked with the popular front-end frameworks. <img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/images/3/structure.png" alt="The project folder structure" width="1920" height="1080" /> First, on the right, we can see the two main configuration files: `astro.config.mjs` is quite barebones and imports some additional functionality (automatic sitemap & Vercel platform support) and we also enable view transitions for browsers that support it. `.env` contains some SaaS CMS environment variables. Looking at the left of the image, we can follow the process of an incoming web request to a specific page URL: <ol> <li>First, load the relevant logic for the specific URL path from the `pages` folder and execute the logic found. Similar to what we can think of as a 'controller' in MVC terms. In this example, I've set a catch-all route based on Astro <a href="https://docs.astro.build/en/guides/routing/">naming conventions</a> with `[...slug].astro`.  It then loads the as-yet-unknown 'model for this URL by calling <a href="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo/blob/main/static-site/src/api/apollo-client.ts">apollo-client.ts</a> which talks to Optimizely Graph via GraphQL (more on this later). <img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/images/3/route.png" alt="Showing the catch-all route logic" width="1920" height="1080" /> </li> <li>The route then uses the 'model' to populate common shared `components` like the header and footer, and most importantly the `TemplateResolver.astro` (also commonly referred to as TemplateCoordinator) to figure out what page type this 'model' is <img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/images/3/templateresolver.png" alt="Showing the processing in TemplateResolver and the header component" width="1920" height="1080" /> </li> <li>Once we have the page type figured out, we load and populate its exact layout from `layouts` so we can process the rendering of the 'view', here of the StartPage <img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/images/3/layout.png" alt="Showing the layout view redering" width="1920" height="1080" /></li> </ol> It's all very familiar to those of us coming from the back-end world of doing this with PaaS in .NET. I'm sure there are other (better?) ways to structure a solution like this, but given the audience here I think this is easiest to follow. <h2>Did Someone Say Graph?</h2> In `apollo-client.ts` I have all the GraphQL queries needed to render everything for this site from the Optimizely Graph. <img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/images/3/gql.png" alt="Showing how apollo-client is setup" width="1920" height="1080" /> We're also caching the results using the built-in `InMemoryCache`, not that it matters too much for a statically generated site, but we might as well ensure our build times are quick when it is so easy to enable 😇 Admittedly, I've gone for the "quick demo" approach and built one big query to rule them all™ to resolve content by URL rather than what you'd actually want which is more finely scoped queries for each unique page/content type, but the approach is largely the same you just end up with multiple chained requests to the graph. <img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/images/3/bigquery.png" alt="Showing part of the big graphql query to load basically everything" width="1920" height="1080" /> This could be further improved by using a package to automatically create TypeScript models based on what is indexed in the graph, as in the <a href="https://github.com/episerver/cms-saas-vercel-demo">Optimizely Nextjs Demo</a>, but I've not looked into that for this demo. It's standard GraphQL / Astro functionality here so shouldn't be too difficult. <h2>CMS Editing</h2> I didn't want to publish this post before I had time to wrap this up, and thanks to the holiday season I finally could! Optimizely provide <a href="https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs/enable-live-preview-saas">documentation</a> on the full process. <img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/images/3/editmode.png" alt="CMS Edit mode is back" width="1920" height="1080" /> For this, I created an additional catch-all route in the `pages` directory, placing it under a new child `preview` folder. This means we now have a route registered for any request under `/preview` so that we can execute edit-only preview logic differently. <img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/images/3/edit1.png" alt="The edit-only preview route" width="1920" height="1080" /> As on-page editing / visual builder is an interactive experience, this won't quite work for our statically generated website. So we tell Astro to not prerender this page route - thereby making it dynamic. Then we follow the guidance from Optimizely for what we can expect as query parameters of the /preview URL when editors view the page in on-page editing. Most importantly we need to use the provided preview token for our existing graph queries so that we can load unpublished/draft content based on content version rather than URL (as the page may not have a URL yet). For the rendering side, we need to load the provided communication script as instructed by Opti, and setup a client-side event listener to detect the content saved event and refresh the on page editing experience for the editor. <img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/images/3/edit2.png" alt="The wrapping script and browser saved event listener" width="1920" height="1080" /> Finally, we need to wrap our editable layout elements with `data-epi-edit` HTML tags matching the property name as indexed in Graph. Example here for a page `MainBody` <pre class="language-markup"><code> <div set:html={pageContent.MainBody.html} /> </code></pre> And just like that, we have on-page editing and preview support 😁 <h2>Conclusion</h2> We've finally reached what I had in mind for this project when I originally thought of it. We have a simple, yet solid, base template for a SaaS CMS site with Astro that mostly focuses on content that doesn't change all that often. I could 100% use this to power <a href="https://jcpretorius.com/blog/">my personal blog</a> by swopping out the markdown files I currently use and instead pull content from Graph as we just saw for this demo. I have two more ideas in mind to build on: <ol> <li>Render some purely Visual Builder content</li> <li>Render the whole thing dynamically rather than statically.</li> </ol> See you next time 😉 As always, code on Github: <a href="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo">https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo</a> <a href="/link/ad0ab559cb97490491e9c4d448f232ca.aspx">Click here to read part four now</a>.2025-01-06T13:47:07.0000000Z

Blog post

Build a headless blog with Astro and Optimizely SaaS CMS Part 2Well, this took a while. Sorry! I got busy, and we had lots of Opticon content to cover. Now back to the regular programming. Back in May, I shared <a href="/link/033891ed66d94136a8b66d0e00ee3619.aspx">part one</a> of building a super simple static blog website using Optimizely headless SaaS and Astro. Let's go through the setup steps so you can get it running for yourself. <h2>Get The CMS Ready</h2> First, you'll want to <a href="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/static-site/cms-data/ExportedFile.episerverdata">download the CMS export</a> of the sample content I've modelled from GitHub. Then you should go to a SaaS CMS instance and import the export there. Choose the Root folder as the destination. <img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/images/ImportZeExport.png" alt="Import the downloaded file" width="1280" height="720" /> If all goes to plan you should have some content in your CMS. <img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/images/imported.png" alt="Sample content inported in the CMS" width="1280" height="720" /> While we're here, make sure to setup the "Applications" with a hostname where it will be available (the expected Vercel URL). Also run the "Optimizely Graph Full Synchronization" scheduled job so everything gets pushed to Graph. <img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/images/Index.png" alt="Run the scheduled job to index to Graph" width="1280" height="720" /> Finally, go to the CMS dashboard page and take note of your Graph keys as we will need those later. <h2>Copy The Code</h2> Head over to <a href="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo">the repo</a> and download/fork it for your site.  The repo should be fairly familiar if you've worked with any of the modern front-end frameworks. All the fun stuff is in the `/static-site` directory. This repo is a bit ambitious and I hope to someday add a non-static variant with more bells and whistles.  <img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/images/repo.png" alt="The github repo" width="1280" height="720" /> You will want to update the <a href="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo/blob/main/static-site/.env">`.env` file</a> with your Graph's Delivery Keys "Single key" from the CMS dashboard. Then you should update <a href="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo/blob/main/static-site/astro.config.mjs">astro.config.mjs</a> with the same site URL you configured as a hostname. That's it really, save and push the code to a private repo of your choice. <h2>Setup Vercel</h2> The Vercel setup couldn't be easier, all you need to do is create a Vercel account and link your git repo. If you use GitHub this is seamless. Make sure to select the static-site folder as your root directory and it should do all the magic from there. <img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/images/vercel.png" alt="Setup the Vercel deployment" width="1280" height="720" /> <h2> </h2> <h2>Setup a Deployment Webhook</h2> With this incredibly simple use case, I'm not doing anything fancy in terms of having Astro serve static content while doing a cache revalidation in the background or anything like that. At build time in Vercel, it pulls all relevant content from Graph and creates static HTML as output to get hosted on the edge. But I still think it's worth some automation, as we don't want to have to remember to trigger a deployment in Vercel every time content is updated in the CMS. <img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/images/WebhookDeployed.png" alt="Vercel deployment webook in action" width="1280" height="720" /> Thankfully, that's quite easy to do with a <a href="https://docs.developers.optimizely.com/platform-optimizely/v1.4.0-optimizely-graph/docs/use-cases">Vercel to Optimizely Webhook</a>. I won't copy all the steps from there so just follow the wiki from Optimizely, but I will tell you how to authorise with the Optimizely webhook API so you can register the webhook as it is not mentioned anywhere! (at time of writing, it has now been updated, thank you docs team) In your API client of choice (Bruno, Insomnia, Postman) set the authentication scheme to "Basic Auth", then use your Graph Management Keys "App Key" as the username and the "Secret" as the password (you can get them from the CMS dashboard page). This took me ages to figure out. <img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/refs/heads/main/images/brunoAuth.png" alt="How to register the webhook using the correct Auth scheme" width="1280" height="720" /> Example webhook for on-published events, replace the "URL" with your webhook URL from the Vercel settings. <pre class="language-javascript"><code>POST https://cg.optimizely.com/api/webhooks { "disabled": false, "request" : { "url" : "https://api.vercel.com/v1/integrations/deploy/secret/secret", "method": "post" }, "topic": ["*.*"], "filters": [ { "status": { "eq": "Published" } } ] }</code></pre> And with that, you should have a working website running in Vercel, with auto deployments when you make changes and publish it in the CMS. That's all for this post, <a href="/link/6d4fd38dc1254a36855db99902ac4f17.aspx">next time</a> we can look at some code!2024-10-24T15:53:00.0000000Z

Blog post

Build a headless blog with Astro and Optimizely SaaS CMSI’m a big fan of using the right tool for the right job. I’m also a big fan of <a href="https://astro.build">Astro</a>, for the right use case. Let's explore Astro to see what it's all about and how to build an Optimizely SaaS CMS site using it. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" /> <h2>What is Astro</h2> Astro calls itself “The web framework for content-driven websites”, which sounds very fancy and highly relevant to us as we enter the wonderful headless content delivery world with the Optimizely SaaS CMS. I’d imagine that many of the headless sites we’re going to be building over the next couple of years are going to lean quite strongly into not just being “content-driven” (that’s all websites?), but “content heavy”. <div> </div> <div><img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/main/images/astro.png" width="1280" alt="Screenshot of Astro website" height="720" /></div>   The team behind Astro aren’t trying to build a javascript framework for all web experiences ever, instead, they go for a very specific kind of website. That gives them the luxury of making opinionated calls with the framework and the optimisations it can ship straight out of the box. The <a href="https://docs.astro.build/en/concepts/why-astro/">Why Astro</a> page has some great information, most notably: <ul> <li> <a href="https://docs.astro.build/en/guides/framework-components/">UI-agnostic</a>: Supports React, Preact, Svelte, Vue, Solid, Lit, HTMX, web components, and more. </li> <li> <a href="https://docs.astro.build/en/basics/rendering-modes/">Server-first</a>: Moves expensive rendering off of your visitors’ devices. </li> <li> <a href="https://docs.astro.build/en/basics/astro-components/">Zero JS, by default</a>: Less client-side JavaScript to slow your site down. </li> </ul>   However, the Astro team know the lines blur really quickly between static site, SPA, PWA, and everything else content-driven you can build with other frameworks. So they have this <a href="https://docs.astro.build/en/concepts/islands/">Islands</a> concept, where you can use your React/Vue/Svelte “components” inside your Astro project, and at build time they get rid of all the overhead from those frameworks and just ship the javascript needed to make your dynamic components work. If you think about it, these optimisations start to open many doors. I’ll wrap up this section with their design principles, which I think help explain their biases clearly <ol> <li> <a href="https://docs.astro.build/en/concepts/why-astro/#content-driven">Content-driven</a>: Astro was designed to showcase your content. </li> <li> <a href="https://docs.astro.build/en/concepts/why-astro/#server-first">Server-first</a>: Websites run faster when they render HTML on the server. </li> <li> <a href="https://docs.astro.build/en/concepts/why-astro/#fast-by-default">Fast by default</a>: It should be impossible to build a slow website in Astro. </li> <li> <a href="https://docs.astro.build/en/concepts/why-astro/#easy-to-use">Easy to use</a>: You don’t need to be an expert to build something with Astro. </li> <li> <a href="https://docs.astro.build/en/concepts/why-astro/#developer-focused">Developer-focused</a>: You should have the resources you need to be successful. </li> </ol> <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" /> <h2>What about Nextjs</h2> Nextjs seems like it could be the default implementation choice for most Optimizely SaaS implementations, the Optimizely <a href="https://github.com/episerver/cms-saas-vercel-demo">demo implementation</a> also use next. As Nextjs itself is funded by Vercel and built with the React ecosystem you’re in relatively stable hands. <div> </div> <div><img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/main/images/next.png" width="1280" alt="Next website screenshot" height="720" /></div>   If you’re somewhat familiar with Nextjs then you’re probably already thinking these two frameworks have a lot in common, and you’re right. As always, it comes down to the use case. I’m not going to argue the pros and cons here (maybe in a future post?), but I would like to explore the most simple of use cases where I think you could do well with either option. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" /> <h2>Let’s build a blog</h2> What could be more simple than a static site with a few pages and some articles? I can’t think of anything exciting enough to build and share here. Thankfully, building a decent blog with Astro is ridiculously easy. I’m not joking. I moved my <a href="https://jcpretorius.com/blog">personal blog</a> over from a custom CMS I built myself to Astro in less than a day, and it got even better in the process. I spun up the Astro blog template and hooked it up to my SaaS CMS Optimizely Graph and what do you know we have a working website. <div><img src="https://raw.githubusercontent.com/jacobpretorius/Opti.SaaS.Astro.Demo/main/images/sample-site.png" width="1280" alt="Screenshot of sample site" height="720" /></div>   Check it out here <a href="https://opti-saas-astro-static-demo.vercel.app">https://opti-saas-astro-static-demo.vercel.app</a> In the <a href="/link/59abecef9d6642b9816d424de5a0a99b.aspx">next post</a> I’ll walk through the code a bit and share how it all fits together, but for the eager you can find it here <a href="https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo">https://github.com/jacobpretorius/Opti.SaaS.Astro.Demo</a>2024-05-28T17:41:49.0000000Z

Blog post

How to go beyond web A/B testing with Optimizely Feature ExperimentationIn <a href="https://www.dotcentric.co.uk/news-and-insight/optimizely-feature-experimentation/">the latest article</a>, which follows on from our previous <a href="https://www.dotcentric.co.uk/news-and-insight/optimizely-web-experimentation/">Web Experimentation article</a>, we explain how Feature Experimentation goes beyond A/B testing to enable product teams to deliver higher quality releases, run safer tests and validate new features at scale. Feel free to read <a href="https://www.dotcentric.co.uk/news-and-insight/optimizely-feature-experimentation/">How to go beyond web A/B testing with Optimizely Feature Experimentation</a> on the dotcentric blog. Happy Friday!2023-02-17T09:05:30.0000000Z

Blog post

How Optimizely Web Experimentation enables fast validation of design and UX changesEver wondered how to increase conversion rates and quickly validate design/UX alternatives to find the most impactful changes? I wrote a practical article showing how to do exactly that <a href="https://www.dotcentric.co.uk/news-and-insight/optimizely-web-experimentation/">using Optimzely Web Experimentation now available on the dotcentric blog</a>.2023-01-31T15:18:17.0000000Z

Blog post

Three key takeaways from Opticon London 2022Myself and members of the dotcentric team spent the day at Opticon London 2022 learning all about the latest happenings in the Optimizely world. <a href="https://www.dotcentric.co.uk/news-and-insight/three-key-takeaways-from-opticon-2022/">Head on over to the dotcentric blog</a> to read about my three key takeaways from the event. See you next year!2022-11-10T16:45:35.0000000Z

Blog post

Waving To Advance Over the SunsetWhile doing some maintenance work for a client we noticed that on solution startup there were some DNS failure messages for the URL “emea.epcc.episerver.net” and looking at their appSettings.config it is clear where this comes from. <pre class="language-csharp"><code> <add key="episerver:RecommendationServiceKey" value="secret" /> <add key="episerver:RecommendationServiceSecret" value=" secret" /> <add key="episerver:RecommendationServiceUri" value="https://emea.advance.episerver.net/" /> <add key="episerver:CmsCloudSynchronizationKey" value=" secret" /> <add key="episerver:CmsCloudSynchronizationSecret" value=" secret" /> <add key="episerver:CmsCloudSynchronizationUri" value="https://emea.epcc.episerver.net/" /></code></pre> However, getting to the bottom of these turned out to be quite a rabbit hole. Join me as we explore it. Optimizely product names and package names in bold. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" /> Episerver Advance Optimizely support let us know that Advance has been sunset, and pointed us to this document of retired products <a href="/link/c6edeabaacf14b62876d5287e97717c3.aspx">https://world.optimizely.com/contentassets/c1670edf938343f6b1b1076ece6abea6/episerver-discontinued-services-and-products---20200701-distro.pdf</a> <img src="https://i.imgur.com/9dA03Vg.jpg" width="868" alt="Some sunset Episerver products (Including Advance - December 2020)" height="433" /> Okay great, we can get rid of it. But what was it and which packages were a part of it? Of course, there isn’t a nice and easy Episerver.Advance package to uninstall and be done with it. The Advance product announcement post in World by Joakim mentions installing the packages Episerver.Personalization.CMS and EPiServer.Tracking.PageView. <a href="/link/6a57ae88bcb54e819fef3e2c2ef30b11.aspx">https://world.optimizely.com/blogs/joakim-platbarzdis/dates/2018/4/episerver-advance-launched/</a>   We can also see in this article which is in a “CHECKED” category, whatever that means, that it needs the same packages <a href="/link/8cee0891fd0b47aea4c1a742c21d761f.aspx">https://world.optimizely.com/documentation/developer-guides/archive/personalization/checked/advance-api/</a> <img src="https://i.imgur.com/RD7Yx4J.jpg" width="1083" alt="" height="288" />   Let’s now drill into the packages a bit. There doesn’t seem to be any existing proper documentation around these anymore so time to spin up the decompiler. First starting with the packages for Advance. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" /> Episerver.Personalization.CMS – safe to remove This uses the connections strings matching the URL section “<a href="https://atpscan.global.hornetsecurity.com/index.php?atp_str=gvTI2oXDUu5o4xxGQ8_4tYmuMJVw60Q4C3GlalJumgN3qe9fDg2qD9mjHD1CtJ7N2hgyrD7JK0587DrKhvWSYVCFjxFU92phv8m89SXl93LgtKbDycnE--znZjO11KvS1SKj8DRjZ3UaY3DS5-qLUZJiSa55I5FoFlejayMdtPl0JYinXynNGOtz0KqzzywIkV1PJc_GX8vwybuH92FvMoYrgfucSONT1mHdHMzIrqPOD6ulD6WLia167JnGXjm4GGR6eFBsHjo_FNIIPFDTJcArZh9fJxb0Sexz7TwIFSVQf4103ujGX5fyIaugtLCxupH97KZBIzo6Izj4akH-NnMNozY6tCM6OiMRkth3H7QfpnytT4zthGel">emea.advance.episerver.net</a>”. This URL does not have DNS mappings and is now non-functional. <pre class="language-csharp"><code>namespace EPiServer.Personalization.CMS { [InitializableModule] [ModuleDependency(typeof (ServiceContainerInitialization))] public class InitializationModule : IConfigurableModule, IInitializableModule { public void ConfigureContainer(ServiceConfigurationContext context) { context.Services.AddSingleton<IHttpClientFactory, HmacHttpClientFactory>(); string applicationKey = ConfigurationManager.AppSettings.Get("episerver:RecommendationServiceKey"); if (string.IsNullOrEmpty(applicationKey)) throw new ConfigurationErrorsException(string.Format("AppSetting '{0}' is required for recommendation service", (object) "episerver:RecommendationServiceKey")); string secret = ConfigurationManager.AppSettings.Get("episerver:RecommendationServiceSecret"); if (string.IsNullOrEmpty(secret)) throw new ConfigurationErrorsException(string.Format("AppSetting '{0}' is required for recommendation service", (object) "episerver:RecommendationServiceSecret")); string baseUri = ConfigurationManager.AppSettings.Get("episerver:RecommendationServiceUri"); if (string.IsNullOrEmpty(baseUri)) throw new ConfigurationErrorsException(string.Format("AppSetting '{0}' is required for recommendation service", (object) "episerver:RecommendationServiceUri")); // Snip } } } </code></pre> <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" /> Episerver.Personalization.CMS.UI – safe to remove Same as above. <pre class="language-csharp"><code>namespace EPiServer.Personalization.CMS.UI { [InitializableModule] [ModuleDependency(typeof (ServiceContainerInitialization))] public class InitializationModule : IConfigurableModule, IInitializableModule { private void SetupStrategyConfiguration(ServiceConfigurationContext context) { string applicationKey = ConfigurationManager.AppSettings.Get("episerver:RecommendationServiceKey"); if (string.IsNullOrWhiteSpace(applicationKey)) throw new ConfigurationErrorsException("AppSetting 'episerver:RecommendationServiceKey' is required for recommendation service"); string secret = ConfigurationManager.AppSettings.Get("episerver:RecommendationServiceSecret"); if (string.IsNullOrWhiteSpace(secret)) throw new ConfigurationErrorsException("AppSetting 'episerver:RecommendationServiceSecret' is required for recommendation service"); string baseUri = ConfigurationManager.AppSettings.Get("episerver:RecommendationServiceUri"); if (string.IsNullOrWhiteSpace(baseUri) || !Uri.IsWellFormedUriString(baseUri, UriKind.Absolute)) throw new ConfigurationErrorsException("AppSetting 'episerver:RecommendationServiceUri' is required for recommendation service"); string s = ConfigurationManager.AppSettings.Get("episerver:RecommendationServiceCacheDuration"); // Snip } } }</code></pre> <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" /> Episerver.Personalization.CMS.Core – safe to remove Same as above. <pre class="language-csharp"><code>namespace EPiServer.Personalization.CMS.Core { public static class Constants { public const string ApplicationKey = "episerver:RecommendationServiceKey"; public const string Secret = "episerver:RecommendationServiceSecret"; public const string BaseUri = "episerver:RecommendationServiceUri"; public const string CacheDuration = "episerver:RecommendationServiceCacheDuration"; public const int DefaultStrategyCacheDuration = 5; public const string DefaultStrategyValue = "251679C7-088F-45EE-8B39-238F73C7C5C6"; public const int RecommendationItemBufferNumber = 5; } }</code></pre> <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" /> EPiServer.Tracking.PageView - keep! This is an interesting one. While as part of the Advance installation steps they recommended installing this package, it doesn’t relate directly to the Advance product. Instead, it relies on the Profile Store product internally. <img src="https://i.imgur.com/G4FF0FV.jpg" width="482" alt="Profile store is a dependency of EpiServer.Tracking.PageView" height="219" /> Which in turn uses a different set of connection strings. <pre class="language-csharp"><code>namespace EPiServer.Profiles.Client { [ServiceConfiguration(Lifecycle = ServiceInstanceScope.Scoped, ServiceType = typeof (IProfilesTrackingConfiguration))] public class ProfilesTrackingConfiguration : IProfilesTrackingConfiguration { private const string TrackingApiBaseUrlKey = "episerver:profiles.TrackingApiBaseUrl"; private const string SubscriptionIdKey = "episerver:profiles.TrackingApiSubscriptionKey"; private const string ProfileStoreTrackingEnabledKey = "episerver:profiles.ProfileStoreTrackingEnabled"; // Snip } }</code></pre>   The Profile Store is crucial for good recommendations so this package should be kept along with the PageView tracking package. Removing the three personalisation packages above is required when removing the connection string values otherwise there is a runtime error preventing startup, as these packages need the connection strings in place to allow the solution to run. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" /> Cloud Synchronization Now for the URL we see in the startup error logs, <a href="https://emea.epcc.episerver.net/">https://emea.epcc.episerver.net/</a> which is used by EPiServer.Cms.CloudSynchronization <ul> <li>I can find no indication online what this package did, or why it was installed! It is like it never existed. The only trace of it online is as an entry in Knipe’s NuGet feed explorer <img src="https://i.imgur.com/kBBm7oE.jpg" width="886" alt="" height="57" /> <a href="https://www.david-tec.com/optimizely-nuget-feed-explorer/?q=EPiServer.Cms.EPiServer.Cms.CloudSynchronization">https://www.david-tec.com/optimizely-nuget-feed-explorer/?q=EPiServer.Cms.EPiServer.Cms.CloudSynchronization</a> </li> <li> however, it is not available in the official Optimizely NuGet feed so seems like it is no longer supported  <img src="https://i.imgur.com/aGMYJQg.jpg" width="756" alt="" height="160" /> <a href="https://nuget.optimizely.com/package?id=EPiServer.Cms.CloudSynchronization">https://nuget.optimizely.com/package?id=EPiServer.Cms.CloudSynchronization</a> </li> <li>However, I can see the package uses these connection strings we have</li> </ul> <pre class="language-csharp"><code>namespace EPiServer.Cms.CloudSynchronization { public static class ConfigurationSettings { public const string ApplicationKey = "episerver:CmsCloudSynchronizationKey"; public const string Secret = "episerver:CmsCloudSynchronizationSecret"; public const string ServiceLocation = "episerver:CmsCloudSynchronizationUri"; // Snip } }</code></pre> <ul> <li>I also found by exploring the code for it that it added the “Cloud Provisioning” scheduled job</li> </ul> <pre class="language-csharp"><code>namespace EPiServer.Cms.CloudSynchronization.Internal { [ScheduledPlugIn(Description = "Connects to a cloud service and uploads entities such as content, categories, sites etc. Job should be run one time upon installation and should not be scheduled since changes are incrementally synchronized as soon as they occur.", DisplayName = "Cloud Provisioning", GUID = "3FAF1A3C-DF44-4FB3-9F47-B9C3B2A36020")] [ServiceConfiguration(IncludeServiceAccessor = false)] public class CloudProvisioningJob : ScheduledJobBase { public const string JobId = "3FAF1A3C-DF44-4FB3-9F47-B9C3B2A36020"; private static readonly ILogger Logger = LogManager.GetLogger(); private readonly IEnumerable<IProvisioningJob> _syncJobs; private CancellationTokenSource _cancellationTokenSource; public CloudProvisioningJob(IEnumerable<IProvisioningJob> syncJob) { this._syncJobs = syncJob; this.IsStoppable = true; } // Snip } }</code></pre> <ul> <li>Running it leads to an error since the URL also does not have DNS mappings anymore. <img src="https://i.imgur.com/bswVqbF.jpg" width="850" alt="" height="258" /> </li> </ul>   It should be safe to remove this along with the three Advance personalisation packages and the related connection strings for both products. (Please leave a comment with what it did if you know as I'm burning to find out) <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" /> Content Recommendations Advance has been superseded by the Content Recommendations product. Which uses the package EPiServer.Personalization.Content.UI and is working well in our client’s solution. Connection strings below for interest sake. <pre class="language-csharp"><code>namespace EPiServer.Personalization.Content.UI.Configuration { [Options] public class ContentPersonalizationOptions { public string Environment { get; set; } public string ClientId { get; set; } public string ClientName { get; set; } public string ApiToken { get; set; } public bool DisableDefaultTracking { get; set; } internal void Validate() { if (string.IsNullOrEmpty(this.Environment) || string.IsNullOrEmpty(this.ClientId) || string.IsNullOrEmpty(this.ApiToken) || string.IsNullOrEmpty(this.ClientName)) throw new ConfigurationErrorsException("Episerver Content Personalization requires the following properties to be set: episerver:personalization.content.Environment, episerver:personalization.content.ClientId, episerver:personalization.content.ClientName and episerver:personalization.content.ApiToken are set in the appSettings section."); } } }</code></pre> <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" /> Conclusion I hope this helps anyone having to do the same kind of maintenance/clean-up work as it was quite shocking to me how little information I could find about these packages online.2022-09-12T08:59:54.0000000Z

Blog post

Unpublish Content the Intuitive WayBeing someone with a technical background who is also "client-facing" means, quite often, that you are the person who has to explain a lot of the platform functionality to the "business" minded folk. That's all fun and games as quite often people with no past experience with Optimizely directly, or even CMS/Commerce solutions as a whole, bring with them lots of weird and wonderful questions. Often with even weirder answers leading to interesting observations. One that I've been asked more times than I can count is "How do I unpublish this content?". Oh, it's super simple. See you're in preview mode now so scroll up so that hidden grey menu appears. Then click the "Tools" dropdown. Now click "Manage Expiration and Archiving". Then on that popup click the "now" next to "Expire date". Ok now click "Save". See super easy! "That's.. weird 🤔" Actually, come to think of it; yes, yes it is. So I made a plugin for CMS 12 that makes it a bit more intuitive and puts the "Unpublish" functionality right where you (okay maybe not you, but the business person signing off our invoices) would expect it to be. <img src="https://raw.githubusercontent.com/dotcentric/dotcentric.Optimizely.Unpublish/main/images/unpublish.png" width="468" alt="" height="270" /> <img src="https://i.imgur.com/JOTo6Dk.gif" width="800" alt="" height="483" /> All you need to do is install it via the <a href="https://nuget.optimizely.com/package/?id=dotcentric.Optimizely.Unpublish">Optimizely NuGet feed</a> and then add the below to your <code>Startup.cs</code>  <pre class="language-csharp"><code>public void ConfigureServices(IServiceCollection services) { // The usual stuff omitted // using dotcentric.Optimizely.Unpublish; services.AddUnpublish(); }</code></pre> As usual, the code for this plugin can also be found <a href="https://github.com/dotcentric/dotcentric.Optimizely.Unpublish">on GitHub</a>. <h2>*Update*</h2> Seems like this tiny change resonated with more people than I thought it would and I've had a few requests to see if we can get it added to the CMS core product. If you'd like to help make that happen please vote for it here <a href="https://feedback.optimizely.com/ideas/CMS-I-280">https://feedback.optimizely.com/ideas/CMS-I-280</a>2022-04-19T10:58:12.0000000Z

Blog post

Quick Episerver Custom Login BackgroundI'm sure we've all had the same request many times, "Could you change the CMS login background image for us?". It's not a difficult thing to do or something that takes much time. The other day I was creating three different new Episerver solutions and I as I was doing the same thing for each of them it struck me that I've never actually checked to see if there is a NuGet package that does this. I had a look around and could not find anything that is also customizable if I didn't like the particular new background image the plugin creator chose for me. With that in mind, I've created <code>Zone.Epi.BlankLoginBackground</code> for a one-click customizable CMS login background change. <img src="https://raw.githubusercontent.com/zone/Zone.Epi.BlankLoginBackground/master/img/Login_Usage.PNG" width="800" alt="" height="594" /> All you need to do is install it via the <a href="https://nuget.episerver.com/package/?id=Zone.Epi.BlankLoginBackground">Episerver NuGet feed</a> and you are good to go. On the next CMS login you will see a more generic login background image. If you would like to use any other image all you need to do is replace <code>login-background.jpg</code> in the newly created project directory <code>\Static\Images\CMS\</code> and it will be used automatically. As usual, the code for this plugin can also be found <a href="https://github.com/zone/Zone.Epi.BlankLoginBackground">on GitHub</a>.2019-08-14T10:27:00.0000000Z

Blog post

How to easily copy content between pagesWorking with large Episerver builds often comes with unique challenges both from the content management side and from a business rule perspective. Recently one of our clients at Zone decided they wanted to update and restructure large parts of their site layout. Based on other external factors, this would create some extra editor overhead to keep everything running smoothly. Occasionally the editors will need to manually copy content between pages to align marketing strategies. I saw this as an interesting problem that we could make as painless as possible with a custom admin plugin. <img src="https://raw.githubusercontent.com/zone/Zone.Epi.ContentCopy/master/img/Content_Copy_Usage.png" width="600" alt="" height="606" /> The plugin allows editors to choose which language they want, and if they only want culture specific properties shown. To make it as intuitive as possible they have two content trees, one for the 'source' and one for the 'destination' page. Based on the source page selection and culture-specific setting, the available properties for that page type will be loaded automatically. The plugin isn't sensitive to which types of pages are selected; the only requirement is that the selected properties are the same type and have the same name on both source and destination page types. By default the plugin will create a new draft on the 'destination' page if there aren't any issues with the copy process. If there is an outstanding draft on the 'destination' page already, the plugin will let the editor know and not make any further changes to that draft. Editors can also choose to skip the draft process and overwrite any outstanding drafts by copying the content and publishing the changes immediately (assuming there are no errors during copying). To prevent misuse of this I've decided to make the plugin an admin plugin and not put it in the CMS editor interface. All in all, I think this plugin is very useful for managing complex content strategies with ease. This plugin can be installed using NuGet from the <a href="https://nuget.episerver.com/package/?id=Zone.Epi.ContentCopy">Episerver feed</a> by searching for <code>Zone.Epi.ContentCopy</code>. As usual the code for this plugin can also be found <a href="https://github.com/zone/Zone.Epi.ContentCopy">on GitHub</a> if you want to change any of the standard features or build it out more. Thanks to Raffaele Millo for helping determine exactly how it should work.2019-07-01T17:16:46.0000000Z

Blog post

Introducing the A/B Test List GadgetEpiserver A/B testing has been around for a while, and editors can easily use it to get some real-world metrics that measure how different content versions compare. However with complex websites, it can be difficult to get the right message across as efficiently as possible on all devices – A/B testing is a powerful tool to make sure our sites do just that. Unfortunately, it can be rather difficult for editors to keep track of exactly what is being tested, how far along the tests are and which changes seem to be doing the best. On larger builds with multiple sites and many different editorial teams it can quite easily become a "who knows?" type problem. Out of the box you could go to CMS edit mode and get some info on the "Tasks" tab, but that list feels very hidden and leaves a lot to be desired. With this in mind, we at Zone decided to create a CMS dashboard gadget which gives editors a list of running A/B tests, owners, results, views, participation percentage and a direct link to the detailed test overview page. This list can also be filtered based on the test site directly from the component interface. <img src="https://i.imgur.com/5iF3PSF.png" width="714" alt="" height="436" /> We think this is a much better way to get an overview of exactly what is going on with A/B testing across the whole build and allows editors to get the most of this powerful testing tool. The component can be installed using NuGet from the <a href="https://nuget.episerver.com/package/?id=Zone.Epi.ABTestListGadget">Episerver feed</a> by searching for <code>Zone.Epi.ABTestListGadget</code>. The code for the component can also be found <a href="https://github.com/zone/Zone.Epi.ABTestListGadget">on GitHub</a> if you want to customise and expand it more – please let me know if you do as we are interested in seeing where this could go.2019-05-20T16:33:17.0000000Z

Blog post

Autofill Episerver Forms fields from Profile StoreAs a user, it can be frustrating to repeatedly fill in the same information, especially if the system already has that data recorded. So why not use all the info from Profile Store to autofill forms and save some time? The Episerver Profile Store can be a great option for tracking visitor behaviour and getting personalisation going quickly. Once you combine the Profile Store with Insight, Forms and David Knipe's <a href="https://github.com/davidknipe/InsightFormFieldMapper">Insight Form Field Mapper</a>, you can easily extract a great deal of value from the service. At Zone, we've recently been investigating how we can extend the Episerver platform to provide the best user experience possible. One of the stories we have is the ability to autofill Episerver Forms elements. With this idea in mind I started digging around to see how we could achieve exactly that. Fortunately, I found the <a href="/link/51e6228df528414eb2964adf40fba9ae.aspx">developer guides for the Forms Autofill API</a> and even though it’s still in beta, it doesn't look like there has been much new development going on around it. I decided to give it a go. <img src="https://i.imgur.com/awDm73x.gif" width="745" alt="" height="453" /> For this demo we show a user providing their details in a standard custom form during checkout. That info is then stored to the Profile Store and retrieved to autofill the Forms elements on the homepage. Sharing information between different forms is also supported as long as they are mapped to push and pull data from the Profile Store in the CMS. All we really need to do to get the Forms elements hooked up to our data source (Profile Store) is implement <code>IExternalSystem</code> and <code>IAutofillProvider</code>. <h2>Implementing the interfaces</h2> Both interfaces can be implemented in the same class as there is some overlap between them. I've called my implementing class <code>ProfileStoreAutofillFields</code>. The <code>IExternalSystem</code> interface is used to register a custom data source and drives the CMS drop-down list. <pre class="language-csharp"><code>public virtual string Id { get { return "ProfileStoreAutofillFields"; } } public virtual IEnumerable<IDatasource> Datasources { get { // Register the Profile Store as a data source var profileStoreDataSource = new Datasource() { Id = "ProfileStoreDataSource", Name = "Profile Store Data Source", OwnerSystem = this, Columns = new Dictionary<string, string> { // "Name of mapped field", "friendly name in CMS" { "profilestoreemail", "Email" }, { "profilestorename", "Name" }, { "profilestorecity", "City" }, { "profilestoremobile", "Mobile" }, { "profilestorephone", "Phone" } } }; return new[] { profileStoreDataSource }; } }</code></pre> Up next, the <code>IAutofillProvider</code> is where the magic happens and we use <code>GetSuggestedValues</code> to provide our "suggested" values from the Profile Store based on the device GUID as set in the Profile Store Cookie. The drop-down list in the CMS needs to match here for a value to be suggested. <pre class="language-csharp"><code>/// <summary> /// Returns a list of suggested values by field mapping key. This will be called automatically by the GetAutofillValues() function in DataElementBlockBase for each field /// </summary> /// <returns>Collection of suggested values</returns> public virtual IEnumerable<string> GetSuggestedValues(IDatasource selectedDatasource, IEnumerable<RemoteFieldInfo> remoteFieldInfos, ElementBlockBase content, IFormContainerBlock formContainerBlock, HttpContextBase context) { if (selectedDatasource == null || remoteFieldInfos == null) return Enumerable.Empty<string>(); // Make sure the Data sources are for this system if (!this.Datasources.Any(ds => ds.Id == selectedDatasource.Id) || !remoteFieldInfos.Any(mi => mi.DatasourceId == selectedDatasource.Id)) { return Enumerable.Empty<string>(); } // We also need to make sure that we have some tracking info to auto fill // _madid is the default Episerver Profile Store tracking cookie, see https://world.episerver.com/documentation/developer-guides/tracking/episerver-cookies/ var userDeviceId = context.Request.Cookies["_madid"]?.Value; // Because this gets called with EVERY FIELD it is suggested to cache the response elsewhere var userProfile = ProfileStoreApiService.GetProfileByDeviceId(userDeviceId); if (userProfile == null) { return Enumerable.Empty<string>(); } // Unpack the info object var info = userProfile["Info"]; // Get the field details var activeRemoteFieldInfo = remoteFieldInfos.FirstOrDefault(mi => mi.DatasourceId == selectedDatasource.Id); switch (activeRemoteFieldInfo.ColumnId) { // Suggest the data from the Profile Store user profile case "profilestoreemail": return new List<string> { (string)(info["Email"] ?? info["Email"]?.ToString()) }; case "profilestorename": return new List<string> { (string)(userProfile["Name"] ?? userProfile["Name"]?.ToString()) }; case "profilestorecity": return new List<string>{ (string)(info["City"] ?? info["City"]?.ToString()) }; case "profilestorephone": return new List<string>{ (string)(info["Phone"] ?? info["Phone"]?.ToString()) }; case "profilestoremobile": return new List<string>{ (string)(info["Mobile"] ?? info["Mobile"]?.ToString()) }; default: return Enumerable.Empty<string>(); } }</code></pre> I have only added a handful of fields to demonstrate how it works. To add more, simply update the implementation of both interfaces with the fields available in the Profile Store API - <a href="/link/cba0a11a3ed44e37b9319475791d819f.aspx">all of which you can see here</a>. <h2>Getting the user profile from the Profile Store</h2> We get all the user info by querying the Profile Store API. There are some ongoing improvements to provide a wrapper instead of manually having to implement the API calls, such as the <a href="https://www.david-tec.com/2019/05/episerver-profile-store-.net-client/">Episerver Profile Store .NET client</a>; however, to keep things flexible I've provided a (mostly unchanged) version of the one call we need here from the client by David Knipe. <pre class="language-csharp"><code>using Newtonsoft.Json.Linq; using RestSharp; public static class ProfileStoreApiService { // This should come from app settings really private static readonly string apiRootUrl = "https://somesecret.profilestore.episerver.net"; // Get from Insight / Profile store developer portal private static readonly string subscriptionKey = "somesecret"; // Get from Insight / Profile store developer portal public static JToken GetProfileByDeviceId(string deviceId) { // Set up the request var client = new RestClient(apiRootUrl); var request = new RestRequest("api/v1.0/Profiles", Method.GET); request.AddHeader("Ocp-Apim-Subscription-Key", subscriptionKey); // Filter the profiles based on the current device id request.AddParameter("$filter", "DeviceIds eq " + deviceId); // Execute the request to get the profile var getProfileResponse = client.Execute(request); var getProfileContent = getProfileResponse.Content; // Get the results as a JArray object if (!string.IsNullOrWhiteSpace(getProfileContent)) { var profileResponseObject = JObject.Parse(getProfileContent); var profileArray = (JArray)profileResponseObject["items"]; // Expecting an array of profiles with one item in it return profileArray.First; } return null; } }</code></pre> It should be noted that in production you would want to build out this <code>ProfileStoreApiService</code> to include some form of response caching. The <code>GetSuggestedValues</code> function we have calls <code>GetProfileByDeviceId</code> (aka the Profile Store API) for every Forms element we have mapped. Personally, I would parse the response JToken object and cache a strongly typed user profile object, but there are various ways to go about it. With all that done it's time to spin up the site and go update some Forms. <h2>Forms configuration</h2> First, you need to update the Form Container to map our new data source. <img src="https://i.imgur.com/xuWsGew.png[" alt="" /> Next, we need to edit the Form Elements to link the mappings. <img src="https://i.imgur.com/WXKcPU9.png" alt="" /> Make sure it's mapped to push responses to the correct Profile Store/Insight fields. <img src="https://i.imgur.com/a3vrCMk.png" alt="" /> And finally, map to the Profile Store data source to retrieve the stored fields. <img src="https://i.imgur.com/IJJVSXh.png" alt="" /> That's all there is to it! You should now have Forms elements that fill themselves out as the user information gets updated. <h3>Future work</h3> This should be seen as more of a POC to get things going. You need to decide if and when you want to "trust" that a user profile is actually who we think they are (such as only for logged-in users) to make sure you don't expose personal user data. <h3>Useful resources</h3> Check out the Forms <a href="https://github.com/episerver/EPiServer.Forms.Demo">demo project</a> and the <a href="https://github.com/davidknipe/InsightFormFieldMapper/">Episerver Insight Form Field Mapper</a> to see examples of what else is currently possible. The sample code for this can be found on <a href="https://github.com/jacobpretorius/Episerver.Autofill.Forms.Sample">Github</a>.2019-05-10T11:10:38.0000000Z

Blog post