WordPress Planet

October 15, 2026

WordCamp Central: WordCamp Jinja 2026 Recap: Three Tracks, Two Days and Creative Currents on the Nile

On 19th and 20th September 2026, the WordPress community gathered at Civil Service College Uganda, a venue close to River Nile, for the fifth edition of WordCamp Jinja. The event brought together more than 300 diverse participants across 2 days and 3 parallel tracks of sessions full of learning, collaboration and connection. In a city known for its flowing waters, creativity and ideas flowed too, as participants shared their experiences, explored new possibilities with WordPress and built relationships that would carry beyond the weekend.

Our theme, “Embrace Creative Currents on the Nile: Where Inclusivity Fuels Creativity,” reflected the mix of people and ideas in the room. Students sat alongside developers, designers, writers, educators, entrepreneurs and experienced WordPress contributors. Across three parallel tracks, everyone could find a way to learn, share or build.

Students and Creatives at the heart of WordCamp Jinja

Nearly half of this year’s participants were students. Their presence was felt throughout the event, from the speaker sessions to the labs and hackathon tables. We had students from primary schools, secondary schools and universities joining us for this year’s WordCamp.

Some came to explore WordPress for the first time. Others arrived with projects, questions and skills they wanted to develop. Sharing the same spaces with people already working in technology and creative fields gave them an opportunity to learn directly from practitioners and see where their own interests might lead.

One student in attendance found a creative way to remember his experience. Fascinated by the WordPress ecosystem, its generosity and inclusivity, he drew all the sponsor logos by hand so he could remember them after the event. His drawings became a personal record of the community he had encountered at WordCamp Jinja, a small but memorable expression of the curiosity WordCamp Jinja inspired.

Bringing young people into the community has been a continuing part of WordCamp Jinja’s work. Last year’s edition at Jinja Senior Secondary School brought the event closer to students; this year, their participation remained central even at a different venue. We hope the relationships formed over these two days continue at Jinja WordPress Meetups and in the projects students choose to pursue next.

Event highlights

Diverse Speaker Sessions

Our speakers brought different backgrounds and experiences to the stage. Sessions opened up conversations about WordPress and the wider web, including how people use technology to create, teach, solve problems and build livelihoods.

The value of these talks was in the experiences behind them. Speakers shared what they had learned through their own work, answered questions and gave attendees ideas to take back to their studies, organisations and businesses. Thank you to everyone who prepared a session and made the journey to Jinja to share it with us.

Charity Website Hackathon and Contributor Sessions

The Charity Website Hackathon returned as one of WordCamp Jinja’s most practical activities. Participants and facilitators worked together on WordPress projects for organisations seeking to establish or improve their online presence. The teams had to think about real needs: what information a visitor should find, how to organise it and how the organisation could keep its site useful after the event.

For newer participants, this was a chance to learn by working through a real project with support close at hand. For experienced developers and designers, it was a chance to mentor others and put their skills to work for the wider community. The work begun at the hackathon can continue beyond the conference as teams and organisations develop their websites further.

Contributor activities connected that local work to the wider WordPress project. Attendees explored the idea that contributing to open source goes beyond writing code: people can help through photography, translation, testing, documentation, training and community work. There were a lot of new contributors who were taken through the contribution journey by table leads. We hope that for those that took their first steps, WordCamp Jinja will be the beginning of a longer contribution journey.

Hands-on Labs

The Hands-on Labs offered a different pace from the speaker sessions. Instead of only listening, participants could practically follow a facilitator on state of the art computers, try something themselves and ask for help when they needed it.

That kind of guided practice matters, especially for people who are new to a tool or trying to turn an idea into something they can build. Thank you to the facilitators who prepared the activities and worked directly with participants, and to the volunteers who helped make the sessions run.

Memorable moments, connections and networking

Some of the weekend’s most useful moments happened away from the front of a room. Over lunch, in the corridors and between activities, attendees met people from other communities, exchanged ideas and caught up with friends they had met at earlier WordPress events.

For a student attending for the first time, a conversation with a developer or designer can make a possible career feel closer. For returning community members, it was a chance to meet new collaborators and hear perspectives they might otherwise miss. Those connections are part of what keeps WordCamp Jinja going after the closing session.

Celebrating at the Source of the Nile

The celebration continued at Source of the Nile for our after-party, where attendees, volunteers, speakers, facilitators, sponsors and organisers were welcomed to the Source of the Nile. Unbeknownst to them, there was a surprise awaiting: an after party aboard a double-decker boat. The boat ride took them on a tour of Lake Victoria and finally landed at the actual source of the Nile itself, where they learned about its history before taking time for photos together.

The Nile has been part of WordCamp Jinja’s identity across previous editions. This year, gathering there brought our theme back into focus: people with different skills and experiences had come together, learned from one another and added something to the community.

The people who made it possible

WordCamp Jinja is built by volunteers. Long before the doors opened, the organising team was working on the venue, programme, speakers, communications, sponsorships, registration and practical activities. During the event, volunteers welcomed attendees, supported speakers, guided participants and helped the different spaces run smoothly.

To our attendees, thank you for showing up ready to learn and share. To our speakers and facilitators, thank you for the time and care you put into your sessions. To the hackathon teams and contributors, thank you for building and giving back. And to every organiser and volunteer, thank you for the work people saw and the work they did not.

We are also grateful to our sponsors Jetpack, Hostinger, WordPress.com, Woo, Hosting.com, SEOPress and Infinity Computers and Communications Company (i3c) and to our continued local community partners for supporting an accessible gathering for people at different stages of their WordPress journey. Their support helped bring this fifth edition to life.

Relive the weekend and keep in touch


You can explore photographs from the event in our WordCamp Jinja 2026 photo album:
https://photos.app.goo.gl/Fd61HxxyNT8xK4Ni7

WordCamp may be over, but the learning continues. The Jinja WordPress Meetup will keep bringing people together to share skills, contribute to WordPress and build on the projects and relationships started here.

Thank you for embracing the creative currents with us. See you at the next WordPress Jinja event!

by Joan Namunina at October 15, 2026 07:54 PM

bbPress: bbPress 2.6.20 is out!

bbPress 2.6.20 is a security and maintenance release. Everyone running bbPress should update. 🔒

This release strengthens topic and reply password validation and keeps bbPress post shortcodes literal in ordinary WordPress content loops. It also adds a site-wide Forum Status setting with Open, Closed, and Frozen modes. Existing sites remain Open unless that setting is changed.

The maintenance work improves BuddyPress profile actions, group topic routes, activity visibility, and group-forum access. It also restores compatibility for subscription links in third-party theme packages, preserves moderation forms after validation errors, and includes fixes for notifications, converters, widgets, profiles, topic and reply administration, and restricted-content visibility.

bbPress 2.6.20 still requires WordPress 6.0 or newer and PHP 7.2 or newer, and is tested through WordPress 7.1. The database version remains 264, so no database upgrade is required. The 2.6.20 upgrade notes cover compatibility details.

These changes are also in the 2.7 development branch, which remains 2.7.0-alpha-4. Thank you to ahillmortons, alejandroescobar89, bor0, bradleyt, chefranov, dd32, deborah86, Dermes, diegootgs, dilip2615, fraph24, hardel, imath, immeet94, iworks, jgasba, josephscott, konnektiv, lmstearn, mehrazmorshed, michael8888, mike80222, obenland, Palagrin, peopleinside, r-a-y, robin-w, SirLouen, tobifjellner, wpturk, and zaerl for reports, patches, testing, and review.

Download bbPress 2.6.20 from WordPress.org, or update from your WordPress dashboard.

by John James Jacoby at October 15, 2026 05:46 PM

Open Channels FM: The Hidden Dependency Problem in Open Source Infrastructure

When we think about what keeps the Internet humming, most of us imagine massive data centers and super-fast connections. Fewer people realize that our everyday digital experiences often depend on the efforts of a very small group of individuals. Recent analysis revealed that in many essential open source projects, just one or two people are […]

by Open Channels FM at October 15, 2026 03:30 PM

October 14, 2026

Open Channels FM: Rethinking Access and Dependence in Tech From AI Outages to Open Source Lifelines

Who maintains education AI, the backbone of software infrastructure, and a new open source document tool.

by Bob Dunn at October 14, 2026 02:00 PM

WPTavern: #237 – Robert Abela on WordPress Security and the Battle Against AI Threats

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, the state of WordPress security in 2026, and the battle against AI threats.

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 Robert Abela.

Robert has been working in IT security for 25 years, ranging from antivirus software to web security scanners, and for the past decade has been running Melapress. A company focused on WordPress security plugins, particularly around user visibility, authentication, activity logs, and 2FA.

Robert is here to talk about the 2026 WordPress security survey. This is an annual project now in its fourth, or fifth, year gathering data from a wide range of WordPress professionals across agencies, enterprise teams, freelancers, and product owners. The conversation today is focused on the biggest security challenges and trends facing WordPress users in 2026.

We start off with some sobering stats. Over 67% of survey respondents reported experiencing at least one security incident in the past year, and concerns about WordPress security remain high, especially among less technical users.

We chat about the disconnect between awareness of security threats and actually taking steps to mitigate them, such as breach recovery plans and team training.

The discussion also explored the different types of risks that worry site owners. Site downtime, defacement, reputational damage, data loss, and even legal compliance issues. How the shakeout depends on the type of site, whether it’s e-commerce membership, a news outlet, or a simple brochure site.

We also talk about the tendency for even experienced WordPress users to take a reactive approach, only addressing vulnerabilities after something has gone wrong.

Towards the end of the episode, we discuss the rising impact of a AI on security, the explosion of AI facilitated vulnerabilities, and the shifting landscape of risk and response. There’s a healthy dose of reality, some optimism about the tools and best practises available, and plenty of good advice, especially for smaller teams and freelancers who may not have access to enterprise level resources.

If you care about keeping your WordPress sites secure, or want to understand where the community’s biggest concerns and opportunities are in 2026, 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 Robert Abela.

I am joined on the podcast by Robert Abela. Hello, Robert.

[00:03:48] Robert Abela: Hello Nathan. Thanks for having me.

[00:03:50] Nathan Wrigley: You’re very welcome. Nice to have you with us.

We’re going to chat today about internet security, but we’re going to be looking back over the past year, so the year 2026. Robert, can tell us a little bit about the company he founded, works for, and so on. It’s called Melapress, you can find out about that in just a moment.

But I would like to draw your attention to something which is going to really be the fulcrum of what we talk about. It is their 2026 WordPress Security Survey. Now, the easiest way to get that is probably to go to wptavern.com, search for the episode with Robert in it, and I will make sure it is linked in the show notes there.

But it might be a good idea to read it, because in about 10 minutes, you’re going to be able to capture absolutely everything that we’re talking about today, and you’ll get all of the data and, what have you. But that’s going to be the point of this episode, summarizing what happened in the security space in WordPress in 2026.

Robert, I guess there are a few areas in the WordPress space where it’s pretty important to know that we know, that you know, what you’re talking about when it comes to security, because we don’t want to have a lot of hot air from somebody who’s not experienced. So it’s an opportunity for you really to give us your bio and tell us a little bit about what you’ve been doing in the WordPress space, particularly around security, the companies you’ve worked for, the things that you’ve founded and so on. So over to you, Robert.

[00:05:07] Robert Abela: Thanks. I’ve been working in IT security for twenty-five years. I’ve always worked for software companies, software startups which worked in security industry. We used to do antivirus software, web security scanners, et cetera. I’ve had different positions. I started as systems engineer, QA, product management, project management, almost any field.

Anyway, and the last ten years I founded Melapress, and it’s a WordPress plugin business, and basically we develop a number of security plugins for WordPress. The security we do, we don’t do the typical firewall malware, et cetera, like the other, brands. We mostly focus on user visibility and authentication. So basically we have an activity logs plugin, and we also have a plugin for 2FA, passkeys et cetera. So we are focusing much more, on what happens post login once someone logs into WordPress, rather than the whole hardening and protection.

[00:05:56] Nathan Wrigley: Thank you for that. So anybody that’s interested, anything that we mention today, including the URLs of the companies that Robert has just mentioned, so Melapress, you’ll be able to find those in the show notes as well.

So the 2026 WordPress Security Survey, how many times have you actually run this? So obviously we’re looking at the 2026 version. Have you done this a couple of times and refined the way that you’ve done it and the way that you’ve surveyed over many years?

[00:06:21] Robert Abela: Yes. I’m not sure if this is the fourth or fifth year. But yes, we do every year, we’ve had more respondents. This year, by the way, it was the highest ever with 219 respondents. We had more, but before we publish all the results, we go through the sheet. Maybe there are some duplicates. Maybe some of them are not correctly filled in, et cetera.

But yeah, we’ve been doing it for around four years, and we’ve also fine-tuned from where we gather the data. For example, the first year, we’re only sending our newsletter basically, but this year we’ve done a lot. We’ve promoted the survey through third parties. We’ve gathered responses from WordCamp Europe, in person, through a number of other conferences, et cetera.

So while there is still a percentage that most probably are our users or our clients, still the biggest percentages is spread out to a wide range of different type of WordPress users, ranging from people who work for agencies, developers, designers, but also people who work with WordPress in bigger enterprises or businesses.

[00:07:15] Nathan Wrigley: Okay, so yeah, caveat emptor. With that in mind, the limitations, or otherwise, of the numbers that you’ve got represents what you’ve got in this survey.

