Workspaces is revolutionizing Drupal Core: Unlock True Enterprise Content Management in Drupal

[00:00:00] All right, let's get started everyone. We got a lot to cover and uh I will be channeling Fabian Franz.

[00:00:12] Um welcome to our enterprise content management um in Drupal with Workspaces talk. Um I'm Peta Hoyes. I'm the chief operating officer. Sorry.

[00:00:24] Into the mic. Into the mic. Into the mic. All right.

[00:00:27] Um I'm Peta Hoyes. I'm the chief operating officer of Tag One Consulting.

[00:00:32] Um I found my way to Drupal a little um via engineering product design and

[00:00:41] wanting to make technology uh very transparent to what I call fuzzies uh

[00:00:47] artists and musicians and writers. Um, back in 1993 when the web wasn't a

[00:00:55] thing, um, I used the Bolton board software, uh, to create a wide area network, um, for to connect people. Um,

[00:01:05] basically I had a wall of haze modems and a T1 line coming into a Brooklyn brownstone.

[00:01:12] Fast forward about 15 years.

[00:01:15] What I realized was that I was actually creating social networks, which I didn't know what they were at the time.

[00:01:25] While I try not to live in regrets, I do get serious twitches from time to time.

[00:01:33] Around 2008 though, Drupal got on my radar when I started working with Nat Catchpole at Civic Actions.

[00:01:42] Catch introduced me a few years later to Jeremy Andrews and Ryan Newton at Tag One Consulting.

[00:01:50] We've continued making waves ever since then, especially in the Drupal performance arena. I'm joined today by

[00:01:58] one of my colleagues, Ray Stewart, who will be presenting for Fabian Franz,

[00:02:06] who's TAG 1's VP of software engineering.

[00:02:10] He's recovering from the flu unfortunately and couldn't be here. So, we're going to do our best to cover for him.

[00:02:19] As you guys know, Drupal is a D7 maintainer and core committer and he's been developing content preview system

[00:02:27] CPS um the D7 predecessor to workspaces since 2014.

[00:02:37] He's been guiding the development of workspaces for the last three years in pursuit of feature parody with CPS.

[00:02:45] Now, Ray Stewart, he's a senior technical lead at TAG 1 and is an avid outdoorsman.

[00:02:52] We happen to both be Jamaican, by the way.

[00:02:56] And like the Jamaican bobsledding team, we kind of just do it, do anything just because.

[00:03:05] and we go for the gold.

[00:03:08] Ray's expertise centers on back-end architecture and development with front-end capabilities. He specializes

[00:03:16] in what he considers moving as moving data around in ways that create meaningful impact.

[00:03:23] Since discovering D Drupal around 2007, Rey has built his career on the platform, developing a particular

[00:03:32] appreciation for teams where each person contributes meaningfully to the complex engineering challenges.

[00:03:40] That is TAG One in a nutshell.

[00:03:43] If you're not familiar with TAG1, we're a global technology group that focuses on using open source software to solve

[00:03:50] very difficult problems for a lot of difficult difficult to different clients. Um, we work with a lot of

[00:03:58] different technologies, but we're best known as the number two all-time contributor to Drupal. Since 2001, our

[00:04:07] team has created many of the innovations that have fueled Drupal success, such as the taxonomy system and migrate API. If

[00:04:15] you use Drupal, and I'm pretty sure you have, um, every time you update a Drupal site, we manage the infrastructure of drupal.org.

[00:04:26] um and uh this and basically the tooling and uh use to build test and release Drupal on behalf of the Drupal association and its community.

[00:04:38] So what do we mean by true enterprise content management?

[00:04:44] Since TAG one was founded, we've worked with a lot of enterprise organizations

[00:04:50] over those last few decades. We've helped many grow their websites from something basic to a critical part of their business.

[00:05:00] As those websites have become more and more important, the most successful enterprise companies have expanded the

[00:05:08] role of their CMS from a tool that helps them manage their website to one that's also a key element of content governance.

[00:05:19] If content governance isn't a familiar term or concept to you, it's a term that refers to all of the various things from

[00:05:28] procedures to technology that a complex organization needs to make sure its content meets its standards and requirements.

[00:05:38] Anyone who works for or with large enterprise organizations knows that that's no small feat.

[00:05:47] There can be a lot of content stakeholders with diverse concerns from brand marketing to legal compliance.

[00:05:54] That's a lot of cooks in the kitchen.

[00:05:57] Strong content governance is what hopefully stops all of that from devolving into chaos.

[00:06:04] So for CMS to truly meet the requirements of an enterprise content management, it needs to provide the tools for both creating content and

[00:06:13] managing the end toend governance of that content. Drupal has been working towards this in core for a long time

