51ºÚÁϲ»´òìÈ

Transcript

Okay, we had some issues in the live session, unfortunately, so I’m recording the slide content and demo again. With that being said, let’s jump to today’s agenda.

So first of all, we’ll be talking about session goals, what we hope to achieve in this session. After that, we’ll be giving an introduction to the universal editor. We’ll be taking a brief comparison to the AEM page editor that most folks will be familiar with. We’ll be talking about some primary use cases, other use cases that may be coming to mind. Then we’ll have a demo session on a few use cases, and we will look at common technical considerations.

So, getting today’s session goals, essentially, the universal editor is relatively new. It’s been around since 2024, and a lot of presentations exist. These typically focus on specific use cases in architecture, so you may be doing edge delivery services with a commerce storefront.

However, a lot of people in the AEM community have been hearing about this new editor and are wondering, they don’t have a specific use case yet, and are thinking when and how they should be using it. So with that said, this session intends to give a broad overview of the universal editor, along with its primary use cases and some of those other use cases, just to give some clarity.

So the universal editor itself is a modern, reimagined visual offering interface included with AEM sites. What you see is what you get editing that most AEM teams are used to, and it allows editing as a key thing in any headless or head full experience. It fully integrates with AEM tools like the site console, content fragment editor, and many more. These would be things like multi-site management, translation, workflows, all the web content management tools in AEM.

The big part of this tool is to highlight what it’s not, and it’s not intended as a direct replacement to the AEM page editor.

So as we look at the UI, we’ll see essentially three major UI parts, and then these also act as extension points with one additional one available. But in the top right screenshot, we can see the header menu with the example customization there with an export functionality. Typically, the header menu is going to be where you handle all the web content management tasks, locking pages, running workflows, publishing content. To the next image, on the right side, we have the properties rail. Within that, we’ll be doing more form-based content editing as opposed to the inline editing that’s also possible on simple text fields. So in this properties rail, each of the pieces of content, nodes that we’ll be editing, will have components, and there’s a lot of default components you can use, text, rich text, select menu, radio button type inputs, but that also serves as an extension point. So if you need to create custom data entry types, you can do that via that extension point. And then in the bottom image, we can see tabs that we also have in the properties rail. We’ll be showing some examples of extensions there. And lastly, there’s modal dialogues you can build on certain events. You may have a modal pop-up to confirm something. And in all of these cases, with these extension points, you have accessible data and events to have that two-way communication between the actual editing interface.

So speaking of all these extensions, you also have the AEM extension manager. This is a permission-based surface enabling extensions, both in AEM, content fragment, those interfaces, but it also covers the universal editor extensions. It allows you to enable and disable extensions, either supplied by 51ºÚÁϲ»´òìÈ or else an implementation team can build their own BYO extension.

You can also configure extension variables. And a nice feature that this has is you may be evaluating an extension, but you don’t want to enable it globally, so to speak. So you can share a link, admins can share a link to a version of the universal editor that has that extension so specific team members can evaluate it. Just to list some of the extensions, and I do have a screenshot of the degenerate variations extension on the right side. That’s included if you have AEM with edge delivery services. But there’s also content drafts, AEM workflow, AEM multi-site management, and an AEM forms experience extension if you have that product.

So now that we’ve introduced the universal editor, let’s compare that to the page editor that again has been around at least in the touch UI version since about 2014, I think, with AEM 6. But the AEM page editor was initially developed to allow editing of pages where content was both stored and rendered in the AEM author and published stack. So a key point is that you edit page content using the page editor in AEM’s Java content repository.

Again, since AEM 6, the HTL sitely templating language was introduced. So the vast majority of components that we see would be in HTL, which is HTML templating language. It had a separation of logic into Java based sling models. And another key point is that the dialogues you built, the actual elements that the author was interfacing with were built in a UI called Quarrel UI.

And then also we had the concept of editable templates that allowed kind of no code or low code UI to build out templates and component policies.

So one more thing to add, the SPA editor capability was added on for single page applications. What we saw is that these were pretty limited to AEM publish server delivery as opposed to being headless or server side. They would be client side and served from AEM publish. And it was also tightly coupled to specific React and Angular versions. So that was kind of one of the issues there that led to the SPA editor deprecation that happened back in January. So we do have an FAQ item about that and link in the reference with the document that covers a lot of the potential avenues and considerations.