And essentially, what it boils down to is a, it was kind of a bunch of questions which then led to a bunch of information being spat out the other side. And I’ve summarized it into about 10 bullet points. It may very well be that I’ve missed a few bits and pieces, but be interesting to go through, and you can lend your experience as to whether or not there’s been any change, whether things have got worse, whether things seemingly have got better.

We’ll begin, if it’s okay with you, with the top item, which I suppose, came out, which was a concern around WordPress’s security, or the things that can happen around WordPress and security. And what came out of it was that 7.85 out of 10, so 78 and a half percent, I suppose you could describe it as. They were developers who were expressing basically that they were concerned.

Now, I don’t know if you have more telemetry, like what concerned means, but off the face of it, that seems like quite a high number. If the platform that you’re using to build websites, you are in the sort of mid-70s concerned, is there anything you wanted to add to that or is that just the sort of top level statistic?

[00:08:28] Robert Abela: No. That was like a top-level statistic, a question we ask, like if people are concerned or they have worries about their WordPress, the security of their website.

What’s funny is the last few years, the level of concern has been the same. However, also we’ve noticed that people who have some sort of recovery plan, et cetera, also remains the same. So the level of concern has remained the same. So the majority of people know that something can happen to their WordPress website, especially now with AI, et cetera. It’s even more, things are moving much faster.

However, it seems like people are not taking the next step, as in like taking action to make sure nothing happens. What I’ve noticed as well, once we break down those who have concerns and what job they have, if they’re developers, or with their security people, et cetera. There’s this correlation, like, the more informed someone is, the more is involved in the tech aspect of the website, the more understanding they have on how things work, the less concerned they are.

So maybe it could also be education or awareness because of course, if you don’t know about how something works, then of course you are much more concerned. How you’re going to protect it? However, if you are, let’s say, a developer and has an understanding of sessions, cookies, the usual things, like passwords, maybe you’re a bit less concerned because you feel you are a bit more in control of how you can protect your website and what you can do.

[00:09:39] Nathan Wrigley: It seems like on the face of it, I should say, it seems like 78%. It seems like quite a lot.

[00:09:44] Robert Abela: Yes.

[00:09:45] Nathan Wrigley: If I had any kind of intuition, let’s say I was to go out into my car and drive around the street, if I thought that 78% of the time there was going to be some potential accident. Or I was worrying of the time about the possibility of an accident, I don’t think I’d be getting in the car. So it’s kinda curious. But, let’s move on.

So the next data point that dropped out was 67.7%, so let’s call it 68% of respondents. Now this is fairly shocking, and maybe this number will actually start driving up in the years to come, and we can get into that later.

68% of respondents had experienced at least one known security incident, with many multiple incidents. Now, that really is shocking to me. Closing in on 70% of people have had some kind of incident. I don’t know what, or maybe you do, what the magnitude of that is, but did that surprise you? Did that seem like a really large number?

[00:10:38] Robert Abela: 67.7 of all respondents, correct, they reported one security incident. I’m not surprised because almost everyone I speak to at WordCamps, even non-WordCamps, other events, someone down the line has had some security issue. Not just with WordPress, but especially with WordPress. And the funny thing, it’s not even funny, but 13.2% of those are repeat targets, which means they have experienced more than five security incidents.

Now, why does it happen? There are a number of reasons. Outdated software, lack of user awareness. In fact, what’s really more concerning is, I have some numbers here actually I can tell you. Yes, we’re still looking at some other statistics. Only 27.9% reported like they have some sort of training for their users. And only 37% use logs. At least 2FA’s a bit higher, it’s around the 40% something. I don’t have the exact number right now.

So yeah, so I’m not surprised because there is still a lot that can be done from website owners, from agencies, from everyone, to make sure we take down that number, and not everyone. Or so not the majority of people experience some sort of security incident on their website.

[00:11:41] Nathan Wrigley: Yeah, it’s curious. It’s not really a conversation. When I’m at events or chatting to fellow WordPressers, security is not the default conversation that I have, because I’m not a security person. So I end up chatting about, I don’t know, custom post types and how to do various things that I’m doing. Maybe podcasting in the WordPress space or something along those lines.

You, I guess, are having these conversations, and it’s very much in the territory. It’s in your wheelhouse. And so maybe it’s not a surprise to you that 67-plus percent of people have had something in the last year. But, on the face of it, that just seemed like so many. If I see 1,000 people at a WordCamp and I think, “Well, 670 of those have had a problem during the course of this year,” gosh that really does seem like a systemic problem.

And I know that outside of the WordPress community, WordPress gets a bit of a hard rap, on the security front. It’s insecure and what have you, and, all of the caveats. We know that really isn’t typically the case for WordPress Core. Tends to be the addition of code and plugins and themes that adds that on top. But I’m still surprised, feels almost like if the mainstream press got hold of your survey and just pull out that one statistic and bandy it around, it doesn’t feel great, if you know what I mean.

[00:12:53] Robert Abela: Yes. I think WordPress gets a lot of bad rep also because it’s very popular. As in like pre-WordPress, I’ve used web servers before as in like custom PHP websites, .NET, IIS, Apache, et cetera. Websites used to get hacked as well in the thousands. The thing is that you couldn’t point your finger to one type of website, you know because they were all custom. So these problems have been happening since we started having websites, quite frankly.

With WordPress, unfortunately it happens and we have a bad rep because I think there are two things. Look, first of all, it’s very popular, so it’s always there. If WordPress power is around 42, 43% of the, or maybe it went a bit down, but anyway, let’s say 40%.

[00:13:30] Nathan Wrigley: Roughly, yeah.

[00:13:32] Robert Abela: Yeah, The chances, for every 10 websites, four of them are going to be WordPress. That’s a common denominator. So of course, WordPress is going to get a lot of attention.

I also think, again, goes hand in hand with how many people have security concerns. WordPress has made it very easy to launch your own website, which is a good thing. However, of course, those same people who launch their own website, maybe they don’t have the technical understanding and experience what it takes. Because setting up a website’s one thing, but keeping, managing a website for a year, two, three, and growing it, adding new functionality is another thing. So most people might not have the experience that they have, so of course, it’s much easier to find security issues with these type of websites.

[00:14:10] Nathan Wrigley: Okay, we’ll move on anyway. So we’ll talk about the concerns. So you’ve obviously polled your recipients of the survey about the kind of things that they were worried about. So what are the outcomes that they fear the most, if you like?

And website availability, so the taking down of a website came in at number one, with 55.8. And then in no particular order, but these are the two that I picked out. The fear of being defaced, so the website in some way being amended, or there being some reputational damage because of what the amendment was. I don’t know, maybe there was some imagery, or some slightly political content that ended up on your website.

That was just slightly south of the availability, so that was 54.2%. And then dropping a full 10%, so 46.4%, was the worry about data theft or loss. Frankly, I’m not surprised by that. I guess any developer’s nightmare is their website actually disappearing off the internet. That’s number one, so that doesn’t surprise me.

I remember in the day, 15 years ago, defacement was the thing. Honestly, I can’t say that I’ve been browsing the internet recently and seen something that’s been defaced. It seems like the hackers have all moved on. Maybe there’s things buried in the source code that I don’t know about.

Yeah, it doesn’t surprise me that the availability is the main thing. But I am surprised that data loss comes in third, if you like. I personally would have had that as number one, especially, if you’ve got a, I don’t know, an LMS, or you’re connecting with a CRM, or you’ve got form data which potentially is capturing something personal that the GDPR would worry about. So there’s no question, just if you want to comment on those particular things, go for it.

[00:15:42] Robert Abela: No, definitely. Those are the numbers based on all the respondents. But if you start breaking down the numbers, there’s more nuance to, to these things. So for example, if you look, those who are concerned about website availability, or defacement, are usually those who have content websites. Mostly based on content, news, magazines, et cetera. Those who are more concerned about financial loss or data theft are more the e-commerce websites.

[00:16:08] Nathan Wrigley: Oh that makes sense. Yeah.

[00:16:09] Robert Abela: The membership websites, et cetera. In fact, the membership websites are as well more concerned, for example, about compliance because of privacy. So those numbers, like fifty-five point eight percent, those are from the all respondents. But as soon as you break all that down, it differs a bit on the type of website you have.

And it’s expected because if you have an e-commerce website, of course you are dealing with billing details, payments, and all this stuff. If you have a membership website, maybe you are also dealing with payment details, but you are also dealing with much more data. Maybe you have some sort of internal chat. People are sharing their addresses on it, their personal information. So that you are more concerned about GDPR or any sort of compliance, et cetera.

But if your main selling point is if you have a content website, a news website, and your main selling point is your website being available, then of course that is your biggest worry.

[00:16:53] Nathan Wrigley: That’s an interesting split of the data there. That makes perfect sense, of course, now that you say it in that way it really is obvious.

So that was you polling your respondants respondents there, and you were trying to figure out what their worries were and what they were into and all of that kind of stuff.

And then we sort of to move to a different realm where despite all of that being said, so, you know, got a lot of people worried. We’ve outlined some of the different worries that they have, depending on the type of website that they’ve got.

From all of that, if you’d have ended the survey there, I would have assumed at that point that everybody had something in the back pocket to pull out, an SOP or something like that, to pull out in the event of an actual problem. If data theft is apparent, we do this. If the website goes down, we do this. But your survey reveals entirely the opposite.

So the high numbers on the one side, the fear numbers, are not mirrored by the what we’re going to do about it numbers, because you go straight into the high 20s, so 27.9% had a breach recovery plan. So how to get back from a problem with your website being, let’s say, hacked, let’s use that word. And 26% provided some sort of training for their team, some sort of security team training, that kind of thing.

Again, does that surprise you? You’re in this space. Maybe that’s really typical, but given the high levels of concern, there seems to be a real disconnect with what we’re going to do about it. That’s curious.

[00:18:18] Robert Abela: I’m not surprised, in the sense, it’s very common. The majority of people, especially nowadays, there’s much more knowledge that, yes, websites can be hacked, this can happen. However, that doesn’t translate. People don’t have the, I don’t know if it’s the resources, the means, the time to actually take action on it, to prepare some things. So, I’m not surprised.

Again, similar to what we discussed before, there’s a bit more nuance to these type of numbers because you said only 27.9% has a breach recovery plan. Actually, that’s based on all the respondents, but typically the number is much less, because when you look at it, from the respondents, from all those who have a security breach, from those 27.2%, 70.2% which have control in place are corporate or brand websites, which means they have their own in-house team. Only those, 70% of those have their own, have their activity logs, have their firewalls in place, have a recovery plan in place, et cetera.

So the number of, let’s say, the non-branded, the smaller websites, yeah, they have absolutely nothing. They have no sort of recovery plan or anything like that. In fact, the numbers are much smaller. Only 23% of those websites typically have some sort of recovery plan.

[00:19:23] Nathan Wrigley: Okay.

[00:19:24] Robert Abela: I’m not surprised because usually, especially if you’re an enterprise, or a bigger business, you are bound by more compliance. Maybe you have more security people on board who are much more aware what can happen of what they need to do. But yeah, the average website doesn’t have these things.

[00:19:38] Nathan Wrigley: Yeah. I wonder if your data here might be skewed by the type of correspondent that you got. So for example, who knows how many blue-chip companies, have submitted to your information gathering here. Perhaps not many, but maybe you got lots of WordPress community members, and so the data might be skewed in that direction. But that’s an interesting point. So dependent upon the nature of the website and the type of team they have behind it.

But it is still, regardless of all of that, it is still quite low. And I was using my analogy earlier about insurance, and I think that applies here. Insurance is the most uninteresting thing to purchase because you spend this money and, let’s say for example, you got home insurance. I would imagine most people typically go through a year and they never make use of it. Sorry to anybody listening who has obviously had to make use of that. But the moment you need it is the moment that you’re glad of every single penny that you’ve sunk into that, and I guess that applies here. If we can persuade people to get that data breach recovery plan, whatever it may be, have that in your back pocket, that would be a useful thing to have.

[00:20:38] Robert Abela: Yeah. As I’ve said in the beginning, I’ve been working in IT security companies, security software companies for 25 years. All of them, the most common sales opening, like sales reason, like people coming to us like, “Hey, this happened, so now I need this.” They’re always after they’ve been hacked, after they’ve been a leakage, after there’s been something wrong.

Very few proactively come and as I said, like the bigger enterprise companies, because they have certain regulations and stuff and certain budgets that they invest in these things. But the average website, yes, first they have to experience something, and then. I think it’s, in all fairness, I think it’s common human nature. It’s not just about IT. We tend to be all humans. We tend to be like, “Oh, we’ll see later,” and then if it happens, “Ooh, I should have…” it’s always like that.

[00:21:17] Nathan Wrigley: Well, there’s also that calculus of how much time does it take to recover. So for example, if you’ve got a brochure site, and you’ve got backups going back for many many months you can restore to a point that you’re fairly sure that everything was actually fine, and the breach has been mitigated by going backwards in time. But it’s just all the wasted time. It’s the wasted time going through the backups and seeing, okay, is this backup, does it have the malware in as well? Okay, that one does. What about this one? What about this one?

And there’s no knowing how long that’s going to be, and the minute you step, as you said, into e-commerce and you’ve got transactions happening every couple of minutes, and then you’ve got receipts and you’ve got to fulfill those orders, and somehow, oh boy, yeah.

[00:21:59] Robert Abela: Yes. Then it’s a different ballgame. Yeah.