[00:06:20] now. From early features like granular user roles that let enterprise teams effectively control permissions and

[00:06:29] access to incorporating tools like workflows and content moderation in D8 for managing the content of publishing life cycles.

[00:06:39] And with the adoption of workspaces and core, we've closed another major governance gap where Drupal has lagged

[00:06:46] for some time now. Content staging and review in the CMS.

[00:06:52] Let me explain why that's more important than ever.

[00:06:56] In our modern age of com com composable content and visual page builders, a lot

[00:07:03] of enterprise websites have gone from looking like this to more like this. These are types of

[00:07:11] sites we've worked hard to make Drupal great at building.

[00:07:16] Content is coming from a bunch of different systems. It's highly designed and dynamically laid out in the CMS with

[00:07:25] edits and updates automatically propagating all over the site. But here's the catch.

[00:07:34] Those types of critical large-scale updates that Drupal does so well, things like adding new products or services,

[00:07:41] migrating in a new department, those are notable visual changes. They impact navigation and views and blocks throughout the site.

[00:07:51] And because of that, the governance of those changes, the reviewing of things like brand consistency, legal compliance, accessibility, whatever

[00:08:00] really need to happen in context of the overall site with all the pieces of the puzzle present. Until now, Drupal hasn't

[00:08:09] had a great solution for that kind of content staging. its required workarounds and compromises. Things like the content staging site.

[00:08:21] The content staging site is of course a duplicate of your production site where content managers can stage all of their

[00:08:29] changes without dup disrupting the live site. Sounds great in theory and a lot of you are using them for enterprise websites, but it's time to say goodbye.

[00:08:41] Here's why.

[00:08:43] That staging site requires a duplicate codebase, database, file system that has to be maintained. Often that means a

[00:08:52] whole other file server that requires ongoing maintenance.

[00:08:58] Keeping it in sync with your live site probably means complex CI/CD pipelines and build workflows all need to be used.

[00:09:08] Sure, I get it. We're all working in the cloud.

[00:09:12] our DevOps teams or our favorite manage platform has a lot of stuff set up for us. But getting all that stuff set up, keeping it up to date is time consuming.

[00:09:23] It's expensive. And for what?

[00:09:28] Staging infrastructure often doesn't have resources equal to production, which introduces concerns when it comes to things like performance testing.

[00:09:39] But okay, we're enterprise drupalists.

[00:09:43] We're comfortable with DevOps coding, config management. What needs to be done? What about the impact though on the people who need to manage the content?

[00:09:53] External staging sites mean content managers need to work in two or more different places.

[00:10:02] Why more?

[00:10:04] Well, what happens when you need to be staging more than one set of updates at a time?

[00:10:11] More staging equals more problems.

[00:10:14] I know the build tubes can probably handle it, but do you know what most content managers don't love? Remembering

[00:10:21] which subdomain that's autogenerated from the git branch ID is the only one they're supposed to be updating.

[00:10:29] But even if that doesn't convince you, the hardest part and the part you've been waiting for me to get to this entire time,

[00:10:38] you need some way to get the content from one site to another.

[00:10:44] Content deployment across systems is rife with opportunities for failure.

[00:10:50] Remember, we're not talking about version controlled code.

[00:10:55] We're talking about rows of data from multiple tables moving from one database to a second completely unrelated database and that is always risky.

[00:11:09] There have of course been numerous attempts to overcome this in the Drupal community over the years. I'm certain I'm not the only one who remembers and

[00:11:17] still has nightmares about the features module and long lists of overridden mistakes.

[00:11:23] Seriously though, drupal.org's documentation has a page that compares 50 content deployment modules and there

[00:11:31] are also a number of external systems that tackle a problem. Some of these solutions are quite good. But to be

[00:11:38] clear, no matter what, content staging servers are costly,

[00:11:46] complex, very inconvenient, and very risky way to work around Drupal's historic limitations and workspaces.

[00:11:57] It's incorre.

[00:12:09] Okay.

[00:12:14] So uh you've heard about uh all these capabilities the atomic publishing full-sight preview zero overhead on

[00:12:23] production uh which might sound complex to set up it's not really uh workspaces is now built into Drupal core uh getting

[00:12:32] started is uh one command that many of us are familiar with uh drush enable workspaces and you're done mostly as

[00:12:41] with a lot of Drupal mostly uh But no, you have uh what's in core and you also have WSE. WSSE is Workspaces Extra. Uh

[00:12:51] since uh Drupal 10.3 in June 2024, Workspaces is stable and fully supported. Uh it ships with every Drupal

[00:13:00] 11 installation. Uh and you now have enterprise content staging that rivals Adobe Experience Manager and it's free

