June 2025

Speaker 0: Hello, everyone. Welcome to June's version of the changelog. If you're new, I'm Beth, and I'm gonna be taking you through what we've got in store for you today. Whether you are joining us live or on demand, do let us know if you've got any questions. If you are live, then we've got the chat running.

And, otherwise, it's community.directus.io. And if you do have any questions along the way, we'll do our best to get them answered for you. I hope you're having a great start to your day, week, and month, and we're gonna be kicking off with product updates from me this month. So I'm gonna be kicking that off now. Alright.

For Directus 11.8 released last month, there are a bunch of smaller improvements and bug fixes, so we're not gonna spend too much time going through it, but here are a couple of highlights. We've added the ability to have a toggle variable input for the in and in filters. We fixed relation creation to files and added filters to files and image interfaces. And finally, IP, user agent, and origin are now tracked in the activity records for WebSocket activity. That's a really short overview of some of the things we've been up to this month.

If you'd like to see the full release notes, they're available on GitHub. This month, we have six new tutorials across two themes, submitting forms using Directus and integrating the Directus visual editor. And you can find those in Next. Js, Nuxt, and SvelteKit. Go check them out.

They're in the docs at directors.i0/docs/tutorials. Alright. And something else that's new with us this month is the directors MCP server, which we've got a demo from Brian coming next.

Speaker 1: Hey. What's up, guys? Brian here. And in this video, I'm gonna show you how to use AI tools like Cloud Desktop to quickly build landing pages inside Directus CMS. Alright.

So I've got this prompt up, and this is the time that I've actually tried this prompt, so we'll see how it goes. Basically, I want Cloud Desktop to create a landing page inside my Directus instance for me. Now this is a complicated endeavor, because, one of the the huge benefits of Directus is the ability to create pages dynamically using our many to any relationships. Basically, page blocks. Right?

So a page can be made up of a bunch of different blocks and each block with its own schema, its own data model, and its own presentation on the front end of the website. So it makes it really easy. I can also edit these things visually. But, still scaffolding out these pages, can be time consuming. There's no way around it.

Like, we've gotta rearrange blocks on a page. So let's use Claude and this prompt that I've got set up. So I'm just gonna go here to my prompt section. We're gonna create a landing page. And the way this prompt works, basically, I've got a bunch of variables to fill in and the direct us content MCP picks up those variables that I've included in either the message or the system prompt and prompts me to fill those out.

So, draft a landing page for a specific audience based on an idea or topic. So we're selling Directus the AI ready CMS. Cool. Desired action is going to be sign up for cloud instance. You could check this out on cloud.

There's also a command that you can run-in our documentation to get this full CMS set up locally. Value proposition. AI plus Directus eliminates busy work and death by a thousand cuts. Descriptive tone, we wanna use professional but friendly and confident, super relatable. Alright.

The audience that we're aiming for, technical marketers and developers. Specific pain points. Where's the pain point? Other solutions, too slow, too complicated, don't do enough. Specific solution outcome, Directus CMS is the best.

Level of knowledge, mildly aware. Alright. This is a super detailed prompt, so I'm expecting the results to be amazing. Don't want to switch systems, migration pane, costs, etcetera. Alright.

So this is our prompt. Basically, it has filled out all those variables for us. It's gonna send that to Claude, and we're gonna start building out this landing page. Right? So you're seeing this the time, same as me.

What's happening behind the scenes? The Directus Content MCP server is feeding these tools to Claude. Claude is calling its system prompt, that we've set up. So, hey. You're a Directus assistant.

Here's what you've got access to. It has understood our schema. So it understands the specific data model that it's working with. Right? And now it is working its way through the landing page.

And here we could see it's already created the page. Right? So if I just refresh, Directus, the AI ready CMS, eliminate busy work forever. Right? So here's our page, and we don't see any blocks though.

Right? Of course, this is also still a draft. But what's happening here is because the MCP and, by consequence of the LLM is now aware of my specific data model in Directus, it can go through and create these blocks for me that are a 100% on brand, that are a 100% correct to our data model. And let's see what it comes up with. Right?

We got a CTA button group. It's adding buttons within that. See the live demo. Start a free cloud instance. That's our main, callout that we said.

It's even picked up the Directus cloud registration URL just somewhere in the ether, problem agitation section. So it's doing a ton of work on my behalf here and actually creating these blocks inside Directus, and then it's gonna come back and actually add those blocks to the page. Now if you were to scaffold this out yourself, maybe you're super efficient. Yeah. It's still gonna take you a while and you're gonna have to fill out a lot of these fields.

So now it's going to add all this for us and the end result is gonna be something that we can come back and just edit manually. Right? So here I see all the different sections. It is creating all those for us. And this is what it's all about.

Right? I don't know about you, but in sci fi, when I was a little kid, we were promised this dream of computers doing a lot of work for us, taking our ideas and and helping us achieve the result. So here's our landing page. I'm just gonna hit refresh, And maybe we wanna actually open this in the Directus visual editor so I can start going through this personally. Alright?