[00:22:02] Nathan Wrigley: Different ballgame isn’t it? Yeah.

Okay, so the next point that we’re going to move on to is actually one that you probably just made. And it’s that the detection in most cases, well actually not most cases, in many cases. So 42.6% of your respondents said that their detection is mostly retroactive. So that is to say the thing has already gone wrong. Somebody in the 42.6% of the case is because they see something on the website. They’ve noticed that something isn’t quite right, something looks out of order.

38.4% because they were actually inspecting the logs. That tells me that whoever’s inspecting the logs is doing diligent work. That’s kind of interesting. So don’t know if you want to comment on that, but basically a lot of people are figuring this stuff out after the thing has happened, as you described, not before the thing has happened.

[00:22:51] Robert Abela: Yes. So there are four criteria. So 42.6%, as you said, is common website behavior, either detected by their team or by clients. 38.4 via logs. Now, the logs is a bit, it can be reactive and proactive, because with the logs, you can actually, in fact, we have some notes on this, but I don’t have the exact numbers right now. Because some of them were actually by someone analyzing the logs, but some of them were actually because someone has configured notifications based on the logs, like a sort of intrusion detection system.

And so if, I don’t know, if X login happens after X time, whatever, please send me an email or an SMS, and that, it’s still reactive in a way, but at least they could act right away as soon as it’s happening. Yeah.

[00:23:31] Nathan Wrigley: Yeah kind of proactive reactive, isn’t it? That’s a really interesting subcatagory.

[00:23:33] Robert Abela: Exactly, yeah.

[00:23:34] Nathan Wrigley: Yeah.

[00:23:34] Robert Abela: So yeah, but yeah, it’s still reactive because then you have 35.6% they knew through their web host, and 30% they knew through some sort of malware scanner alerts on their website, et cetera.

[00:23:45] Nathan Wrigley: Okay. Again, just kind of interesting data coming out.

So the next one, incidents most commonly resulted in downtime for the website. So that’s pushing up to 70%, 68.4% of whatever happened, resulted in some downtime. And then I don’t have the numbers for the following data, but I guess it decreases from here.

The next thing was reputational damage. That was a result of some sort of incident. And then search engine ranking is affected. That’s an interesting byproduct.

This one’s brutal. Client trust disappearing. That’s really interesting. And then in some cases, lost revenue. I imagine the lost revenue is being described as in some cases, because, as we described earlier, if you’re dealing with revenue, you’ve probably got more bulletproof security measures in place.

But the ones that sort of jump out to me there aren’t the downtime, because I would’ve assumed that. It’s really the curious byproducts of things like the reputational damage, the search engine damage. You can’t really get your hands on those, can you? There’s no real way of knowing what that’s going to look like or feel like, or how that’s going to affect your business this year or next year.

Just to know that, you wake up one morning to discover that you were in first place on Google after six years of hard SEO work, only to discover that you’re now in fourth and descending fast, that’s pretty brutal.

[00:25:01] Robert Abela: Yes. And in fact, if you break down those numbers a bit more, like 45.9%, there’s loss of search engine ranking, and that happens usually when search engines detect you have issues. I don’t know if you remember, Google used to have that page sometimes.

So that happens. When that happens, when the search engine themselves realise there’s an issue, you lose a lot of rank. The penalty you get there is very heavy. In fact, only 14.5 of those who have had some issues with the website has lost ranking because they have discovered their issues before the search engine did.

So again, that’s why you should be a bit more proactive because if your search engine finds out before you, the penalty, as you said, and you cannot really quantify it because God knows how long you will remain. As you said, if you were position one for six years in a row, now one fine day you’re on the second page, God knows how much work you need to go back up, and you cannot even calculate what the revenue loss is.

But when it comes to revenue loss, again, it’s the same. There are some websites, I’ve seen some websites where like they generate $70,000 per hour. So for every hour down, that’s $70,000 gone.

So yeah, there are lots, and of course, the reputation, on top of the reputation, there’s also compliance and legal consequences, especially in the US. Things are becoming much stricter now. If you had some issue, some customer data has been leaked, you have problems with the law, fines, and other similar stuff. So, the financial damage to all of this, of your website getting hacked, is very high.

Not just the reputation, losing customers, you might end up in court. You might lose your search engine ranking, and that is why most probably it’s a good idea to become a bit more proactive rather than reactive. Or it’s almost impossible to, there is no 100% secure solution, and that is why I think it’s very important to have good hardening, but also good monitoring, the whole process, the whole 360 degrees, the whole cycle.

[00:26:44] Nathan Wrigley: It’s such a curious industry that you’re in because, how to describe this? It would seem, or at least, it would be possible to perceive that this security survey is perfectly aligned with your business goals in a way. There’s loads of problems out there on the internet. There’s multitudes of ways that things can go wrong, and for every one of them, there’s, a WordPress solution out there.

But I know Robert. We’ve met many times before. I get the intuition that’s really not why you’re doing this, although somebody listening to this might have that sort of slightly, I don’t know, cynical approach that, Robert’s just saying this so that he can launch his Melapress products at you. Just put our minds to rest on that score. Why do you actually carry out this survey?

[00:27:25] Robert Abela: Good question. Actually, our plugins only address part of the security. There’s much more when it comes to firewalls, et cetera, that I still say hardening you still need. We don’t even cover it.

No, we do it, honestly, it started around four or five years ago, for me, it was just curiosity. It sounded like an interesting to do. Hey, let’s do a survey, just experimenting, et cetera. And we had very good response, and now we’re just, doing it honestly.

Like I really believe that by knowing, this is not just about WordPress security, about everything else. By knowing where other people are doing it wrong, you will learn from it. By knowing, okay, clearly I can see, for example, as we were saying, like seventy percent, seventy point two percent of enterprise and marked businesses usually have logs, usually have firewalls, et cetera. Maybe we should aspire more towards them and be more like the average website should have a bit more like things like that, and maybe they’re doing something right.

So yes, there is a lot to learn from surveys in general, not just this, any type of survey. There is usually a lot to learn. And that’s why we’re doing it as well, because from the first time we’ve done it, which started really as a curiosity project, we got so much good feedback. And actually the second year people were asking us if we are going to do it. Because yeah, people learn from these things.

I mean, of course there’s the benefit of it, hopefully it will promote as well a bit our plugins. But anyway, it’s going to promote all other type of security solutions. We are not, in fact, the survey is not tailored just for our plugin. It talks about everything. As I said, the whole security cycle. You have the hardening, you have the monitoring, updating, et cetera, and we only do one part of it, the monitoring aspect, basically.

[00:28:50] Nathan Wrigley: Before we move on to our sort of final bit, which I want to concentrate on AI, I’m just going to wrap up the security bit just by summarizing what comes towards the end. And it’s less about numbers, and it’s more about just conclusions that may have been drawn. But most of it, I think, would be fairly obvious from what we said. So I’ll just summarize it a little bit.

The first one is that e-commerce and membership sites tend to have greater security concerns and stronger practices. That kind of makes sense. I guess it reflects the nature of the business they’re in, and the kind of data that they’re holding, and the legal compliance that they may need to be concerend with.

In-house teams are more likely to have recovery plans. Again, I presume that’s fairly obvious. The boss, the head of the pyramid can sit down and say, “Okay, it’s your job now to crack on and do that. You’ve got a week to figure out all this sort of stuff,” and what have you. Whereas a freelancer sitting in their own office, there’s always regular work to be built, sites to be built and other things to do. So I can well imagine why that’s the case.

And sites, again, fairly obvious, sites with repeated security incidents tended to have stronger controls in place. Today, presumably, it’s a case of once bitten and all of that. Once you’ve actually had this nasty stuff happen to you, you’re pretty likely to make sure that does not happen again.

In summary, I suppose the reports really, the recommendations are focus on prevention, detection, and recovery rather than simply adding in more security tools, would be the way that I would describe it.

Okay, let’s move on then just before we finish. It is, as we’re recording this, it’s September 2026. In the more recent past, I want to say, I don’t know, the last two months, something like that, the WordPress security news bulletins have been on red alert really. We’ve had some charts being put out on social media which show the amount of vulnerabilities discovered, and also the amount of AI-based plugins that have gone into the repository. The supply chain attacks that have suddenly become a thing. A lot of it really because people can corral AI to do mischievous stuff and what have you.

I don’t really have a question, but I just wondered if you had a comment on where we are in September 2026, because it does feel as if there’s quite a lot of, there’s a lot of scope to be very doomer at the moment. It almost feels like the AI is winning the arms race, but maybe that’s not what you’re thinking from your end.

[00:31:04] Robert Abela: No, it looks a bit negative. I wouldn’t say AI is winning the race. Actually, people with malicious intent using AI are winning because AI is neutral in a way, like it depends on what people ask the AI to do.

[00:31:15] Nathan Wrigley: Yes.

[00:31:16] Robert Abela: But it is worrying, yes. The graph you are mentioning, I saw a graph shared by John Blackbourn, yeah, about the number of issues reported in the HackerOne WordPress vulnerability program, which is insane.

[00:31:28] Nathan Wrigley: Yes.

[00:31:29] Robert Abela: And they received more reports in the last week than they ever did in a whole number of months. So yes, it is worrying. You can look at it both ways. The same way attackers can use AI to find issues. We are doing it ourselves as well, quite frankly, because whenever there’s a new model out there from all of these vendors, most probably attackers are going to use them to scan our code, et cetera. So we’re doing it as well.

We always used to do the manual security analysis, et cetera, but now that we have AI, with every release, we just hammer the update and try to find as many issues as we can.

The reality is also that some, if not many of these vulnerabilities are not actually so easy to exploit. Like it’s really, the stars really have to align and it’s really, but still, it’s better safe than sorry. Because even though today it might be difficult to exploit a particular issue, in six months’ time, we might have technology that might make it very easy to exploit this type of issue.

It looks negative, but the same tools that attackers have, malicious users have, we have them as well. So it’s up to us to use them and be ahead of the curve, and use them proactively ourselves and before every update, during the whole development cycle. We should use them more often to make sure at least that we cover what other people can find before us.

[00:32:35] Nathan Wrigley: Yeah. I suppose the bit that I find curious is the optics of it. So, there was always this universe in which people would be able to throw dirt at WordPress because you know WordPress isn’t secure, and we talked about that earlier. It’s usually plugins and very rarely Core. Plugins, themes, additional code, what have you.

However, given that it would appear that people can stack 14 overlapping problems and create this one vulnerability from things that probably humans would never have conceived in the past. That then just lends into this narrative of, well there’s this deluge, this tidal wave of things that are coming at WordPress.

So I woke up this morning to discover in my feed BleepingComputer. I don’t know if you’ve seen this one yet today, but BleepingComputer have got an article with a CSV attached to it about yet another WordPress thing. And it just feels like that sort of day in, day out, there’s just another and another, and it’s that narrative that, that concerns me. It’s just that it gets away from us, that there’s one this day, there’s one this day, one this day, one this day.

And having to explain, “Look, calm down. That one was nothing. Okay, calm down. That one was also nothing. Okay, yeah, that one was something, but that one was nothing, that…” It’s just that constant fighting the narrative in an era where every day something seems to be out in the press, a problem that WordPress. Do you capture what I’m saying there?

[00:33:57] Robert Abela: Yes, no, and no wonder we get negative rep in the rest of the IT industry because, yes, we do get these news, and the numbers are very big. If you find a vulnerability in a plugin that has half a million installations, all of a sudden you see the news, “Oh, half a million WordPress websites are vulnerable to X.”

Unfortunately, yes. The thing is, WordPress in general, it’s very secure like. There are so many I’ve seen in my life, I don’t know how many custom web applications I have seen that are horrible in terms of security, like really horrible. It’s just because, of course, no one is seeing these because this might be a website in millions of websites, so no one is targeting. But WordPress, because it’s a popular platform, is going to be targeted.

But yeah, because the numbers are big, yeah, unfortunately, we do have a bad rep. And yeah, the news like to sensationalize things as well. So yeah, the rep is not good, no. But the reality is that it’s going to happen. It’s going to happen more often, most probably. It happened to us. All the vendors I’ve spoken to at WordCamp US and WordCamp Europe, they’re all the same. If you look at our plugins as well, maybe we used to get, I don’t know, maybe on average a vulnerability or two reported a year.

As soon as this whole AI started thing, all of a sudden within a month or two, you get like four, five, six reports like, “Whoa, what happened?” In just one week. It’s just reality. It’s up to us, as I say, we have to be more proactive. Of course, it’s easier said than done, but we have to be more proactive and try to use the same tools that attackers are using to make sure at least we detect them, yeah.

[00:35:13] Nathan Wrigley: Yeah, the bit that genuinely I find curious is what will be the calculus in terms of time that people can spend on this stuff. So as an example, if let’s say that by January 2027, many of us are having to spend a good proportion of every day, and by a good proportion, I don’t know, let’s say 30 minutes or something, browsing through the news to see if anything has cropped up. Or indeed to read the things that we know has cropped up because the fire hose of security news has gone through the roof.

This seems like it could happen, that we’ll all have to be mindful of it. And it’s just that sort of attritional wear and tear that, “Okay, really? Do I have to do this each and every day?” That will be interesting.

I suppose the flip side of that, curiously, is that it, how to describe this? It doesn’t do your business any harm because the more that people are concerned about their WordPress websites, the more security news there is, the more that they will be drawn to companies like yours. So it’s a very curious tightrope walk that you’re going to have to perform, I think as well.