[00:13:07] and open source. Uh but you really want also workspaces extra uh which WSE

[00:13:15] uh core workspaces is git branches for content. WSE is like the full CI/CD pipeline uh that you have for your code.

[00:13:25] Uh you have scheduled publishing, preview links for external stakeholders, roll back capability, access control,

[00:13:32] menu staging and task monitoring. Uh plus WSE config lets you stage configuration changes alongside content.

[00:13:43] Uh installing WSE um is also should be very familiar to many of us now which is just a composer require uh Drupal WSSE.

[00:13:53] Uh and that's pretty much it. Um it's a pretty low barrier to entry and enterprise capability out of the box.

[00:14:06] Workspaces in a state is a staging site.

[00:14:09] So traditional staging servers cost as much as production. Uh separate infrastructure, databases, certificates,

[00:14:16] you typically typ typically get one maybe two environments and workspaces eliminates all of that or can eliminate

[00:14:23] all of that. Uh uh when you preview a workspace, you see the entire site as it will appear when it's updated and live

[00:14:32] uh and published. Uh views, listings, navigation menus, entity references, everything reflects your stage state. Uh

[00:14:41] your workspace changes layer transparently on top of the live site.

[00:14:45] Uh uh it's a complete context and automatic.

[00:14:49] Uh you get enterprise features uh out of out of workspaces right from the get-go.

[00:14:54] Uh unlimited workspaces uh design, content, translation and legal teams uh whichever teams you have can all work in

[00:15:02] parallel. Each workspace is isolated with granular permissions. Content moderation integration uh which is

[00:15:09] somewhat in development but but ongoing uh gives you entity level workflow states with atomic publishing and schedule p schedule publishing roll back

[00:15:18] external preview notifications all within one Drupal installation. Uh zero infrastructure cost zero overhead on

[00:15:25] live traditional stage is infrastructure whereas workspaces is architecture.

[00:15:33] Now most of us here know git. Uh if you do uh then you you pretty much already understand workspaces. Uh the workflow

[00:15:41] is uh identical to working on a feature branch and then merging to main. Uh the difference here is content. So in git uh

[00:15:49] you create a branch where changes accumulate. Uh you switch between main and your branch to see uh the complete

[00:15:56] state. Uh then merge atomically. The the parallels are are fairly exact. A workspace is a content branch. Live is

[00:16:04] main. Publishing is merging uh your staged content. Uh your repository is

[00:16:11] your site. The mental model is is is pretty identical.

[00:16:17] Uh developers take branching for granted. Uh content editors face a similar problem. uh coordinating related

[00:16:25] changes, but they've been stuck with per item drafts and manual coordination until now.

[00:16:32] Workspaces doesn't implement automatic merging uh that leads to data corruption uh with structured content. Instead,

[00:16:40] teams should coordinate via communication uh shared workspaces for collaboration and for clear content ownership. Your workspace will never

[00:16:48] contain content that you didn't put there.

[00:16:53] Uh here's uh uh kind of a direct mapping of of comparing workspaces and git. Uh the repository equals the Drupal site.

[00:17:02] Uh git branch equals workspace. Uh the main branch equals uh the main branch in git equals the live workspace uh in

[00:17:12] Drupal. Uh a commit equals a save. Uh a working copy equals workspace preview.

[00:17:19] uh emerge equals publish.

[00:17:23] Uh the workflow is is identical. Create a branch for your feature, make commits, preview the complete state, get

[00:17:31] approval, merge to bane. Uh in workspaces, it's create a workspace for your campaign, save changes, preview the

[00:17:38] complete site, get approval through content moderation, and then publish.

[00:17:44] Developers already know this workflow intimately. content content teams just haven't had uh the tooling until now.

[00:17:53] Branches aren't just for de developers.

[00:17:55] Anytime you need to coordinate multiple related changes, preview them together and deploy as a unit, you need branching. The the architecture that

[00:18:04] powers git, isolated workspaces, atomic merges, zero cost on maintain, the same architecture powers workspace workspaces.

[00:18:12] Uh and you can say if your dev team uh wouldn't ship code without branches um then why why would your content team ship content without workspaces?

[00:18:24] Uh workspaces is built for content teams uh that are coordinating multiple related changes. Uh so large organizations where departments work in

[00:18:32] parallel uh let's say marketing legal design content uh teams uh campaign launches where articles media navigation

[00:18:40] and landing pages must deploy simultaneously uh what's the common thread full-site content preview. If you've ever had a landing page go live

[00:18:49] before its menu length you need workspace.

[00:18:53] Uh who it's not for? Uh here's a surprising answer. No one is

[00:19:00] excluded from using workspaces. Content moderation will use workspaces soon. Uh there's one issue left uh in court to

