AdultZone

Archives

Gutenberg Times: WordPress 7.1 Beta 3, AI in Action at #WCUS, Playground UI testing and more — Weekend Edition 370

Hi, After a few month dealing with a bad knee and a bad back, I enjoy moving again. As long as the weather is nice, I will be biking, swimming and walking the city with all the tourists that populate downtown Munich. From an SEO veteran’s surprisingly upbeat take on WordPress market share to a one-file answer to “what makes a block theme,” this week’s finds dig a little deeper than the usual headlines. There’s also plenty of hands-on material, whether you want to test 7.1 Beta 3, try the new Playground UI, or get your store ready for agentic commerce. Enjoy your weekend! Yours, Birgit WCUS 2026 has a dedicated AI track The AI in Action sessions are built around the questions site builders are actually sitting with right now. How do you set guardrails for AI-assisted development without losing client trust? How do you build sites that serve AI agents as visitors, not just humans? What are the legal and ethical boundaries when you put AI tools in front of clients? They’re practical sessions for developers navigating a workspace that changed faster than anyone planned for. The full schedule is live. If you’re figuring out how AI changes your pricing, your workflow, or your service model, this is a rare room to be in. August 16–19, Phoenix Convention Center. $100 includes four days, all sessions, lunch, and the community social. us.wordcamp.org/2026/tickets Developing Gutenberg and WordPress WordPress 7.1 Beta 3 is now available for testing. Rae Morey, The Repository, has the news WordPress 7.1 Beta 3 Now Available, Punts Unicode Email Support Over Security Concerns Contribute by Help Test WordPress 7.1 and learn deeply how the new features and blocks work. It’s a very impactful way to contribute to the open-source project that powers hundreds of millions of websites. Quite a few Dev notes made it out of the publishing queue this week: Text Shadow Support in Global Styles Editor components updates in WordPress 7.1 Editable blocks inside the Custom HTML block React 19: punted beyond WordPress 7.1, experiment in Gutenberg Registering and rendering SVG icons in WordPress 7.1 The latest episode is Gutenberg Changelog #132 – Proposals for Core, Calls for Testing, WordPress 7.1 and Gutenberg 23.4 and 23.5 Plugins, Themes, and Tools for #nocode site builders and owners On the WordPress.com blog, Joe Fylan explains what agentic commerce means for your store. AI assistants that discover, compare, and buy products on a shopper’s behalf. You’ll get an overview of where the big AI tools stand on in-chat checkout, plus reassurance that small stores can win with verifiable facts. Fylan’s checklist for getting ready: clear product descriptions, structured data, and making sure your robots.txt isn’t blocking the agents you want. Dave Smith, core committer and Gutenberg contributor, thinks WordPress has a homepage problem — and he built a better version to prove it. In his video, he walks you through why setting a static homepage trips up so many beginners, then demos a prototype exploring a simpler, clearer approach. You can try the live demo yourself in the browser. Smith wants to know if the direction resonates, so drop your homepage struggles in the video’s comments. Theme Development for Full Site Editing and Blocks In episode 226 of the WP Tavern Jukebox podcast, Nathan Wrigley talks with Jessica Lyschik about why accessibility in WordPress themes is easier than you think. Fresh from her WordCamp Europe 2026 talk, Lyschik walks you through the recently updated accessibility-ready requirements, quick wins like correct HTML tags, alt text, and skip links, and why block themes make much of this effortless because Core handles it. The insight: AI agents navigate your site like screen readers do. Ryan Welcher digs into how WordPress decides a theme is a “block theme” — and the answer might surprise you. It all comes down to one file: templates/index.html exists, or it doesn’t. Neither theme.json nor patterns flip the switch, which is why Astra, Kadence, and Blocksy all still test classic. “Keeping up with Gutenberg – Index 2026” A chronological list of the WordPress Make Blog posts from various teams involved in Gutenberg development: Design, Theme Review Team, Core Editor, Core JS, Core CSS, Test, and Meta team from Jan. 2024 on. Updated by yours truly.  The previous years are also available: 2020 | 2021 | 2022 | 2023 | 2024 | 2025 Building Blocks and Tools for the Block editor In episode 477 of the WP Builds podcast, Nathan Wrigley talks with Olly Campion and Tommy Rockett about lessons from their WordPress plugin business and their block-based plugin Slidey Panel, which slides customizable side panels into any site. You’ll hear how years of client work revealed a gap in both classic themes and the block editor, the philosophy behind their “page as panel” approach, and their candid take on AI, market share shifts, and the future of bespoke agency work. Ryan Welcher walks you through What’s New for WordPress Developers for July 2026 in his monthly video roundup. You’ll learn why WordPress 7.0.2 is a must-install security release, how to test React 19 via a runtime flag in Gutenberg 23.4, and what the now-enforced iframed editor means for your themes. He also covers responsive styling, Block Bindings for list items, and MCP support in Playground. Prefer reading? There’s a companion post on the Developer Blog. What’s new with Playground The Playground team wants your help testing the new WordPress Playground UI before it officially launches. Fellyph Cintra shares four testing modules you can pick from: creating and managing Playgrounds, the Blueprint experience, developer tools like Files and Logs, and import/export workflows. Five minutes on desktop or mobile is enough, and the post walks you through each step. Feedback on text clarity, mechanics, and design goes into the GitHub issue #4092. Elliott Richmond shares how he uses WordPress Playground and Blueprints to train clients on block themes, inspired by WordCamp Europe. For a client migrating from a classic theme, he trimmed a gigabyte-plus database to a 50MB export,

