164. WordPress 7.2 ships «random»

WordPress 7.2 adds the /random/ address, which takes visitors to a randomly chosen published post. It’s on by default, can be turned off with a filter, and has sparked heated debate about performance, content exposure, and whether it should be a plugin.

Program transcript

Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.

In this episode, you’ll find the information from November 2 to 8, 2026.

WordPress 7.2 includes a small-looking change that has triggered a very heated debate: a /random/ address that takes any visitor to a randomly chosen published post. It’s on by default and built on the rewrite APIs. The folder name, “random” by default, can be changed under Settings → Permalinks, and it’s prepended to existing archive paths, so /random/category/release/ lands on a random post from that category, and the same goes for tags, authors, and custom post types.

Anyone who doesn’t want it can turn it off entirely with a filter that removes the rules, hides the settings field, and ignores the query variable.

Reaction in the comments has been mostly negative, mainly for two reasons: that it’s on by default and that it’s a niche feature for core. Site administrators fear having to disable it across hundreds of installs, and several voices point to the risk of content surfacing that was never meant to be discovered, such as invoices, offers, or client pages, since every content type is sometimes used in unexpected ways and is only “private” because it isn’t linked.

Commenters also add that core would benefit more from a way to mark content as non-indexable, which would let it be excluded from this feature, and another reader warns that their site already has a page called “random.” The response is that WordPress doesn’t add opt-out switches for every feature, that most people want their content discovered, and that it has helped them rediscover things they had written and forgotten; one person says a client has been asking for this for weeks, and Matt Mullenweg himself joins in with a light tone.

The other focus of discussion is performance, because picking a random row with ORDER BY RAND() scales linearly with the number of posts. Measurements were shared on a fast machine with MariaDB: about 24 ms with 50,000 posts, 140 ms with 200,000, 824 ms with one million, and 1.87 s with two million, and 20 simultaneous requests to the two-million-post site took 14 s.

Beta 4 of WordPress 7.2 explains, somewhat jokingly, what happened to Beta 3: it wasn’t released separately, because it was bundled into WordPress 7.1.4, the October 28 security release. This beta keeps polishing the release without major new features: better keyboard focus visibility in Windows high-contrast mode, adjustments to admin interfaces, fixes to block alignment in right-to-left languages and to custom block spacing, and more work on the Abilities API, DataViews extensibility, and REST API behavior, along with fixes to revision handling and data validation. Ipsum, the new default theme, also gets accessibility improvements, with clearer focus indicators and more descriptive links for screen readers, better right-to-left support, and adjustments to patterns, touch spacing, and color palettes.

The most practical change for anyone running multilingual sites is an improvement to translation management: the Updates screen will now show each available translation separately, and they can be reviewed and installed selectively, just as is already the case with plugins and themes.

Gutenberg 24.3 finally allows formatting text that spans multiple blocks: when you select it, the formatting controls apply to the entire selection. You can also drag a selection by clicking anywhere within it, move dragged text, and keep the selection when Shift+clicking within the same block. Notes gain emoji reactions, such as heart, confetti, smiley, eyes, or rocket, and mark an unsent note’s text with a draft indicator. The media inserter gets a new look, based on the same DataViews grid used in Site Editor lists, with its own previews for audio and other files. And save errors are now explained: notices can be copied and have a button to show details, autosave failures with no server response are described with the HTTP code when available, and a countdown indicates when the next attempt will happen.

Among the practical details, “My Patterns” is renamed “Site Patterns,” with an author filter, and synced patterns can be read but not edited, and can be unlinked. Non-breaking spaces are marked with a red dot, and a button replaces them with regular spaces. Navigation lets you edit links in a popover from the list view, and the Query Loop block shows taxonomy terms to choose from instead of making you remember them. Design tools keep spreading to more blocks, text wrapping reaches the Post Title, and background videos in the Cover block no longer autoplay if reduced motion is preferred. On performance, merged theme.json data is cached and the icon library is faster, and for developers the server now registers actions and fields for core entities, and several Interactivity API bugs are fixed.

AI 1.5.0, the canonical WordPress AI plugin, arrives with six new experiments.

Text to Speech generates an audio version of a post, processed in the background, saves it to the Media Library, and can display a player on the published post.

Content Verification detects C2PA content credentials, the image provenance standard, in JPEG, PNG, and WebP files, and shows their status in the Media Library, though for now it only reads them and doesn’t verify them cryptographically.

MCP Access installs the MCP adapter and adds a screen under Tools to choose which Abilities are exposed to external agents, while WebMCP lets AI-enabled browsers interact directly with the block editor, reading the post, moving blocks, or publishing.

Revision Change Summary summarizes in plain language the changes between two revisions.