[00:19:06] deal with that. Um and there's an issue uh there is an issue with updating the content to the multiple workspaces. Uh there is a parallel workspaces module to

[00:19:15] help with that. Uh but there is also an issue that will help fix this in core as well.

[00:19:23] Uh workspaces has a fundamental uh principle. Um it is uh it's a boundary

[00:20:00] production. When the active workspace uh is live 100% of the which is 100% of the time for anonymous users uh the workspace system is literally invisible.

[00:20:10] Your st your staging work cannot affect production performance.

[00:20:15] Uh form submissions within a workspace are prohibited. Uh they trigger irreversible side effects like um uh sending emails or processing payments.

[00:20:25] Uh, you can stage content, preview layouts, test navigation, but can't accidentally trigger real world

[00:20:32] consequences. Nonworkspace safe entities that don't support revisions simply can't be modified in a workspace. The

[00:20:39] system enforces architectural safety at every level. Uh, now the uh how about performance?

[00:20:48] Uh, this is workspace's most important architectural property. uh zero overhead on the live site when the active workspace is live 100% of the time.

[00:20:58] Again, for anonymous users, uh the workspace system is literally invisible.

[00:21:03] So, your production site performs exactly as if workspaces didn't exist.

[00:21:09] Uh this makes workspaces viable on the highest traffic production sites in the world. Content staging systems that add

[00:21:18] overhead to every page load get disabled. Workspaces was architected from day one in CPS in 2014 uh to have

[00:21:27] zero impact on live traffic. That's why it's been running at Alexa top 500 companies for over a decade

[00:21:35] inside a workspace. Yes, there's overhead uh but that's generally uh editorial traffic uh which will be a tiny uh tiny fraction of your load. Uh

[00:21:43] you will see a slight um uh decrease in performance with workspaces because of the additional overhead. Um but the

[00:21:50] editors get a full site preview uh and get uh visitor while the visitors are getting the full production speed.

[00:21:59] The most common question is uh what happens when two people edit the same content in different workspaces?

[00:22:10] Uh the answer is simple and deliberate.

[00:22:12] Uh you can't and this is the right design. Now uh there is work as I mentioned with parallel workspaces to uh

[00:22:20] improve on this uh and also in core um and also uh there's no automatic merging

[00:22:28] uh that happens uh within workspaces uh that it's really up to the team to communicate those changes um and uh to

[00:22:35] merge to to manually merge those conflicts later on. Uh when an entity is modified in a workspace, uh it's tracked

[00:22:42] there. Uh another editor can't modify it in a different workspace. Uh this isn't a limitation exactly. It's a feature. Um

[00:22:50] automatic merge of structured content fields, entity references, media relationships, uh that could lead to

[00:22:57] data corruption. So um every system that's attempted, it has encountered fundamental issues. So especially when you're talking about config, you'd want

[00:23:05] to be careful with those merges. Uh, workspaces takes the same approach as a well-run dev team. Coordinate via

[00:23:12] communication. So, shared workspaces let teams work together. Content ownership keeps responsibility responsibilities

[00:23:20] clear and WSE workspaces extra lets you move content between workspaces when needed.

[00:23:30] The absence of automatic merging in that regard is a safety guarantee. Your workspace will never contain content that you didn't put there.

[00:23:42] Uh because workplace workspaces are conflict-free, scheduled publishing is

[00:23:48] actually safe. So WSCuler lets you set a date and a time. Your workspace publishes automatically at 2 a.m. on launch day, for example. Uh the workspaces contents are deterministic.

[00:24:00] What you reviewed and approved is exactly what goes live. No surprises. uh in a mergebased system you couldn't

[00:24:07] guarantee what state the content would be in at deployment time. Uh roll back is guaranteed to work uh because the

[00:24:15] workspace is an atomic unit. Uh WSC's roll back feature can revert an entire published workspace. Uh undo the

[00:24:24] complete deployment. Uh there's a clean boundary. These specific changes uh came from this specific workspace. No

[00:24:31] ambiguity about what to undo. uh revert the workspace and you're done.

[00:24:38] And conflict free means correctness to some degree. Uh what your editor reviews is what is published. What your legal

[00:24:47] team approves via preview link is what goes live. Uh no merge during during deployment, no conflicts introduced during review.

[00:24:57] Now uh the deletion problem and solutions. Uh deleting content in a workspace creates a challenge. Uh the

[00:25:06] content needs to disappear from uh the workspace preview but remain visible on the live site until you publish. Uh trash solved this elegantly with a uh deleted field using a a turnary state.

[00:25:19] Uh essentially uh the values greater than one are Unix timestamps of actual deletion. Um and th those are subject to