Okay, so moving on to the universal editor, let’s kind of go through the features and talk about key ones that differentiate. So it’s a editor as a service pattern, which decouples it from specific content sources, versions of those React or Angular, basically any web based application you can instrument to use.

So talking about some of those comparisons, you can edit page content like the page editor, but also content fragment content. And you can edit content that’s in the AEM JCR. You can edit edge delivery services content, which is sometimes in AEM, but it’s sometimes in the offer bus, it’s called in the new document offering option. That’s currently early access, but that’s that flexibility of content backends. And there is the potential to integrate with custom backends as well. So there would be some API setup and things, but essentially you have variables that you define the content source and the universal editor being an editor as a service just communicates via those paths. So another comparison to the page editor where the page editor was usually HTML, this supports any web front end templating via attributes that you put into the HTML.

So it also differentiation point is that it uses React spectrum based offering components and plugins as opposed to the Quirrel UI that we had in the legacy AEM page editor.

And one thing I wanted to highlight there is it was quite common to have to do things like hiding and showing of fields and the syntax there in Quirrel UI was a little bit cumbersome. I think a nice thing within the universal editor is that it uses a JSON logic schema and the conditional fields, they’re a lot more developer friendly.

Okay, next up is let’s take a look at the two primary use cases with the first one being edge delivery.

And the goal here is not to go all that deep. Like I mentioned before, there’s a lot of existing sessions on this, but this is just one of the patterns that’s supported by the universal editor. AEM edge delivery services replaces the publish and dispatcher and the traditional way of building core components or components based on the core components in favor of a multi cloud solution and the development approach is pure front end. Content instead of being published to the published tier goes to an edge compute layer and it integrates with many customer CDNs. And a lot of the vision is ensuring a 100 Lighthouse score as part of this. So we can see that on the right in the diagram that with the universal editor, you would have AEM offering. We can see at the bottom left is one of the content sources you can use with edge delivery and that with an AEM, we would have that structured and unstructured content that gets published to edge delivery.

So again, it’s not a full technical deep dive, but to explain edge delivery to folks that might be new. So it’s a front end for all approach. Page content is built using blocks completely in JavaScript and CSS.

It built in as a continuous integration and deployment CI CD. So when any code is committed, GitHub actions will set up a server that will be able to set up a new URL with the branch name in it. And you essentially in that way, you’re not tied to a certain number of development environments. So whatever feature is being developed can be tested. And then once that’s been tested and a pull request is open, if you supply some test URLs, it’ll automatically execute Lighthouse score tests directly in GitHub. And that can be part of maintaining that optimal performance.

So other aspects kind of on the delivery side is you get essentially simple pre-rendered HTML. It’s quite similar to a markdown document, and that is delivered to the browser. And then on the client side, you have JS, JavaScript, and CSS that decorate the HTML. And with any publishing, with those multiple CDN integrations I mentioned, you have content is automatically flushed. So we can give content long cache time to live, but also ensure cache freshness.

So at this point, going back to the main point of this webinar is folks may be asking, hey, I’d like to use the universal editor. Does this mean I should migrate to edge delivery service perhaps? And that’s definitely a potential avenue. But keep in mind, it’s a rather different way of building components. So you would need to develop new JavaScript CSS-based blocks, as it’s called on the edge delivery side, that represent all the page content. And the content itself needs to be reshaped to be served within those blocks. So there’s a tool you can use called the AEM importer. And that essentially takes the HTML from any website and attempts to convert that into those markdown style content sections that will be styled by the blocks. So the tool can help. But depending on the variety of content and the source system, there’s some development to be done. So the point I want to make there is that the main incentive to do such a switch would be an overall update to use edge delivery, but not simply just a switch to the universal editor.

Part of this next slide I’ll be showing in the demo.

So at a high level, the content in this use case of universal editor would typically be content within AEM. You still have the web content management tools of AEM, MSM, workflows, et cetera. When you open a page, it opens into the universal editor on a site set up like this and do the editing. And then when you publish the page itself and any AEM assets that get referenced get published to the edge tier instead of publish. And again, a major goal being that excellent Lighthouse score.