[00:36:10] Robert Abela: Yes. Yes, it’s the reality. If I can do a shameless plug, at WordCamp US, I spoke about, WordPress user sessions and hijacking, and one of my lines was that all the things I had mentioned, but the talk is available on YouTube on the WordPress channel. All the things that I have mentioned, so many missed it, because if you look at user session hijacking, the bottom of it is all derives from user mistakes. A user making a mistake, that’s all it is.

And the reality is it all sounds dramatic. It all sounds like it’s the end of the world and apocalyptic. However, the reality is that, yes, nowadays, if you use a website, even as a user, you need to be aware of some basic things.

So yes, there are these news, and hopefully more and more people will become aware and more and more people need to become aware that yes, these are the dangers, these are like the risks of logging into a website nowadays. Of maintaining a website nowadays. It is. It’s like a double-edged sword. Like the news are making sometimes a bad rep for WordPress, but they’re also reaching more people that they need to wake up and say, “Oh, these are the risks, so we need to take action.”

[00:37:07] Nathan Wrigley: Yeah, it will be interesting in the face of AI vulnerability. It’d be interesting to see what the, let’s say hosting companies, let’s paint a target there. What they do to manage their stack, because obviously it’s going to be very important for them to make sure that the clients that they have. And how they position themselves in the news, and how they can portray the security solutions they’ve got. But as well as companies like you, you know, plugins and other firewall companies and things like that. Be interesting to see through 2027 how they manage that.

Okay. In which case we will wrap it up there. Just another quick reminder, go to the WP Tavern.com website, search for the episode with Robert Abela. You will be able to find the 2026 Melapress WordPress Security Survey over there. Download it, have a little bit of a look. And Robert, are you available anywhere online? Do you, other than Melapress’ do you actually make yourself available? And if so, where can we find you?

[00:37:58] Robert Abela: Yes, I’m active on LinkedIn, Robert Abela. I’m active on X.com, and I finally also have my own website. It’s more on personal things quite frankly, but yeah, it’s robertabela.me.

[00:38:08] Nathan Wrigley: In which case I will bury those in the bottom of the show notes as well.

[00:38:12] Robert Abela: Thanks.

[00:38:12] Nathan Wrigley: So that you can find those. Robert Abela, thank you for chatting to me today. I really appreciate it.

[00:38:16] Robert Abela: Thanks likewise.

On the podcast today we have Robert Abela.

Robert has been working in IT security for 25 years, ranging from antivirus software to web security scanners, and for the past decade has been running Melapress, a company focused on WordPress security plugins, particularly around user visibility, authentication, activity logs, and 2FA.

Robert is here to talk about the 2026 WordPress Security Survey, this is an annual project, now in its fourth or fifth year, gathering data from a wide range of WordPress professionals across agencies, enterprise teams, freelancers, and product owners. The conversation today is focused on the biggest security challenges and trends facing WordPress users in 2026.

We start off with some sobering stats, over 67% of survey respondents reported experiencing at least one security incident in the past year, and concerns about WordPress security remain high, especially among less technical users. We chat about the disconnect between awareness of security threats and actually taking steps to mitigate them, such as breach recovery plans and team training.

The discussion also explored the different types of risks that worry site owners, site downtime, defacement, reputational damage, data loss, and even legal compliance issues, how these shake out depends on the type of site, whether it’s e-commerce, membership, a news outlet, or a simple brochure site. 

We also talk about the tendency for even experienced WordPress users to take a reactive approach, only addressing vulnerabilities after something has gone wrong.

Towards the end of the episode, we discuss the rising impact of AI on security, the explosion of AI-facilitated vulnerabilities, and the shifting landscape of risk and response. There’s a healthy dose of reality, some optimism about the tools and best practices available, and plenty of good advice, especially for smaller teams and freelancers who may not have access to enterprise-level resources.

If you care about keeping your WordPress sites secure, or want to understand where the community’s biggest concerns and opportunities are in 2026, this episode is for you.

Useful links

Melapress

WordPress Security Statistics 2026: Melapress Survey Results

Robert’s personal site

by Nathan Wrigley at October 14, 2026 01:00 PM

Matt: RIP Eric Binnion

For the next 30 days, a few billion of you will get an extra header in honor of Eric Binnion. The code in Nginx to do this is poetic:

add_header X-Remembering "Eric Binnion <https://friendsofericbinnion.wordpress.com/>" always;

Our design team will make that less AI and more humane in the coming days.

Automattic.com will have a mourning band for 30 days.

Eric was the 21st recipient of the Distinguished Janitor Award, Automattic’s highest honor, and in our hangs the last few months we’ve been talking about how to redefine and evolve it, which will happen internally at Automattic. One of the ideas was for the award to come with a physical memento, an etched tungsten cube. I don’t have many words so I’ll share something I wrote to Eric a few months ago when I gave him my cube when he was going through chemo.

Two Totems To Take With You

The first is a tungsten cube I keep on my desk. Its weight will surprise you, but tungsten is singular in having the highest melting point of any metal. That represents one of the things I admire most about you.

Tungsten has an atomic number of 74, its symbol is W, and it’s also known as wolfram.

My next post I’ve had in drafts for a while so please try to imagine me happy and promotional when reading it, but otherwise, I’m wrecked. Just going to soldier through because that’s what Eric always did.

by Matt at October 14, 2026 06:53 AM

October 13, 2026

OpenStation Blog: I Deleted 168,000 Lines of Comments. My AI Agent Didn’t Notice

Almost a third of our source code was comments. I deleted all of them and asked an AI agent to build the same features on both versions of the codebase, three times each. The code it wrote was just as good with or without comments.

If you use agents on a real codebase and wonder whether comments help them, slow them down, or don’t matter, here’s what I found.

Why I tried this

In this video (around 23:07), Lauren mentions that they don’t let their agents write comments in the code. Our codebase, is the opposite: it’s full of comments, and most of them were written by agents.

So I wondered: are all those comments helping the agent, or are they just extra text it has to read?

The experiment in one paragraph

I made a copy of the codebase with every comment removed, about 168,000 lines in total. Then I gave the same task to the same agent on both copies, three times on each, and checked the results the same way. I did this for two tasks, a small one and a bigger one.

The results

Every run passed every check: lint, type checks and the existing tests, plus, on the bigger task, a hidden test the agent never saw. A separate AI judge scored each result without knowing which copy it came from (more on that below).

Small task: tile all open windows (score out of 19)

BranchScoreTokensCost
With comments18.32.18M$1.42
Without19.01.71M$1.04

Bigger task: keep a window on top (score out of 23)

BranchScoreTokensCost
With comments21.79.06M$3.84
Without22.09.12M$3.95

The numbers are averages of three runs. The score differences are within noise, and so is the cost on the bigger task. On the small task, the agent used about 22% fewer tokens without comments, which makes sense: there was simply less to read.

The bigger task had a trap. The pinned state has to survive a page reload, and the PHP function that saves the window session drops any key it doesn’t know. Miss it and the feature looks fine until you reload. That’s exactly the kind of thing you’d expect a comment to help with. All six runs found it, with and without comments.

Why one run is not enough

My first plan was to run each branch once. I’m glad I didn’t.

On the bigger task, the three runs with comments used 8.21M, 8.79M and 10.17M tokens. The three runs without comments used 7.01M, 9.70M and 10.64M.

If I had picked one run from each branch, I could have written two opposite blog posts. Comparing 10.64M with 8.21M, removing comments makes the agent 30% more expensive. Comparing 7.01M with 10.17M, it makes the agent 31% cheaper. Same task, same code, same day.

Agents are not deterministic. If you’re measuring one, run it more than once.

How I ran it

  • The agent: Claude Code with Opus 5.5 at high effort. Same model and settings for every run.
  • The two codebases: our main branch, and a copy with the comments removed. I compiled both and checked that the resulting code is identical. The only comments left are the ones the tools need to work, such as lint directives and plugin headers, about 800 lines.
  • The tasks: two real features, with the same prompt on both branches.
  • The checks: the project’s own lint, type checks and tests. On the bigger task, also a hidden test I added after the agent finished, so it couldn’t write code just to pass it.
  • The judge: a separate Claude session read each change and scored it against a checklist written before the runs: does it work, does it follow the project’s conventions, does it have tests, and so on. The changes were labelled with random names, so the judge didn’t know which branch each one came from.
  • The runs: three per branch per task, alternating branches so that time of day affected both equally.

My conclusion

For the agent, code comments don’t make a difference to the quality of the code it writes. They don’t help, and they don’t hurt.

So keep a comment or delete it based on what it does for the people reading the code, not for the agent.

This doesn’t prove comments have zero effect. I tested one model, two tasks and three runs per branch, which is enough to rule out a big effect, not a small one.

Next: comments made no difference, but removing our docs/ folder and AGENTS.md did. That’s the next post.

Appendix: data and links

WithWithout
Whole repository765,491597,332
Plugin source code408,527280,421
Plugin source code means the code that ships in the plugin (src/, includes/, apps/ and the CSS), without tests, docs, or tooling.

by Roberto Aranda at October 13, 2026 05:58 PM

Matt: Neal Stephenson Live!

Speaking of sci-fi authors, Automattic is hosting Neal Stephenson for a livestream about his new book soon, please tune in!

Neal was a big influence on WordPress! I got hip to him from Tantek. In the source code of billions of pages you’ll see this:

<link rel="profile" href="https://gmpg.org/xfn/11">

GMPG is the Global Media Protocols Group, “an experiment in Metamemetics.” Inspired, of course, by the Global Multimedia Protocol Group that owned the virtual real estate in Snow Crash’s metaverse.

Eric, Tantek, and I were reacting to the idea that there should be a separate heavily-marked-up RDF or XML web, and that HTML couldn’t be extended or enriched with metadata in a way that was beautiful to both humans and machines. It was really an aesthetic war. (It later got more built out in Microformats.)

We should revisit some of those principles because the web could use more distribution right now.

by Matt at October 13, 2026 03:53 PM

Open Channels FM: Balancing AI Efficiency Costs and Value in Markdown Data and Open Source Security

In today's news, markdown streamlines AI input, AI-generated security reports increase workloads, and autonomous agent costs affect project efficiency

by Bob Dunn at October 13, 2026 02:15 PM

Open Channels FM: Open Channels FM Heading to the Web Summit 2026 in Lisboa

Next month in November, I’ll (Bob) be attending the Web Summit in Lisbon, Portugal. I have been to conferences in the past that have had attendance up to 15,000, but never one that has over 70,000 attendees. That’s a lot of people. A few months ago I applied for media creditation, unsure of their parameters […]

by Bob Dunn at October 13, 2026 10:00 AM

Matt: Board Agent

Automattic is always 5–15 years ahead of other companies, but things happen faster now. I predict other companies will start scrambling to add great writers to their boards, because, well, look at the headlines in AI. United’s board already has Walter Isaacson. Authors are awesome, akin to founders in the startup/tech ecosystem.

Public offer to all the great sci-fi/etc writers out there who I’m a huge fan of (Ken Liu, Neal Stephenson, Ted Chiang, Andy Weir, Ramez Naam, Kim Stanley Robinson…) but not as close to as Hugh (I was part of him meeting his wife, officiated one of their weddings), I offer my services as your Board Agent to negotiate compensation and contracts for you! 1% fee, donated to the WordPress Foundation or Locus Magazine. I’ve become a bit of an expert in board protections, dynamics, compensation, and such. 🙂

Aside: If you haven’t seen the Robert Caro / Robert Gottlieb documentary Turn Every Page, run, don’t walk to your nearest streaming service!

by Matt at October 13, 2026 09:10 AM

October 12, 2026

OpenStation Blog: What WordPress would have looked like in 1995

I’ve been wondering how far a theme can take OpenStation. Not just a wallpaper and a different color, but everything: windows, dock, menus, fonts, icons, layouts, etc. So I tried to make wp-admin look like two operating systems from a long time ago.

The same wp-admin desktop, with the same windows open, switching between a 1995 look (teal desk, grey windows, a taskbar) and a 1984 look in black and white.
Can you believe that this is still WordPress? Turns out that the web is still fun! You only need WordPress, OpenStation, and one of these two themes.

Retro 95 reimagines wp-admin as Windows 95. It even comes with a Start menu! And the classic clock sitting in the bottom-right corner is also there. You can try it live.

wp-admin with the Retro 95 theme: opening Posts from the Start menu and writing a new post titled Hello from 1995.

Retro 84 is the counterpart for Apple fans. It turns wp-admin into the first graphical OS that many people ever saw: the original Macintosh’s System 1. The beloved monochrome display, the classic pixelated font, and more! Check out the live demo.

wp-admin with the Retro 84 theme in black and white: previewing documents on the desk and writing a new post titled Hello from 1984.

And here’s a fun fact: every icon is pixel art typed into a text file, one character per pixel. The fonts were also made the same way, letter by letter.

For each theme, a text file where every character is one pixel, the icon it becomes (a 1995 computer and a 1984 floppy disk), and the rest of the theme's icons.

Underneath, it’s the same wp-admin as always, just a few decades older.

If you want to build your own theme, the docs list everything a theme can change. Maybe it’s time for a proper Windows Vista comeback.

by Miguel Torres at October 12, 2026 11:31 AM

Open Channels FM: Building Stability Through Diversification in Tech Careers

In a fast-evolving tech industry, professionals are embracing diversification for stability and growth. This strategy fosters financial security, creativity, and adaptability, preparing individuals for unforeseen changes.