[00:25:27] garbage collection as well. Um uh one means draft in a in a workspace not yet published and zero means live and visible.

[00:25:35] When you delete content within a workspace, the entity remains live in the main table with deleted equals zero.

[00:25:42] But the workspace revision marks it as deleted. Within the workspace, that content disappears from listings, views,

[00:25:49] and search results. Uh on the live site, it remains visible until you publish.

[00:25:55] Content deleted in a workspace is recoverable until you publish. Uh and this

[00:26:02] integration removes the uh the constraint. Any entity type can now participate in workspaces,

[00:26:10] not just those with publication status, by the way.

[00:26:16] Uh workspace and workflows. Uh workspaces integrates cleanly with with Drupal's uh core workflows module. Uh

[00:26:24] you can move an entire workspace through workflow states draft, review, approved, published, for example. Uh the entire

[00:26:32] collection of changes moves through the approval process as a unit. Uh your legal team reviews the complete workspace for example and your content

[00:26:40] manager approves the entire set and when it reaches publish state, the whole workspace deploys a auto atomically.

[00:26:48] The simple the simplified content workflow initiative makes this uh even better. Um uh when those final issues land uh it

[00:26:57] will um make content moderation and workspaces work work together seamlessly for complex scenarios where different entities need different approval paths.

[00:27:08] Entity workflow uh entity workflow module contrib module provides entity level workflow granularity within a workspace context. Most sites won't need this uh but the capability exists.

[00:27:24] Uh now beyond content entities, uh here's where workspaces becomes truly revolutionary. Uh up until now we've

[00:27:31] talked about content entities, uh nodes, media, taxonomy terms. Uh but what about configuration? Uh block placements, view

[00:27:40] configurations, theme settings, site title, field definitions. Uh WSC config is bringing all of that into workspaces

[00:27:48] and it's almost production ready. Uh with WSC config you can modify a view for example within a workspace and

[00:27:55] preview it uh change sorting and filters all stageable all previewable block placements menu settings layout

[00:28:03] configuration site settings everything that's normally configuration management export import workflow uh can now happen within a workspace. Uh there are some

[00:28:12] limitations that I I can't talk about right now. I'm not I'm not sure exactly but there are some limitations but it's almost there. uh you add WSE theme and

[00:28:20] and you can preview an entirely different theme. Want to test a major visual redesign? Stage it in a workspace, preview it with real content,

[00:28:29] get stakeholder sign off via WSC's preview links, then publish the entire redesign atomically.

[00:28:40] Configuration staging within workspaces closes one of the last remaining gaps between Drupal and the most capable proprietary CMS's.

[00:28:52] Uh and now like AI is uh everybody's talking about AI and uh no difference here. Workspaces is the perfect AI

[00:29:00] sandbox. Um AI content generation is scaling rapidly. The Drupal AI module integrates

[00:29:08] uh 48 plus um AI providers with uh automators that bulk populate fields, generate summaries, translate content.

[00:29:18] But AI is non-deterministic. It hallucinates. Uh it will produce errors.

[00:29:23] So how do you use AI at scale safely? Uh workspaces provides the natural architecture, the side effect boundary.

[00:29:31] Think of a workspace like a a pure function. Everything inside is safe, reversible, no side effects.

[00:29:39] Uh, and AI can generate content, edit fields, restructure pages, populate entire sections, all inside a workspace.

[00:29:46] But nothing touches live, completely reversible. Uh, publishing uh is IO at that point. That's when content gains irreversible real world effect.

[00:29:59] Uh the human uh however you still want the human in there to verify everything, right? So uh the human can verify everything within the workspace uh before it's uh published to live.

[00:30:12] And the the diff in the workspace uh will uh will help you to accomplish that.

[00:30:23] Now uh workspaces uh as I mentioned is stable in core uh since 10.3 and it ships with uh every Drupal 11

[00:30:31] installation. Um it's no longer experimental. Uh it's core infrastructure. Uh so it's say it's safe to use them. Uh your sites can benefit

[00:30:40] from it now. Uh but here's what we need from the community. Uh this is the X uh testing uh real world testing on

[00:30:49] production projects. Try it with your contrib modules. Uh test it with custom entity types. Uh report bugs when you

[00:30:56] find them. Uh like any complex subsystem, there are edge cases. Uh every bug report makes it better. Every production deployment proves the

[00:31:04] architecture. Uh the people who built this have been running in production since 2014. Now it needs the community.

[00:31:13] Uh this matters urgently. uh AI uh workspaces isn't just nice uh to have for AI integration. It's almost a

[00:31:21] must-have. Uh AI content generation is scaling now, but with the problems with, you know, hallucination and uh you know,