So stop fighting your CMS. Start building. Other CMSs are too slow, too complicated, and don't do enough. Get back to what matters. Creating amazing digital experiences.

So there's our headline. Here's kind of the problem agitation. Traditional CMSs weren't built for AI powered workflows. What if your CMS actually worked with you? We've got a pricing block, and it looks like it did miss some of the format here for this, which I'm curious about.

But, we've got this landing page all scaffolded out. I could go in and manually adjust any of this that I need. Adjust any of this content. Command s for save and see those changes live. But this, wow, that is using the Directus Content MCP to build your landing pages out for you so you can go in and tweak them so they're just perfect.

Speaker 0: Alright. It's super exciting. And if you want more information, Bryant has done a great post on our forum for having much more explanation than that. And if you have the tag on AI, if you're searching for it, you can find it, or I've just put the link to the post, over in comments on directors.i0/tv/live if you are joining us live. Speaking of the community forum, our next segment is again Brian with a special edition of community hotline.

Speaker 1: Alright. Alright. Welcome back. We are live on the Directus community hotline. I'm your host Brian Gillespie.

Today, we are answering a question from community member, RHB. RHB, what's up, sir? Glad to have you inside the community. Let's get to your question. Thanks.

But is there an automated way to generate API docs for my custom collections inside Directus? The open API spec that generates that Directus generates is massive, and 99% of it is system stuff I don't need. I just want clean docs for my own collections like products, customers, services, etcetera. Anyone know of a tool or script that could filter the open API spec to only include my collections? Or maybe there's a better approach entirely.

Well, I'm not sure of a tool or a script, but I can give you a better approach. Let's dive into it. So, this is familiar to probably everyone. This is like the swagger spec. This is kind of the out of the box API documentation.

This is just their pet store demo. But, one of the nice things about Directus, I know I say this a lot in videos, is the ability to generate this open API spec. So I could just come to server slash specs slash o a s and get the full open API spec. It's beautiful. Now, it is very comprehensive in that every single API endpoint that the current user has access to will be shown here.

So we can kinda see which way we're leading here. The easiest way to get a filtered list for your API spec is just to use a user to grab the API spec that has lowered permissions, restricted permissions. Permissions just to the collections that we want in the spec. So how can we do that? We're gonna go into Directus settings, and I'm just gonna create an access policy for this.

Now technically, again, just use any user that has the correct permissions that you want and generate the open API spec. But to make this super clear, we're just gonna generate a new policy called API spec, and I'm gonna add two collections to this. Just pages. We'll give all crud access. Not trying to print the page.

We'll do posts. Great. We'll give all crud. We'll take away the shares. I don't typically use those a lot.

Okay. So now we'll we've got this policy. We're gonna go in and create a user, and I'm just gonna call this one, surprise surprise, API spec user. Great. What do we need to actually pull this off?

Right? We don't have to add a role. Directus 11 was really nice in that, we got permission or we got support for access policies. So we can, roll up policies up to the role level or I could just add them directly to specific users in this case. So we're just gonna add API spec.

I'm gonna generate a token. And now I'm gonna hop over to Swagger and I'm gonna add my direct us URL. I'm going to go to this endpoint, server slash specs slash o s, and I'm gonna add a query param for access token. Now this is definitely, do what I say, don't do what I do. Adding the access token as a query param is not safe, doing it just for demonstration purposes here.

Make sure, you know, you're passing that is an authorization header, for the bearer token. So I'm just gonna hit explore and server specs OAS. Let's try again. Grab the token, got the API spec, save, explore. Server spec, forgot an s.

Gotta get the s in there. Okay. So now we're going to see, we'll see the authentication endpoints just because those are always available. Right? The server health endpoints.

Okay. Great. But if I take a look now, I don't see a giant list of endpoints. I just see pages, and I just see posts. And, again, I can use Swagger to test those out, but this is the best way to filter down that list, without running extra scripts or extra processing on it.

So RHB, I hope this is helpful for you, man. The other thing that I wanna show you, if you go into the marketplace, we've got several extensions that could get the job done for you as well potentially. So if you just search rapid in the marketplace, there's an API viewer extension, a rapid docus extension that allows you to view that open API spec without ever leaving the Directus App Studio. If you would like your question to be featured on Community Hopeline or you just have Directus questions in general, hop into our community at community.directus.io, post your question, and you may be featured on the next episode. We'll see you.

Speaker 0: Alright. Thank you so much to Brian for both of those amazing segments. It's always a treat. As we're approaching the end of the show or towards the end, we have our final segment, which is from Carmen, and it is an episode of Translation Station.

Speaker 2: Carmen. Suite developer educator share direct translation station. Translation station. Alright. Back to English.

So here we've got a Directus project dedicated for storing my blog posts. Now amongst the collections, we can see posts. And I'd like to take a minute to take a look at the structure or the data model of these posts. Gonna hop over to the settings module and take a look at posts itself. So we can see a variety of fields here.