by Open Channels FM at October 12, 2026 09:18 AM

October 09, 2026

Open Channels FM: OCN Week in Review #5: Scale, Adaptation, Verification and Infrastructure

This week on Open Channels News, discover how AI is changing hardware, security reports, and gaming, plus the latest WordPress and enterprise data updates. Explore our concise wrap-up of major open source and tech stories, along with the recurring themes shaping the industry’s future.

by Open Channels FM at October 09, 2026 01:00 PM

October 08, 2026

Open Channels FM: Why Learning from Younger Colleagues Keeps You Fresh in Tech

To thrive in the evolving tech industry, professionals should engage with younger colleagues, embracing their fresh perspectives to foster adaptability, resilience, and ongoing personal and professional growth.

by Open Channels FM at October 08, 2026 02:06 PM

Open Channels FM: How Open Channels FM Balances Human Content with the AI Transparency Report

Learn how Bob Dunn chose to create a AI Transparency Report for the Open Channels FM Podcast Network.

by Bob Dunn at October 08, 2026 12:00 PM

October 07, 2026

Open Channels FM: Meta Opens Muse to DIY Hardware, GPT-6 Plays WoW Blind, and BootLoops

Open Channels News host Robert shares AI's evolving role, highlighting Meta's Home Link for hardware integration, GPT-6 Astra's gameplay without visuals, and BootLoops enhancing scientific research tools.

by Bob Dunn at October 07, 2026 03:00 PM

WPTavern: #236 – Brian Coords on WordPress as the Source of Truth

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, making WordPress the source of truth across web projects, not just the website.

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 Brian Coords. Brian’s journey started in teaching and after a surprise detour, thanks to a growing family and a need for new work, he jumped headfirst into WordPress, spending a decade in agency and freelance roles before landing as a developer advocate at WooCommerce. He’s known for his knack for explaining the complicated parts of WordPress, championing documentation, blogging, podcasting, and bridging the gap between community needs and product development.

Brian recently delivered a talk at WordCamp US entitled, The Site is the Source of Truth, Block Themes, AI and Agency Workflows, and that’s the focal point for our conversation.

We start with Brian’s background in both education and development, and how he finds his DevRel role the perfect bridge between those worlds. We then get into the evolution of WordPress from its early days to the present, questioning just what it is that has given the platform such staying power, especially as agencies race to adopt shiny AI tools or static site builders, and are tempted to throw WordPress out with the bath water.

Brian sees unique value in the WordPress ecosystem, especially for sites with longstanding content, integrations, and complex needs. And he makes the case for why the platform is built to last.

We talk through the idea of the site as the source of truth, using WordPress, and increasingly block themes, not only as a publishing platform, but as the repository for all your design, content, and workflow guidelines. Instead of letting generative AI run wild, and potentially cause chaos, Brian outlines how agencies and product teams can centralise approved patterns, templates, and even content guidelines directly in the WordPress site, helping both AI and human users maintain brand and design consistency.

We also unpack the state of block themes, why agency adoption is taking longer than expected? What’s coming soon for WooCommerce users, and how the move to block-based building is reducing plugin sprawl and making sites more resilient. And of course, we wrestle with the tight rope walk of what should go into WooCommerce Core, versus what is better left to the ecosystem, especially in a world where AI can spin up basic plugins in seconds.

If you’re curious about how WordPress agencies can survive and thrive alongside AI, what the future holds for block themes, and how to build smarter, more sustainable workflows, 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 Brian Coords.

I am joined on the podcast by Brian Coords. Hello, Brian.

[00:04:05] Brian Coords: Thank you for having me.

[00:04:05] Nathan Wrigley: Oh, you’re so welcome. Brian and I were supposed to record this podcast episode at WordCamp US, but, Jamie Marsland.

[00:04:14] Brian Coords: He ruined it, yeah.

[00:04:16] Nathan Wrigley: Yeah, we’re going to blame him. We had another engagement, which was to watch Jamie Marsland. But I appreciate you giving me the time after your WordCamp US experience. We’re both back home now.

But if anybody isn’t familiar with you, Brian, we’re going to be talking a little bit about a presentation that you did at WordCamp US. That’s going to be the fulcrum around which the conversation goes. I’m going to encourage everybody, probably to go and look at the WP Tavern show notes, check them out. We will link to that presentation, which is called The Site is The Source of Truth: Block Themes, AI, and Agency Workflows.

Hopefully gives you some intuition of what we’re going to talk about. Brian, do you just want to tell the audience a little bit about you? I know it’s a rather generic question, but tell us about you, your background, lo these many years.

[00:04:58] Brian Coords: Yeah, so currently I work at WooCommerce as a developer advocate, so just working on community documentation, release posts, the blog, all that kind of communication stuff for WooCommerce.

But before that, I spent like 10 years in the agency and freelancer world building WordPress sites, so I leaned on that for WordCamp US. Especially because you can only talk about WooCommerce so much at a WordCamp, so I leaned on my agency background and figured block themes, AI, all this stuff mixing around, what can I try to make sense out of it, and I don’t know if I did, but I got some thoughts out.

[00:05:34] Nathan Wrigley: I remember a couple of years ago, prior to you getting that job, you were doing various bits and pieces, one of which actually for a tiny period of time was writing for The Tavern. And then I remember you getting the job. I was looking at your profile on social media, I think, and you landed the developer relations job, and I thought, “Oh, if ever there was a job which fitted a character,” it felt like you had dropped into something absolutely ideal. Do you just want to tell us what that role actually involves? And is it as ideal as it sounds for somebody of your characteristics?

[00:06:03] Brian Coords: Yeah. To be honest, I saw that that was a type of job that existed in tech, and before I worked in any web development, I was a teacher. I was a high school teacher, so kind of wanted to bring back teaching and writing into what I did as a day job. So I saw that’s what a developer advocate, that’s like what DevRel does, and I basically spent like a year or two doing it for free, to prove that I could do it and get a job. And was like, “I’ll just pretend to be one, and then eventually somebody will pay me”,. And that’s kinda how it worked out.

I mean that’s basically the job, is you’re teaching, you’re doing a lot of writing, you’re doing a lot of explaining things, you’re taking a lot of community feedback and bringing it back internally and saying, “This is what people are asking for, this is what they like or don’t like about the new feature”. You’re just bridging that communication gap, but you are also not responsible for any code, and that’s the best part of it. I’m less stressed about code overall.

[00:06:57] Nathan Wrigley: I’m just going to go totally off piste here because I want to dig into what you said there, because I find that really interesting.

One of the most important pillars of, I think, every society is the education piece, particularly of the younger generation, the children. I have reasons to be into that, but I won’t share them here. But, very, very meaningful to me.

Do you miss that aspect of life? Obviously there’s a reason that you stepped away from that. Perhaps it was paperwork or burnout or whatever it may be. But do you miss the kind of face-to-face bit? Because obviously I’m imagining that you were, there was you, Brian, at the front talking to actual humans who you could reach out and touch if you needed to. How does this map to that, and the desire that you obviously once had to be an educator with real humans inside a real classroom?

[00:07:39] Brian Coords: I left it sort of accidentally. We got pregnant with our first kid and needed to move, and I just needed to find a job closer to home. And it just was an accident, and I stumbled into WordPress and tech and everything. And so, I did miss it and I felt, I think I had an experience where I spoke at a WordCamp and I was like, it felt like teaching, because it was like I know everybody in the room. This is a community, I know everybody, I have a relationship with them. I’m up in front of the room talking to them, but they’re also yelling at me and heckling me because we know each other so well.

So it reminded me of that vibe. So I kind of did look for this job as a way to bridge the two things, the WordPress and the tech side, and also a chance to do writing and teaching and bring it back a little bit. And maybe one day I’ll go back to a classroom or something.

[00:08:27] Nathan Wrigley: Yeah, maybe. One of the curious things that I think about when you see education done well online, you watch somebody’s YouTube content or wherever that content may land. You sort of get the impression that they just turned on the camera and began. Oh, they’ve added in some animations, and they’ve cut and done transitions and things like that.

But for every, let’s say 30 minutes that you produce online, is there, an hour, two hours, three hours of thinking it through, figuring out the pedagogy, who’s the audience, how do you write to their skill level? Just talk us through that bit a little bit, and I promise that’s the last off-piste bit we’ll do.

[00:09:03] Brian Coords: Yeah, I mean, for everything that I record, I spend a lot of time doing drafts of it. I’ll try to write the whole thing and just, what would this look like if I wrote the whole thing out?

And then, I’ve tried doing, a prompter where you read into the camera, and that never feels natural, it doesn’t work. But if I do three or four takes of it, by the time I get to that fourth take, I’ve internalized it, and then I can free flow it after that. And that’s how I approach my talk at WordCamp, where I just kept doing it personally, to the point where I felt like I could just say the stuff naturally.

But I do bring in some of the teaching stuff of thinking about what is the student doing at the time? What are their goals? What is the one thing that they should walk away from this? And I try to bring as much of that into it, but, it’s hit or miss, you know.

[00:09:49] Nathan Wrigley: Yeah, I guess one of the things that you always were going to miss is the sort of the feedback loop of having people in front of you, you know you’re, if all the children in front of you are gazing at the floor, then you know you’ve definitely pitched it incorrectly and you probably need to rethink. But you’re not necessarily going to get that shooting YouTube videos, but perhaps would, inside of a WordCamp. I can see you nodding, I hope that’s not actually what’s happened.

[00:10:12] Brian Coords: Yeah, your YouTube comments are pretty close to being in front of a bunch of middle schoolers, right? That’s pretty similar. But the face-to-face and being in a real room is important. That’s why I took this job too, is more WordCamps, more Meetups, more time in person, but also I don’t have to leave my house every day.

[00:10:29] Nathan Wrigley: Yeah, there is that.

[00:10:30] Brian Coords: I get a balance.

[00:10:30] Nathan Wrigley: That’s really nice, isn’t it? Yeah, so you can be working at the time of day that suits you and your family.

Okay, so back on the piste. The title of the presentation, as I said, is The Site is the Source of Truth, Block Themes, AI, and Agency Workflows. I’m just going to read some of the blurb just so that the listener has context, and it goes like this.

“Block themes give WordPress an opportunity to become more than a publishing tool or a place where finished designs are implemented. With the right theme structure, patterns, templates, and brand guidelines, a WordPress site can become the source of truth for how new pages and layouts should be built. That matters even more as agencies begin using AI in their build process. AI is useful when it can work from existing pieces, approved patterns, real content, design tokens, reusable blocks, and known template structures. It is much less useful when it starts every landing page from scratch.”

And it goes on, but I’ll stop there. Do you want to just summarize what you actually did in that presentation? Then we’ll dig into the bits and the pieces.

[00:11:27] Brian Coords: Yeah, so you submit the idea for a talk months before a conference, and then you get to the conference and three weeks ahead they tell you, “Hey, your talk got selected.” I submitted a couple. That was the one they picked, and then I read all that and I thought, “Did I write that?” I couldn’t even remember writing all that.

But it, the timing actually worked out because we are doing a block theme in Woo right now, and I’m spending a lot of time focusing on that. It all lined up. But I definitely read that description, and I had already started working on some slides and I thought, “Oh, I don’t know how much this lines up to what I actually am presenting.”

But I think the goal of what I wanted to do is talk about, I feel like a lot of agencies these days are saying, “We don’t need WordPress. We’re moving to static sites. We’re just letting AI vibe code everything on our sites.” And I wanted to kind of say there’s some value in the systems that WordPress has. It’s maybe a little more work, but there’s reasons for it.”

And I ended up doing a history lesson of, “Here’s where WordPress started. Here’s where we took the journey of why things are the way they are, and the benefits for agencies.” and so I kind of ended up in a place where I got to that topic, but I did a lot of rambling throughout the presentation. I felt like the context was really important. The like, why are we here? Why is WordPress the way it is.

[00:12:45] Nathan Wrigley: Yeah. Okay, that’s really interesting. So you said there, values in the systems that we have, and we’ll explore that in a moment. But technology’s such a weird one, isn’t it? In that most of the evolution of humans, we come up with ideas and then we finesse them a little bit. We adapt them over time, but it can be, a decade, 100 years before any major improvement takes place. You think the printing press, it just carried on as that printing press for many hundreds of years before it got slightly tweaked with linotype and things like that.

But technology seems to be quite happy to wholesale throw the baby out with the bathwater on a more or less continuous cycle. So, why then do you feel that WordPress should buck that trend in the advent of AI? Like, why does it stand a chance when AI systems are becoming ultra-capable, static sites, or just talk to your agent and it’ll just build whatever you want. What is it? What’s the intrinsic value that you think will mean that it will be around in a, I don’t know, 5 years, 10 years, whatever that may be?

[00:13:42] Brian Coords: Yeah, I think that’s a question everyone’s asking, which is, “Is there a unique value to WordPress that you can’t replace with AI?” And I think some people will point to the community and just the ecosystem and the fact that so many solutions already exist. I feel like AI is really good when you have nothing, and you’re going from zero to one. I have nothing and I’m going to make something brand new.

Once you get to something where you’ve had a site for 10 years and it has tons of content and tons of authors and all these integrations and all these sorts of things, AI is helpful, but everything has to move a little slower, everything has to be a little bit more resilient, and those are the places where having a little framework underneath, something like WordPress holding everything together, ends up being a little bit more valuable. But it’s definitely changing when you would use it, when you would reach for it, and I think that’s the part people are struggling with right now.