[00:31:30] you you could really use a sandbox and workspaces provides that sandbox for your AI content generation.

[00:31:40] Okay. So, now we're getting into uh demos. Uh I'm going to

[00:31:48] start up a couple videos that we have here and I'll try to talk over them. Uh Fabian couldn't be here, but uh we have

[00:31:56] um couple of items that would be helpful to see. Let's see.

[00:32:08] So this is uh we're sw this is an example of switching into a workspace

[00:32:15] and uh we're looking at some content and editing uh various aspects of it including uh the title

[00:32:24] uh and the body content uh and this is the stage uh workspace.

[00:32:37] Now we're going to save that content in the stage workspace. So now you can see that even better uh is the change that

[00:32:45] we made to the title. So we're looking at that in the stage workspace. Once we switch back to live, then you see that it switches back to super easy, which is

[00:32:53] the original title. Uh back to the stage content type. And now we're going to uh edit the content again and change a few more items.

[00:33:05] Uh we're adding some we're updating the taxonomies and we're going to change out um an image.

[00:33:20] And we're also going to change some content in a multiple uh text field.

[00:33:35] And maybe most importantly and interesting, we're going to change the URL alias uh for this item as well. And

[00:33:43] so you'll see even- better as part of the alias.

[00:33:50] Uh it's hard to see, but you'll up in the URL bar there, it's even better as the alias. And you'll see that the uh

[00:33:58] contents have been switched out. Uh the image has been switched out and uh as well as the terms that we had in there.

[00:34:05] Now we're going to switch back to live.

[00:34:07] And you'll see that the the URL has switched back to the original URL. Uh and the image has been switched back as well, which are the easy visual marks.

[00:34:18] Uh now we're going to switch back to the stage side and we're going to go to

[00:34:24] layout. This using layout builder. Uh so now we're going to make a change here

[00:34:31] which is uh we're going to move some blocks around. We'll put the ingredients on the right and the uh directions on the left.

[00:34:45] And then we'll save that layout. And then we're still on the stage workspace.

[00:34:49] So you see that ingredients is on the right. Uh we'll switch back to the live works work workspace and you'll see that

[00:34:56] ingredients is on the left and back on the right again in the in the stage workspace.

[00:35:10] Now we're going to update uh a block and edit some of its configuration.

[00:35:17] We're going to change the uh the title there text field and we're also going to

[00:35:24] change the uh the the URL alias alias that we're pointing to

[00:35:32] and also changing out an image within this block as well. So keep in mind this isn't just um node content. It's uh

[00:35:42] entities many entities site wide any many many content entities site wide. So now we're in the stage

[00:35:50] workspace and we're switching we're going to the uh the workflow

[00:35:59] management. You can see what the the changes that are staged. And in that edit menu you can see you can move to another workspace um translate etc. So

[00:36:06] you have some functionality with of workspaces for the individual content items. Now we are publishing uh the

[00:36:13] content and you'll see that uh the changes are uh now applied in the live workspace.

[00:36:28] Okay. Now, we're going to create a a new workspace, a blog workspace.

[00:36:37] And uh this is going to go through and it's going to create um a number of uh

[00:36:44] blog content items uh relatively quickly. Uh it's going to be sped up here.

[00:37:09] So, we've created a number of items and it's all in the blog workspace that

[00:37:16] you can see in the upper right. And now we're going to go to uh menu items uh which is always interesting to uh figure

[00:37:24] out when deploying uh new content and new new menu items.

[00:37:29] It's creating a uh I think it's nutrition blog. Yeah, nutrition blog.

[00:37:35] This is when you realize that you kept on your computer glasses and not your distance glasses.

[00:37:42] Um okay.

[00:37:46] And so in the blog workspace, you can see that the nutrition blog menu item is there and takes you to the correct place

[00:37:52] where you would expect to be taken. Um, and go back to the homepage. We uh switch back to the live site and you'll

[00:38:01] ee that the uh nutrition blog menu item is no longer there.

[00:38:11] Switch back into returns.

[00:38:16] And you can see everything outstanding at a glance what is what is outstanding in in this uh workspace. And now it's going to publish uh the blog workspace.

[00:38:25] Uh it's published. It automatically uh directs to live and um the nutrition blog is now there. Uh you haven't done

[00:38:34] anything particularly uh special in order to make it happen. Um it's just there.

[00:38:42] Okay.

[00:38:50] Now, we have another video that I'll play here.

[00:38:59] Um, we've just And this one,

[00:39:08] I used a little AI, just a small one, um, make the size a little bit more.

[00:39:17] Oops.

[00:39:25] Okay. So, this one is uh is using the umami theme, but it's been replaced, as you can see, with lots of Drupal cons for Drupal Con.

