Home Blog

WordPress.org blog: WordPress 7.1 Beta 3

0

WordPress 7.1 Beta 3 is ready for download and testing!

This beta release is intended for testing and development only. Please do not install, run, or test this version of WordPress on production or mission-critical websites. Instead, use a test environment or local site to explore the new features.

How to Test WordPress 7.1 Beta 3

You can test WordPress 7.1 Beta 3 in any of the following ways:

WordPress Beta Tester Plugin Install and activate the WordPress Beta Tester plugin on a WordPress install. Select the “Bleeding edge” channel and “Beta/RC Only” stream.
Direct Download Download the Beta 3 version (zip) and install it on a WordPress website.
Command Line (WP-CLI) Use this WP-CLI command:
wp core update --version=7.1-beta3
WordPress Playground Use a 7.1 Beta 3 WordPress Playground instance to test the software directly in your browser. No setup required-just click and go!

The scheduled final release date for WordPress 7.1 is August 19, 2026. The full release schedule can be found here. Your help testing Beta and RC versions is vital to making this release as stable and powerful as possible. Thank you to everyone who contributes by testing!

Find out what’s new in WordPress 7.1: Read the Beta 1 announcement for details and highlights.

How important is your testing?

Testing for issues is a critical part of developing any software, and it’s a meaningful way for anyone to contribute – whether or not you have experience. Details on what to test in WordPress 7.1 are available here.

If you encounter an issue, please share it in the Alpha/Beta area of the support forums. If you are comfortable submitting a reproducible bug report, you can do so via WordPress Trac. You can also check your issue against this list of known bugs.

Curious about testing releases in general and how to get started? Follow along with the testing initiatives in Make Core and join the #core-test channel on Making WordPress Slack.

What’s in WordPress 7.1 Beta 3?

For technical details on the more than 71 issues addressed since Beta 1, see the following links:

Note: Beta 2 was released on July 17, 2026, as part of the WordPress 7.0.2 release and includes important security fixes.

Beta 3 introduces two improvements to styling.

Applying local style changes globally is no longer an all-or-nothing action. The Apply globally option in the block inspector now opens a quick review step, allowing you to choose which modified styles to apply globally while keeping the rest as local overrides.

Other notable fixes include improvements to media uploads: long animated GIF uploads no longer hang, images rotated using EXIF metadata are processed correctly, and uploading a single HEIC image in Safari no longer creates two entries.

The editor also includes additional fixes for Notes, responsive styling, and custom CSS. For developers, WordPress Coding Standards has been updated to version 3.4.0.

Unicode email address support will not be included in WordPress 7.1. The work will continue in a community plugin, allowing broader testing of compatibility, security, and data-handling considerations.

A Beta 3 haiku

Fresh bugs surface now,
click by click, we chase them down—
codebase grows steady.

Props to @krupajnanda, @annezazu,
@wildworks, @amykamala for proofreading and review.

Open Channels FM: Signal – Issue 17

0

Talk about the intersection of open source software and business, rapid security response amid AI advancements, the importance of fundamentals in AI implementation, and concise content creation for engaging media.

#226 – Jessica Lyschik on Why Accessibility in WordPress Themes Is Easier Than You Think

0
Transcript