[00:14:30] Nathan Wrigley: Yeah. There’s so many examples in my life where there’s a new innovation, but I stick with the older thing, just because it’s tried and it’s tested, and I know the limitations of it and I know what I can do with it. So maybe that’s a good comparison.

It will be interesting to see how AI is able to adapt and just simply build things which are robust and usable. But I think at the moment, the core promise for anybody trying to sell a website to a client, for example, is exactly that. It’s reliable. It’s battle tested. It’s been used on millions of sites all over the world, and it’s got a familiar interface and you can go in and do this, that, and the other thing, and click save and publish and what have you, and it’ll just work. Whether or not that remains the case a, a decade from now, I guess only time will tell.

But, have this idea in your presentation of the site being the, and you said the, source of truth. What did you mean by that? What is the underpinning of that? What are the bits that kind of spin off if the WordPress site is the source of truth, what are the bits that sort of rely on that foundation?

[00:15:28] Brian Coords: Yeah, I think one of the things that people see when they start using AI is it will just do whatever it wants. So you could ask it for two pages on your site, and they might look completely different. It might pull in some design trend here. The language might be completely different on this other one. It might not understand your audience and your values.

And so with AI, you end up doing a lot of shepherding that’s kind of like, “well, no, this is the target audience. This is my color palette. This is the design things I like to use.” And so I leaned a lot in the talk to things like patterns in WordPress. Where, it’s something we do in WooCommerce where we have a designer, they’re very talented, they make really nice patterns that really conform to our brand. And then AI can go in and say, “pull the patterns down from the site first and use those. Don’t spin up crazy new designs. Use the ones that our human designer put a lot of care and effort into, that live in the pattern library on the website.”

And so the more you put into the website and the more you train AI to, don’t go crazy and create new things, use the stuff I already have, use the tools I have, that I think makes things a little bit more reliable, a little bit more consistent. And so I think for agencies, finding ways to put stuff into the website that’s going to help the AI, and guide it directly to doing things the right way. Instead of it always wanting to like, come up with some brand-new chunk of code that you now have to look at. So that was kind of a part of it definitely.

[00:16:52] Nathan Wrigley: So, what you’re saying there is instead of having all these disparate things like, I don’t know, you’ve got a Figma file over there. And you’ve got a Google document over here. And you’ve got another three different things and you can’t really figure out where the heck they are.

Put it all in a WordPress website, and from the point of view of the design, patterns would fit beautifully for that. You can organise your typography, and basic colour palettes, and layouts, and the way things ought to look. And I don’t know, here’s two dozen ways that we might structure a page. Lock all of that away. You don’t necessarily have to publish it anywhere on the front end, but the AI can go and creep around in there and get some guidance.

But then also presumably you could do the same with, I don’t know, your writing style. You could have draft posts where you outline the manner in which you would like to convey your company. And the words which are off limits, or the words which are definitely going to be used. So in that sense because WordPress can do video, it can do audio, it can do designs, it can do layouts and typography, why not just have that as the source of truth? Is that a sort of summation of what you were saying?

[00:17:54] Brian Coords: Yeah, I think that’s essentially right. And I talked a little bit about, there’s a project in WordPress called Content Guidelines, I think, and it does that. Where you put in a lot of your rules. And then I also talked, a lot of agencies use GitHub and Git repos for their WordPress sites, and in there you can do things like having agents files, and skills and stuff that share across your team.

So sometimes it’s in WordPress, sometimes it’s in that kind of GitHub code base for your website. So it depends on your agency’s workflows and stuff. But the point is, everybody puts stuff in the same place, because when I worked at an agency, it was that. It was, they used Figma and they used XD, and they have a Google Doc with all the technical specs, and then there’s 15 emails from the client. And AI actually is really good at taking all those things and putting it in one place and building a little knowledge base. And then when you bring on another developer, their AI is going to know exactly where that is, and it’s going to make things a little bit more scalable.

So it’s just an organizational principle, like just cleaning things up, putting stuff in one space, and making WordPress sort of the home for that, instead of using all these different tools that maybe you don’t need, or maybe you’re going to lose access to.

[00:19:00] Nathan Wrigley: I can’t remember the name, I think you just called it content guidelines or something like that. I can’t remember the name of that project, and I also can’t remember whether the intention is to ship that in Core at some point.

That seems like a really curious idea. Presumably it’s a non-public facing repository of, I’m doing air quotes, “stuff”. So you just dump into there all of the different bits and pieces. Presumably by trial and error over many iterations, you’ll figure out exactly what the agent’s creeping around in your site, and that content guidelines portion of your site is going to be able to take from that.

And you would amend it, and then when you begin another client site, that would be your first port of call. Get your client guidelines figured out, get that set of constraints worked out, and then move on with the design process.

That’s a really neat idea. Somewhat hidden from the public, but pretty neat. Now, I don’t really deal with agencies. I don’t have any communication with them. Do you have a sense that they’re open to these ideas, or it’s just some sort of curiosity which the core team think they might ship, but who knows whether anybody will use it? Have you got intuitions that this would be used?

[00:20:00] Brian Coords: Yeah, that’s been an interesting one. That content guidelines feature almost shipped, and then it got pulled at the last minute and was kind of like, “Let’s see some real world usage of this.” I think it’s probably really helpful for big news publications. That’s what I’ve heard a lot of. Where they have 20 authors and they want to make sure their authors are doing the right thing, and so that makes sense.

I think for agencies, a lot of the ones I talk to, they really, they like putting things in GitHub. That’s where they like to put stuff, and they like putting it in the code. I don’t know if they’ll put it in WordPress, but I think it’ll be interesting to see. But I feel like we’re all just dealing with, there’s just tons of content, and markdown files, and prompts and skills and all these overwhelming amounts of things, and it’s like everybody together is trying to figure out what are the best ways to do this. And I think it’s just fun to explore the ideas and see. In two years maybe we’ll all have the answer to this.

[00:20:54] Nathan Wrigley: Yeah. We’ll have a fresh set of new problems in two years.

[00:20:57] Brian Coords: Yeah.

[00:20:57] Nathan Wrigley: It was curious there, we’d been talking about AI for a while and then when you, corroborated your examples there, you described the humans using it, which I thought was quite interesting. So you’ve got these 20 people working for, let’s say, TechCrunch or something like that. Big organization, lots of editors, lots of authors and what have you. But even if the AI never touches base on that, just the idea that the humans can access it in a human-readable way, not all about the AI.

Just that seems worth shipping. If all that you do is have some mechanism to show brand new author to techcrunch.com, how you would like things to look and feel and what have you, that seems like a reason to ship it even if the AI portion isn’t launched at the beginning.

[00:21:38] Brian Coords: I think everybody’s explored, I know I did, where you go all in on AI and it’s going to write all my stuff, and it’s going to do all these things for me. And then internally we’ve had a, I forget what the post, but somebody wrote this kind of, writing is for humans post, and a lot of people in the company rallied around that. Which is like, it was fun to let AI do some stuff, but writing is important, and writing should be done by humans. We don’t want to put AI content out. So at the end of the day, we expect humans to write, and we still really value that, and writing is a valuable thing in and of itself.

But then AI can come in a little later and say, “Well, maybe I’ll review it for you. Maybe I’ll give you some feedback and you can take it or not.” But it’s been an interesting, I feel like there was a pendulum where AI will do everything, and now it’s like, no, I think we’ll find the places for it to make things move faster, but there’s just still human value, and I’m glad to see that pendulum maybe coming back, at least internally for us it is.

[00:22:34] Nathan Wrigley: Sorry, going slightly off piste here, but I have an intuition that by the time another decade has passed, I think there is a version of the universe in which people have become really sick and tired of AI. I think it’s a really plausible future that some things will be viewed with enormous incredulity and skepticism if there’s any hint of it being done by an AI.

So perhaps that won’t be design. Perhaps it won’t be music. Perhaps it won’t be coding. But I’ve got a feeling that writing, especially fictional writing and things like that, but also opinion pieces and things, I think that is highly likely to become, once again, the domain of a human being. And I know for certain that my own children are very skeptical about AI and the future that’s presenting. So yeah, I welcome that commentary. I’ll leave it there if you’ve got anything to follow up with. If not, I’ll ask another question.

[00:23:22] Brian Coords: Yeah, I go back and forth on it. I’ve never listened to AI music, and I don’t think I ever will.

[00:23:28] Nathan Wrigley: No.

[00:23:29] Brian Coords: Maybe I have and I just don’t know it.

[00:23:31] Nathan Wrigley: Curiously, I bet you have. Yeah.

[00:23:32] Brian Coords: Yeah, I probably have. AI writing is the same way. It’s if you can’t tell that it’s AI, will that matter? And I think at the end of the day it will, because I don’t read things unless I know who the author is and I’m interested in their perspective, and I don’t really listen to music if I don’t know, I like to know the story of the band, and I like to know the context. If I’m reading a book, I like to know when the author lived and what culture they’re filtering everything through and, yeah, maybe we’ll be unique and some people will just want to doom scroll AI videos of cats, but I never did that before, so I don’t know if I’ll do it starting now.

[00:24:05] Nathan Wrigley: No, but curiously, it might offer a slight marketing edge, let’s put it that way. If you can certify provably that you are the real thing. Whether that be in the music space and you simply have to record the process of you going through the process of creating a song with all of the mistakes, and heartache, and anguish that that is.

But I feel that maybe there will be a craving for that in the future. Maybe people will literally work harder to find people online who are provably writing their own material, be that songs or making videos or writing and what have you.

So we’ve all been swamped AI and been beguiled by it, I think as you’ve said, the pendulum feels like there’s a bit of a swing in the other direction, and it might be that you can have a marketing edge simply because you’re actually taking the time to, to write things out. So anyway, there you go.

Let’s move on slightly. So block themes. You were mentioning that at Woo you’re currently playing with a block theme. I don’t know how many of those are actually in the bag already and out there in the wild coming directly from Woo. But it does feel that many years ago block themes were being touted as the thing.

It feels like it didn’t turn out quite the way we expected. There hasn’t been this deluge of block themes, and everybody’s put the classic themes behind them. I think people are clinging to classic themes for a variety of reasons. Do you want to just talk about why you think block themes fit into this whole agency source of truth piece as well?

[00:25:28] Brian Coords: Yeah, block themes have been interesting. I’ve seen a lot of agencies that really start to like them, and agencies understand the value. I think, for a lot of existing websites, just changing your theme is hard. There has to be a really good reason to change your theme, because who knows what’s going to break? Who knows how everything is going to work, especially with e-commerce? It’s like if it’s not broken, don’t touch it. There better be a good reason for it.

And so I think in some ways for a lot of people, block themes for existing sites maybe haven’t given them a really good reason to switch yet. But I think it will for a number of reasons. I was actually just talking to a coworker about our block theme that we’re getting ready to launch. Probably by the time this is out, it might be in a public beta.

But one of the things that was interesting is in WooCommerce, there was a theme called Storefront, which was like, that was the WooCommerce theme. And we’re doing a comparison right now, where if you wanted to move from Storefront to our block theme, Storefront had all these plugins. A plugin to do a header on your site, and a plugin to do a little mini cart, and a plugin to do product carousels, and all these plugins you would have to install. And that meant testing them and making sure they work and updating.

And we did a comparison of how many of these things can you already just do in the block editor, and it was like 90% of it already exists in the block editor. And you don’t need a plugin for it, and you don’t need extra code, and you don’t need to buy a new extension. So I think people are starting to see the value of it, once they realize how much is just included. I can change anything. I don’t need a plugin to add this or that to my site.

So I think there’s a lot of value to it, and it just ends up being a little safer because it’s just WordPress and WooCommerce and a theme that only has a little bit of styling. I’m not worried about the compatibility of plugins, and I’m not worried about paying for updates and all these sorts of things, and is it going to break on the next version?

And so I think there’s a lot of value to it, and it just makes WordPress itself more the thing you’re relying on. You’re just relying on the blocks. You’re just relying on the things that WordPress gives you. So I think there’s going to be a lot of benefits to it, but yeah, we have not, there is no WooCommerce official block theme yet, but we’re hoping that there will be one soon.

[00:27:31] Nathan Wrigley: One of the things that I thought block themes would tackle really quickly soon after launching, which never kind of ended up being the case, was for example, things like WooCommerce, atomising every bit of a WooCommerce site into a separate, let’s say block. So for example, I don’t know, the add to cart block, and the the I don’t know, show the quantity in the cart in the menu block, and yada, yada.

And you go to the cart page or the payment page, and you would just fill it up with the blocks as you’d like, and add spacing and add margins and what have you. That never seemed to take off, but also I don’t know if it’s still talked about, or the promise of that is still something that you are hoping to deliver.

Just talk us through where we’re at in terms of atomising the entirety of a WooCommerce site into individual blocks. So rather than dropping entire sort of templates or structures, you can pick and cherry pick. obviously there’d be dependencies. If you’ve got this, you must have that. But just tell us where we’re at.

[00:28:28] Brian Coords: Yeah, so overall you can do that for most of a store. I think the only thing that doesn’t have blocks right now at all is like the account pages. Somebody logs in and they see their downloads and their order history and all that. That stuff is, I don’t even think is anywhere blocks at all. But that was one of the things as part of this process is, we looked at all the blocks, because there is a add to cart button block, and there is a quantity selector block, and there is a product image gallery block. I mean there’s like a, more than 100, maybe 200 blocks in WooCommerce.