[00:39:34] And uh we have everything in a uh in a workspace. I keep wanting to call it change set from CPS.

[00:39:54] And this is content that was created by an AI agent, for example. Uh we're not demoing that today, but uh this content was created by uh an AI agent and um

[00:40:04] just replaced lots of content uh in the site with with Drupal Con essentially and replaced a lot of terms on the site with Drupal uh Drupal Con. Uh so it's

[00:40:13] it's sort of AI going rampant uh in a sense. Um when you are uh looking at uh

[00:40:21] the the workspace uh you can see you know what's been changed what's existing uh in your AI agent workspace lots of

[00:40:29] changes currently existing in there and you'll see that lots of media images

[00:40:38] uh but you also have configuration updates uh listed in the bottom as well uh that's using WSC config

[00:41:04] Okay.

[00:41:06] And the the important thing to uh to witness or to uh realize is that it's just content that has been uh majorly

[00:41:15] updated. Uh that's a view that's been updated as well. Um uh with uh additional configuration in the uh in

[00:41:24] the change set in the workspace and uh this is showing where the change is happening uh for that.

[00:41:35] Okay, we have one more. Oops.

[00:41:56] and this one.

[00:42:05] Okay, so these are changes uh that we're putting in uh for the

[00:42:12] uh edits again that we're putting into uh content in the title and in the uh uh descript or the body.

[00:42:29] And this is moderated content. This change is moderated content. Um so this change was put in uh it's moderated content and then um it's been

[00:42:38] essentially imported into uh a workspace using what we're calling virtual workspaces uh at the current time. Um,

[00:42:46] so it's like using normal uh content moderation uh but now it's being imported into a virtual workspace. So

[00:42:53] you can imagine all these disperate changes on your site uh that were made with content moderation and then bulked into a uh virtual workspace.

[00:43:07] So uh yeah, we've talked a lot about workspaces and seen some cool demos. Um uh but in summary uh it's stable and

[00:43:16] it's in core. Uh it's fast and simple to use. Um it's the perfect AI sandbox and a and a must-have for a safe AI

[00:43:25] integration. Um it'll provide seamless support for content creators. um and has uh enterprise support for content uh

[00:43:33] workflows and governance and and again yeah so we need you uh to

[00:43:44] uh start using it uh workspace is stable it's ready uh test it use it report what you find uh the AI age needs this

[00:43:52] infrastructure now and I think we have some maybe have some time for questions

[00:44:06] Okay. Any questions out there? Right there. Canvas. I'm sorry. Heard a lot about Canvas.

[00:44:14] Canvas.

[00:44:15] You've heard a lot about Canvas. Uh you've heard a lot about canvas. Does it work with Canvas? Um I I would say I'm not sure. Uh but I believe that it it's

[00:44:24] it's a little bit different implementation and I think it's going with layout builders versus the canvas approach. I don't know enough about canvas uh to talk about that um specifically. Is Chris here.

[00:44:37] Okay.

[00:44:38] It will that is what it will.

[00:44:42] Yes, it will.

[00:44:43] What I have we've been discussing the last couple of days. But yes, it will.

[00:44:48] Okay. Any other questions back there?

[00:45:04] Uh the question is if you have a CDN or varnish cache, will it work with that or does it need something extra? Did I get

[00:45:10] that right? Okay. Um the it will work uh like in terms of your anonymous content

[00:45:17] uh that's going out. it's it's there's no change to your anonymous site usage.

[00:45:22] Um, in the same way that uh you're not likely to have a lot of that enabled for your uh content editors, um it it it'll

[00:45:30] work in the same sort of way. So, um as long as you have that set up and appropriate for your content editors using the site, then it should work. It should work fine.

[00:45:40] Sure. Right back there.

[00:45:44] How do you deal with uh giving permissions to you don't want to give any other permissions to observe the work is happening work.

[00:45:53] Uh the question is how do you deal with permissions uh to users that you do not want to see uh or or do not want to see

[00:46:01] happening in workspaces work going on there?

[00:46:03] Let's say I want to have someone review it before we publish it. How do you can you control the permissions for public otherwise anonymous?

[00:46:13] Got it. Yes, you do have uh so uh do you do you have can you give permissions or how do you deal with permissions uh for

[00:46:21] pages that you might want to send uh that would be for anonymous users to review? Okay. Um, so in that case, uh, I

[00:46:29] don't know enough about this, but I believe that there is preview functionality that you can send for reviewer links. That would be, um, I'm

[00:46:37] not sure if they would be, uh, that's right.

[00:46:41] That is right. That would be for anonymous users uh, to to click on and use.

[00:46:46] So you can share the preview link and in the permissions you have to select which users can access the preview. So that so