So moving on to the second primary use case, AEM headless.

This is an example that could be really any app. I mentioned React, SPA, and Next.js because that’s a common one.

So looking at the diagram in the bottom right, we see that’s the AEM piece, which contains structured content, typically modeled and managed as content fragments and delivered via GraphQL. But you can also use content out of CQ page components as using JSON content services. Moving up on the right side, we can see the app itself, which is hosted externally to AEM, is interacting with that GraphQL and JSON. And this could be any theming, any rendering. But in the middle of that block, we see the universal editor instrumentation. So the front end is marked up with attributes that allow it to communicate with the universal editor or through the universal editor to the AEM back end.

Also, as a piece of that that we’ll show in a later slide is that you have some page level inclusions as well to set this up.

OK, I think that covers that slide. In this case, the headless app, we do have a tutorial called Secure Bank designed to showcase the power and flexibility of the universal editor. This utilizes a package available in the node package manager called the AEM headless client. So in any JavaScript based front end, you have that one available to interact with AEM headlessly in a simplified way. This example uses GraphQL content, again, using content fragments that represent the page article services and even some components. The GraphQL is really as AEM headless evolved was the primary way. But again, you do have the ability to interact with other JSON content. And this example shows atomic component design. So we have subcomponents, you could call them title text that get reused across multiple components with those components mapping to a content fragment in AEM.

So now that we’ve talked a little bit about this headless use case, I want to give a little bit of considerations. I think this is an ideal fit when you have an existing SPA, a single page application or some other web app and you want to introduce offering capability with AEM’s web content management features.

Personally, I would say if you have a net new project standing up a new site, or new application, a lot of times technical teams have experience in a specific technology.

I would say that you can absolutely do this. The universal editor enables that using headless AEM. But I think it’s also worth taking some time to look at edge delivery services being the new all in the 51ºÚÁϲ»´òìÈ ecosystem offering.

With edge delivery, you’ve got available boilerplate projects. And with those, the team can set up in minutes, or if not, maybe half an hour if you haven’t done it before, you can typically have a functioning website with customizable code, some baseline content and that CI CD built in. And I will acknowledge that edge delivery has some quite opinionated patterns of using vanilla JavaScript, vanilla CSS, there is no bundler built in necessarily. But if let’s say you like React, there’s precompiled versions you can use selectively in areas that need more complex UI elements.

And I would also mention going headless could be considered a little bit more advanced of an effort. You obviously have an app that’s being hosted elsewhere that needs to be set up and you have maintenance of that. And then also the integration with AEM will be something that you’re building into a custom app. So again, we have a tutorial. We will talk a little bit later about what’s involved in connecting to the editing.

But I think it’s just worth considering all the options on a net new site.

Okay. And the last one and maybe the biggest one, other use cases. So we have quite a few customers, I think, again, hearing about this new editor and wondering should I be using it yet? So at this point, I’ll mention there’s an experience league tutorial that shows you how to take existing core components, specifically the teaser, which consists of a title and text, traditional AEM components and shows you how to instrument those to use them in the universal editor. And you may be asking, hey, is this a guide? Should I be doing this? And to that, I would say in most cases, no. The general rule of thumb is on existing sites, you can still continue to use the page editor. These tutorials use these components as a lot of us come from an AEM background. It’s a quick place to go in and make some edits, hook things up and evaluate the technology. But it’s not necessarily to say, hey, go do this.

Moving on to the next slide, we’ve got some kind of constraints of going from those core based components and also want to acknowledge the potential that we have flexibility and the universal editor does support page content. So starting with the constraints column, there’s no direct migration path from an existing AEM site to the universal editor. So there’s fundamental differences in the two technologies. The universal editor by design doesn’t introduce all of the features of the page editor, including the templates, editable templates, style system and the responsive grid. In a lot of ways here in 2025, these use cases can be handled efficiently with lean front end CSS and JavaScript. And a lot of that also in edge delivery services is those enhanced development flows. So you can quickly put those things out, have a test environment and make those layout changes. Also being that it’s an editor as a service, you can’t directly inject CSS and JavaScript is commonly done to customize AEM dialogs so that blocks automatic conversion. And it also in a lot of dialogs, it was pretty common to have various validations and things happening in that Quirrel UI implementation. And the new universal editor uses React Spectrum.