[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, why accessibility in WordPress themes is easier than you think.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox and use the form there.

So on the podcast today we have Jessica Lyschik. Jessica is a longtime member of the WordPress community who’s been working in the ecosystem since 2015. She’s spent years learning and advocating for web accessibility, both as a developer and as an active community participant, joining agencies, working on theme reviews, and helping improve standards.

Many theme creators assume that making themes accessible is an intimidating task, but Jessica’s here to show you that achieving an accessibility ready WordPress theme is more straightforward than you might imagine.

Her WordCamp Europe 2026 presentation, accessibility in themes, easier than you think, aimed to demystify the requirements for accessible themes. Explaining what the WordPress guidelines mean in practise, where the low hanging fruit is, and how both block and classic themes can reach accessibility ready status with manageable efforts.

We talk about the personal and moral journey that brings developers to accessibility. The technical hurdles and documentation challenges, and the ways in which things like AI agents are putting accessibility in the spotlight for everyone.

Jessica talks about practical steps that quickly improve accessibility, like using correct HTML tags, adding alternative text to images, and configuring skip to content links, and shares why building accessibility in from the start saves time and effort down the road.

We also explore the differences, and possible advantages, of block themes when it comes to accessibility, and why theme guidelines work the way they do, and the importance of interdisciplinary awareness across SEO, design, and content teams.

Jessica mentions helpful resources, influential leaders in accessibility, and the ongoing need for documentation improvements to help everyone level up.

If you’ve ever felt overwhelmed by accessibility requirements, or wonder why they matter, and how you can build better WordPress sites that work for everyone, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Jessica Lyschik.

I am joined on the podcast by Jessica Lyschik. Hello, Jessica.

[00:03:39] Jessica Lyschik: Hi Nathan.

[00:03:41] Nathan Wrigley: Nice to have you with us. This is my second interview at WordCamp Europe 2026. We’re in a beautiful, big media room. I’ve got to say, this is one of the nicest spaces I’ve ever had for these kind of interviews, so that’s really nice.

Jessica has already done, I want to say presentation but maybe it was a workshop. I’m not sure.

[00:03:57] Jessica Lyschik: No, it was a regular talk actually, yeah.

[00:03:59] Nathan Wrigley: Okay. And how did it go?

[00:04:00] Jessica Lyschik: It went super well, except for my slides went missing in between. That wasn’t so great. But the audience was very respectful of that, and I made a bit fun of it, so they laughed for a second and I tried, the media guys tried to fix that. We got it fixed in the end. I would’ve winged it anyway because I, like I knew what was coming up. But it’s always good to have your slides. It’s like seeing them, because for me it’s also visual reminder. It’s like, I need to see what I’m talking about, so I’m not losing track of it. But yeah, this was just a little technical hiccup. But overall I got very great feedback so far on my talk, and I’m very glad.

There were also quite a lot of people. I did not expect this many. And that makes me just super happy that people are actually interested in this topic, although it is sort of scary for some of them if they even like try to touch this topic. We can probably get into the details later. Yeah, just overall like, what does it do? Why do I need that? These unanswered questions that they have that they were like, ah, no, I’m not really interested into that.

[00:05:01] Nathan Wrigley: Oh, that’s nice a big reception.

[00:05:03] Jessica Lyschik: Yeah. And that’s just great to see because I think just as we all grow older, and I even noticed that, and I’ve said that in my talk, like I kind of get to appreciate when a website is accessible. I mean I’m still have a long time to go, hopefully in my life, but I start to appreciate the small things that make just browsing websites easier, to be honest.

[00:05:23] Nathan Wrigley: So I guess we should introduce the subject and then give you a chance to introduce yourself because it feels like in this context, the subject at hand, it’s important to know that you know what you are doing. It’s not, well, I suppose it’s a general skill in that it should be something most people know an awful lot about. But I fear that that’s not the case.

So the presentation that you’ve just given was called accessibility in themes, easier than you think. That’s nicely phrased. Let’s get them through the door.

And then the blurb that went with that, I’ll just read that into the record then everybody knows what we’re talking about. So it says, many theme developers assume accessibility ready requirements are hard to meet, but that’s rarely true. This session shares practical insights for real theme reviews, and shows how both block and classic themes can reach accessibility ready status with manageable effort.

So that’s the context of what we’re going to talk about today. However, as I just alluded to, could you just tell us a bit about you, how long you’ve been using WordPress, and then I guess if you want to focus a bit on your accessibility credentials and what you’ve been doing in that space.

[00:06:23] Jessica Lyschik: Yeah, of course. So yeah, I’ve been using WordPress, I think I started around 2005 or 6 already. So like dipped my toes into it, played with it around, just got a feel for it. But actually professionally, I started out in 2015 in the WordPress ecosystem.

Before that, I already joined the community. So I was working at another place that did not use WordPress before. And then in 2015 I joined a WordPress agency. Today they’re called Syde, for anyone who’s wondering. And ever since I’ve been into WordPress that long.

And accessibility in that case I have, I think it was a gradual process more of. It was not just like, I’m now doing accessibility. That just didn’t happen. It was, I learned it over time. And when I started learning about how to create a website accessibility was absolutely not a thing. No one cared about it. And it just became more and more aware for people, for developers, especially in the past couple years. I think we still have some way to go but like, as I said earlier, there were so many people interested in my talk. So I think we’re now at a pace where things get really interesting for many more people.

And yeah, I learned a lot along the way. Made a lot of mistakes along the way. But I’m glad I’m learning this. I’m still learning. So it’s always something that you continuously learn, because I think the hardest part to grasp for people is that, if you are abled, it’s like you can see, you can hear, you can navigate a device with your own hands, all stuff like that, you take it for granted.

And if you suddenly see or people tell you the perspective of like a blind person, a person who’s deaf, a person who may not be able to use a device like you do, maybe have a hand injury, or no hands anymore, that’s also happening. Then you start to wonder, okay, how do these people actually like use websites or use their phones or computers? And there are many different ways to do that. And I think if you have the chance to learn about this, it is absolutely eye-opening.

You can also then, there was a talk at WordCamp Leipzig this year, but also last year, I attended last year, by a blind person. And her brother was also blind. He was a developer. And they shared like how bad some websites are, and how they struggle to like get the information out of the website, and what crazy, crazy stuff people are doing to their websites that do not make it accessible for these people.

And then you are sitting there and wondering, oh my God. And sometimes I have to say, I even did this in the past and I didn’t know, but I’m glad today that I learned about this and make a better web essentially. Yeah, that’s why I’m here sharing my knowledge.

[00:09:11] Nathan Wrigley: It kind of sounds for me, so when I talk about accessibility, there’s always two strands to it. There’s like this legal bit where the governments are increasingly talking about things that will happen to you as a company that builds websites if you don’t follow guidelines. So that’s one side.

But there’s also this moral side. There’s the side of, we ought to do this despite what the law says. You know, it’s just a necessary thing. And it feels to me as if your journey in this was a moral one.

[00:09:38] Jessica Lyschik: More of, yes.

[00:09:39] Nathan Wrigley: Yeah, there was a definite need here. You know, in the real world when you see somebody, let’s say somebody who’s sitting in a wheelchair and they’re trying to get into a post office and there’s a step that they can’t get over, there’s no bit of you which doesn’t see that as unjust. Every bit of you says that character can’t get over that step. That’s wrong.

And yet, the bit of the world which is becoming increasingly the way that we interact, you know, we book flights, we file our taxes, we do our banking, we, all of these things, they’re completely invisible.

Most of the time we’re doing the internet by ourselves. You know, we might be sitting on a train, but nevertheless it’s a solitary activity, or we’re in our own home or whatever. And these pitfalls, the equivalent of the step in front of the post office is totally invisible.

And it also seems that the voice of the people whose lives are made more difficult is just drowned out. Somehow that anger that they must feel never seems to rise to the top quite enough that we all take the necessary steps.

I don’t know if any of that landed, and there was definitely no question there, but I’ll hand it back to you if any of that resonates.

[00:10:49] Jessica Lyschik: No, I think you, you’ve put it absolutely right. And the invisibility is the thing, because a step for us is visually, like we see it I mean. If you’re blind, you’re not seeing it. But let’s put it away for a second. But in the web, the invisibility is like the key thing. And I just talked to Anne-Mieke Bovelett about, who’s doing another accessibility talk this afternoon. She told me about like a company where they put effort into their website, making it more accessible. And their sales actually increased. So it can definitely help. This is just one example.

But there’s also a new player in the field that will probably even increase the interest in accessibility, and that is AI agents. Because AI agents, they do not see a website as we do visually. They rely on that the website is technically built correctly. Google actually just last month announced that they will focus on this. They will focus on the accessibility for the AI agent. I have put a link in my slides to that document. This is basically, I think something that will be easier to grasp for people for some weird reason. But it’s made more visible to them because if an AI agent cannot read your website, and I know we are probably still at the very beginning of this AI agent stuff, but I think this will increase over the next couple months or even years.

[00:12:14] Nathan Wrigley: That’s really interesting because when an individual, let’s go back 10 years, when an individual is creating a website, every single bit that you have to achieve is a minute of work or another minute or 20 minutes or an hour or what have you. And so there was this whole thing of just building the website, especially when page builders and things like that came along, just building the website to see what it looks like. And that whole accessibility layer just basically gets ignored.

However, that’s what you’ve just said is curious because the AI agent building the website, to the AI agent, that’s kind of no extra work to get it right, if you know what I mean? If it’s configured to do all of the bits correctly, I’m using air quotes around the word correctly, then in theory it should be quite a good custodian of accessibility when it’s building things. I guess only time will tell whether that actually happens.

[00:13:08] Jessica Lyschik: Yeah, but it’s also for like, not the agents itself building, but also the agents visiting your website. Especially if you do like, I think shopping will be the one thing that if you say, hey, I don’t know what the best coffee or what, this is like a good topic. Yeah, okay, here are three options. And then, okay, buy me option one, a kilo of these beans or whatever. The AI agent, if the shop is accessible, the AI agent could do the shopping for you. This is where things are going and progressing towards, that you are not actively anymore the person who actually goes to the online shop, puts it in the cart, goes to the checkout and does all that stuff for you. But if the agent knows all that, it can do it for you.

[00:13:50] Nathan Wrigley: Can I ask a question then? Because I may have, I think I’ve understood what you were just saying and curiously, I’ve never had that thought, the one that you’ve just expressed. I want to know if I’ve got it right. Are you saying that in a world in which we increasingly ask AI to achieve things on the web for us, if it’s built with accessibility in mind, it’s more likely to be able to achieve the result of, let’s say, buy me a kilo of coffee.

[00:14:14] Jessica Lyschik: Yep.

[00:14:15] Nathan Wrigley: That’s so interesting.

[00:14:16] Jessica Lyschik: Yeah because like, Anne-Mieke, whom I just talked about, shared a long document with me recently and I was just reading through it and was like, yeah, of course. Of course, if we technically do things right, we use the right elements, we do the right descriptions for everything that a computer, because AI agent is just a computer. Like assistive technology, like a screen reader who needs to read the right structure out of it and to fit the right content. But also is able to interact with stuff, like click on that button, put that in the cart, go to the checkout and so on. It’s basically the same. An AI agent is a screen reader.

[00:14:53] Nathan Wrigley: Yeah, that’s really interesting. I’m thinking of a map where I’m trying to get to a destination, but the map has no directions. Imagine a scenario where we set off from one place and our destination is here. What you are saying is all the instructions in between to get from the start to the end can be read if the HTML and all of the bits and pieces wrapped up in that are correct. I had never had that thought before. That’s so interesting.

[00:15:17] Jessica Lyschik: Yeah, that’s very interesting. And I did not focus too much on this topic in my talk, but I wanted to put it in there at least in one slide to give like the food for thought that people can actually think about it because this is like what’s hyped right now. I have not tried out this whole agent thing yet, but like from a developer perspective, I can totally see that this is something that will increasingly help AI agents to achieve stuff.

[00:15:41] Nathan Wrigley: Yeah. And presumably make it so that a whole tranche of people who struggle with the web as it is currently might be able to interact with their voice or whatever other technique they use. We’ve completely gone off the rails, but that was such an interesting aside, thank you.

[00:15:58] Jessica Lyschik: Yeah, I think this is something interesting to share. And as I said, I wanted to focus more on the technical details in my talk, so I left it kind of out. But I think it’s a great opportunity to share it here with you.

[00:16:08] Nathan Wrigley: Yeah. That was lovely. Thank you.

So let’s go back to the WordPress bits and pieces then, and I’ll just do the title again because hopefully that’ll refresh it in listeners’ minds. Accessibility in themes, easier than you think. Dear listener, if you’ve been using WordPress for any length of time, you’ll know that the themes still plays a giant part in the structure of your website and the way that people experience it.

So where are we at then in the year 2026? Does the theme still represent a huge part of accessibility? In your experience, is it easier than most people think to get an accessible website in the year 2026? We’ll get into block based themes and classic themes and all that in a minute. But essentially what I’m asking is, is it an easier thing to get right than most people imagine?

[00:16:51] Jessica Lyschik: Yes, because I think what scares people off from my own experience, there are requirements to get the accessibility ready tag in the wordpress.org theme repository. And these requirements, if you first read them, they’ll sound a bit cryptic and you do not really understand what they actually mean.

In my talk, I was trying to combine this, what the requirement says with what is actually meant by that. Because right now, and this is something I would like to improve for the future, I’ve already talked to people about this, and I will have another chat with Rian Rietveld about it later, or tomorrow. Let’s see when we can make that happen.

Because right now the requirements read like, okay, this must be achieved. This is what the website should do. Then there are some testing instructions, but you’re not told how to achieve it. What do you technically need to do in order to do that?

I noticed this while I was reworking. I found out about the requirements also just a month ago because the requirements got updated. I have a theme in the wordpress.org repository and I tried to apply these new rules and have another fresh look at it. I got the accessibility ready tag for this already when I first got the theme into the repository. But like it was a good refresher to like go over all the requirements because they have slightly changed a bit, they added new ones.

When I was there, I was like, okay, like I understand this now because I have learned about accessibility over the past couple years. For someone who is fresh to this topic and doesn’t know too much about it, it’s hard to understand. Because there are some descriptions of things like, basically what it means is that you need to use, for example, the right HTML tags, header, footer, the main tag. We have section and aside, which are available in HTML 5. But the requirements does not say this explicitly.

And I think this is where probably most people have gotten stuck in the past, because they did not understand like, what is actually required from me technically? Because the texts are not so much focused on that. And this is something I would like to contribute as well, to give back and to enhance. So it’s not there yet, but hopefully sooner than later we can add all this information so it gets even easier for people.

Because if you’ve done a website and you know about the HTML, you know about maybe a little bit of CSS, you know how to achieve this. You just need to connect the dots to what is relevant for accessibility and how do you do this in your HTML essentially.

[00:19:20] Nathan Wrigley: Yeah, I guess that’s a bit of a shame really, isn’t it? Is that the documentation is difficult to follow because I feel that accessibility is one of those things where if something is difficult it can get dropped basically.

[00:19:33] Jessica Lyschik: Yeah, people won’t do it.

[00:19:34] Nathan Wrigley: Yeah, because the majority of people browsing the internet can browse the internet despite your accessibility efforts, that will be the standard that they’re aiming for in most cases. So if it’s difficult to achieve these things and the documentation’s not really straightforward, every time somebody comes across a question and thinks, I don’t really know the answer to that, probably the quickest thing to do is just to, ah, push it to one side and not press through. But you obviously have and made it a bit of a goal.

So is there a particular accessibility requirement that developers in your estimation kind of overestimate the difficulty of? What I’m asking here really is about some low hanging fruit that you know about. In the scenario that we’ve just described where it’s easy to get put off and to sort of say to yourself, okay, I can’t do this. I’m wondering there are some sort of quick wins that you could describe that people could maybe achieve within the next half an hour, once they sat down at their machines?

[00:20:27] Jessica Lyschik: Yeah, I think there are definitely some. There is like underlining text in your main content, just underline the text. It’s one line of CSS, text declaration underline. For links, obviously, not for the entire text.

And there is like, as I said, the HTML tags. With block themes, it’s super easy. For example, you just need to configure that correctly in the editor, or use the correct template part and it’s basically done for you. Core does that. This is one advantage of block themes, but we can dive into this deeper later. Or the skip to content links also in block themes.

As an example, in block themes it is just like putting the content block in a group and assigning the main HTML tag to that group. And WordPress does the rest for you. It’s just like assigning this one little setting correctly and then you get automatically a skip a content link for block themes.

[00:21:18] Nathan Wrigley: Yeah, but curiously, if you didn’t know that small fact, that WordPress would handle that for you, if you don’t know, you don’t know. And you’d presumably go around the houses trying to figure that out for yourself and implement some custom version of that thing. Whereas in fact, what, three clicks, four seconds and you’re done.

[00:21:33] Jessica Lyschik: It’s super easy, yep.

[00:21:33] Nathan Wrigley: Yeah. Any more before we move on?

[00:21:35] Jessica Lyschik: I think these are like the most, absolutely the low hanging fruit is also if you use any images to add an alternative text. I think this is probably the most common one people already know. It is so easy. And even WordPress, even if you use classic themes, it’s already in the media library, the alternative text field. For block themes you have it directly at the image so it’s already in front of you. You just need to use it.

[00:21:57] Nathan Wrigley: Yeah, you just not ignore it basically. Yeah, that’s true.

So has this become kind of a habit for you then, over the last period of time since you’ve taken more and more interest in this? Have you got to the point now where this is just how it works? You know, in the same way that I drive a car and I use the gears and that’s all just second nature. Is it like that for you when you are building your themes? Because it’s now locked away in your head. Every time you do a thing that previously you would’ve omitted. You are now just in the habit. Has that been a difficult journey or fairly straightforward?

[00:22:28] Jessica Lyschik: I think it’s, like starting out with this, it would feel like a bumpy road. But for me it was, it’s a gradual process. But right now it’s really like, yeah, I just know that when I use a button in a context that is not like sending off a form to add an aria label to it, it’s like, it is baked into my brain essentially already because I know.

And I just had a very interesting example this week at work where there was a client reaching out saying, hey, we did an accessibility test on our website and it marked like two buttons that did not say what they’re doing. These were essentially missing the aria label because they had only icons on the buttons, not real text.

So if there’s just an icon, the screen reader cannot read, what is this button for, essentially, with just an icon? The win here was just to add the aria labels, because the fields were already there. This was also part of the Greyd.Suite, so from our product so I knew how to put it in there. And then it was like, oh no, like I have to do this 12 times, my colleague said. And I was like, yeah, okay, then you have to do it twice, 12 times. So 24 times. But be happy it’s not 200 times you have to do it.

So, and I said, do not take this personally. This is a great example of why putting accessibility at the very beginning of when you’re creating this makes life so much easier than rather when you just build a website and then you figure out you have to change 300 buttons. This is probably a crazy number, but just to give you an example, to change all the buttons manually again, going through every single page or whatever you have when you just could have taken the extra step, added the aria label, and then just be done with it.

[00:24:09] Nathan Wrigley: Right. That’s an interesting thought. And also the exasperation of your colleague there kind of perfectly sums up the problem. In that you see it as a problem. Does that mean I’ve got to do something 24 times? And there’s this sense of, ugh, I’ve got to do this work. And it feels like a chore. But then I suppose if you step back and look at what you’ll actually enable by doing those 24 things.

And I know that in the workday that’s hard to do. It’s hard to sort of step back and say, okay, if I do this thing 24 times, this will be the result, and lots more people will be able to, in this case, view the image.

[00:24:42] Jessica Lyschik: I mean this was like they started already working on. If you fix it now, you do not have to do it for the coming pages. So if you multiply that with how many pages more you need to do, once you get this one fixed, and ideally you need to change the aria label of the text changes obviously, but this was, I think for a header, in a header, where there was like, I think one sort of popover or popup. Fully accessible by the way, so don’t worry about that. And also a button to, I think for the phone numbers, like just a phone icon. And they could click on it and it would be something like that, along the lines. I don’t exactly remember what it was. But it was just like two icons in the header. And if you take that header, use it on, I don’t know, another 250 sites, you don’t need to do the work anymore.

[00:25:29] Nathan Wrigley: Okay. So you are painting a picture in which, get it right at the beginning, follow the guidelines, do the hard work once, then almost the career from then, from this moment forward, your life will be immeasurably easier if you build it into the theme or.

[00:25:45] Jessica Lyschik: And accessibility will not be taken as, ugh, and I now have to do this all. Because when you do it from the start, you have to make sure at the end of course that it still works. You may have to run into issues and redo stuff. That can happen. But I think you just have saved yourself so much work in the end if that requirement for some reason pops up later or so.

[00:26:10] Nathan Wrigley: I’m wondering, depending on the kind of nature of where you work, and how you do this. You know, if you’re a freelance, then this is on you. If you’re in an agency, then it may be that there’s somebody, you know, maybe there’s an SEO person, there’s a design person, maybe there’s an accessibility person. But it does feel like the moral argument states everybody should have some insight. Maybe you’re not right in the weeds of it, but you should have some knowledge of what the low hanging fruit is, at least.

[00:26:38] Jessica Lyschik: Yeah it’s, what’s the right word for it? Interdisciplinary. It is like not just the developer who needs to think of accessibility. It’s like, okay, we need to because like we provide a technical structure for it. But it also needs to be for the content people who write the blog posts, the pages, whatever, for SEO people to understand that.

And I think accessibility, if you want the entire website to be accessibility, everyone who works on a website needs to know about it. That an SEO person needs to know how to create a skip link, probably not. Or how to use, maybe to use the right text. But for them, the text would be just the, using the right heading structure, for example. This is also a requirement, that you do not use an H3 and then an H6 heading in your content, but you structure it correctly that you have the H1 on the top, and then every next level is H H2, and then every level under that is H3. So this way. They should know about this. But they do not need to know too much about the technical side. Because in the end, it all comes together and creates an accessible website.

[00:27:42] Nathan Wrigley: In your commentary a few minutes ago, you mentioned that there were some guidelines in order to put a theme on wordpress.org. Is that the nature of it? Is it a guideline, or are there some hard and fast rules, which will prevent a theme getting into the repo based upon a lack of accessibility? What I’m asking is, are there some things that you must do as of now, or is it very much, okay, if you do this, great, but if you don’t, we’ll let your theme pass anyway?

[00:28:09] Jessica Lyschik: Yeah. Let me explain this. So there’s this accessibility ready tag. So you have different tags for the themes in the repository. And in order to get the accessibility ready tag, you need to follow the requirements, the accessibility ready requirements, I think it’s completely called.

And these are as of now 18 requirements. I went through them all in my talk. We’ve already touched on some of these. Some are really low hanging fruit, some are, one of the newer ones are, a theme should not recommend or require a plugin that is not accessible. This is something else that the team came up with, which is an interesting one. There’s, I guess a lot of room for discussion.

But also another one is to have an accessibility.txt file in your theme. Which basically, it’s not a standard yet, but like close to a standard sort of, has information about what has been done in terms of accessibility. Are there any classes that you can, CSS classes that you can use to make use of texts for screen readers? So basically hide them visually, or hide these texts or items visually, but still have them read out by screen readers. So they’re not like discipline none where you just remove that basically from the accessibility tree, but make it still readable for screen readers. And just some more information about that.

Yeah, you need to meet all these requirements with your theme if you want this tag. But you can still like do not care about accessibility and still get your theme in the repo if you want.

[00:29:40] Nathan Wrigley: Would you like that to be flipped? Would you like that to be, because I mean we’re a very open ecosystem, aren’t we? And would you like to see though a day where you don’t meet these 18 guidelines, you don’t get the tag, you don’t get to play, you’re not allowed in the repo? Or is that a touch too far?

[00:29:56] Jessica Lyschik: Let me share some numbers, I think. So there are like 14,700 plus themes in the repository right now. All themes. At least that’s the number I can access. I don’t know if there’s maybe a bit more, I don’t know. But this is the public number you can access. And out of these themes, I think if I saw the correct number, it’s like just 270 have the accessibility ready tag. So then that is like 1.5% of all themes who have that tag.

So I think it will be extremely hard to force sort of, if you want to flip that, force that onto people. And I think we need to do a more gradual way. And that’s what I’m sharing my knowledge because I think it is not that hard. If you can improve the documentation for it, it will be even easier for people. And I think this is the way to go instead of forcing like, because we do not like to be forced to things we do not understand.

[00:30:50] Nathan Wrigley: That’s right. Yeah, that’s interesting. I wonder if there’s a future in which that slowly gets ramped up.

[00:30:56] Jessica Lyschik: I think with the AI agents, we will have an acceleration on this, I guess. So maybe not in WordPress themes, in the repository directly, but I think the attention will be put there and then like, oh, maybe we should make it more accessible. Let’s read into this. And I think these guidelines are also very interesting, maybe not just for WordPress themes. I mean, of course they’re for the repository, but you of course can apply them to your own custom theme, definitely. You do not have an absolute check like the team will do for you. But nothing stops you from using them even on a non WordPress site.

[00:31:30] Nathan Wrigley: Do the guidelines, do they feel like they’re kind of firmly fixed or is it always a movable feast?

[00:31:35] Jessica Lyschik: They’re relatively fixed.

[00:31:37] Nathan Wrigley: Okay, so if you were to swat up, for want of a better word, on what there is right now, there’s a good chance that the rug will not be pulled out from under you in six months, a year, two years time.

[00:31:46] Jessica Lyschik: No, I think the last time the requirements got updated was in 2012, 14. I would need to ask, Joe Dolson did the initial, or was working on the initial thing. And so it has been a while since this got updated and they just got updated last month. So I don’t think that they will be changing anything.

The one I talked about, not requiring or recommending plugins is the one, this is something, it kind of creates a grey area sort of. And I think this will be put to discussion. It’s like, I don’t mind, but I can see many people like really, not raging against it, but like raising questions about it. If this is something that should be a requirement.

But I think for like the actual technical stuff, I don’t think that there’s much that should change, because like they’re based on the WCAG requirements. These are like the standard requirements that also have, I’m not sure if they’re used on governmental things, like on the European Accessibility Act, but I think they’re a sort of base for that. And it’s not like completely this. So the theme requirements are not like the WCAG requirements 100%, but like a subset of it, sort of.

[00:32:57] Nathan Wrigley: Yeah, it’s a fairly slow moving ship in other words. If you acquire the knowledge today, you’ve got a good chance that in a year, two years, maybe even five years, the knowledge that you’ve got will need amending. But most of it will broadly work several years from now.

[00:33:11] Jessica Lyschik: It’s with like development in general. So like you always need to be constantly learning. And I think if you learn about accessibility today, I think you’re in a very good spot. Because like of course we have European Accessibility Act and governmental requirements, at least in Europe we do have them. But I think there’s already so much information out there, that it should be relatively easy to onboard you. And I think this is just beneficial if you learn, it’s basically about learning about how to use things correctly. And if you’ve got that, then you’re absolutely good to go.

[00:33:45] Nathan Wrigley: So not that long ago I suppose, we had block themes coming around, which is an entirely different way of creating themes in WordPress. So you’ve got classic themes, which is the way it always used to be. And now we’ve got block themes. Is there a striking fundamental difference in the way that you might approach accessibility if you were used to doing block themes? Is there a whole lot more to learn? Maybe it’s more straightforward if you’re using block themes. Just tell us about how those two things differ.

[00:34:08] Jessica Lyschik: Yeah. It is more straightforward actually. Core is handling stuff for you. So accessibility just got a tad bit easier if you use block themes actually. In classic themes, you have to do a lot of things manually. You have to make sure that the elements are right, that the skip link is there, for example, things that we touched on already. And in block themes, if you use the correct blocks on the correct structure, Core handles stuff for you.

For example, there’s a requirement labelled form fields. So when you use a form or the form fields should have a label to it. In themes you don’t really have that because usually you should not put like, something like a form in there. There are two forms that by default come with a theme that are the comments form, but that’s completely handled by Core. And there’s the search form on the search results page.

But in block themes, both of them are handled by Core. Both of them are accessible because Core handles it all for you. You just need to place them and actually not do anything to them. It is that straightforward.

And same for like template parts. If you want to use header and footer, just use the template parts and use them. You can assign them a header template part as header of course, and one as footer. And then the HTML text will be automatically added correctly for you. So there’s not too much that you need to do manually anymore, just get that right.

And as I say, I really love block themes for the much easier accessibility, or the way you can make a block theme accessible. This is so much easier than with a classic theme.

[00:35:38] Nathan Wrigley: So presumably though, it sounds like there’s meta knowledge, if you know what I mean. You’ve got to know which block to put in which spot, and which block wraps this other block, and the parents and the children. But if you learn that, and if you make that, we were talking about habits earlier, if you make that your habit, and then save that habit and save the theme and what have you, you are painting a picture where it’s significantly more straightforward because you don’t have to think about it in many cases. Well, that’s the wrong way of phrasing it. You don’t have to do that hard work.

[00:36:07] Jessica Lyschik: Exactly. If you have like a, sorry to interrupt you here, but if you have a theme that already gives you the correct examples, you can build off from that theme. For example, if you’re creating a new template, you can use an existing template and then just adjust it to what you need. If you need to change like colours or something but you have the structure already correct. You do not need to think about doing the structure again and maybe just have a check that it’s actually the right one. But if you just copy what’s already there, that is part of the theme, that’s actually super easy.

[00:36:38] Nathan Wrigley: I’m going to link to your presentation, which I know by the time that this goes out will be probably on wordpress.tv, I would’ve thought by that point. But I’ll link to your presentation and all of the different bits and pieces.

But I’m curious, who in the WordPress space, and maybe not the WordPress space, maybe outside of that, who do you follow or try to get guidance from? Maybe that’s a YouTube channel or a blog, or a, I don’t know, government based website. Maybe it’s just wordpress.org, I don’t know. Where do you go to swat up on all of this?

[00:37:06] Jessica Lyschik: Ooh, there are some very good resources out there. So I do follow like people within the WordPress community. I mentioned a few names already, like Joe Dolson, Rian Rietveld, Amber Hinds from Equalize Digital. They do a lot of stuff in that area. And then I also follow Sara Soueidan, she’s a developer from, I think Lebanon, if I remember correctly. She does great stuff on accessibility. There is a few more names. There are some good resources out there. I can probably research that for you because I cannot remember the names right now.

[00:37:39] Nathan Wrigley: I’m putting you on the spot. I’m sorry.

[00:37:40] Jessica Lyschik: Put me on the spot. That’s okay. I’ll share some links with you that you can then put in with the podcast information. There are some great resources both within the WordPress community but also outside of it that can give you a very good overview. And I think it’s just interesting to follow people who like can build the bridge between, okay, this is a requirement, this is how you technically do it, and this is why you do it.

[00:38:05] Nathan Wrigley: I have a friend who’s recently been on the journey of trying to go from zero to really quite proficient in this space. He’s found a bunch of YouTube channels and several of the names that you mentioned there, particularly the Lebanese lady that you mentioned.

And I think followed a course that they put together and found that structure profoundly helpful. The dry documentation, I think was the way it was described on the WCAG website can sometimes I think be a, you know, it’s hard to get into that in some way.

You know, if this all sounds like a lot of work, there’s definitely resources out there, which, fun is perhaps the wrong word, but make it more engaging. There’s videos to watch, and channels to follow and blogs to read and all of this. And so it turns this, I’m doing air quotes, dry subject into something a little bit more manageable and easy to take in.

[00:38:52] Jessica Lyschik: Yes. Yes, because like the WCAG requirements, like they’re hard to read. It’s like reading, the HTML 5 spec. This is also super hard to read.

[00:39:01] Nathan Wrigley: Yeah, it’s the cure for insomnia.

[00:39:03] Jessica Lyschik: Yeah, sort of. And it’s, yeah, I think if we have, not more content, but the right content available to people in the right spot, I think this will be beneficial for everyone.

[00:39:14] Nathan Wrigley: Yeah. I think unless there’s something else you want to cover off, I think, Jessica, I’ve asked everything I wish to. Is there anything you think we’ve omitted or are you happy to call it a day there?

[00:39:24] Jessica Lyschik: I think we’re, I mean we could go on probably for days. But I think for now it’s, we’ve covered every topic.

[00:39:32] Nathan Wrigley: Well in which case, what I’ll do, dear listener, if you go to the WP Tavern website and search for Jessica’s post, I’m not sure what number it will be as we’re recording it, go there and anything that we discussed, and any names that we discussed and those kind of things, I’ll put a link and obviously if Jessica supplies any other things she mentioned, we’ll add those in as well.

So Jessica, thank you so much for chatting to me today. And now that your presentation is done, you can relax and enjoy the rest of the spectacle.

[00:39:55] Jessica Lyschik: Yes. Thank you so much, and thanks for having me.

[00:39:57] Nathan Wrigley: You’re welcome.

On the podcast today we have Jessica Lyschik.

Jessica is a longtime member of the WordPress community who has been working in the ecosystem since 2015. She has spent years learning and advocating for web accessibility, both as a developer and as an active community participant, joining agencies, working on theme reviews, and helping to improve standards.

Many theme creators assume that making themes accessible is an intimidating task, but Jessica’s here to show you that achieving an accessibility-ready WordPress theme is more straightforward than you might imagine. Her WordCamp Europe 2026 presentation, “Accessibility in themes: easier than you think,” aimed to demystify the requirements for accessible themes, explaining what the WordPress guidelines mean in practice, where the low-hanging fruit is, and how both block and classic themes can reach accessibility-ready status with manageable effort.

We talk about the personal and moral journey that brings developers to accessibility, the technical hurdles and documentation challenges, and the ways in which things like AI agents are putting accessibility in the spotlight for everyone. Jessica talks about practical steps that quickly improve accessibility, like using correct HTML tags, adding alternative text to images, and configuring skip-to-content links, and shares why building accessibility in from the start saves time and effort down the road.

We also explore the differences, and possible advantages, of block themes when it comes to accessibility, why theme guidelines work the way they do, and the importance of interdisciplinary awareness across SEO, design, and content teams. Jessica mentions helpful resources, influential leaders in accessibility, and the ongoing need for documentation improvements to help everyone level up.

If you’ve ever felt overwhelmed by accessibility requirements, or wonder why they matter, and how you can build better WordPress sites that work for everyone, this episode is for you.

Useful links

Accessibility in themes: easier than you think – Jessica’s presentation at WordCamp Europe 2026

Syde

WordCamp Leipzig 2026

 Greyd.Suite

Accessibility Handbook – Theme section

WCAG 2 Overview

European Accessibility Act (EAA)

 Joe Dolson

Rian Rietveld

Amber Hinds

 Sara Soueidan

Open Channels FM: We are Welcoming Automattic as our Newest Sponsor

0

Automattic is now a sponsor of Open Channels FM Podcast Network, supporting creators with tools for WordPress, WooCommerce, and more, promoting freedom online.

Open Channels FM: The Growth of Domain Names and the Future of AI in Internet Identity

0

This episode looks at the evolving online landscape, focusing on domain names, digital identity, and AI’s influence. Key insights include rising domain registrations, AI in managing abuse, and the importance of open source.

Open Channels FM: Open Source and the Open Source Initiative

0

People think Open Source is just about having access to the source code. Actually, there’s a much longer history behind it. Open Source existed before the term Open Source was even coined, back in the late 60s. Universities started giving away software like Unix for free under small licenses like BSD or MIT, coincidentally named […]

WordCamp Central: WordCamp Rajshahi 2026: Celebrating Community, Learning, and Open Source

0

WordCamp Rajshahi 2026, held on July 2nd-3rd, 2026, at the Rajshahi University of Engineering & Technology (RUET) Auditorium, brought together WordPress enthusiasts, developers, designers, business owners, students, and open-source contributors from across Bangladesh and beyond. As a non-profit, community-driven conference, the event demonstrated the strength of collaboration, knowledge sharing, and the spirit of open source.

More than just a technology conference, WordCamp Rajshahi became a place where people connected, exchanged ideas, and inspired one another to contribute to the future of WordPress.

Sharing Knowledge That Matters

The conference featured a diverse lineup of local and international speakers who shared practical experiences, real-world case studies, and emerging trends shaping the web today.

Artificial intelligence was one of the most discussed topics throughout the event. Sessions explored how AI is transforming the way developers and businesses work—from integrating AI into WordPress without writing code to building customer support agents, using modern Large Language Models (LLMs) for development, debugging applications, and improving everyday workflows.

Performance, architecture, and security also received significant attention. Speakers demonstrated advanced WordPress optimization techniques, object caching strategies, no-code animations using GSAP, methods for identifying system vulnerabilities, and practical approaches to cleaning malware-infected WordPress websites with AI.

Beyond technical sessions, the conference emphasized personal and professional growth. Attendees learned about building successful careers, transitioning from startups to multinational companies, product marketing, the realities of remote work, and maintaining mental well-being while working in the technology industry.

Contributor Day: Giving Back to WordPress

Contributor Day, held on July 2, served as one of the most meaningful parts of the event.

Participants worked alongside experienced WordPress contributors and Table Leads to improve the WordPress project itself. Whether they contributed to Core, Accessibility, Themes, Plugins, Polyglots (translations), Education, or Photos, attendees experienced firsthand how community collaboration built the global WordPress ecosystem.

For many first-time contributors, it was their first opportunity to make a direct contribution to one of the world’s largest open-source projects.

Campus Connect: Inspiring the Next Generation

One of the highlights of WordCamp Rajshahi 2026 was the Campus Connect initiative.

To encourage student participation in open source, 40 university students received complimentary tickets to attend the event. This initiative introduced young learners to the WordPress community, allowing them to interact with experienced professionals, attend technical sessions, and discover opportunities to contribute to open source.

By investing in students today, the community hopes to cultivate the next generation of developers, designers, and contributors who will help shape the future of WordPress.

Sponsors Who Made It Possible

WordCamp events are made possible through the generous support of organizations that believe in strengthening the open-source ecosystem. Rather than simply sponsoring an event, these companies invest in community growth and knowledge sharing.

This year, the sponsorship tiers celebrated Rajshahi’s famous mango heritage.

Fazli Majesty (Platinum Sponsors)

Himsagar Legacy (Gold Sponsor)

Amrapali Delight (Silver Sponsors)

Community Sponsors

Official Partners

  • FM Networks (Internet Partner)
  • TNR Soft (Payment Gateway Partner)

Their support enabled the community to deliver a world-class experience while keeping the event affordable and accessible.

Thank You to Everyone Behind the Scenes

An event of this scale is never the work of a single person.

Our sincere appreciation goes to every speaker and Contributor Day table lead who generously shared their knowledge and experience with the community.

We are equally grateful to our organizers and volunteers. From sponsorship coordination, website management, registration, design, photography, audiovisual production, venue operations, food management, and attendee support, every team member played a vital role in ensuring the event ran smoothly.

Their dedication transformed months of planning into an unforgettable experience for every attendee.

Looking Ahead

WordCamp Rajshahi 2026 demonstrated what is possible when passionate volunteers, contributors, sponsors, and community members work toward a common goal.

The event was more than a conference—it was a celebration of learning, collaboration, and the open-source values that make WordPress one of the world’s most successful communities.

As the community continues to grow, the relationships built, ideas shared, and contributions made during WordCamp Rajshahi 2026 will inspire future events and encourage even more people to participate in the global WordPress ecosystem.

Here’s to many more WordCamps, more contributors, and a stronger open-source community in Bangladesh and beyond.

Gutenberg Times: #WCUS Schedule, iframed Post Editor, WooCommerce 11.0 and so much more — Weekend Edition 369

0

Hi there!

What a week! WordPress 7.1 Beta 1 (and Beta 2) arrived with a huge array of updates. We’ll unpack them together over the next four weeks, right up to the final release on August 19, 2026.

One thing shouldn’t wait, though: the security release WordPress 7.0.2. Go update your production sites now — this newsletter will still be here when you’re back. 😉

In this edition, you’ll also find the first speaker lineup for WordCamp US, a fourth page-builder migration story, WooCommerce 11.0 on the horizon, and plenty of block development goodness: from iframed editors to on-brand maintenance pages.

Grab your favorite Saturday beverage and dig in.

Yours, 💕
Birgit


WordCamp US 2026: Four Tracks, Three Workshops, 33 Speakers

First speaker spotlight WordCamp US>

The first wave of WCUS 2026 speakers is live — and it reads like a who’s-who of WordPress in practice.

WordCamp US just published its opening lineup for August 16–19 in Phoenix: 34 confirmed speakers so far, including K Adam White, Brian Coords, Jamie Marsland, Kathy Zant, Miriam Schwab, and Robert Abela, all experienced developers, educators, security specialists, community builders.

The program runs four tracks.

  • AI in Action leads with sessions on agentic workflows, AI search, and guardrails for AI-assisted development.
  • Honing Your Skills covers the practical side: maintenance, privacy compliance, creator commerce, security.
  • Technical WordPress digs into block migrations at scale, WP-CLI automation, and plugin pipelines.
  • Beginning WP101 is the on-ramp for newcomers — or for clients you’re bringing along.
  • Three hands-on workshops round out the program, where you build something real in the room and leave with it.

The full session schedule isn’t out yet, but the speaker list alone is a useful signal. If someone on that page is a voice you follow, a tool you depend on, or a corner of WordPress you’re actively navigating, you now have a specific reason to be in the room.

🎟 us.wordcamp.org/2026/tickets — $100 General Admission · $750 Micro-Sponsor (includes listing on the sponsors page) 👥 Full speaker list →

Developing Gutenberg and WordPress

WordPress 7.1 Beta 1 was release on July 15, 2026. is now available for testing. The release post offers instructions how to sent up a test side and shows an extensive list of new features.

The security team released WordPress 7.0.2 with the urgent appeal to update right away. The security fixes were also backported in 6.9.5 and 6.8.6.

The security fix was also included in WordPress 7.1 Beta 2, so testing sites are also protected during this release cycle.

Huzaifa Al Mesbah, from the Core Test team, published the accompanying Help Test WordPress 7.1 post.

A few WordPress 7.1 Dev Notes are already available:

Plugins, Themes, and Tools for #nocode site builders and owners

In about 10 days, WooCommerce 11.0 release is schedule. Brain Coords has the skinny for you in what’s coming for developers in WooCommerce. Performance leads the release with 28 PRs — product object caching becomes the default for new stores, speeding up variable products by 9–12%. You’ll also find email verification connecting guest orders to accounts, new phone validation hooks, video embeds in the block email editor, and the final removal of the Product Editor beta. The beta is ready for your testing now.


Jamie Marsland followed his instincts and build Jamie’s Front-End Editor for Content Teams, a plugin that lets your editors click any paragraph or heading on the live page and start typing — no block editor required. With the latest updates, you can now edit text, links, buttons and images right on the live page. No wp-admin, no block editor, just click and change it in place.

Built on the Interactivity API with no build step, it preserves block markup on save, records edits as native block notes for an audit trail, and lets you restrict chosen roles to front-end-only editing. Let Marsland what you think.


Last week, I shared three migration stories from page builders to the Core block editor and block themes. Here’s a fourth perspective: The team at WP Expert, an Ottawa agency founded by Frederic Sune, put together a comprehensive post on migrating agency sites from page builders to Gutenberg, should you go on that journey, too. You’ll find the strategic arguments (better Core Web Vitals, smaller attack surface, less technical debt) alongside a practical playbook covering backups, staging, block theme selection, pattern development, and SEO safeguards. The post also explores what block-based architectures mean for an agency’s business model, from premium modernization packages to fewer layout-related support tickets. An FAQ rounds it out.

Theme Development for Full Site Editing and Blocks

Brian Coords tackles a common WooCommerce pain point: custom product templates for block themes. He combines two core WordPress features — the plugin template registration API from 6.7 and the venerable single_template_hierarchy filter — to serve custom templates for product collections, like all products in a category. His example plugin falls back to your Single Product template unless you override it. Clone the repo and give it a try; custom Product fields are next on his list.


On the WordPress Developer Blog, Troy Chaplin shows you how to build an on-brand maintenance mode for block themes. You add one small hook to your theme’s functions.php once, then design and manage the maintenance page entirely in the Site Editor with full access to your Global Styles. Renaming or deleting the template toggles maintenance mode on and off, no code needed. An SEO-friendly variant adds 503 headers so crawlers know the downtime is temporary.

“Keeping up with Gutenberg – Index 2026”
A chronological list of the WordPress Make Blog posts from various teams involved in Gutenberg development: Design, Theme Review Team, Core Editor, Core JS, Core CSS, Test, and Meta team from Jan. 2024 on. Updated by yours truly. 

The previous years are also available:
2020 | 2021 | 2022 | 2023 | 2024 | 2025

Building Blocks and Tools

On WP Mayor, Jean Galea untangles when to reach for WP-CLI, the REST API, or the Abilities API. His mental model: they’re layers, not rivals. WP-CLI lives on the server for bulk work, REST serves off-server callers like headless front ends, and the Abilities API tells AI agents what they’re allowed to do, complete with schemas and permission checks. Galea also shares how his own sites lean on all three at once.


Get up to speed how to make your custom blocks plugin work in the iframed post editor, if you haven’t yet. After five years of ruminating and communicating the switch is coming to WordPress 7.1. In his post, Ryan Welcher explains why the post editor is going full iframe in WordPress 7.1 and what that means for your custom blocks. You’ll find the fixes for the most common breakage — global window and document references, editor styles enqueued into the wrong document, stale admin-scoped CSS, and third-party libraries — plus a companion demo plugin with broken/fixed block pairs, Playground blueprints for testing both states, and a handy pre-flight checklist.


The video volunteers at WordCamp Portugal uploaded all recordings to WordPressTV and two of the talks caught my eye:

Imran Sayed walks you through the fastest way to build Gutenberg blocks with modern tools, scripts, and AI. If custom block development has felt complex or time-consuming, you’ll appreciate his focus on practical, real-world workflows you can adopt immediately — moving fast without over-engineering. The recording is available on WordPress.tv, and the presentation slides are linked below the video for easy reference.

Jorge Costa shows you how to use the AI building blocks already shipped in WordPress core (the WP AI Client, the Abilities API, and the MCP adapter) to bring AI-powered features into your own plugins, themes, and sites. He also tackles the bigger question: when agents can spin up entire projects on any stack, why is WordPress still the right bet? Slides are linked alongside the recording.


Check out the not so new any more Talk Devy to Me series on Ryan Welchers YouTube Channel! In the latest epsiode, Antonio Sejas demos Studio Code, the agentic AI assistant built into WordPress Studio’s desktop app and CLI. You can spin up sites, run performance audits, add content, and install plugins and themes through natural language conversation — all locally, so nothing you break goes public. Sejas explains how it works under the hood before building something live with the host. Studio Code is free while in beta, so now’s a good time to experiment.


If you rather want to read about the updates in WordPress Studio, Fredrik Rombach Ekelund shares three big updates to WordPress Studio: a new default Native PHP runtime makes your local sites load 30–50% faster while using a third of the memory, the Studio CLI now installs with one dependency-free command — no Node.js or npm required — and Claude Sonnet 5 is the new default model in Studio Code, improving multi-step work like tracing bugs across files. A Sandbox runtime remains available for testing untrusted code.


Need a plugin .zip from Gutenberg’s master branch?
Gutenberg Times provides daily build for testing and review.

Now also available via WordPress Playground. There is no need for a test site locally or on a server. Have you been using it? Email me with your experience.


Questions? Suggestions? Ideas?
Don’t hesitate to send them via email or
send me a message on WordPress Slack or Twitter @bph.


For questions to be answered on the Gutenberg Changelog,
send them to changelog@gutenbergtimes.com


Featured Image:


Matt: Important Security Update

0

WordPress 7.0.2 went out today with two important security updates. One is a type of pre-authorization RCE we (fortunately!) have only seen a few times in WordPress’ 23-year history; the last, I believe, in the PHPMailer class five years ago.

Major kudos to Adam Kues of Searchlight Cyber for finding the batch REST API RCE, to TF1T, dtro, and haongo on the facilitated SQL injection!

Thanks to responsible disclosure, the WordPress.org Security team was able to coordinate with hosts and CDNs to mitigate the attack at the network layer. Please upgrade anyway! But it’s a huge relief to know the vast majority of WordPress sites were protected by defense-in-depth even before the updates went out.

I really appreciate how people and organizations that otherwise might not be on the best of terms come together in times like this. (Full credits in the release post.) Everyone buries the hatchet to protect as many people as possible as quickly as possible.

I’ve said it before, I’ll say it again: security is going to be a big topic this year as the technology industry digests the incredible advances in AI models. It’s a good time to review your plans and processes, sweat the details, invest in maintenance, and hug a sysadmin. 🙂

WordPress.org blog: WordPress 7.0.2 Release

0

WordPress 7.0.2 is now available.

The 7.0.2 security release addresses one critical and one high severity security issue.

Because this is a security release, it is recommended that you update your sites immediately. Due to the severity, the WordPress.org team have enabled forced updates via the auto-update system for sites running affected versions.

To manually update you can visit your WordPress Dashboard, click “Updates”, and then click “Update Now”, or you can download WordPress 7.0.2 from WordPress.org. On sites that support automatic background updates, the update process will begin automatically.

Security updates included in this release

The security team would like to thank the following people for responsibly reporting vulnerabilities and allowing them to be fixed in this release:

  • A facilitated SQL injection issue reported as a team by TF1T, dtro, and haongo
  • A REST API batch-route confusion and SQL injection issue leading to Remote Code Execution reported by Adam Kues at Assetnote / Searchlight Cyber

For more information on this release, please visit the HelpHub site.

Backports

  • WordPress 6.9 is affected by both vulnerabilities. Version 6.9.5 has been released containing fixes for both.
  • WordPress 6.8 is only affected by the first vulnerability. Version 6.8.6 has been released containing a fix.
  • The beta release of WordPress 7.1 is affected by both vulnerabilities. Version 7.1 beta2 has been released containing fixes for both.
  • Versions of WordPress prior to 6.8 are not affected.

CVE and GHSA references

Thank you to these WordPress contributors

This release was led by John Blackbourn and Barry Abrahamson. In addition to the security researchers mentioned above, WordPress 7.0.2 would not have been possible without the significant contributions of the following people: Aaron Jorbin, Alex Concha, annezazu, Barry, David Baumwald, Dominik Schilling, Ehtisham Siddiqui, Joe Dolson, Joe Hoyle, John Blackbourn, Jonathan Desrosiers, Marius L. J., Matt Mullenweg, Mohammad Jangda, Peter Wilson, Sergey Biryukov, vortfu, Weston Ruter, plus representatives from Altis, Automattic, Bluehost, Cloudflare, GoDaddy, Hostinger, and WP Engine.