Matt: AI Slop

If you’re going to give me AI slop, at least make it fun! Give me iambic pentameter. Make it all rhyme. Have it be a song. I think we’re under-utilizing the artistic and creative capabilities of models by making them produce work that sort-of-but-not-really looks like human effort.

WordPress.org blog: WordPress 7.1 Beta 3

WordPress 7.1 Beta 3 is ready for download and testing! This beta release is intended for testing and development only. Please do not install, run, or test this version of WordPress on production or mission-critical websites. Instead, use a test environment or local site to explore the new features. How to Test WordPress 7.1 Beta 3 You can test WordPress 7.1 Beta 3 in any of the following ways: WordPress Beta Tester Plugin Install and activate the WordPress Beta Tester plugin on a WordPress install. Select the “Bleeding edge” channel and “Beta/RC Only” stream. Direct Download Download the Beta 3 version (zip) and install it on a WordPress website. Command Line (WP-CLI) Use this WP-CLI command: wp core update –version=7.1-beta3 WordPress Playground Use a 7.1 Beta 3 WordPress Playground instance to test the software directly in your browser. No setup required-just click and go! The scheduled final release date for WordPress 7.1 is August 19, 2026. The full release schedule can be found here. Your help testing Beta and RC versions is vital to making this release as stable and powerful as possible. Thank you to everyone who contributes by testing! Find out what’s new in WordPress 7.1: Read the Beta 1 announcement for details and highlights. How important is your testing? Testing for issues is a critical part of developing any software, and it’s a meaningful way for anyone to contribute – whether or not you have experience. Details on what to test in WordPress 7.1 are available here. If you encounter an issue, please share it in the Alpha/Beta area of the support forums. If you are comfortable submitting a reproducible bug report, you can do so via WordPress Trac. You can also check your issue against this list of known bugs. Curious about testing releases in general and how to get started? Follow along with the testing initiatives in Make Core and join the #core-test channel on Making WordPress Slack. What’s in WordPress 7.1 Beta 3? For technical details on the more than 71 issues addressed since Beta 1, see the following links: Closed 7.1 WordPress Core Trac tickets since July 15, 2026 7.1 Gutenberg commits since July 15, 2026 Note: Beta 2 was released on July 17, 2026, as part of the WordPress 7.0.2 release and includes important security fixes. Beta 3 introduces two improvements to styling. Applying local style changes globally is no longer an all-or-nothing action. The Apply globally option in the block inspector now opens a quick review step, allowing you to choose which modified styles to apply globally while keeping the rest as local overrides. Other notable fixes include improvements to media uploads: long animated GIF uploads no longer hang, images rotated using EXIF metadata are processed correctly, and uploading a single HEIC image in Safari no longer creates two entries. The editor also includes additional fixes for Notes, responsive styling, and custom CSS. For developers, WordPress Coding Standards has been updated to version 3.4.0. Unicode email address support will not be included in WordPress 7.1. The work will continue in a community plugin, allowing broader testing of compatibility, security, and data-handling considerations. A Beta 3 haiku Fresh bugs surface now,click by click, we chase them down—codebase grows steady. Props to @krupajnanda, @annezazu, @wildworks, @amykamala for proofreading and review.

Open Channels FM: Signal – Issue 17

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

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