So with that being said, possibilities… flexibility absolutely exists to read and update CQ page content. And we see AEM customers have just a quite diverse need when it comes to content. Quite often you’ll have multiple AEM programs. Maybe you wanna share content between. I think another common idea that folks may have is to build a microsite, a small dot sub domain that uses universal editor instead of the page editor. But my advice at that point would be to also take a look at the AEM page editor and then have the edge delivery services license, maybe consider building it out in edge delivery and getting some of the benefits of that new technology. So general advice is on those existing sites, continue to use the AEM page editor. It’s a decent amount of work to adapt to the universal editor and it would likely make most sense to move to the universal editor when you have another major initiative, a whole new site, maybe a redesign of a site that’s been around a lot of years. And I would also say on any new project to consider AEM’s latest offerings, including edge delivery.

Okay, and now it’s time to do a little demo of the things that we’ve been talking about. Just give me a moment to switch between my windows.

Okay, so let me go back one tab.

So to start with, I’m gonna be showing the primary use case one, which is edge delivery services backed by AEM and the universal editor. So we can see I have a test site in the AEM sites console, selected the homepage to that. I’m gonna go ahead and click on edit. And as I mentioned, there’s some configuration that’s baked into the boilerplate example to this, so those affected pages will be opened up in the universal editor, got some duplicate tabs.

So first thing I wanted to show is some of those common UI elements we talked about at the beginning. So I’ve got almost every extension enabled, but we can see that we have workflows, developer login, I’ll talk about that in a little bit, but the page properties, publication, all of this is kind of the main web content management tasks. If we click into basic fields, we could see this opens up in the properties panel, but we also have the ability to double click and edit in line.

Let me just do one thing real quick here. Okay, so you can make those changes in line. And also the second main UI element is this properties rail. So within this, we can both switch to a content tree, navigate the content, image, text, components, sections, that’s a key piece of edge delivery, part of the stuff above the fold is loaded first to help with Lighthouse. And then we can switch to this properties tab. And when we select a component like the hero, we can see that we have the more form-based editing fields and also one of the extension points. I’ll say alt text, this is a basic text field, but you can build custom input types in React Spectrum.

I think an example I’ve seen at least in content fragments is a Google Maps API integration to have address auto-complete.

An example I have built into this proof of concept extension of the boilerplate is if I go to edit the image here, I’m using a customized asset picker that we can see. I have the ability to select assets hosted on another environment using dynamic media with open API, but I can also switch to the author environment that my site is the content is hosted on. So if I was to select one of these images via configurations I have within the dam, it’s taking an image out of AEM author. And then when I publish, that’s going out to the edge delivery edge, I think it’s called the media bus, but the alternate to the AEM publisher. So a couple of options there. Moving on to the next major UI element and one of those extension points is these tabs that we have down below. So one of the example ones we have is a content drafts extension that you can, as an author is editing, maybe they want to think about various ideas of content and you could copy and paste that content in. Another one that I’ll just show at a high level is a generate variations extension that’s included with AEM edge delivery license. To my understanding, if you have specific questions, I would recommend talking to your 51ºÚÁϲ»´òìÈ account team, but let me switch to a page that’s got a little bit more realistic content on that one. So I’m gonna go to these adventures and we’ll go to Bali’s surf camp and let’s switch back to edit mode. And what this extension is telling me to do is select some content that I’d like to generate some variations of. So I’ll select that text. We have some suggested prompts. So maybe I want to optimize the text for a better SEO. This is an open field. You can put in what you want and then you can click generate on that. It collects page context.

It’s gonna use that in suggesting alternate text, which I think is a nice feature. But essentially what I wanted to show here is with these tabs as an extension point, if you have more complex UIs that you want to make available to the offers, it could be some type of calculator, some type of lookup. Really the sky’s the limit, but that’s when you would be extending those tabs.