There’s a lot, but the thing that they were missing was the style controls, which is I think what a lot of people wanted. Which is if I have the button, is it going to look like every other button on my site? And can I customize it? Are all the form inputs on my checkout page going to look just like the drop down on my product selection page?

And so that’s been the big push recently, like actually building the block theme, like 90% of the work of what they’re doing is just fixing the blocks, and making the blocks better. And the theme is just a very thin layer.

So it’s gotten a lot better, and that’s kind of the goal is once we have our own theme we can show, okay, all this stuff is customizable and editable. And I think probably in the next release you’ll see a huge focus on those block style changes showing up in WooCommerce.

[00:29:44] Nathan Wrigley: I have a curious question that you may or may not wish to answer. Let’s see how this one goes. If you, as you just described, you were talking about you don’t need a plugin for that. You don’t need to worry about an update or a payment for this thing. We’re bringing all that functionality into Core.

I’m wondering what that tightrope looks like, where over there somewhere, part of the community, somebody’s got a paid plugin, which is the basis of their entire livelihood. But it just so happens that, we could really ship that in Core, and that would be really useful to have in Core. We reckon that 80% of the people who use WooCommerce will use that.

How do you decide when something gets made and the obvious sort of community impact that that thing may have had? So as I said, that’s a tricky question. I will leave you to answer it or not.

[00:30:31] Brian Coords: Yeah, it is a huge topic of discussion. James Kemp, who is the Core product lead has been pushing for more of these things in Core. And I think that the big question right now is, are a lot of the people making money on plugins going to be able to continue making money on some of those plugins with AI? Because there’s a lot of plugins that are 100 lines of code that an AI will happily spit out for you.

And so I think the floor is raising on people building plugins. Where if your plugin isn’t doing anything super complicated, if it’s set it and forget it, then there’s probably not going to be a market for it in the future.

But that said, there’s this whole other area of opportunity where there’s tons of plugins that need to be built still. There’s integrations that are really complicated that you don’t want to leave to AI. There’s things around modifying payments and modifying how your checkout works and different types of products. And all of that stuff I think is still available, and I think most people will choose to pay for those sorts of things.

But if your plugin is something, I will just say we’ve, all the ones we’ve brought in are our own plugins so far. So this new WooCommerce release that’s coming out this week is different product variations can have image galleries on each variation. That’s a thing. But that was our plugin. So we took our plugin and we put it in Core, and gave it away for free. We don’t really try to go after if somebody’s got an established community plugin and they’re supporting it. We don’t want to go after them. But we are definitely cannibalizing a few of our own plugins, and turning off a little bit of revenue we get from those to put those in Core. And that’s, we think it’s worth it in the long run to just have a better WooCommerce.

[00:32:09] Nathan Wrigley: I think that’s a really difficult tightrope to walk, isn’t it? Because obviously you would love to have every piece of functionality available in a, you know, easy to use manner in Core, or at least all the bits and pieces that were essential. But at the same time, there’s this delicate balancing act of the community, which at the moment seems to be, how shall we say it, in a holding pattern? Let’s go with that.

There’s a lot of uncertainty, people who have this sort of utility plugin that does this one thing, as you’ve described, it may be 100, 200 lines of code. Where in the past that was probably going to make you some nice pocket change. It does feel like that is going away.

So if that is the calculus upon which you’re basing whether you build something into Core or not, you’re potentially swooping in and creating something for which there is no business anymore anyway, Because now in the advent of AI, anybody with half a minute can whip that same functionality up, and you might as well have it all security checked and what have you inside of Core.

But very difficult to figure out how to balance damaging, I suppose, is the wrong word, but it’s adjacent to what I’m after. Damaging relations with community members who are great great advertisements for building on top of WooCommerce, and yet shipping all these things in Core. Difficult. I’m glad, I don’t have to square that circle.

[00:33:23] Brian Coords: Yeah, and we have a very vocal extension developer community. They give us feedback all the time. And some of them, I think they’re well aware that they’re much more likely to be threatened by AI, than they are us wanting the functionality of their plugin in Core.

But there’s also a general sense in WooCommerce from, like the customers, which is, “Why do I need so many plugins?” And that’s kind of a concern and that fear of, when I update WooCommerce and I have 30 to 50 extensions, which is very normal for a WooCommerce store, is each one of those going to work? Do I have to worry about that?

And so it is also a balance where it’s almost damaging WooCommerce that you need so many plugins just to run a store. And that why do I need a plugin for this and this, you know? So we’re trying to balance that, where we want to make it feel more secure and reliable.

But also I think a lot of those plugins are much more threatened by AI than they are us getting around. We have plenty to work on before we get around to taking other people’s plugins. We have plenty to work on our own to improve basically WooCommerce, subscriptions, all the kind of Core stuff we already manage.

[00:34:25] Nathan Wrigley: Yeah, I feel that in the WordPress space, the most likely bit to survive, is potentially WooCommerce. Just simply because there is so much that is at stake by messing up your website by injecting a bunch of AI slop. Again, I’m doing air quotes.

Because, this is your revenue. If you take your site down for half a minute, that really could lose you, I don’t know, thousands of dollars in orders. But I don’t know if that’s your intuition as well. It feels like brochure sites, that is very much up for debate at the moment. We’ll have to see how the landscape goes with that. But it feels like the WooCommerce bit, the e-commerce of WordPress’s community, it feels like you’re on a bit of safer ground just simply because of the revenue that’s generated by those sites and the reluctance of people to meddle with them.

[00:35:14] Brian Coords: Yeah. I mean that’s what I’ve been yelling internally, so I’m glad you agree. I think e-commerce is definitely much more, has a much stronger moat than static brochure sites. And I think that’s what people in WordPress are sort of dealing with, which is for all these sites that are on WordPress how many of them need WordPress? How many of them need this functionality? WooCommerce definitely. You need a database, and you need security, and you need updates and you need all this stuff.

For a marketing brochure site, you probably didn’t need it to begin with, but WordPress was easier. So the question is for those simple marketing sites, do we make WordPress easier so that they can keep using WordPress, or do we say, “No, we’re going to lean in on publishing, commerce, really complicated, heavier duty sites that probably generate more money, but maybe the total market share goes down,” I don’t know. I think that is a big question.

[00:36:05] Nathan Wrigley: Yeah, it’s interesting. I can imagine in a decade from now, the UI for a typical brochure site almost not even a UI. It’s something that we can’t really conceive of at the moment. It might be that, you speak to a thing, and the thing reacts and amends as necessary. Maybe WordPress will have to fight that territory to keep its market share.

But I do feel that the WooCommerce side, I think people are going to be able to justify the time put in to logging into a platform and going through a list of products and adding, “Okay, I’ve got some shoes that I’m selling over here and they come in seven different varieties. I want to sell the shoes. I’m going to upload the color palettes for each of those shoe,”. There’s just some calculus of the work that needs to be done and the maintenance that needs to be done. I feel that you’re on much, much stronger ground as you described. So yeah, I think you’ve every reason to be sanguine.

[00:36:52] Brian Coords: Yeah, and I still think people want to log in to something and look at something. Especially with e-commerce, they want to just see a screen of how their orders are doing. They don’t want to ask AI to generate that every single second that they want to see how many orders they have, and what their revenue is for that day and all their analytics. They just want to log in and see the thing that they see every day. They don’t need to vibe code that on the fly by asking AI to generate it, right?

[00:37:15] Nathan Wrigley: Do you know that’s really interesting? I have genuinely never thought about the desire to log into a thing, but that actually makes a lot of sense to me.

This is going to sound extremely out there, but I’m going to say it anyway. There is something of akin to getting home when you’ve been on a long journey, and you finally get to your own front door after sleeping in hotels, beds, and all of that. There’s just something quite nice about getting into you own environment and it’s, “Ah, I’m at home.”

And I actually have started blogging again recently, and I get a real great feeling when I log in and all that familiar stuff is there, and, “Oh, look, there’s all the pictures that I’ve posted on this website these many years.” I think there’s something there. I think that’s really curious. The idea of logging into something, being purposeful about it. Not speaking to the exact same interface that you talk to every other thing to do the job. Having a place, a URL that you go to, the environments how you’ve set it up, I can’t believe I’ve never thought of that before, but I think that’s quite profound. I hope you’re right.

[00:38:18] Brian Coords: Yeah. I hope I’m right too. I hope that there’s just some things in life you don’t want to ask an agent to go do for you, and you just say, “Let me just click on this and change this thing.” Some things are just faster than, “All right, I’m going to text my agent, and hopefully he does it right, and then he’s going to send me a screenshot that it got done.” I mean, I love doing that kind of stuff. I do it for some things, but yeah, sometimes you’re just, “show me that same dashboard.”

[00:38:41] Nathan Wrigley: Yeah. And I do wonder in the years to come how ready we are going to be to submit all of that control. Just the idea that an essential part of your business, like your e-commerce site could be done by an AI with very little intuition as to what’s happening once that command has been given and it updates that stuff.

But not just that you don’t know what that thing did, what the thousand other things that were done prior to that one prompt. Okay, it looks nice at the minute, but how did it even get there? Well that was about two years of prompting. Okay. All right. Can we unpick that? Not really. We haven’t the faintest idea how it got to this. Yeah, that’s really interesting. Okay. I think I’ve asked everything I wish to ask. Is there anything you wanted to get out before we knock it on the head, Brian?

[00:39:24] Brian Coords: No, just hopefully we’re still here in five years, not just prompting away in our basements.

[00:39:29] Nathan Wrigley: You know what? I think if you’d have asked me that question six months ago, I had less certainty than I do now. I think I’ve seen a sort of, tsunami is the wrong word, it certainly is not that, but a general sense out in the world at at large of distrust and a move towards the sort of more artisan side of life.

And so I think it’ll be curious to revisit this conversation in a few years time and see how that pendulum has swung. If the AI overlords are listening to this in the year 2028, please do not come and get me. I was wrong. But there we go. Let’s hope that we’ve all got somewhere to stand, a beachhead to stand in a few years. That’d be nice to think about.

Okay, Brian, thank you so much for chatting to me today. I really appreciate it.

[00:40:10] Brian Coords: Thank you.

On the podcast today we have Brian Coords.

Brian’s journey started in teaching, and after a surprise detour, thanks to a growing family and a need for new work, he jumped headfirst into WordPress, spending a decade in agency and freelance roles before landing as a Developer Advocate at WooCommerce. He’s known for his knack for explaining the complicated parts of WordPress, championing documentation, blogging, podcasting, and bridging the gap between community needs and product development.

Brian recently delivered a talk at WordCamp US entitled “The Site Is the Source of Truth: Block Themes, AI, and Agency Workflows,” and that’s the focal point for our conversation. We start with Brian’s background in both education and development, and how he finds his DevRel role the perfect bridge between those worlds.

We then get into the evolution of WordPress, from its early days to the present, questioning just what it is that has given the platform such staying power, especially as agencies race to adopt shiny AI tools or static site builders and are tempted to throw WordPress out with the bathwater. Brian sees unique value in the WordPress ecosystem, especially for sites with longstanding content, integrations, and complex needs, and he makes the case for why the platform is built to last.

We talk through the idea of ‘the site as the source of truth’, using WordPress (and increasingly block themes) not only as a publishing platform, but as the repository for all your design, content, and workflow guidelines. Instead of letting generative AI run wild (and potentially create chaos), Brian outlines how agencies and product teams can centralise approved patterns, templates, and even content guidelines directly in the WordPress site, helping both AI and human users maintain brand and design consistency.

We also unpack the state of block themes, why agency adoption has taken longer than expected, what’s coming soon for WooCommerce users, and how the move to block-based building is reducing plugin sprawl and making sites more resilient. And, of course, we wrestle with the tightrope walk of what should go into WooCommerce Core versus what is better left to the ecosystem, especially in a world where AI can spin up basic plugins in seconds.

If you’re curious about how WordPress agencies can survive and thrive alongside AI, what the future holds for block themes, and how to build smarter, more sustainable workflows, this episode is for you.

Useful links

Brian’s website

The Site Is the Source of Truth: Block Themes, AI, and Agency Workflows – Brian’s presentation at WordCamp US 2026

WooCommerce

Content Guidelines: A Gutenberg Experiment

by Nathan Wrigley at October 07, 2026 01:00 PM

October 06, 2026

Akismet: Upgrade to the official Akismet Drupal module

If your Drupal site still runs the community Akismet module (drupal/akismet), the official Akismet module (drupal/akismet_antispam) can upgrade it in place. You swap the Composer package, run database updates, and your API key and protection settings come along. We built it so you don’t have to uninstall, reinstall, and re-enter everything. This post walks through the steps.

Which sites this covers

The update needs Drupal 10.3 or later on PHP 8.1 or later. That covers sites on the community module’s 2.0.x releases and its 8.x-1.x dev branch.

If you’re on an older setup:

  • 8.x-1.0-alpha2 (Drupal 8 or 9): update the community module to 2.0.0-alpha2 while you update core, then follow this post.
  • 7.x: upgrade Drupal first, then install the official module fresh. Your Akismet account and API key still work.

The migration guide on drupal.org has a table for every release if you’re not sure which one you run.

Before you start

  • Back up the database. The update only goes one way.
  • Note which roles have “Bypass Akismet protection.” The update removes that permission (more on that below).
  • Plan one deploy for the whole swap. Between the Composer change and drush updb, spam protection is off and some admin pages break, so don’t leave a gap between them.