And Block Container Label Generation suggests descriptive names for container blocks in the list view.

Other pieces also improve. Content translation supports more blocks, Markdown feeds include approved comments, and friendly URLs stop working, so they now need to be used with parameters. The Abilities Explorer is rebuilt with DataViews.

WordPress Playground can now clone your own site in the browser, without installing a local server, relying on the Reprint plugin, which copies the files and the database. You get an editable WordPress with your own content, and changes to the copy are not published to the live site, which makes it useful for trying a new design, checking a plugin update, or investigating a bug.

To clone it, you need to install and activate Reprint on the site, with administrator access: in Playground you choose “Clone a live site,” enter the address, copy the migration key, paste it into the site’s Tools → Reprint Server to authorize Playground, and click “Clone site” again. Entering just the URL gives no access to anything.

Reprint transfers files and the database in small chunks, without the server having to create one enormous ZIP, and adjusts the stored addresses for the copy.

The Marketing team, inactive as a team, has moved its repository again, now with a set of AI skills for writing in the WordPress voice. All of them rely on a writing style guide adapted from the handbook’s but designed for agents, and they are the same ones used by several automated workflows. There are four: WordPress Writer News, for WordPress.org/news posts, with the usual format and voice; WordPress Writer News Event Recap, for event recaps, which explains why they come out so quickly, often while the after-party is still going; WordPress Writer Showcase, which drafts Showcase posts; and WordPress Writer Social, for social media. They’ve been refined over a couple of years based on content performance and model changes, and the author offers them as a starting point, inviting people to break the rules and submit improvements.

Nicholas Garofalo, from the Community team, proposes a fixed schedule for announcing flagship WordCamps on WordPress.org/news, after noticing that the site was one of the main drivers of traffic to the WordCamp US 2026 page. Its news also feeds email newsletters and social media, and reaches far more people than each event’s blog. Until now advertising has been irregular and largely reactive; for example, WordCamp Asia 2026 had four posts, WordCamp Europe two, a preview and a recap, and WordCamp US five, including a call for participation fifteen weeks out, ticket sales, the Kim Parsell scholarship, an event guide, and the final recap. With that more consistent rhythm, WordCamp US website traffic doubled compared with 2025.

For 2027 events, five posts per event are proposed: one year before, a call to organizers and sponsors with the venue and a dossier; six months before, ticket sales, with themes, photos from the previous year, and headline speakers; four months before, scholarships, highlighting recipients; two months before, the full schedule; and after the event, a complete recap. To help with writing, there are published examples and an agent skill.

The team is also going to review who is still active among its Event Supporters, Program Supporters, and Program Managers, the people who guide organizers, review requests from communities and events, and keep the events program running, and at the same time opens a new call. The Supporters and Managers page currently lists 71 people, and all of them will receive an email and a Slack message with a short form to choose between staying active, pausing for up to six months with temporary removal of tool access, or leaving the role, with the door open to apply again.

Event Supporters guide organizers during planning, review requests from local communities, and check on dormant ones, with a commitment of about three or four hours a month, experience in community events, and two Learn WordPress courses, which can be completed afterward; to guide a WordCamp, you must have been lead organizer of one in recent years. Program Supporters review requests from communities and events, interview and guide lead organizers, and help with the team’s inbox, with about two or three hours a week, organizing experience, and three references from people in the program. Both roles handle sensitive information and sign a confidentiality agreement.

Nilo Vélez proposes Badge Designer, a visual editor for creating WordCamp badges. The problem is that making badges remains one of the most technical tasks for an organizer: the two methods in the handbook, which are ten years old, involve writing CSS in the Customizer and printing from the browser, or exporting attendees, running a script, and laying it out in InDesign, and many teams end up with spreadsheets, paid tools, or the one volunteer who knows how to do it.

The tool lives in the dashboard, under the event’s Tickets; you upload a design made in any program, place the name, WordPress.org username, Gravatar, a QR code to the profile, and any ticket answer, such as city, website, or company, review each badge on screen, with warnings if text doesn’t fit, and get a print-ready PDF with bleed and crop marks. No CSS, no scripts, and no paid tools, and because the PDF is generated in the organizer’s browser, it doesn’t load the website’s server, however large the event.

For now it’s a standalone plugin that can be tested, with a Playground demo with CampTix and 140 test attendees, and a user guide. After testing, the plan is to integrate it into the badge generator in CampTix, which every WordCamp already has, as the recommended method, keeping HTML/CSS and InDesign as alternatives, with the guide replacing the organizer handbook pages; it would be a small change and could be ready before the end of the year, for 2027 WordCamps.

And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org.

Thanks for listening, and until the next episode!