Now, going back another part of what I have, so we can see those variations came up. We can apply those variations. We can see history if we did make a change, if we want to undo the change text. But another thing I wanted to highlight, so this is an edge delivery backed site, but I think a lot of the power of Universal Editor is the ability to have multiple content backends all in one WYSIWYG editing surface. So what we see on this page is actually a list of content fragments being called via GraphQL and rendered on the page.

So I could select, let’s get out of preview mode, but if I select this one, we can kind of see at the top there, it’s pointing to an asset in the dam content fragment. And then if I switch back to the properties, I have all those individual fields of the content fragment. And if I wanted to edit it as a content fragment, I can open it up into the CF editor.

Okay, so that’s an example of some hybrid content, and I’m going to now move on to my second use case, which is a headless app.

So in this case, I’m developing on local host. This is a React single page application that will be served on some other hosting method. The content is coming from AEM content fragments mostly, that’s how it is in the default tutorial. So going back, I can put any page, again, you can edit anything that’s instrumented to be used in the universal editor. So I’ll put in the path to that page, click on open, and we can see that page loaded up. There’s some setup to do this, I’ll talk about that and when I get back to the slides, but let’s go ahead and take a look at the content tree. So we can see the page itself is made up of a content fragment.

Again, we can typically on local host, it’s not quite the same, you would use the assets view, but this is a content fragment that can be opened in the content fragment editor. We have some composite components. So again, I’m going to switch back to my content tree here.

Okay, yeah, I’m selecting into one of these and we can see we have this featured services. So this is a content fragment that has references to other content fragments, a few listed out below, but we can also edit those fields in line.

So next to what I wanted to show is the AEM side of this. So let me see, I think I’ve got local host environment open. So if I go to my assets view on local host, I can open up my Secure Bank tutorial example and we can see, as I mentioned, we have got multiple services backed by content fragments with a model that’s essentially aimed at often a specific component type in the headless app or else it could be pieces of content like this.

One thing going back to the hybrid type of use case, I do have a quick example. I need to do a toggle on my local app.

So let me just give me one second. So I’m going to move down the page. So what we have on this page is content fragments. That’s again, the most common headless example we’ve seen in the past, but I’m going to toggle a little Boolean and we can see now I’ve added a section of content that is actually backed by AEM pages instead of a GraphQL, it’s using JSON. So I think I have this page open. Yeah, so I think it actually might be best if I show this in the sites view.

Let’s go back, take a look at my sites. And if I open up, I set up a kind of a homepage path. Now the routing on the app is handled on the React side. I set up a page that corresponds to the homepage. I’ve got that open here. So we can see we have a title component and a text component. I’d like to highlight those are both quite simple components that don’t have a ton of options in the dialogue, but I can go ahead and open up the edit dialogue. So this is that classic, AEM sites page editor dialogue with a handful of fields.

So in part of what I did here is I instrumented my app. Going back to the universal editor, I only so far have exposed a few of those fields. And like I mentioned before, there’s no automatic conversion due to the differences in the technologies used. But if I click on this title component, I can double click on that and let’s just add some exclamation points. If I come back to my page, we’ll see that that content was persisted back to AEM.

Let’s take a look here.

And I think that was a lot of the stuff I wanted to show, but to also, when I click on this, we can see it in the content tree, but I can also switch to the properties of it. And like I mentioned, I moved a couple of the options out of the, I redefined them in the universal editor to be used this way. So I can change the type, I can change the text. I think on the text component, all I have is that rich text dialogue is defined.

Okay, I think with that being said, let’s go back to the slide deck and take a look at some of how this was done and some common technical considerations.

So just a moment so I can switch back to the slides.

Okay, I’m just finding the slide I left off on. Okay, so as I mentioned, we’ll look at some common technical considerations.

So again, this is front end agnostic tooling. So with any web-based technology, we can connect this at the page level and we can mark up the individual components and content to, I’ll get into the detail right now. So at the top level, we instrument the page. There’s a universal editor library that gets connected.

And that involves cross origin resource sharing, commonly known as CORS.

So that’s also part of the setup that you do is the front end lives on a different domain. Within AEM, there’s OSGI settings to allow multiple origins to communicate. I’ve got some good links, I think some tutorials that’ll help with that at the end of the slides.