What carries over, and what doesn’t

These come along:

  • Your API key
  • Your connection timeout, if it’s between 1 and 60 seconds
  • Your comment, contact and registration protection settings

These don’t:

  • Check history. The community module’s akismet table is dropped, so the Spam tab starts empty. Those rows hold submitted content, including author emails and IP addresses, and the official module has no way to erase them later.
  • Per-form settings. The community module could protect some comment types or contact forms and not others. The official module has one toggle per category, and it covers all of them.
  • Per-form “discard spam.” This becomes one site-wide strictness setting.
  • Test mode, custom API endpoints and the “block all submissions” outage policy.
  • The “Bypass Akismet protection” permission. The update removes it from every role that had it. The official module’s equivalent is bypass akismet, and it isn’t granted automatically.
  • Webform handlers. You’ll need to re-attach the Akismet handler to each webform that used it.

You don’t have to track any of this by hand. The update prints a report that names every item above that applies to your site.

The migration

composer remove drupal/akismet
composer require drupal/akismet_antispam -W
drush cr
drush updb

Run them in that order, back to back.

  1. composer remove first, and leave the module installed in Drupal. Don’t uninstall it, because the update reads its database state. The official module’s composer.json conflicts with drupal/akismet, so Composer won’t install them side by side.
  2. composer require ... -W lets Composer update shared dependencies, like the Akismet PHP SDK or the PSR HTTP packages, if your lock file pins an older version. Without -W, Composer can refuse with “the package is fixed to … (lock file version).”
  3. drush cr before anything else. The community module shipped services that no longer exist, and Drupal still has them cached. Until you rebuild, logged-in pages return a 500 and drush commands die on shutdown. drush cr works when nothing else does.
  4. drush updb runs the update. Stay off the comment admin screens until it finishes.

Read the report. It’s also logged to watchdog, so you won’t lose it if your terminal scrolls away. Then export and commit the new configuration:

drush cex

On every other environment, rebuild the cache before anything else touches it:

drush cr && drush deploy

Check that it worked

  • Settings: confirm your protection toggles at /admin/config/content/akismet.
  • Status report: check the Akismet entries at /admin/reports/status.
  • Test submission: post a comment as an anonymous user named akismet-guaranteed-spam. Akismet always flags that name, so the comment should land in the Spam tab.

Already on the official module 1.0?

Upgrading to 1.1 is one command and a database update:

composer update drupal/akismet_antispam -W
drush updb

The -W matters here. Version 1.1 needs Akismet PHP SDK 1.5, and if your lock file still pins 1.4, Composer stops with:

drupal/akismet_antispam 1.1.0 requires automattic/akismet-sdk ^1.5 -> found automattic/akismet-sdk[v1.5.0] but the package is fixed to v1.4.0 (lock file version).

-W (short for --with-dependencies) lets Composer update the SDK along with the module.

Questions

If something in the report surprises you, or the update doesn’t go the way this post says, open an issue in the issue queue. The migration guide and the module’s README have the full details.

by Derek Springer at October 06, 2026 10:13 PM

WordPress.org blog: WordPress 7.1.3 Maintenance and Security Release

This security and maintenance release features 7 security fixes and 4 bug fixes.

Because this is a security release, it is recommended that you update your sites immediately.

You can download WordPress 7.1.3 from WordPress.org, or visit your WordPress Dashboard, click “Updates”, and then click “Update Now”. If you have 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 and organizations for responsibly reporting vulnerabilities, and allowing them to be fixed in this release:

  • A stored XSS on the Comments administration page, exploitable via pending comments, reported by Trail of Bits in collaboration with OpenAI.
  • A DoS issue in the WP_Http::make_absolute_url() method, reported by Anthropic
  • A second-Order SQL injection in WordPress WXR export, reported by Anthropic
  • A weakness allowing Author role users to sticky posts, reported by Anthropic
  • Unauthenticated disclosure of comments on private & unpublished posts, reported by Ananda Dhakal from Patchstack
  • Imgur embeds are vulnerable to XSS, reported by Zhengyu Liu, Jingcheng Yang, and Gavin Zhong
  • Forgeable parameters passed to the {status}_{type} hook can lead to action name collision, reported by Alex Concha of the WordPress security team

Thank you to these WordPress contributors

This release was led by Jake Spurlock.

WordPress 7.1.3 would not have been possible without the contributions of the following people. Their asynchronous coordination to deliver maintenance and security fixes into a stable release is a testament to the power and capability of the WordPress community.

Aaron Jorbin, Adam Silverstein, Adi Moldovan, Adrian Duffell, Alex Concha, Arkaprabha Chowdhury, Deepak Kumar, donniam, Ehtisham Siddiqui, Jake Spurlock, Jb Audras, Jeremy Felt, Joe Dolson, John Blackbourn, Jon Surrell, Jonathan Desrosiers, Ken Gagne, Khokan Sardar, Lance Willett, lucatume, marcs0h, Peter Wilson, Paul Kevan, RS Software, Rudy Faile, Sergey Biryukov, siliconforks, smerriman, Stephen Bernhardt, Suryakant Upadhyay, vortfu, webVerts, Weston Ruter, Yogesh Bhutkar

Backports

As a courtesy, the security fixes are being backported, where necessary, to all branches eligible to receive security fixes (currently through 4.7). As a reminder, only the most recent version of WordPress is actively supported. The backports are in progress and will ship as they become ready.

How to contribute

To get involved in WordPress core development, head over to Trac, pick a ticket, and join the conversation in the #core channel. Need help? Check out the Core Contributor Handbook.

by Jake Spurlock at October 06, 2026 05:00 PM

Open Channels FM: Open Source Maintainers Defend Against AI Spam, Linux Data Trends and WordPress Accessibility Challenges

AI-driven growth presents challenges in security and accessibility and infrastructure hurdles that technology teams cannot ignore.

by Bob Dunn at October 06, 2026 03:45 PM

Open Channels FM: The Essential Human Touch in Genealogical Research

As artificial intelligence becomes more integrated into genealogical research, it is tempting to imagine a future where longstanding mysteries are unraveled with a few keystrokes. AI tools can now scan, transcribe, and sort through centuries of records, but the heart of successful genealogy still depends on something machines cannot replicate: the human touch. No matter […]

by Open Channels FM at October 06, 2026 10:42 AM

OpenStation Blog: Someone Said “I Hate OpenStation.” That Was Actually Useful.

A few days ago, someone opened a support thread about AllTerrain Forms and, in the middle of otherwise useful feedback, wrote something very direct: “I hate OpenStation.”

Obviously that is not the nicest sentence to read when you are working on the product, but at the same time it immediately got my attention because this is exactly the kind of feedback that can be useful if you don’t take it personally.

So instead of trying to explain why OpenStation is good, or why we made certain decisions, I asked a very simple question: what exactly makes you hate it?

Her answer was actually very good.

She works on a laptop, so screen space matters a lot. OpenStation was opening windows too small for her workflow, which meant that one of her first actions was always maximizing them. She also didn’t like losing the visible URL because she regularly copies URLs into emails, project trackers or messages. On top of that, her users are not very technical, and from her point of view OpenStation was adding another layer to WordPress that she would eventually have to explain and support.

She basically said that browser tabs already exist, users understand them, they use the whole screen, and they don’t hide the URL.

And I think this is exactly where building software becomes interesting, because from our side all of those decisions had reasons behind them, but reasons don’t really matter if the final experience is worse for the person using it.

None of these are theoretical product discussions. They are very concrete things that someone hit while trying to use the software for real work.

That matters a lot to me.

We started discussing these points immediately, and one of them has already made it into the next OpenStation release.

OpenStation Preferences interface displaying settings for window appearance and behavior, including options for window focus, corners, and dimming effects.

Users will now be able to choose how new windows open: using the current default behaviour, maximized, or focused. Focused mode maximizes the new window and minimizes the other windows on the same desk, so people working on smaller screens can have something much closer to the experience they expect.

This came directly from that kind of feedback, and the implementation is already merged:

PR #964: Preferences: choose how newly opened windows appear

And this is really the point.

We obviously have our own vision for OpenStation. We believe WordPress can have a much better working environment than the traditional admin experience, and there are many things we still want to explore there. But having a strong idea of where the product should go does not mean pretending every decision we make is correct.

Sometimes the most useful feedback is not “great release” or “this looks amazing”. Sometimes it is someone telling you that a window is too small, that they want the URL back, that something scrolls when it shouldn’t, or simply that they don’t see the benefit of what you built.

That kind of feedback forces you to look at the product from outside your own head, which is probably one of the hardest things to do when you have been working on it every day for months.

For me, OpenStation becoming more mature is not only about adding more apps, more features or more ambitious ideas. A big part of maturity is improving all those small things that make the product feel natural, predictable and less annoying to use.

And I think there is also something important here about open source. People can complain, explain exactly what does not work for them, and a few days later they can literally see the code that changes that behaviour.

That is a pretty healthy way to build software.

So yes, tell us when OpenStation is great, but especially tell us when it sucks. We may not agree with every suggestion, and we obviously cannot build every requested feature, but if there is a real problem behind the feedback, we want to understand it.

In this case, someone said “I hate OpenStation.”

Fair enough.

A few days later, OpenStation got better because of it.

by Daniel López at October 06, 2026 08:54 AM

Matt: Beeper MCP

Fellow Automattician Job Thomas, down in Cape Town, South Africa, has a lovely story about using Claude and the Beeper MCP to wrangle all the group chats for his daughter’s sports.

by Matt at October 06, 2026 06:35 AM

October 05, 2026

Open Channels FM: Technology’s Fast Feedback Loop with Triumph of the Nerds, Agile AI, and WordPress Security

Faster tech means new challenges from AI feedback loops to WordPress security incidents.

by Bob Dunn at October 05, 2026 03:00 PM

Open Channels FM: Topics in Tech Business, It’s Rinse and Repeat

Sometime we think, been there, done that, but hey, not everyone has done that.

by Bob at October 05, 2026 09:54 AM

October 02, 2026

Akismet: Akismet now supports Drupal 12

Version 1.1.0 of the official Akismet Drupal module is out with support for Drupal 12. If you’re planning your move to 12, spam protection won’t hold you back. Here are the highlights.

Drupal 12 from day one

The module now runs on Drupal 10.3+, 11 and 12. On Drupal 12, Akismet checks comments and user registrations as soon as you install it, since both live in core. Contact forms, webforms, and the Key module will be supported as soon as they’re ready for D12.

What else is new in 1.1.0

Better spam scoring

Every check now gives Akismet a fuller picture of each submission. The module’s bot detection watches how someone fills out a form: how long they take, how they type, and how they scroll, click or tap. In 1.1.0, all of those signals feed straight into Akismet’s spam scoring. With more context, Akismet can better tell a real person from a bot, so you should see more spam caught and fewer real messages flagged by mistake.

Better GDPR export

drush akismet:gdpr-export now takes --format=json (or csv and yaml) and returns the full stored record for each match, including the original submission. That makes subject access requests easier to answer completely.

The export also withholds the moderator’s identity, as GDPR Article 15(4) allows.

Clearer warnings about your stored API key

The status report now warns you about a leftover copy in yoursettings and stays visible until you deal with it. A new Delete stored API key form removes it in one step. You’ll find the link on the settings page and in the status report.

Coming from the community module?

Before the official module, some Drupal sites used the community-maintained Akismet module (drupal/akismet). That project is no longer maintained. If you’re still running it on Drupal 10.3 or later, 1.1.0 can take over your install in place. Your API key, connection timeout and protection settings carry over, and the update prints a report of everything it migrated, changed or dropped. Our migration guide on drupal.org walks through the process.

Get started

You’ll need an Akismet API key. Grab one from our pricing page. It’s free for personal sites.

For a new install:

composer require drupal/akismet_antispam

If you’re already on 1.0, update the module along with the Akismet PHP SDK it depends on, then run the database updates:

composer update drupal/akismet_antispam --with-dependencies
drush updb

The module needs Drupal 10.3, 11 or 12 and PHP 8.1 or newer, or the newer PHP your Drupal core requires.

Found a bug or have an idea? Tell us in the issue queue.

New to the module? Start with our introduction to the official Akismet Drupal module, or see how it’s built on the official Akismet PHP SDK.

by Derek Springer at October 02, 2026 06:59 PM

Open Channels FM: Beyond Rants, Productive Discussions and the Mystery of Poor Design Choices

Bob Dunn reflects on online conversation styles and an infamous hardware design blunder, offering unsolicited solutions and food for thought.

by Bob Dunn at October 02, 2026 12:02 PM

October 01, 2026

Open Channels FM: Why We Build Systems aka Zach and Carl’s Emporium of Madness

In this episode, hosts Zach and Carl discuss adapting to technological change, personal reinvention, and the impact of AI on creativity and web development, emphasizing diverse income strategies and effective ADHD management.

by Bob Dunn at October 01, 2026 11:41 AM

September 30, 2026

Open Channels FM: The Jerks and Flows of the Open Web

You may start something and then boom, it's over. Or an idea that disappears as quickly as it appears.

by Bob at September 30, 2026 03:21 PM

Follow our RSS feed: 

WordPress Planet

This is an aggregation of blogs talking about WordPress from around the world. If you think your blog should be part of this site, send an email to Matt.

Official Blog

For official WordPress development news, check out the WordPress Core Blog.

Subscriptions

Last updated:

October 15, 2026 09:45 PM
All times are UTC.