Transcript [00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley. Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, why accessibility in WordPress themes is easier than you think. If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players. If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox and use the form there. So on the podcast today we have Jessica Lyschik. Jessica is a longtime member of the WordPress community who’s been working in the ecosystem since 2015. She’s spent years learning and advocating for web accessibility, both as a developer and as an active community participant, joining agencies, working on theme reviews, and helping improve standards. Many theme creators assume that making themes accessible is an intimidating task, but Jessica’s here to show you that achieving an accessibility ready WordPress theme is more straightforward than you might imagine. Her WordCamp Europe 2026 presentation, accessibility in themes, easier than you think, aimed to demystify the requirements for accessible themes. Explaining what the WordPress guidelines mean in practise, where the low hanging fruit is, and how both block and classic themes can reach accessibility ready status with manageable efforts. We talk about the personal and moral journey that brings developers to accessibility. The technical hurdles and documentation challenges, and the ways in which things like AI agents are putting accessibility in the spotlight for everyone. Jessica talks about practical steps that quickly improve accessibility, like using correct HTML tags, adding alternative text to images, and configuring skip to content links, and shares why building accessibility in from the start saves time and effort down the road. We also explore the differences, and possible advantages, of block themes when it comes to accessibility, and why theme guidelines work the way they do, and the importance of interdisciplinary awareness across SEO, design, and content teams. Jessica mentions helpful resources, influential leaders in accessibility, and the ongoing need for documentation improvements to help everyone level up. If you’ve ever felt overwhelmed by accessibility requirements, or wonder why they matter, and how you can build better WordPress sites that work for everyone, this episode is for you. If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well. And so without further delay, I bring you Jessica Lyschik. I am joined on the podcast by Jessica Lyschik. Hello, Jessica. [00:03:39] Jessica Lyschik: Hi Nathan. [00:03:41] Nathan Wrigley: Nice to have you with us. This is my second interview at WordCamp Europe 2026. We’re in a beautiful, big media room. I’ve got to say, this is one of the nicest spaces I’ve ever had for these kind of interviews, so that’s really nice. Jessica has already done, I want to say presentation but maybe it was a workshop. I’m not sure. [00:03:57] Jessica Lyschik: No, it was a regular talk actually, yeah. [00:03:59] Nathan Wrigley: Okay. And how did it go? [00:04:00] Jessica Lyschik: It went super well, except for my slides went missing in between. That wasn’t so great. But the audience was very respectful of that, and I made a bit fun of it, so they laughed for a second and I tried, the media guys tried to fix that. We got it fixed in the end. I would’ve winged it anyway because I, like I knew what was coming up. But it’s always good to have your slides. It’s like seeing them, because for me it’s also visual reminder. It’s like, I need to see what I’m talking about, so I’m not losing track of it. But yeah, this was just a little technical hiccup. But overall I got very great feedback so far on my talk, and I’m very glad. There were also quite a lot of people. I did not expect this many. And that makes me just super happy that people are actually interested in this topic, although it is sort of scary for some of them if they even like try to touch this topic. We can probably get into the details later. Yeah, just overall like, what does it do? Why do I need that? These unanswered questions that they have that they were like, ah, no, I’m not really interested into that. [00:05:01] Nathan Wrigley: Oh, that’s nice a big reception. [00:05:03] Jessica Lyschik: Yeah. And that’s just great to see because I think just as we all grow older, and I even noticed that, and I’ve said that in my talk, like I kind of get to appreciate when a website is accessible. I mean I’m still have a long time to go, hopefully in my life, but I start to appreciate the small things that make just browsing websites easier, to be honest. [00:05:23] Nathan Wrigley: So I guess we should introduce the subject and then give you a chance to introduce yourself because it feels like in this context, the subject at hand, it’s important to know that you know what you are doing. It’s not, well, I suppose it’s a general skill in that it should be something most people know an awful lot about. But I fear that that’s not the case. So the presentation that you’ve just given was called accessibility in themes, easier than you think. That’s nicely phrased. Let’s get them through the door. And then the blurb that went with that, I’ll just read that into the record then everybody knows what we’re talking about. So it says, many theme

Gutenberg Times: How WordPress decides a theme is a “block theme”

The term “block theme” is used a lot in WordPress but it was never really clear to me what that meant exactly from a code point of view. While researching The post editor is going full iframe: what block developers need to know before WordPress 7.1, I learned that the outcome of testing WordPress 7.1 Beta 1 may soften the plan: instead of forcing the iframe for everyone, core might force it only for block themes, while classic themes using blocks with apiVersion 2 or lower keep the current 7.0 behavior. (The linked article covers the 7.0 state of things in full.) If that’s the split, then the exact definition of “block theme” suddenly matters a great deal. So what does core actually check? The public API is wp_is_block_theme(), which just asks the active theme: PHP // wp-includes/theme.php (guard clause trimmed) function wp_is_block_theme() { return wp_get_theme()->is_block_theme(); } // wp-includes/theme.php (guard clause trimmed) function wp_is_block_theme() { return wp_get_theme()->is_block_theme(); } And WP_Theme::is_block_theme() is, in its entirety, a file-existence check: PHP // wp-includes/class-wp-theme.php (caching trimmed) public function is_block_theme() { $paths_to_index_block_template = array( $this->get_file_path( ‘/templates/index.html’ ), $this->get_file_path( ‘/block-templates/index.html’ ), ); foreach ( $paths_to_index_block_template as $path ) { if ( is_file( $path ) && is_readable( $path ) ) { return true; } } return false; } // wp-includes/class-wp-theme.php (caching trimmed) public function is_block_theme() { $paths_to_index_block_template = array( $this->get_file_path( ‘/templates/index.html’ ), $this->get_file_path( ‘/block-templates/index.html’ ), ); foreach ( $paths_to_index_block_template as $path ) { if ( is_file( $path ) && is_readable( $path ) ) { return true; } } return false; } A theme is a “block theme” if it ships an index.html block template, either in templates/, or in block-templates/, the pre-5.9 legacy location. Nothing else is consulted. That has a few consequences that may surprise people: theme.json doesn’t make you a block theme. Neither do patterns, block template parts, or add_theme_support( ‘block-templates’ ). A theme can adopt every one of those “hybrid” features and still land on the classic side of this check, because the test only looks for a top-level index.html template. Child themes inherit the answer. get_file_path() looks in the child theme first and falls back to the parent, so a child theme of a block theme is a block theme even if the child ships no templates of its own. It’s a filesystem check, not a declaration. There’s no header in style.css that opts you in or out. Drop a templates/index.html into a theme and, as far as WordPress is concerned, it is a block theme. The minimum files required for block and classic themes This is the entire minimum viable block theme — two files: Markdown my-block-theme/ ├── style.css ← standard theme header └── templates/ └── index.html ← this file IS the decider my-block-theme/ ├── style.css ← standard theme header └── templates/ └── index.html ← this file IS the decider (WordPress considers a theme valid if it has style.css plus either index.php or templates/index.html, which means for a block theme, index.php, functions.php, and even theme.json are all optional.) And this is a theme that is guaranteed to stay classic: Markdown my-classic-theme/ ├── style.css └── index.php ← the classic fallback template my-classic-theme/ ├── style.css └── index.php ← the classic fallback template Staying on the classic side of the check comes down to two conditions: No templates/index.html and no legacy block-templates/index.html. Other block templates don’t matter: a theme with `templates/single.html` but no `templates/index.html` still tests as classic. (In practice, though, if you’re shipping block templates, ship the index and be a block theme on purpose.) No block-theme parent. The check falls back to the parent theme, so a child of Twenty Twenty-Five is a block theme no matter what the child contains. To be classic, the whole chain has to be. Everything else is fair game. theme.json, patterns, add_theme_support( ‘block-template-parts’ )` custom templates registered from plugins — none of them flip the switch., patterns, add_theme_support( ‘block-template-parts’ ), custom templates registered from plugins: none of them flip the switch. Where real themes land Running that check against some current releases from the theme directory Tests classic Tests block Twenty Twenty-One and every earlier default Twenty Twenty-Two and every later default Astra, Kadence, Blocksy, Botiga, Sydney, Hello Elementor — all ship theme.json GeneratePress, Neve, OceanWP, Storefront Six of the themes in the first column ship theme.json, the marquee “block” feature, and still test classic, because the check never looks at theme.json Twenty Twenty and OceanWP are another good gotcha: both ship a templates/ directory and are still classic, because it’s full of PHP page templates (template-cover.php, landing.php). The check wants templates/index.html specifically, so “does it have a templates folder” is not the indicator you might assume. How the editor reads it On the JavaScript side, the block-theme flag surfaces in two different places, which is worth knowing if you go source-diving. As an editor setting: PHP // wp-includes/block-editor.php, get_block_editor_settings() $editor_settings[‘__unstableIsBlockBasedTheme’] = wp_is_block_theme(); // wp-includes/block-editor.php, get_block_editor_settings() $editor_settings[‘__unstableIsBlockBasedTheme’] = wp_is_block_theme(); and on the REST themes endpoint, which is where @wordpress/core-data picks it up: PHP // wp-includes/rest-api/endpoints/class-wp-rest-themes-controller.php $data[‘is_block_theme’] = $theme->is_block_theme(); // wp-includes/rest-api/endpoints/class-wp-rest-themes-controller.php $data[‘is_block_theme’] = $theme->is_block_theme(); The one-file switch For all the weight the term carries, “block theme” boils down to a single file: templates/index.html exists, or it doesn’t. Not theme.json, not patterns, not any amount of hybrid adoption. Just one index template, checked up the parent chain. That’s worth keeping in mind if 7.1 does end up drawing the iframe line at wp_is_block_theme(). A hybrid theme that has adopted everything except block templates would keep the classic editor behavior, while adding a single templates/index.html (even accidentally, even in a parent theme you don’t control) would flip a site to the forced iframe. If your theme or your users’ sites sit anywhere near that line, now is a good time to check which side of it you’re actually on: it’s one is_file() call away.

Open Channels FM: Open Source and the Open Source Initiative

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