But once, and also at this page level, you’ll see the second element is a AEM connection that I’ve specified. So we can have multiple connections. It may be hosted on one author instance with edge delivery content, but you have a separate instance. You give it a variable name, and then you can connect to that as well to consume maybe some GraphQL content. And then once we get into the components, I think this is a title component I have a screenshot of, but we can see that AEM connection is specified. We have a dynamic path based on routing within the app, but that’s going to correspond with pieces of AEM content. And then we define, so in this case, it’s a title and the property in the content node is JCR title. The data type is text, the label is title, and we also have a component model. So by defining that component model, it enables that properties rail on the right side with more fields. Let’s take a look. So the component models.json, it’s a separate file. You can also use partials. This defines the fields that you see in that properties rail. We have things like AEM tag, Boolean, check boxes, content fragment, and also I mentioned like that custom assets picker that allowed us to use multiple asset content sources, including dynamic media. So at a high level, not every component is going to need a model definition. Let’s say a container component may not have multiple options. And you also have the ability to put these fields into tabs. There’s various validations you can do. You have conditional logic to hide and show, and I think I need to fix this sentence because it’s incomplete, but I’ll add that link. There’s a nice page that lists out all of those along with screenshots of how they look.

The next piece that we have is the component definitions.json.

This is on the page, included on the page, and it tells the Universal Editor the full list of components or blocks that you’ve defined, and also that definition allows those to show up in the content tree, be able to change the sequence of those elements. And lastly is the componentfilters.json, which defines allowed components within each container. So you may have, again, developers really control the layout.

There’s things you could do to give author selections and select one of those developer-focused templates. That’s especially in Edge Delivery, I’ve seen that, you can develop in such a thing.

But you’ve got sections of pages and you may want to control which components can be placed in those sections. So you use the componentfilters.json.

Some other common integrations, I’ve mentioned a few times assets. So in Edge Delivery, at the folder level within the dam, you have configurations that tell it when these assets get published, content, media bus.

And then in other use cases, so AEM headless, dynamic media with open API, or just classic dynamic media, you can also use either the reference field to select an asset, or else you have that custom asset picker, which I linked to in one of the end slides.

Quarries I also mentioned, it’s using a headless use case, you have multiple domains that’ll be interacting. So you need to set that up in AEM’s OSGI configs, or else if you have GraphQL that is being cached in the dispatcher, then you can set those allowed origins within the dispatcher configs.

Local development, I believe this mostly applies to AEM headless, and if you have some type of hybrid use case using JCR content, I think the development flow in Edge Delivery, you’d typically be using a sandbox, but it’s really quick to deploy sandbox, or like an actual cloud environment as the backend.

But with that being said, so in those applicable use cases that you would be doing local development with the local AEM SDK, you need to set up a few things to be able to interact with the web hosted Universal Editor service. So one of those is that you set up the service on your local machine as part of this development.

I’ve got a link actually in this section of the slide, but essentially you need this in local, but we also have customers who maybe have certain IP allow lists defined that don’t allow you to use the service that’s hosted by 51ºÚÁϲ»´òìÈ. So the documentation also tells you how you can self host that service to do that connection.

Going back to the local use case, HTTPS secure is usually, it’s not always needed on local AEM development, but as you communicate with the Universal Editor, that does need HTTPS. So the local development setup document shows a way to use a node JS local proxy. This can be used on the local AEM stack. And if you have a local application for an end, like React that you’re doing local development on, you can use that same proxy. And that’s shown in the secure bank tutorial, which I showed in the demo.

And then the last piece I wanted to highlight is authentication with the local author SDK. So when using the Universal Editor, you have a different login cookie context. So you’ll see some kind of odd authentication issues talking to that local AEM SDK. So this has evolved over time a little bit, but the best advice right now, and I have a link to it, is there’s a developer login extension that you enable. So when you go to edit that content in the Universal Editor, if you need to, you can click the login button. A piece of that is that on the AEM local SDK, you do need to apply an OSGI setting to allow it that cookie context doesn’t have to be the same site. So you set that to none, and I’ve got a link to a document that shows that OSGI config.