[00:46:54] basically what people do is create a new role specifically to trigger this and then just assign them permission share

[00:47:02] the link and that okay uh so uh did you catch some of that?

[00:47:08] Okay. So uh essentially you would uh uh prepare roles uh for users and uh create

[00:47:15] preview links that would then be applied for those users as well. Um would that work for anonymous as well? Yep. And that works for anonymous as well.

[00:47:24] Okay, any other questions? Yes.

[00:47:27] Yeah. Question about the static files that you uploaded inside the workspace.

[00:47:33] Is it available then if it's public to users that know the URL?

[00:47:40] Okay. So static files that are uploaded within the workspace are is that um available to uh users if they if anonymously if they know the URL?

[00:47:51] Okay. Uh I believe that that would be caught by Drupal in any case. However, um well, I'm not entirely sure about that. Static files uploaded in the workspace.

[00:48:01] Yeah. So I upload a new image. Yeah.

[00:48:03] It's like one JPEG and then somebody just goes anonymously to sites default

[00:48:09] files one. Will they see it? I think in the case of an image, so uh if if an image for example is uploaded to Drupal

[00:48:18] and that that file exists at a a static URL at that point kind of um would it be seen for somebody that knows the URL? I

[00:48:25] believe that Drupal would catch catch it in that case. Uh like uh if you're uploading a file to a workspace, it's

[00:48:33] still going to be covered under Drupal security and and features. So if you have it so that it's uh generally open to the world, then it would be would be

[00:48:41] seen. But um uh that should be caught by Drupal and Workspaces permissions I believe. Anybody know the answer to that specifically?

[00:48:50] Not sure. Okay. Any other questions? Right back there.

[00:48:59] So for for changes like the demo for views, how does that how does that interact with like the configuration

[00:49:07] export system? Does it like exclude those views?

[00:49:15] That's a good question. So the question was with the uh config with the WSC config that we showed for example the

[00:49:21] changes to config um that were in the demos uh does that how does that interact with the uh configuration import and export uh system in Drupal?

[00:49:32] Um straight up answer is I'm not sure.

[00:49:35] However, what I imagine would happen is that is that once it's uh once it's published, then you would have the

[00:49:42] ability to then export that uh to configuration in the same way. Uh that it wouldn't be um uh that whatever is in

[00:49:50] the live would be what would be exported. Uh however, that's a good question. Uh and I and I'm not 100% sure on that answer, but that's sort of what

[00:49:58] makes sense to me based on what I know there. Um, and so I think that's a that's an interesting question though because we use configuration import and

[00:50:05] export for a lot of things but um this might be a case where um uh for a lot of sites that are not necessarily using configuration import and export that are

[00:50:13] handling their configuration directly on the site and not necessarily exporting it to code all the time.

[00:50:20] You know followup question if I created the workspace and then after I did some changes to view for example and then in

[00:50:28] the live workspace I did configuration import already from view changes how then it will know what's what is the map

[00:50:37] now you're getting into different territory territory here so you're talking about the question is uh the configuration

[00:50:45] um uh if you import configuration Let's say before you publish a workspace, how does it know uh what the

[00:50:52] changes are? Um and I think at I think at this point the uh the answer would be

[00:50:59] that the configuration that is in the workspace would I believe override the configuration that was imported.

[00:51:08] However, I'm not sure if there would be a flag telling you that that that has been changed uh at some point.

[00:51:15] Yes.

[00:51:17] So similarly when you were talking about the the content free um aspect of content editing like let's say you have

[00:51:25] a a new section being added or a new campaign you created a workspace and then you also need to keep minor updates

[00:51:33] going on you might want to u you're doing a separate workspace your live workspace. So is it the workspace extras

[00:51:42] that allows you to pull in let's say you're making changes directly live in a campaign workspace can something like

[00:51:50] workspace extras pull in changes as long as they're not the same entities pull in uh changes live into the workspace so

[00:51:58] when you publish they don't get over yeah so that's a good question and um this I think maybe this is probably the last question that we have time for but

[00:52:07] it's an important one to answer uh so the question is um as you are working on a workspace and you have changes is in

[00:52:16] live how does that affect the content or can you pull in that those changes into the workspace so uh when I mentioned

[00:52:23] about git in terms of um how this is how workspace is related to git um think of this as more of a shallow copy so it's

[00:52:31] not that all these uh copies of every content are in this workspace it's just that whatever changes that you make are in this workspace so if you make changes

[00:52:40] to content on uh on live um that's uh the changes that you have in the workspace aren't necess if you're if

[00:52:48] you're not talking about the same content then the changes that you have in your workspace aren't going to affect that content. Thank you folks.

[00:52:56] Thank you.