And the ones I want to highlight are slug, which will help us build a URL to find our post in our application. Next, we've got the title and the content. Another field I want to highlight is translations. Now I've gone ahead and created some translations for our blog posts. If you want to find out how to translate your content in the data studio, check out our data studio content translations episode of Translation Station.

Back in our data model, I also want to take a look at post translations, which is a hidden field that holds the translation data for each of our posts. You can see we've got the title and the content. Let's now take a look at the post itself. We've got the ultimate guide to rabbits, which is written in both English. Scroll down here.

As well as French. So I'm going to show you how you can build an application to retrieve translations of your blog posts. So what we have here is an application written in Nuxt, which uses three ways of accessing our translated blog posts. One is using the Directus SDK. One is using the REST API of our Directus project.

And the last is using the GraphQL endpoint of our Directus project. I'm gonna give you a short tour of this Nuxt application. we set up our environment, which will connect to our Directus project and proxy accordingly to go to local host 3,000 slash Directus so that we can access our data. So let's start with the SDK. I've set up a Nuxt plugin here, which instantiates a Directus client and makes it available to my Nuxt application.

By going to SDK slash the language code of the content slash the slug of the blog post, we're going to retrieve and display the translated data for our blog post. Let's walk through this real quick. we instantiate our client and set up the retrieval of the parameters and a reference for the post itself. Then we asynchronously use the direct client to read several posts. Using the deep and filter parameters, we're going to grab the blog post that corresponds to the slug given in our URL as well as the translation itself for that locale.

We then make available the data of the translations into the result and limit to one just for good measure. Once we have that, we grab the translation itself from that payload and display it accordingly. Let's take a look at it in action. So here we are. We've gone to local host 3,000 in my running Nuxt application slash sdk slash en u s, that's for English, slash the ultimate guide to rabbits.

And that gives us my blog post. To view it in French, I just have to change my URL to frfr. Check it out. Now it's in French. Fantastic.

Let's see how it's done with REST now. All right. So we won't be using our SDK client and instead we'll be using the fetch API in order to retrieve the posts that match the slug as well as the locale itself. And then retrieving as fields, the translation title, content, and the language code. Limited to one for good measure.

Then we retrieve the translation with the correct language code from our locale. And then just like before, if there's a post, we display its content. Let's see it in action. Back in my browser, I'm going to go to rest slash en dash us slash the ultimate guide to rabbits. Access that, and there's our English blog post.

And for French, f r dash f r. And there we go. All good and in French. One more. Let's look at GraphQL.

So just like with the REST API, we'll be using fetch, grab the GraphQL data. we'll build our query, which will filter out the posts by slug and specifically filter out the translations by the language code alongside that translation's title and content. Then we make a request to the GraphQL endpoint of our Directus project, and then set that post value to have that translation data. Then just like before, if we have a post, we go ahead and display it. Let's have a look.

All right. Back in our browser, let's go to graph QL slash en dash us slash the ultimate guide to rabbits. And there we go. There it is in English. Now let's try it in French.

Wonderful. So that's the three ways we can access our translated data from our direct Us projects API. Alright. Well, there you have it. How to access your translated content from Directus using our APIs and SDKs.

But that's not the only stop on this translation station journey we're on. If you wanna learn how to translate Directus directly or where it gets translated, how to use translation strings, or how to translate your content, check out the other episodes of Translation Station. So I hope this was helpful, and I'll see you on the next stop of Translation Station. Bye for now.

Speaker 0: We want to take a moment towards the end of the changelog for thanking our community contributors who give their time and expertise to improve the directors project. Since last month there have been five contributors. A huge thank you to Bruno for ensuring the configured display format is applied to the Kanban layout, Mehdi for enhancing the appearance of the flow trigger buttons in the sidebar by applying their custom colors, a FAQ for ensuring the flow logs with color indications for success and failure and adding a new filter to view only failed logs, AMOS for fixing permissions handling in the files module and for adding new action events for extensions, Nico for fixing admin password, admin token, key, and secret to always be interpreted as strings. A huge thank you once again. You can see their specific pull requests inside of the full release notes on GitHub.

Lastly, we also want to take the time to thank our GitHub sponsors of May who kindly financially contribute to Directus' development. A huge thank you to Wayfam, Hintle, Mike, Fergus, Omar, Marcus, Mission Control, Peter, Utomic, Steven, James, nonlinear, Andreas, Reza, John, Jamilinin, Barb, Adam, Jason, Barker, Yuya, Vincent, CK, Valentino, Jens, Wayne, and Avi. The money we are given from our GitHub sponsors go straight back to community members who build tooling and extensions for the direct to see ecosystem. Thank Thank you again for being part of that. Alright.

And that is the show for this month. As always, if you've got any feedback about things you would like to see in upcoming shows, do let us know. But other than that, thank you so much for taking the time to spend with us. We really appreciate it. We hope you found this useful.

And, yeah, take care, and we'll see you next month.