Okay, getting to FAQ.

So what versions of AEM does this support in the Universal Editor? And basically it’s 6.5 and up. So 6.5 LTS, which is the new Java 21 based 6.5.

AEM 6.5 is supported. I think there is a particular service pack you need. And then AEM is a cloud service as long as you’re up to date on the version with that, which most should be since it’s a auto updating service.

Second question, I’ve spoken about this a decent bit, but we have an existing AEM site using the AEM page editor. Should we be moving to the Universal Editor? And to that, the Universal Editor is a re-imagining modern.

It’s essentially it’s decoupled. I don’t wanna say modern like it’s the page editor is not, but the advice is typically the rule of thumb is on those existing AEM sites, continue to use the page editor. It’s got a massive install base. There’s no deprecation date that I’m aware of. So, and I don’t picture it going away anytime soon. So you can continue using that page editor.

Plan to make the switch when implementing one of these new architectures, or maybe it’s time to do a major update to the site. Maybe you wanna realize the benefits of a new architecture, but it’s not a de facto choice that you should just be switching over.

Another question, we have an edge delivery site that’s using the document based offering. We didn’t talk about that in this session, since it’s kind of out of scope, but if you’re using SharePoint, Google Docs to maintain that content, can we switch to the Universal Editor? And the answer is yes, it’s possible. The specifics depend on whether you’ll be moving to AEM author based or da.live, which I mentioned before document offering, that’s an early access technology built specifically for edge delivery service. So my best advice on the specifics, I don’t have a document to link to, but there’s an AEM community that’s quite active that I linked to. And then also if you have the edge delivery license in cloud manager, there’s a way to request a channel to talk with the product team. So I think to get the latest advice on steps, I would connect to one of those channels.

Okay, next question, going back to the AEM spa page editor being deprecated, what do we do now? I linked to the documentation, there’s a spa editor deprecation page, which contains technological comparisons and some considerations of that.

To boil it down as simply as possible, that page states that deprecation does not mean immediate removal in existing projects, you can continue to use the spa editor as long as it’s meeting your needs. And they do talk about specific support levels on that page.

Okay, I touched on this in the slides, but what’s needed to use generate variations and according to the documentation that comes with the edge delivery services, AEM cloud service license, I would say that’s possibly subject to change. If you have questions, talk to your 51ºÚÁϲ»´òìÈ account team.

Any limitations, does the universal editor have any limitations compared to the page editor? So again, it’s not intended to duplicate all the page editor functionalities with examples being editable templates and style system. They do have some specific limitations documented, which I linked to on the slide. There’s a limit of 25 AEM page resources on an individual page that deals with publication. A lot of reference checks can cascade. So that’s the recommendation. And there’s also at this time limited MSM support for content fragments specifically. So there’s MSM extension that within components, at the component level, you can handle and heard and saw an MSM live copies, but at this time, content fragments don’t have that full support just yet. So last FAQ item is can I use the universal editor on a traditional AEM sites project with CQ components and Sling models? Again, it’s possible to instrument that. It’s a decent bit of conversion and maybe rethinking some content structures. So there’s no automated conversion and there’s no plan as of now to update the core components for this use case. So the recommendation is, I know I don’t have difficulty imagining hybrid authoring use cases and potentially even a microsite that you wanna test out with the universal editor.

It’s absolutely doable, but the rule of thumb again is to on new projects using one of these new technologies, that would be the best time.

Okay, and then I’m gonna go ahead and jump to the references just kind of high level. We’ve got universal editor documentation, edge delivery documentation. I would say if you want just a quick tutorial to get this running on a sandbox and then test it out, the edge delivery boiler plate that I linked to. Yeah, that’s that third item, that UE tutorial, that is the quickest way to get something going and check out the new editor. I also linked to the Secure Bank sample app, that tutorial I mentioned before, getting started with the universal editor for AEM developers.

It’s a quick start if you already have AEM set up. Yeah, and then I mentioned on a previous slide, the model definitions, fields, component types of the UE.

That’s a great document, but we won’t go one by one.

That’ll be available in the deck that we send out. And with that being said, thank you for spending this time with us and I hope this has given some clarity on this new editor. Thanks.