Save the Children International – Page 164 – Save the Children UK Alumni Association

Gutenberg Times: WordPress 7.1 Source of Truth
by Birgit Pauli-Haack on 30th July 2026 at 13:51
Welcome to the Source of Truth for WordPress 7.1! Before you dive headfirst into all the big and small changes and pick your favorites, make sure to read these preliminary thoughts about this post and how to use it. If you have any questions, leave a comment or email me at pauli@gutenbergtimes.com. A huge “Thank you” to Anne McCarthy, Justin Tadlock, Isabel Brison, Adam Silverstein, Ramon Dodd, Andrew Serong, Hans-Gerd Gerhards, Marin Atanasov, Krupa Nanda, Isabel Brison, Aaron Robershaw, Ben Dwyer, Brent MacKinnon, Ashar Fuadi, and a lot more. It still takes a village. Also huge respect to the whole release squad on getting WordPress 7.1 over the finish line. Estimated reading time 33–49 minutes at 7,735 words Table of Contents Changelog Important note/guidelinesOverviewResourcesAssets TagsPriority Items for WordPress 7.1Responsive styles for blocks [theme builders] [site admin][end user]Viewport breakpoint customizationInteractive states styling (hover, focus)Media editor modal and free-form image cropper [end user][site admin]Client-side media processing improvements [developer][site admin][enterprise]Icons now inherit color, and the Icons API takes shape [theme builder][plugin author][developer][enterprise]For developers: Registering more collectionsAdmin Bar everywhere [all]New Blocks [all]Playlist blockTabs blockImproved Blocks and Block handlingBlock transforms: preview first, convert faster [end user][site admin]Combine gradient and image backgrounds [end user] [theme builder][site admin]Cover Block: control video embed providers [theme builder][plugin author][enterprise][developer]Gallery and the attached images workflow in the Media Library [end user][site admin]Image Block: Mark as decorative toggle [end user][site admin]Login/out Block Improvements [theme builder][site admin][developer]Navigation Block and Link Creation [theme builder] [site admin][end user]Search block Styling[theme builder] [site admin][end user]Query block [theme builder] [site admin][end user]General quality of life improvements. Pattern editing experience improvements [theme builder] [site admin] [developer] Block Width and Layout Controls [theme builder] [site admin] [developer]Link Control and Preview Enhancements [theme builder] [site admin] [developer]Additional CSS Validation [theme builder] [site admin] [developer][end user]Block Editor Attribute Handling [theme builder][developer]Image handling improved [end user][site admin]Post Template Layout Improvements [theme builder][site admin]Post Title Block Enhancements[site admin][end user]Block Inserter Enhancements [site admin][end user]Editor enhancements Notes move toward a full commenting workflow [end user][site admin][developer][enterprise]Dedicated Identity section [site admin][theme builder][end user]Visual revisions improvements [site admin][end user][theme builder]Admin / Workflow updatesOrganized command palette [all]Change a comment’s parent from the Edit Comment screen [end user][site admin][enterprise]See an excerpt of posts without titles [end user][site admin]On This Day dashboard widget[end user][site admin]Media Library: infinite scrolling is back on by default, with a per-user opt-out [end user][site admin]Developer Goodies [developer][theme builder][plugin author][enterprise]Post editor iframe now always onGlobal Styles and theme.json Text Shadow support for theme.jsonText-Align Block Support MigrationBlock VisibilityBlock Supports: CSS variables by feature selectorA minimum-width option for block dimensionsDesign System Theme Provider Admin color schemes in Site EditorMix static HTML with editable blocksBlock Bindings for list-items and inner blocksConnectors authentication improvementsBlocks package stabilizes two experimental functionsAccessible tooltips and toggle tips API Changelog Any changes are cataloged here as the release goes on. July 30, 2026 – First edition. Important note/guidelines Try not to just copy and paste what’s in this post since it’s going to be shared with plenty of folks. Use this as inspiration for your own stuff and to get the best info about this release. If you do copy and paste, just remember that others might do the same, and it could lead to some awkward moments with duplicate content floating around online. Each item has been tagged using best guesses with different high-level labels so that you can more readily see at a glance who is likely to be most impacted.Each item has a high-level description, visuals (if relevant), and key resources if you would like to learn more. Overview WordPress 7.1 rounds out the block editor’s styling controls and makes working with media noticeably smoother. Long-requested features let you style how blocks look across three screen sizes and in interactive states like hover and focus — all without writing custom CSS. The admin experience becomes more personal, too, following you with your own color scheme and toolbar across every screen. Handling images gets a considerable upgrade, too. The new media editor modal brings free-form cropping, rotation, and metadata editing into one workflow, and client-side media processing makes uploads faster and more resilient, with broader format support and better-optimized files. The new Playlist and Tabs blocks enrich the layout options available out of the box and make for more creative information presentation. In the same realm fall the expanded Icon API with custom icon collections, dynamic galleries, and background gradients for more blocks. The unification of WP Admin and the block editors progresses as well: the editors now respect your admin color scheme, and the admin bar stays with you on every screen — including the editors and the front end. A new “On This Day” Widget connects you to your site’s history. While real-time collaboration has been punted to a future WordPress version, the asynchronous collaboration in Notes took real steps forward with inline notes on partial text selections, @mentions, rich text formatting, and multiple notes per block. Beyond the headliners, core blocks receive many quality-of-life improvements and bug fixes to make editing content in WordPress streamlined, consistent, and fast — and developers get an expanding set of APIs to build on. Resources Help Test WordPress 7.1 \\ FieldGuide + Dev Notes are scheduled to be published August 5. Roadmap to 7.1 This release consists of features from the Gutenberg plugin version 22.7 – 23.6. Here are the release posts of those plugin releases: 22.7 | 22.8 | 22.9 | 23.0 | 23.1 | 23.2 | 23.3 | 23.4 | 23.5 | 23.6 Later Gutenberg releases contain bug fixes, backported to WordPress 7.1. release branches. Assets In this Google Drive folder you can view all assets in this document. Tags To make this document easier to navigate based on specific audiences, the following tags are used liberally: [end user]: end user focus. [theme builder]: block or classic theme author. [plugin author]: plugin author, whether block or otherwise. [developer]: catch-all term for more technical folks. [site admin]: this includes a “builder” type. [enterprise]: specific items that would be of interest to or particularly impact enterprise-level folks [all]: broad impact to every kind of WordPress user. How can you use these? Use your browser’s Find capability and search for the string including the brackets. Then use the arrows to navigate through the post from one result to the next. Short video on how to use the tags to navigate the post. Priority Items for WordPress 7.1 WordPress 7.1 introduces significant enhancements to block-based design and editing. These priority features focus on responsive controls, interactive states, media management, and modernized Admin bar navigation. Responsive styles for blocks [theme builders] [site admin][end user] Probably the most requested improvement of the block editor: after years of pushing intrinsic design for fonts and spacing, WordPress 7.1 makes responsive design a built-in, first-class part of the editing experience. The feature builds on earlier steps in this direction — the ability to show or hide blocks by screen size and the Navigation block’s customizable mobile overlay — and extends the idea to styling itself. The feature is available across all block editors for Posts, Pages, Templates, Patterns,template parts and Navigation. Responsive styling follows a desktop-first model, letting styles cascade to smaller screens until you customize them for specific devices. Viewport-specific values are currently limited to block sidebar settings (like typography, spacing, and colors). The controls work in Global Styles (affecting all instances of a block) and on individual block instances, across all block editors — Posts, Pages, Templates, Patterns, template parts, and Navigation. Any controls from the toolbar that can’t be set by viewport will be hidden when a viewport state is enabled. Among the most significant controls: viewport-level aspect ratio presets for Image, Featured Image, and Cover blocks, so each can be optimized per device (#78543). Alongside this work, the Layout controls moved from the Settings tab to the Styles tab, keeping all styling decisions together. Follow the Call for Testing: Responsive Styling to learn how to invoke the feature and what to look out for, and find the technical details in the Dev Note: Responsive block styles and configurable viewports in WordPress 7.1. You can find more technical details in the Dev Note: Responsive block styles and configurable viewports in WordPress 7.1 Viewport breakpoint customization Themes can now define custom breakpoints in theme.json, so both responsive styling and per-viewport block visibility work from your design system’s breakpoints instead of WordPress’s defaults. For theme developers and designers, this provides fine-grained, device-agnostic control over responsive behavior. (79104). JSON"settings": { "viewport": { "mobile": "30rem", "tablet": "45rem" } } "settings": { "viewport": { "mobile": "30rem", "tablet": "45rem" } } Tracking: WordPress 7.1: Block visibility configurable breakpoints and theme.json integration (#75707) Interactive states styling (hover, focus) You can now style interactive pseudo-states (:hover:, :focus: or :active:) for two blocks: Button and Navigation Link. The styling can be applied globally and per-instance without writing any CSS. For example, Users can change a button’s color on hover directly in the editor. (76491) The underlying mechanism allows for the styling of the current menu item in a navigation block via theme.json (75736). JSON"core/navigation-link": { "@current": { "color": { "text": "#ff0000" }, "typography": { "fontWeight": "700" }, ":hover": { "color": { "text": "#0000ff" } }, ":focus": { "color": { "text": "#00aa00" } }, ":active": { "color": { "text": "#ff6600" } } } } "core/navigation-link": { "@current": { "color": { "text": "#ff0000" }, "typography": { "fontWeight": "700" }, ":hover": { "color": { "text": "#0000ff" } }, ":focus": { "color": { "text": "#00aa00" } }, ":active": { "color": { "text": "#ff6600" } } } } This makes interactive design accessible to non-coders and theme builders. It eliminates the need to add custom CSS snippets for common interactions. Dig into the Dev Note: Responsive block styles and configurable viewports in WordPress 7.1 Media editor modal and free-form image cropper [end user][site admin] The new media editor modal replaces the inline cropping tool, accessed via the familiar Crop button, and brings together free-form and aspect-ratio cropping, flip, fine-grained rotation with snap guides, and metadata editing in one unified workflow. (78653, 78935, 78792) This considerably improves the editing experience in WordPress Block editor. The goal was to eliminate the need for external tools for basic image editing. You can now exercise faster, more precise control over your images—fine-tuning framing, fixing orientation, or mirroring an image to better fit your layout in just a few clicks, all without breaking your editing flow. For the Cover Block, this new media editor modal is hooked up to the Crop background image button. The option appears whenever the Cover block uses an editable image, and the block automatically recalculates its overlay color and contrast after an edit, so text stays readable even if the crop removes the image’s brightest or darkest areas (79258 )Tracking: Media Editor Modal task tracking (#73771) Client-side media processing improvements [developer][site admin][enterprise] When you upload an image in the block editor, your browser — not your server — will now handle the creation of all sub-sized images using a WebAssembly (WASM) version of libvips (wasm-vips), a high-performance image processing library. The result stored on your server is improved over what server-side processing produced until today: smaller files generated directly on your device. Server-side image processing CPU usage could decline by more than 80% on capable devices (79188) The update also comes with broader modern image format support that includes HEIC (the default format for iPhone photos), JPEGS with HDR gain maps (used by UltraHDR and Adaptive HDR), AVIF and WebP support built in. A great performance improvement is the GIF-to-video conversion feature for lighter, more efficient files that are faster to load on the front-end. This feature is opt-in right now. Uploads are also more resilient, with a progress indicator and automatic retries if your data connectivity drops off (76765, 79307). For content creators uploading media, this update means better support for HDR images, faster, more reliable uploads, broader format support, and better-optimized files without manual intervention.Plugin developers should note that some server-side hooks, including `wp_generate_attachment_metadata`, `image_resize_dimensions`, and `wp_handle_upload` may not fire as before. The team is working on documentation and mitigation strategies. (74333)More in-depth information is available in the Dev Note Client-Side Media Processing in WordPress 7.1 Icons now inherit color, and the Icons API takes shape [theme builder][plugin author][developer][enterprise] WordPress 7.0 shipped a built-in set of SVG icons for the block editor and the Icon block. With WordPress 7.1, this grows into a proper, public API: plugins and themes can register their own icons, group them into collections, render them on the server, and read them over the REST API. For content creators, the most visible change is the Icon block’s picker: it now groups icons by collection, with a tab per collection plus an “All” tab, and your search query carries over as you switch tabs. Custom icons from plugins and themes appear right alongside the core set. The block itself picked up several refinements: it inserts a default icon so you’re never staring at an empty placeholder, offers flip and rotate controls in the toolbar, and shows text and background color controls by default. For developers: Registering more collections For developers, the pieces come together on the PHP side: register a collection with wp_register_icon_collection(), add icons with wp_register_icon() — from an inline SVG string or an .svg file — and print any registered icon with wp_get_icon(), including size, CSS class, and an accessible label. Icon names get strict validation, the registry’s register method is now public, and REST API endpoints expose collections and icons to your own code. A dev note with full code examples is on its way to the Make Core blog. One breaking change to flag: all 330 icons in @wordpress/icons v15 now declare fill="currentColor", so icons inherit the surrounding text color by default. If you’ve been tinting icons with the CSS fill property, switch to color — it’s more reliable, since an icon may use fill, stroke, or both internally. If you register your own icons, add fill=”currentColor” to their <svg> element to get the same behavior. The Dev Note Registering and rendering SVG icons in WordPress 7.1 holds all the details. Tracking: SVG Icon API: Iteration for WordPress 7.1 (#75715) Admin Bar everywhere [all] With WordPress 7.1, the WordPress admin bar which sits at the top of your site’s front end and other admin pages is now displayed when using block editor by default. It stays hidden when Fullscreen mode and Distraction-free mode are both turned on. Until now, entering the editor in its default fullscreen mode meant the admin bar disappeared, cutting you off from the rest of wp-admin. Since the admin bar now provides site context, the update also replaces the top-left W/site icon in the site editor with an explicit back button, making the navigation control more obvious (79197). With this update also comes a design refresh: your site icon replaces the home icon, the profile avatar becomes circular, and the command palette keyboard shortcut moves into the Admin bar to remove visual clutter and resolve shortcut conflicts. (79060) This keeps the familiar navigation with you on all screens again. Dev Notes with all the details for users and developer can be found here: Consistent navigation in WordPress 7.1 with persistent toolbar. New Blocks [all] This release expands the block library with versatile new tools. These additions provide content creators with improved ways to display interactive media and organize information. Playlist block The new Playlist block lets you create audio playlists with waveform visualization, making it easy to showcase multiple tracks or podcast episodes in a single interactive player. Visitors can browse and play through your audio content without leaving the page. For content creators this provides a rich, modern listening experience built right into WordPress to highlight podcast episodes, track of music or talks. Each track comes with its metadata: artwork, artist name, track number, and track length. The tracklist itself is configurable — you can set the play order and toggle artwork, artist names, track numbers, and track length individually to suit the design of your page. The WaveformPlayer visualization comes with a visualization style selector. You can set waveform and waveform background colors for more granular theming and show the track artwork on the play button, accessible for all visitors. The Playlist and Playlist Track blocks are available in the default block library. This is the first version and contributors are working on improvements for the next WordPress version, too looking to add more waveform styles, shuffle and skip buttons, a hover overlay for more intuitive track scrubbing, as well as performance improvements. Tracking: Playlist Block: Iteration issue for 7.1 (#77421) Tabs block The new Tabs block organizes content into separate tabbed panels that visitors click through to navigate. It’s a design pattern that presents information compactly without overwhelming readers with a wall of text. It’s a common layout for FAQs, product features, or any content where you want to show options side-by-side. For editors, it’s a familiar, flexible layout pattern now available natively in WordPress. The block family consists of a Tab List for the navigation and Tab Panels for the content. Each panel accepts any blocks you like, and the tab buttons come with their own color, typography, border, and spacing controls, so the navigation can be styled to match your theme. Using the toolbar buttons you can reorder the tabs quickly. Under the hood, the markup and keyboard behavior follow the best practices set out in the tabs pattern from the W3C ARIA Authoring Practices Guide. Tracking: Stabilize Tabs Blocks (#73230) Improved Blocks and Block handling Core blocks receive numerous quality-of-life improvements in 7.1. These updates refine existing editing workflows, simplify media handling, and provide deeper customization for layouts and design. Block transforms: preview first, convert faster [end user][site admin] Switching a block’s look or type is now much easier to evaluate before you commit. When you open the block switcher in the toolbar, the style options a theme provides — say, a Button’s “Outline” style — show live previews on hover, so you see exactly how your block will look with the style applied. (75889) The same previews in the inspector’s Styles panel now match the toolbar presentation, so it no longer matters where you make the switch. (75989) A small polish fix also centers the Navigation block’s preview in its preview pane. (75741) Transforms got more capable, too: a block can now transform directly into a variation of another block. Instead of converting to a Group and then picking Row afterwards, the transform menu offers Row or Stack as direct targets — one step instead of two. (78713) The same “one step instead of two” thinking extends to legacy content. Pasting or converting an shortcode now creates a proper Embed block instead of leaving raw shortcode text behind, so embeds from YouTube and other services display correctly right away (77937)— and if you change your mind, undo restores a paragraph with the URL rather than deleting it. (77551). The Shortcode block joins in as well: when its content matches a registered shortcode, it now offers block-specific transforms to convert it into the equivalent block. (77944) For anyone maintaining a site with years of shortcode-based posts, that removes a tedious cleanup step on the way to block-based editing. Combine gradient and image backgrounds [end user] [theme builder][site admin] More blocks now support background gradients through the new background.gradient block support, which layers a gradient on top of a background image instead of one overwriting the other — a translucent color wash over a photo, for instance, without custom CSS. Previously, gradients lived only in the Color panel, stored as a CSS background shorthand that clashed with any image on the block. The new support adds a Gradient control to the Background panel next to the existing Image control, and the style engine combines both into a single layered background-image value on individual blocks, in Global Styles, and via theme.json. A follow-up allows modern color functions in standalone gradients, and the text and background color controls moved to the Typography and Background panels to match. WordPress 7.1 ships with six blocks supporting the new gradients: Group, Verse, Accordion, Pullquote, Post Content, and Quote. More will follow, with a long-term plan to migrate the older color.gradient to the new system across all blocks. There’s no built-in migration path in 7.1 yet. For extenders, opting in follows the familiar block supports pattern. Custom blocks declare it in their block.json: JSON"supports": { "background": { "gradient": true } } "supports": { "background": { "gradient": true } } Themes control the setting via theme.json under settings.background.gradient (it’s also included in appearanceTools), and can define gradient values in styles — at the root, per block, or in style variations: JSON{ "styles": { "background": { "gradient": "linear-gradient( 135deg, #000 0%, #fff 100% )" }, "blocks": { "core/group": { "background": { "gradient": "var:preset|gradient|vivid-cyan-blue" } } } } } { "styles": { "background": { "gradient": "linear-gradient( 135deg, #000 0%, #fff 100% )" }, "blocks": { "core/group": { "background": { "gradient": "var:preset|gradient|vivid-cyan-blue" } } } } } All the salient details in this Dev Note New Block Support in WordPress 7.1: Background Gradient (background.gradient) Cover Block: control video embed providers [theme builder][plugin author][enterprise][developer] Besides gaining the new media editor modal for background images, the Cover block addresses a request from community feedback. When the block’s “Embed video from URL” feature shipped in WordPress 7.0, site builders asked for a way to curate or disable it. WordPress 7.1 adds a new allowedVideoProviders attribute to restrict which video providers are offered, or to remove the URL-embed option entirely by allowing none (#80092). Existing embeds keep working; only new URL input in the editor is restricted. The details are already reflected in the Cover block’s documentation. Gallery and the attached images workflow in the Media Library [end user][site admin] Images you upload while writing a post have always been “attached” to that post. This specifically true for older sites, pre-Block editor. Attached images where no accessible as an cluster and need to be added the block editor canvas one at a time. WordPress 7.1 finally puts that relationship to work in the editor, via an additional filter drop-down item Uploaded to this post in the Media Library Inserter modal. Photos and other media you’ve uploaded stay within reach for reuse instead of disappearing into the media library. The Gallery block is the showcase: instead of hand-picking every image, a single Use attached images button populates a dynamic gallery from all media attached to the current post (#78796). For content creators, this makes assembling image galleries faster and more flexible. It also helps reorganize image on older posts. The Source panel provides options for sorting the images. This brings the block editor handling of Gallery’s up to par with some features of the shortcode To have entire freedom to control the Gallery block, the Detach feature comes in handy. A Detach button in the toolbar and in the sidebar’s Source panel, makes out a stand-alone Gallery without the dynamic connetion to the post’s image. Using it help user to edit/upate the gallery block. Below video visualizes the connection between a list of image attached to a post from the Media Library and the gallery block with the new feature. Tracking: WordPress 7.1: dynamic galleries and post-attached media iteration issue (#77117) It’s a step back toward the simplicity of dropping photos into a post and having WordPress do the arranging. It’s the first visible piece of a larger effort around dynamic galleries and post-attached media, with dynamic queries by date and eventually categories or tags ahead. Image Block: Mark as decorative toggle [end user][site admin] Screen readers announce every image to their users — but some images, like dividers and design flourishes, carry no information worth announcing. The Image block’s new “Mark as decorative” checkbox tells assistive technologies to skip such an image entirely on the front end, by rendering it with role=”none” in the published post. It now eliminates the question, did we forget an alt=text or was it a deliberate decision to leave the alt-text empty? There is further processing to come with the checked box. Marking an image decorative clears its alt text and disables captions and links, since an image that links somewhere or explains something isn’t decorative by definition. Until now, the accessible route was knowing the empty-alt-text convention; the checkbox makes the intent explicit, machine-readable, and available to every content creator. (78064) Login/out Block Improvements [theme builder][site admin][developer] The Login/Logout block has an option to display a full login form instead of a simple link — but until now, that form’s submit button ignored your theme entirely, rendering with plain browser-default styles that stuck out next to every other button on the site. With a block theme active, the submit button now carries the standard button classes (wp-block-button__link and wp-element-button), so it automatically picks up the button styling your theme defines in theme.json — colors, border radius, and all — with no custom CSS required. The block follows the same approach the Comments form already uses, resolving a mismatch first reported back in 2023. (76746) Navigation Block and Link Creation [theme builder] [site admin][end user] The Navigation block picks up several improvements that give site builders more freedom in what a menu can contain and where it can be edited. The Login/Logout block can now be nested inside submenus (#75497), handy for tucking account actions into a “My Account” dropdown instead of spending a top-level slot on them. New links can be created directly from the sidebar List View in the Site Editor (#75918), so building out a menu no longer requires clicking into each item on the canvas. And the Home Link block gains previously missing controls (#76672), bringing it up to par with its navigation siblings. Search block Styling[theme builder] [site admin][end user] A styling gap is closed in the release for the Search block: color settings now apply to the search input field even when the search button is disabled (77219), so your search boxes match your design system regardless of which display options you choose. The block also embraces modern HTML: it can now render inside the native <search> landmark element, which carries search semantics for browsers and assistive technologies without the manual role=”search” attribute. Because dropping that attribute could break existing theme CSS, the feature is opt-in — per block via a new HTML element selector in the Advanced panel, or site-wide with add_theme_support( ‘search-element’ ) (#78485). Default output is unchanged, with a path to making the modern markup the default in a future release.(78485) Query block [theme builder] [site admin][end user] The Query block received an additional filter to control the list of blocks: You can now exclude the current post from a list of posts. This is useful when you want to add a list of posts with related posts. (64916). General quality of life improvements. Pattern editing experience improvements [theme builder] [site admin] [developer] WordPress 7.0 shifted pattern editing to focus on content changes rather than exposing every tool, treating patterns more like single blocks. In 7.1, work focuses on UX refinements based on feedback, bug fixes, and general maintenance. For users inserting and customizing patterns, this means a more polished, predictable experience with fewer rough edges. Tracking: WordPress 7.1: Pattern Editing Iteration (#75717) Pattern Editing and Block Fields: Highlight selected block (74841) Pattern editing: show root block identity when editing pattern sections #79417 Block Width and Layout Controls [theme builder] [site admin] [developer] Refines spacing and layout tools to be more intuitive. The Columns block no longer shows a confusing ‘Skip’ option in its layout picker, the Button block now uses the standard width control system, and spacing controls display in a more logical order when unlinked. These changes remove friction points that tripped up editors when building complex layouts. Button: Migrate to width block support #74242 Columns: Remove redundant Skip option from layout picker #78405 Re-order spacing side controls when unlinked #66317 Link Control and Preview Enhancements [theme builder] [site admin] [developer] When linking to pages or posts, the link picker now shows ‘Homepage’ instead of just ‘Page’ for your site’s front page, and uses the actual entity link title for previews. These small improvements make link creation feel smarter and help editors understand exactly what they’re linking to before publishing. Use entity link title for link control preview #77155 Link Picker: Use Homepage badge instead of Page if Homepage #75929 Additional CSS Validation [theme builder] [site admin] [developer][end user] Additional CSS is now validated both on mount and via a new dimension validation endpoint for sideloaded styles. These checks prevent malformed or insecure CSS from breaking your site’s appearance or introducing security risks, giving you more confidence when adding custom styles. Validate additional CSS on mount #78682 Add dimension validation to sideload endpoint #74903 Block Editor Attribute Handling [theme builder][developer] The block editor now correctly targets the right block when copying direct insert block attributes, fixing edge cases where attributes would apply to the wrong block. This fix ensures that copy-paste and duplication workflows behave as expected. Block Editor: Fix target block for copying direct insert block attributes #77877 Block Editor: Allow overriding `disableContentOnlyForTemplateParts` setting #79191 Image handling improved [end user][site admin] A set of small fixes makes working with images more predictable. If an image points to a media library item that has since been deleted, the editor no longer treats it as a local attachment, preventing confusing errors. The crop button only appears when cropping is actually available for your user role and image type, so you’re never offered a tool that can’t work. And the featured image field now shows placeholder text making clear at a glance what goes there. Image block: Validate attachment ID exists before treating image as local #77178 Image/Site Logo: hide crop toolbar when editMediaEntity is unavailable #76626 Set placeholder to featured image field #76342 Post Template Layout Improvements [theme builder][site admin] Ensures the Post Template block’s fallback styles only apply when appropriate, preventing layout conflicts when custom minimum column widths are defined. This fix gives editors more predictable control over query loop layouts without unexpected style overrides. Ensure Post Template fallback styles don’t apply when minimumColumnWidth is defined #77411 Post Title Block Enhancements[site admin][end user] The Title block gains a placeholder attribute, letting you show helpful text when no title has been entered yet. This small addition improves the editing experience for custom post types and guides content creators to fill in required fields. Post Title: Add placeholder attribute #7601 v22.7.0 Block Inserter Enhancements [site admin][end user] Makes discovering and adding blocks easier with visual polish to the inserter interface. The search input now stays visible while scrolling through block options, and the inserter button animates to clearly signal when the panel is open. These small touches reduce friction when building pages and help editors stay oriented while exploring block options. Block Inserter: Animate inserter button icon to signal open state. #78306 Make Block Inserter search input sticky while scrolling #77698 Editor enhancements Beyond the block improvements, the editing experience itself picks up refinements across the board. Notes mature into a fuller commenting workflow. Visual revisions gain a more detailed timeline. And your site’s brand identity gets a dedicated home in the Site Editor. Notes move toward a full commenting workflow [end user][site admin][developer][enterprise] Notes, the inline editorial comments right in the editor, continue to mature, with several additions in this release that make asynchronous collaboration richer and easier to act on without leaving WordPress. The headline feature: inline notes. You can now attach a note to a specific text selection rather than to a whole block. Select part of a paragraph, add a note, and the highlight stays anchored to that text as you keep editing around it. A single block can carry multiple inline notes, sorted by the order they appear, and none of the highlighting shows up in the published post. Also, blocks are no longer limited to a single conversation, either — you can start multiple note threads on the same block. The conversations themselves got more expressive, too. Notes now support rich text formatting — bold, italic, links, and code. @mention autocomplete makes it quick to pull a colleague into a thread. Longer notes collapse behind a “Show more” toggle, and a “Resolved” divider in the sidebar separates finished discussions from open ones, so it’s easy to see what still needs attention. Tracking: Notes iteration for WordPress 7.1 (#76316) Dedicated Identity section [site admin][theme builder][end user] A new Appearance > Editor > Identity screen consolidates your site’s logo, favicon, title, and tagline into one easy-to-find location, with inline editing so you can crop and adjust images right there. This eliminates hunting through Settings or digging into templates just to update foundational branding. For new site builders especially, it makes setting up your site’s identity quick and straightforward. Existing site owners have an intuitive place to update the data. (76264, 76116) Visual revisions improvements [site admin][end user][theme builder] Building on the visual revisions introduced in 7.0, the revisions screen gains a paginated timeline in the inspector with more detailed information about each revision, making it easier to understand what changed as you scrub through versions. (77333) Changes made via autosave are now labeled in the revisions timeline and make the autosave notice work with the visual revisions UI.(79950, 79947) Admin / Workflow updates Updates to admin and workflow tools in 7.1 improve navigation, content management, and site administration. These changes are designed to reduce friction and help you work more efficiently within the WordPress dashboard. Organized command palette [all] The command palette, the quick-access menu you open with keyboard shortcuts, now groups results into recent, suggested, and matching sections, and remembers your recently-used commands across sessions. The visual design has also been refreshed to make scanning results easier. This helps you navigate WordPress faster by surfacing the tools you use most often right at the top. (75691) Change a comment’s parent from the Edit Comment screen [end user][site admin][enterprise] Ever needed to fix a comment that landed in the wrong thread? The Edit Comment screen now has an “In reply to” control in the Save box — hit Edit and you get a dropdown of the post’s other comments, listed by the author with a short excerpt. Top-level comments just show “None.” You can’t create broken threads with it: the dropdown hides the comment itself and anything nested under it, and the server double-checks on save — the new parent has to be on the same post and can’t be the comment or one of its own replies (anything invalid gets bounced with a WP_Error). If the current parent wouldn’t normally show up in the list (a pingback, say), it’s kept in there as the selected option, so saving without touching the field changes nothing. Works without JavaScript too, and there are tests covering the validation. (65570) See an excerpt of posts without titles [end user][site admin] If you publish posts without titles for instance for quick status-style updates, the Posts list has been pretty useless for telling them apart: just a column of identical “(no title)” links. Now, in Compact view, untitled posts show the first 15 words of the excerpt right after “(no title)”, so you can actually see what each post is at a glance. The checkbox’s screen-reader label gets the same text, password-protected posts keep their content hidden, and the Extended view is unchanged since it already shows excerpts.(65022). On This Day dashboard widget[end user][site admin] The dashboard gains a new On This Day widget. It surfaces past content you published on the same date in previous years, similar to memory features on social platforms. It’s designed to motivate you by reminding you of what you’ve accomplished and encouraging you to write more. For content creators, it’s a pleasant nudge to reflect on your archive and stay engaged with your site. (65116) Media Library: infinite scrolling is back on by default, with a per-user opt-out [end user][site admin] The Media Library grid now uses infinite scrolling by default, so attachments load continuously as you scroll instead of behind a “Load more” button. For anyone who prefers the previous behavior, there’s a new personal option: a “Disable infinite scrolling in the Media Library grid view” checkbox on the profile screen. The setting only appears for users who can actually upload files, since others never see the attachment grid. For developers, the existing media_library_infinite_scrolling filter still works and now takes top precedence: a hooked filter always wins, followed by the user’s profile preference, with infinite scrolling enabled when neither is set. Note the filter’s default value has flipped from false to true as of 7.1.0, so any code relying on the old default should be reviewed. The change ships with unit tests covering the new user option and the full precedence chain (65564). Read the Dev note: Media Library infinite scrolling is now enabled by default, with a per-user opt-out Developer Goodies [developer][theme builder][plugin author][enterprise] WordPress 7.1 provides developers with expanded APIs, theme.json capabilities, and system improvements. These tools offer greater control over site design, block behavior, and system integrations. Post editor iframe now always on Other editors in WordPress—the site editor, the template editor, and block, template, and device previews—have been unconditionally iframed for a long time, going back to the template editor’s introduction in 5.8. The post editor was the holdout: starting in 7.0, whether it ran isolated depended on the blocks actually present in a given post, so a post using only Block API v3+ blocks got the isolated canvas, while a post containing even one older block (API v1 or v2) dropped out of it entirely. That meant the same site, even the same author, could see the editor behave differently from post to post. In 7.1, that condition is removed: every post editor is always iframed, regardless of theme type or block API version. For most people writing and editing content, this is good news—no more switching behavior depending on which blocks happen to be inserted. Block developers have a bit of homework, though: the iframe has its own document and window, separate from the admin page where editor scripts run, so any code that reaches for the global document or window to touch the canvas will now be looking at the wrong place. The usual fix is to get the canvas’s document from an element inside it (via ownerDocument and its defaultView) rather than the global object, and to use useRefEffect for attaching and cleaning up canvas event listeners. Read the dev note on the 7.1 changes (once public), the dev note on the 7.0 changes, and the block migration guide for more details. Ryan Welcher published a guide and a demo plugin. The post editor is going full iframe: what block developers need to know before WordPress 7.1 with code examples and instructions how to fix things if necessary. Global Styles and theme.json Text Shadow support for theme.json Theme authors can now define text shadows directly in theme.json via a new textShadow property under styles.typography. It works everywhere you’d expect: at the root level, per-block (say, a shadow on paragraphs only), via style variations, and on elements — including pseudo-selectors like a link’s :hover state. Any valid CSS text-shadow value is accepted, including stacked multi-shadow definitions. Block placeholder text in the editor resets the shadow so it stays readable regardless of what the theme sets. JSON"styles": { "typography": { "textShadow": "1px 1px 2px red, 0 0 1em blue, 0 0 0.2em blue;" }, "blocks": { "core/paragraph": { "typography": { "textShadow": "1px 1px 2px red, 0 0 1em red, 0 0 0.2em red;" } } }, "elements": { "link": { ":hover": { "typography": { "textShadow": "none" "styles": { "typography": { "textShadow": "1px 1px 2px red, 0 0 1em blue, 0 0 0.2em blue;" }, "blocks": { "core/paragraph": { "typography": { "textShadow": "1px 1px 2px red, 0 0 1em red, 0 0 0.2em red;" } } }, "elements": { "link": { ":hover": { "typography": { "textShadow": "none" More details in the Dev Note: Text Shadow Support in Global Styles Text-Align Block Support Migration Eight more core blocks (Post Date, Post Excerpt, Post Navigation Link, Post Title, Query Title, Site Tagline, Site Title, Pullquote and Term Name) now use WordPress’s standardized text-align system. As part of a larger migration effort this update ensures consistent alignment controls across the editor and makes these blocks behave predictably alongside newer blocks. WordPress EndUser are not supposed to see any changes and existing blocks continue to work. Theme designers are now able to style any of these blocks text align via theme.json property. The code example shows how to set the center as the site-wide TextAlign default. And `”textAlign”: false` disables the feature for this block JSON{ "version": 3, "styles": { "blocks": { "core/pullquote": { "typography": { "textAlign": "center" } } } } } { "version": 3, "styles": { "blocks": { "core/pullquote": { "typography": { "textAlign": "center" } } } } } Block Visibility Adds settings.blockVisibility.allowEditing to theme.json, allowing themes to disable the block visibility feature entirely. JSON{ "settings": { "blockVisibility": { "allowEditing": false } } } { "settings": { "blockVisibility": { "allowEditing": false } } } When set to false, the toolbar button and block options menu item are hidden. In this regard, it makes this block support consistent with color, typography etc. blockVisibility.allowEditing follows the layout flag. The reason is the two-fold nature of blockVisibility at the block supports level: a bool means don’t render the block at all, but viewport settings allow users to control visibility per viewport. The object shape also leaves the door open to extending block visibility to triggers, not only blockVisibility.viewports but others like post type or whatever. (76559). Block Supports: CSS variables by feature selector Block Supports now generates CSS custom properties based on a block’s feature-specific selectors, not just its root selector. Some blocks—the Button block is the example given—define their outer wrapper and an inner styling target as different elements, and previously there was no way to output a preset variable (like a dimension size) onto that inner element specifically. Theme and plugin authors building design systems now have a way to target the right element per feature, without needing custom CSS to work around the mismatch. A minimum-width option for block dimensions Blocks already supported height, minHeight, and width. What was missing was a way to stop something from shrinking too far—so a layout element wouldn’t collapse into an unusable sliver on a narrow screen. Minimum-width closes that gap, mirroring how minimum-height already works. It’s opt-in at the block level: the control stays hidden in the inspector until a block explicitly enables it, though it shows by default in the global styles panel. Theme-defined dimension presets carry over automatically, so existing spacing scales just work. The Group block is the first to adopt it. You’ll find more details in the Dev Note New Block Support in WordPress 7.1: Minimum Width Design System Theme Provider The first version of the design system’s theme component arrives in WordPress 7.1. It consists of standardized CSS custom properties that follow the W3C Design Tokens specification. You probably won’t spot the difference right away — the default theme was deliberately built to match existing styles — but this is the machinery that will power the admin color scheme in the Site Editor. You can read more details on the future direction in the Merge Proposal: Design System Theming Admin color schemes in Site Editor The Site Editor’s sidebar and interface now respect your chosen WordPress admin color scheme instead of always showing a dark background. This brings visual consistency across the post editor, Site Editor, and admin dashboard. If you’ve personalized WordPress with a color scheme you prefer, that choice now carries through everywhere you work. 78397 Mix static HTML with editable blocks A new innerContent block support lets a block keep static HTML fragments interleaved with editable inner blocks as the canonical source of its own markup. In practice, this means a hand-written HTML structure can have just a piece of it—a paragraph, an image—editable in place, while the rest stays fixed and can’t be moved, removed, or rearranged. The Custom HTML block is the first adopter: pasting HTML with a block comment delimiter embedded in it (for example, a <!– wp:paragraph –> block inside a larger static <div>) makes that inner piece editable directly in the canvas, while the surrounding markup remains locked in place. It’s a narrow, developer-facing capability for now—the HTML block is the only place it’s wired up—but it opens the door for custom blocks to offer the same kind of “mostly static, partly editable” experience going forward. (79115) The dev note can be found on the Make Core Blog: Editable blocks inside the Custom HTML block Block Bindings for list-items and inner blocks The List Item block has gained Block Bindings support. A List Item’s content can now be connected to a data source—a custom field, a pattern override, or another registered source—so individual entries in a list can be populated dynamically rather than typed in by hand. The change registers content as a bindable attribute for core/list-item. A related fix rounds out the feature: previously, if a bound List Item also contained a nested sub-list, that nested list was dropped when the binding was rendered. Now a List Item can carry a bound value and a nested list beneath it at the same time. In practice, this means multi-level lists—say, a team member’s name pulled from a custom field, with a nested list of their current projects underneath—can now be fully dynamic without losing structure. Tracking: Block Bindings in WordPress 7.1 (#77199) Connectors authentication improvements The Connectors framework, which manages WordPress’s connections to external services like AI providers, now supports username and application password authentication as an alternative to API keys. A merged pull request adds a default connector form for this method, along with the underlying authentication type, mirroring the equivalent API already available in WordPress Core. The change also handles the practical details: saved passwords are masked in the UI and over REST, credentials can be set via constants or environment variables instead of the database, and a companion Core patch keeps the two in sync. For connectors that require an account login rather than a bare API key, this removes the need for a custom settings screen. This lands alongside a broader open proposal for a PHP-side field registry that would let connector authors declare arbitrary settings—model choice, temperature, custom URLs, and more—the way register_setting() works elsewhere in WordPress. That registry isn’t built yet; the application password work is a first, concrete step (new auth method, not new field types), addressing one of the two gaps the proposal identified rather than the full vision. Tracking: Connectors: proposal for a PHP-side field registry for connector configuration (#78647) Blocks package stabilizes two experimental functions The Blocks package stabilizes cloneSanitizedBlock and sanitizeBlockAttributes, dropping their __experimental prefixes now that the functions have been stable in practice for some time. The old __experimental-prefixed names still work but will log a deprecation notice, so plugins or themes importing them directly should switch to the new names. Accessible tooltips and toggle tips API WordPress adds a core mechanism for accessible tooltips (51006), offering an alternative to the title attribute, which is not available to keyboard and touch users. Two new functions cover different use cases: wp_get_tooltip() exposes an accessible name when a control has focus or hover, such as for icon-only buttons, and wp_get_toggletip() implements a popover disclosure with extended help information that stays open until dismissed. Both generate accessible markup that avoids excess verbosity for screen readers and follows best practices for voice command users. The first toggle tip in core explains the “Remember Me” option on the login screen (55343). Plugin developers can use the functions for their own settings screens and metaboxes. (62741) A list of all the dev notes can be reviewed from the Make Core blog
Open Channels FM: Why Open Source Projects Need a License Before They Need Code
by Bob Dunn on 30th July 2026 at 13:35
Open source fosters creativity but involves complex issues like licensing and ownership, especially in hackathons. Proper planning with appropriate licenses upfront is crucial for project success and flexibility.
Open Channels FM: Signal – Issue 18
by Bob Dunn on 29th July 2026 at 17:54
Talk about personal journeys in web development, the complexities of fame, and the benefits of open source, emphasizing enriching content options for listeners beyond traditional podcasts.
WordPress.org blog: WordPress 7.1 Beta 4
by Benjamin Zekavica on 29th July 2026 at 15:30
WordPress 7.1 Beta 4 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 4 You can test WordPress 7.1 Beta 4 in any of the following ways: WordPress Beta Tester PluginInstall and activate the WordPress Beta Tester plugin on a WordPress install. Select the “Bleeding edge” channel and “Beta/RC Only” stream.Direct DownloadDownload the Beta 4 version (zip) and install it on a WordPress website.Command Line (WP-CLI)Use this WP-CLI command: wp core update --version=7.1-beta4WordPress PlaygroundUse a 7.1 Beta 4 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 4? WordPress 7.1 Beta 4 contains more than 114 updates and fixes since the Beta 3 release, including 51 in the Editor and 63 in Core. Each beta cycle focuses on bug fixes, and more are on the way with your help through testing. You can browse the technical details for all issues addressed since Beta 3 using these links: GitHub commits for 7.1 since July 22, 2026 Closed Trac tickets for 7.1 since July 22, 2026 Beta 4 brings a round of fixes that make the editor smoother to work with. Notes now stay reliably tied to the passage they refer to, and tagged people are displayed cleanly and clearly. A Beta 4 haiku Testers lend their eyes,edge cases hide in plain sight—Patch, rebuild, refine. Props to @krupajnanda for preparing this post and @annezazu, @wildworks, @amykamala for proofreading and review. Join us for the launch of WordPress 7.1 at WordCamp US 2026, August 16–19.
WPTavern: #227 – Maciek Palmowski on Testing Secure WordPress Hosting: Does the Marketing Match Reality?
by Nathan Wrigley on 29th July 2026 at 13:00
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, testing secure WordPress hosting, does the marketing match the reality? 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 Maciek Palmowski. Maciek is based in Poland and works at Patchstack, one of the companies in the WordPress ecosystem dedicated specifically to security. At Patchstack, Maciek collaborates with other security professionals on industry reports, bug bounty programmes, and solutions for agencies, product owners, and hosting companies aiming to secure their client sites. I met up with Maciek at WordCamp Europe, and we discussed his presentation there. It examined the claims of secure hosting made by many WordPress hosting providers. He describes how Patchstack set out to test these claims with real world penetration testing, using 30 known plugin vulnerabilities across multiple hosts. Employing standardised methodologies and validating their results independently. The findings are sobering. The majority of WordPress specific attacks still get through, and there’s a significant gap between the marketing hype and real protection. The conversation starts with Maciek’s background, and how his journey in the WordPress security space led to a focus on the promises made by hosts. From there, the discussion gets into the research approach, the selection of well-known vulnerabilities, consistent testing across different hosting environments, and the surprising result that even hosts with identical security tooling produce drastically different outcomes, showing it’s not just about the tools you use, but how you use them. We talk about the Swiss cheese model of security, every layer will have holes, so you need multiple overlapping defences, and honest communication from hosts about their limitations. We also explored whether an industry-wide standard, or badge, for secure hosting is feasible or even desirable, given how easy it is for strong marketing claims to outpace reality. AI also enters the conversation, increasing both the speed and sophistication of attacks, and making patching, and processes, even more important, especially as the volume of vulnerabilities continues to rise and the time to exploitation drops. If you’re interested in understanding what secure hosting really means, how to ask intelligent questions of providers, and the realities of WordPress security in 2026, this episode is for you. If you’d like to find 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 Maciek Palmowski. [00:03:56] Maciek Palmowski: I am joined on the podcast by Maciek Palmowski. Hello Maciek. Perfect. You did great. [00:04:01] Nathan Wrigley: For some reason, your name has got into my head. A lot of the people that I interview, I struggle with their name, and I continue to struggle, but for some reason, I established many years ago that was how to say your name. And I think I’ve done it correctly ever since then. [00:04:16] Maciek Palmowski: Yes you did. You’re almost having the typical Polish accent, so you’re doing great. [00:04:21] Nathan Wrigley: So we are at WordCamp Europe, which is in Krakow, or Krakow, I don’t know how. [00:04:26] Maciek Palmowski: Krakow. [00:04:27] Nathan Wrigley: Thank you, that was good. And the reason Maciek is correcting my pronunciation is because Maciek is actually from Poland, which I suppose means that this is a bit of a, well, it’s like a home game to you. [00:04:37] Maciek Palmowski: In a way so, but it’s also like a bit of a shame because I do like travelling when WordCamp Europe’s are happening. And, you know, just hopping on the train and going to Krakow, it was like a, I mean it’s cool because, yeah, the venue’s amazing, everything is great, but still I’m staying home, so yeah. [00:04:53] Nathan Wrigley: Yeah, mixed feelings. So Maciek has done, or is going to do a presentation at WordCamp EU. Have you done it yet? [00:05:02] Maciek Palmowski: I will do it tomorrow. [00:05:04] Nathan Wrigley: Okay. And are you all set, are you one of these like really prepared people that has all the slides done, or are you last minute? [00:05:11] Maciek Palmowski: Everything is ready. I already did one version of it at the Checkout Summit in Palermo, so. [00:05:17] Nathan Wrigley: Oh I see. So you’ve had a sort of dry run of elsewhere. [00:05:19] Maciek Palmowski: Of course. [00:05:20] Nathan Wrigley: Excellent. So the presentation, which is going to be the focus of today’s conversation, is called Testing the promise, does secure hosting deliver? And I may as well read the blurb because it was a reasonably short one. So it says, secure hosting, in quotes, is everywhere in WordPress. What does it actually protect against? We put this claim to the test with real penetration testing. 30 known vulnerabilities, multiple hosting providers, standardised methodology, validated by independent observers. The findings reveal a critical gap between marketing and reality. WordPress specific attacks succeed most of the time. That’s quite an alarming sentence. This talk shares the complete results and explains why generic security fails. So, we’ll get into that in a moment. But as with all people, when I’m talking to them about security, I guess it’s good to establish who you are, and what your credentials are and what you’ve done, and how is it that you get to talk about security with authority. So over to you really, a little moment to give us your bio and tell us about you. [00:06:20] Maciek Palmowski: Okay. So I work at Patchstack, and Patchstack is one of those few companies in WordPress space that are doing a lot in terms of security. We are constantly running this bug bounty for the whole ecosystem. We have quite a few solutions for both clients and hosting companies, and I work there right now. My role is, if I remember, the Growth Team Engineer, something like this. But yeah, I do spend a lot of time working with other security people. So when we are working on all the reports, when we are checking the data, I’m also part of those teams that are working on it. So yeah, I think I know a thing or two about what is happening behind the scenes when it comes to WordPress security. [00:07:02] Nathan Wrigley: Yeah, thank you. Always good to get that established though, right at the outset. Patchstack is a company which is not a host though, I suppose that’s important to mention at the beginning. It’s a company which is in the security space, very much in the WordPress space, but perhaps more broad than WordPress, I’m not sure. But not a hosting company. But obviously your presentation focuses its aim on hosting, I guess because that’s one of the places where the claim about security is most often made. You know, you’ll go to a, the landing page of hosting Company X, and you’ll see somewhere fairly near the top, secure hosting, or something along those lines. And you’ve decided to examine that in fine detail and look at these 30 vulnerabilities. I guess really just tell us about this test and what it is that you decided to do and some of the items that came out of that. [00:07:50] Maciek Palmowski: Okay, so maybe let’s start with how it even started, right? Because there was a trigger. At some point we published one report about the state of WordPress security. We tweeted about this. We got the response from none other than Matt Mullenweg, who kind of asked a very interesting question, but isn’t hosting companies taking care of this already? And this was, kind of at this moment when we were, we thought that we know the answer that, no they aren’t. But to be honest, we didn’t have any broader proof about this. We knew how it’s working at some hosting companies, but we could say that it was more of an anecdotal evidence that we had. So this was kind of the trigger that made us, okay, let’s check this. But not with one partner or two partners, but with more hosting companies. So we did this research twice. First we just did kind of a beta run because we weren’t sure about the result and, is it even a good idea to go deeper inside of it? And during our first run, we were already very surprised because like the methodology was very simple. We just installed vulnerable plugins and we checked if we would be able to use the vulnerability. Because if the hosting is claiming that, we got your back, we are making your website secure, we have this and that, this means that they should protect against it. So it was as simple as that. And when we were doing our first test, we were quite surprised because we saw, if I remember, that 80% of the attacks went through. 80% of the attacks. So our first reaction was, okay, we are doing something wrong. Okay, this was only few hosting companies, less plugins, but still the result were so surprising for us because we thought that, okay, that the problem exists, but it’s not that big of a problem. But it was. So that’s why we did the second test. And this is about which the, my talk will be mostly when we tested more hosting companies, more plugins. And we saw that the problem still exists. Of course it was, in some cases 70 few percent. So still, it’s a huge problem, especially if we are talking about some companies that are literally saying, you don’t have to install anything additional when it comes to security on your website. We got your back. They don’t. We found a lot of interesting things, but still the problem exists. [00:10:21] Nathan Wrigley: So just deep diving into that a little bit, when tests like this are done, there’s obviously, the claim might be levelled, you know, obviously Patchstack would, this kind of maybe benefits Patchstack, if you know what I mean. So let’s just sort of clear up what the test involved. So presumably the plugins that you chose are ones where it’s publicly known that there’s a vulnerability in this component or this particular file or what have you. So is that the case? This is stuff that, longstanding understanding that there’s a problem here. [00:10:51] Maciek Palmowski: Yes. We only use the plugins that we had all the proof of concepts. So we know how have the vulnerability happened, what was the attack vector? They were all reported through our bug bounty programme, because that’s why we had the proof of concept. Yeah, and that’s it. It was, like I said, it was as simple as that. We had a really broad mix of all the plugins. How many? It was 30 something of those plugins, if I remember. Different ones. Some were connected with WooCommerce. So, like a very broad selection of them. Different vulnerability types. So we try to mix it up as much as possible. [00:11:27] Nathan Wrigley: Was the situation for each hosting company the same though? In other words, was the things that you did in one hosting environment the exact same as you did in another hosting environment? No. You mixed that up a bit as well. [00:11:38] Maciek Palmowski: I mean we used all the same plugins, like the methodology was always the same. But we got totally different results. Even if, and this was one of the most interesting findings, because very often hostings will put a logo of some company that takes care of security. For example, say, Cloudflare. And despite using the same stack for security, they got different results. [00:12:02] Nathan Wrigley: Interesting. [00:12:03] Maciek Palmowski: So it turns out, in many cases, it’s not about the tools that you are using, it’s how you are using them, which was very interesting. And we did everything. We tried to enable every feature, every security features on those hosting, to kind of give them a chance to kind of make sure that they are defending the most as they can. And the result in most cases was very simple. They were doing quite well with the generic ones like uploads, patch reversal, things like this, which are very generic in PHP. But with those WordPress specific attacks, they just failed miserably. [00:12:44] Nathan Wrigley: That’s so interesting. The word secure hosting, which you’ll see all over the place, it feels a bit like using the word healthy on food. There’s no real definition of what healthy is. You know, a company selling chocolate could probably pretend that it’s healthy compared to something else. [00:13:04] Maciek Palmowski: Like here, healthy chocolate is exactly, like in some cases secure hosting. [00:13:07] Nathan Wrigley: Right. So what do you take from this then? I mean basically, is your survey saying that whenever you see the word secure hosting, be sceptical? [00:13:16] Maciek Palmowski: Yes. [00:13:16] Nathan Wrigley: Okay. As simple as that. [00:13:18] Maciek Palmowski: It’s as simple as that. Because one of the things that we were always promoting, security is not a plugin, it’s not a one button thing. Security is a process. It’s layers. And that’s kind of why we, especially after this report starting kind of using the term, Swiss cheese layer model. Because every layer will fail in some way. That’s also why you still need all the security solutions that hosting provides, because they do have a lot of interesting solutions against those generic attacks. Because they’re doing really great when it comes to those generic ones. And that’s great because some of the attacks will be already dealt with. So whatever passes to the second layer, it has less work to do because a lot of it was already stopped at the first layer. The second layer should be something more WordPress specific that understand what is installed. And with this it can catch also a lot of it. But still, you have to be prepared that, because again, this layer also isn’t perfect. Because there are zero days vulnerabilities, there are custom code, there are a lot of things that can happen, that your website will be hacked. I mean, weak password. Simple as that. That’s why you also need to have a layer, which will be more of what to do if everything else fails. Because you do need to know that you have to inform your clients, all the GDPR related things. How to kind of, I don’t know, use the backups. In short you need to have procedures. You have to be prepared before the attack happens. Because let’s be honest, asking some lawyers about, what should we send to our clients? The moment when, well, the milk is already spilled. It’s like the worst moment to think about it. Especially that, hey, your website was just hacked. It’s not just a technical problem, it’s also a business problem. Again, with those GDPRs and everything. So yeah, the more layers, the better. You still need to remember, every layer can fail in some place. That’s why the more, the better. [00:15:29] Nathan Wrigley: Would you like to see a standard industry-wide definition of something like a badge or, I don’t know, let’s say for example, that you put the word secure hosting on your website, that has to actually stand for something. Because obviously coming from the background that you do with a broad oversight on what that is, you have a vast amount of data at your disposal. You can see all of this kind of stuff. But every company can make the claim that our food is healthy, our hosting is secure. But I don’t know, in the model that we’ve got where any company can put anything they like on a website, I don’t really know how you do that, but some sort of accreditation or something. I don’t know. [00:16:08] Maciek Palmowski: Honestly, it’s really difficult because as I said before, a lot of companies using the same tools were failing in different ways. So that’s a problem. On the other hand, like sometimes the, those stupid things like weak passwords. And it doesn’t matter that you had a, let’s call it a certified secure hosting, you still failed because your password was weak, you know? So, also certificates like this can backfire because some people might think I have a secure hosting, I don’t have to worry about things. And then you have 10 admin accounts for everyone. [00:16:43] Nathan Wrigley: Is there is there something, some mark of that description that you, personally, that you go looking for though? Is there some credentialing system which you think actually does carry some weight? So for example, I don’t know, like the insurance space or the accountancy space or something like that. You have to have that accreditation in order to do business. Is there something like that? Is there a mark which hosting companies can apply for which you could have some confidence in it? [00:17:13] Maciek Palmowski: Okay. So for sure one of those things would be, and I don’t want to say it as an advertisement, but it is a thing that you see that the hosting is thinking a bit better about security, kind of looking if they are a Patchstack partner. Because this kind of automatically means that they do have this WordPress, the security WordPress layer. So that’s already a good sign. So yeah, I would start with this. I think that’s kind of one of the simplest ways, but again, Patchstack isn’t the only solution that does it. So looking for partners of such companies might be the best way to start because having those Patchstack aware security solutions built in, into the hosting is a really good sign. [00:18:05] Nathan Wrigley: Yeah, okay. Now, the inevitable conversation in the year 2026 is AI. It doesn’t matter which area of WordPress you’re talking about. AI manages to get in somewhere. I am presuming that the landscape in terms of security only got more complicated because of AI. Because I’m imagining that attacks that needed to be conceived by a human can now be conceived in a fraction of the time by an AI agent. But not just one, maybe a dozen or a thousand or whatever it may be. Let’s just talk about that for a moment. It feels almost as if AI and security are like, that’s a real systemic problem for the future of the entire industry. Because these things can happen so fast, a plugin vulnerability is discovered by an AI agent. It then discovers the attack surface, implements the attack all in a matter of seconds, possibly. What’s the position? Like, how do we stay calm basically in the year 2026? [00:19:09] Maciek Palmowski: So the problem already existed around a year ago, because a year ago when we did our State of WordPress Security Report, we already saw that vulnerabilities are being used after around five hours after kind of being published. So five hours. That’s the first thing, because we still have a lot of people that say, yeah, just update your WordPress weekly and you’re good to go. No, you’re not. Looking at this number, you have five hours. [00:19:39] Nathan Wrigley: Okay. Let’s just parse that at the moment. So the vulnerability is published. So there’s a whole thing there, like the vulnerability may well have been discovered prior to being published, so that’s a whole other thing. [00:19:52] Maciek Palmowski: So first the vulnerability is discovered. Then at least how it works on, with our bug bounty. We inform the vendor they have, let’s say around a month to fix it. When they fix it, we publish everything and, yeah. [00:20:09] Nathan Wrigley: Okay, so from the moment you publish, you can then detect that that is being leveraged within a space of five hours. [00:20:17] Maciek Palmowski: Yes. [00:20:17] Nathan Wrigley: Okay, that’s really interesting. [00:20:19] Maciek Palmowski: But there is a problem. There is a really big problem. So if the vendor doesn’t respond, we still publish it. [00:20:26] Nathan Wrigley: How long do you give them? Is it like. [00:20:27] Maciek Palmowski: It is the one month. [00:20:28] Nathan Wrigley: Okay, thirty days. [00:20:30] Maciek Palmowski: Of course, if they reach out that there is some problem, they need like extra days. But in most cases, we’re talking about the vendors that just don’t respond at all. We publish it anyway. But the problem is that, from all the vulnerabilities that were discovered last year, 50% weren’t patched at the moment of publishing about it. 50%. [00:20:50] Nathan Wrigley: So half of the plugins where there was a known vulnerability, the vendor had been informed, they’d had this 30 day window. Half of them made no amendment to their code. [00:21:01] Maciek Palmowski: Exactly. [00:21:02] Nathan Wrigley: Okay. Wow, okay. [00:21:03] Maciek Palmowski: Again, going back to this classical, yeah, just update your WordPress regularly. No. [00:21:08] Nathan Wrigley: No, that’s a really different surface, isn’t it? [00:21:11] Maciek Palmowski: It doesn’t work on so many levels. Because not only the problem is with the fact that, still the famous five hours, which also, it’s five hours now. It was much longer a few years ago. On the other hand, yeah, most of those, I mean around half of it aren’t patched, so the attacks will happen quicker than it get patched. So yeah, there is a lot of problems like this. And also the problem with security is that it’s really difficult to sell. [00:21:39] Nathan Wrigley: It’s like insurance, isn’t it? [00:21:40] Maciek Palmowski: Yeah. But insurance, okay, you see your car, your house, it’s real. It’s real, you kind of see it. The only category of websites that it’s much easier to kind of explain is e-commerce. [00:21:54] Nathan Wrigley: Yes. You can feel the tightening on your wallet. [00:21:56] Maciek Palmowski: They literally see the money. They can kind of really, okay, one hour of my website not working equals this and this Złotys or Euros or whatever. So that’s easier to explain. But for most people, yeah, security, meh. [00:22:11] Nathan Wrigley: Yeah. That’s really interesting. So you mentioned, about this survey, you mentioned that fully 80% of your penetration testing resulted in something. What were the sort of, the high level items? Apart from that 80% figure. What were some of the other, because you said there were a few interesting things that dropped out of it. Can you mention anything else? [00:22:31] Maciek Palmowski: So like I said, one of the things was that we learned that, despite using the same tools, we got different results. That was also a surprise for us. [00:22:39] Nathan Wrigley: So let’s just figure that out. So at hosting company A, we’ve got a WordPress website with the same collection of plugins in. Hosting company B, exactly the same as far as you can make it the same, but things are different. [00:22:52] Maciek Palmowski: No, no, they are, for example, they’re using for security the same tools. [00:22:56] Nathan Wrigley: Right, okay. [00:22:57] Maciek Palmowski: So in theory, if they’re using the same tools, we should have exactly the same results. [00:23:03] Nathan Wrigley: So does that then point to a different set of configurations on the backend, or is it more curious than that? You just don’t quite know what’s going on. [00:23:12] Maciek Palmowski: I mean because it’s not something that they will tell us. But yeah, in most cases, it’s all about configuration because the fact that you’re using a tool, it’s also important how you use a tool. Also, with security is very often about, is something easy to use or is something secure? And kind of finding the balance. So some of the companies probably had a bit more aggressive configuration, which is better from the security point of view, but probably more often result in some annoying side effects for the user. Also what, this was one of the most interesting things, but also what was very interesting because we contacted every company afterwards and we informed them that we did the test. Here are the results, what went through, what was blocked. And some of the companies did an amazing job of fixing whatever they could. On the other hand, we saw that some of the companies, because we did some extra tests later just to check what they did with our report, did nothing. That’s one of the things about security in general, not about the hosting, about even having vulnerability in your plugin. That’s normal that we make mistakes. We’re humans, right? So that’s normal. What’s important is how we deal with them. If you have a problem and you fix it as quickly as possible, as good as possible, that’s great because you learn from your mistakes, you fix it, and you move on. Perfect. Good job. Now you are in a much better position than before. But if you get this, you look at it and you say, ah, this is fine, that’s the worst behaviour from the security point of view that you can have. [00:24:57] Nathan Wrigley: I’m going to ask you not to name names here, but were some of the companies familiar to us? [00:25:05] Maciek Palmowski: For sure, because we did test the biggest ones. But there is a reason why we didn’t want to name them, and it wasn’t about that we were afraid that I know someone will get mad or whatever. It was more about this weird side effect that could happen. Some users would think, my hosting isn’t on this list, so probably I’m secure. Probably you’re not, you just weren’t in the test. Because we also did some site checks and everything. And we saw that a lot of those problems happen at most of the hosting companies. And like I said, the more important part was how did they reacted after getting the report. Like I said, it was a more common problem that we even thought. [00:25:43] Nathan Wrigley: Do you, obviously, you know, caveat all of this with the fact that you work for Patchstack and what have you, do you see it even as the role of a hosting company to have any position on security publicly? Or would you prefer them not to make grand claims about things that you believe they can’t necessarily substantiate? I don’t really know where I’m going with that question, but I’m just wondering if there’s just a sense that the language that’s being used is too strong. You know, secure hosting implies we’ve got all the padlocks, and the padlocks are there and you’ve got nothing to worry about. You’ve found a different picture. So I’m just wondering whether or not you would just prefer that the hosting companies stop talking about this altogether. [00:26:27] Maciek Palmowski: I do think that’s, one of the biggest problem here is about the claims, the bold claims, the whole marketing around it. Sometimes even you can find documentation of some of them that, yeah, you don’t need to install any third party tool because we got you covered. We checked it, no they didn’t. So that’s kind of the problem. It’s really more about the, how they market it. If they would say, okay, so we have a really performant hosting that does this, this and this. When it comes to security, kind of do it yourself. I mean we are providing this layer, but the rest is up to you. And that’s okay. That’s an honest claim. We are not doing everything for you. We are doing this part, but this is up to you. This would be much better. I know that from the marketing point of view, it doesn’t sound as good as, we got all the security that you can imagine, don’t have to worry about this. Because that’s kind of the thing that very often managed hosts trying to sell, that you don’t have to worry about things. You just have to focus on whatever you have, writing content, selling stuff. If you have a e-commerce, whatever, that’s it. That’s kind of the only thing you should think of. Not about performance, because we got your back. Not about security, again, we got your back. And if you are paying for a managed hosting and suddenly they would start having like this different way of messaging to, it’s not that obvious that we have your back in everything. That would be very difficult for them. So now it’s kind of the problem that, because everyone is kind of using this messaging, everyone else also has to. And also if we think about how a lot of those algorithms, look like that algorithms love bold claims. They want something white or black, not grey. And the truth is, most of the things we are talking about, it doesn’t matter, security, SEO performance, it’s everything in the grey zone. That’s why a lot of developers can end their talk with, yeah, it depends. There is no right or wrong. It depends because there are so many things you have to think about. I could say that, and this is my kind of thing that, most of the websites that people have should be static. They don’t need even WordPress at all. This is a horrible claim if you’re a manager of a WordPress hosting, right? So that’s the thing. But it all depends on so many things, but yeah, the messaging is important. [00:29:08] Nathan Wrigley: Yeah, if you were, on a personal level, if you were going out there looking and let’s say, if you can somehow put your job hat to one side, what would be the kind of things that you would be looking for? What questions would you be asking related to security if you were to be going to these companies? From everything that you said, obviously it’s not black, it’s not white, it’s definitely grey. So every setup has some way of being vulnerable. But what are the kind of intelligent questions that you would be bringing to hosts to get some reassurance that at least they appear to know what they’re doing, even if they can’t make the claim that they’re a hundred percent cast iron, water tight? What might be some intelligent questions to start asking? [00:29:49] Maciek Palmowski: One of the best questions you can ask is just, is there any solution in your security stack that is WordPress aware? Not the general one. Because if they only start talking about some web firewall, things like this, it’s already kind of a red flag. Because this is, overall, if we’re talking about firewalls, that’s not the correct layer about which, this is the generic one. So this is the main question. How do you take care of WordPress specific attacks? Simple question. And if they will start responding, yeah, that we have this web application firewall that, in most cases this will be a sign that, no, we are not talking about the correct layer. That’s not it. It’s probably not aware about what is happening in WordPress. [00:30:40] Nathan Wrigley: Okay. So given that this is a WordPress podcast, and we are at a WordPress event, that would be the beginning of your questioning is demonstrate that something in your stack is specific to WordPress. [00:30:52] Maciek Palmowski: Exactly. [00:30:53] Nathan Wrigley: Okay. And beyond that, is there any questions that, so let’s imagine that they come back with, yes, we have something specific, it’s WordPress. What would be sort of sensible follow up questions? [00:31:00] Maciek Palmowski: I mean you can kind of start off about, okay, what exactly you are using? Because there is a limited amount of tools that are really WordPress aware. So if they will answer with kind of a product name, that’s kind of the easy way that then you can check it on your own. But that’s kind of the thing. Is it WordPress aware? [00:31:19] Nathan Wrigley: Does it worry you in some way that there’s this perception out there that WordPress is insecure? You know, if you ask a thousand people, you’d maybe get 800 saying, oh WordPress, you know, we’re not touching that with a barge pole. Do you worry that content like this, that you are putting out, that that might fuel that fire? Does it concern you in any way that it might lean into the argument that, I don’t know, somebody can link to that blog post from a rival CMS, or a SaaS platform, which does something similar to WordPress? Where do you sit on that? [00:31:51] Maciek Palmowski: That’s a really difficult question. And this is one of the questions that when I talk on non WordPress events, I love to ask people. Is WordPress secure? And in most cases, I see that most of the room is, yes, it’s unsecure for sure. And I’m like, no, that’s not true. WordPress is secure. Every year there is just a few minor vulnerabilities in Core. That’s it. The problem is, of course, that WordPress on its own lacks some functionality. That’s why we install plugins. And here we enter another problem because, okay, every year we have like thousands of those vulnerabilities in general in plugins. On the other hand, we have thousands of plugins. So kind of statistics will always look bad. But that’s why every time when you want to select a new plugin, you need to do some research. Yeah, I know it’s boring and everything but, hey, now we have AI, you can do it much quicker. It can help you a lot. But looking at all those databases, for example, we have one database, WPScan has. There are those databases of WordPress vulnerabilities that occur to every plugin. And you can see, is the plugin you’re interested in had a lot of vulnerabilities? On the other hand, how it kind of looked historically. It’s not just about the number of them. In general, it requires some research. And yeah, if we are just like looking at this, and this kind of vibe that right now we have that we are just about really bold opinions stated quickly that will fit one TikTok, yeah, WordPress is in a horrible position because, let’s be honest, it’s like, if you have, I’m not sure how many seconds does a TikTok movie has? [00:33:39] Nathan Wrigley: I think 30. [00:33:40] Maciek Palmowski: Okay, let’s say 30. So it will sound much better that you will say, yeah, WordPress is unsecure, which is not entirely true because it depends again. One of the most boring, especially again for those algorithms and everything, it’s a grey zone. Because we are collaborating with a lot of companies that are making plugins, and we see how their security flow looks like. How they are dealing with vulnerabilies that are discovered. And honestly, I’m amazed how well some of those companies are doing it. They are very serious about it. They understand how important it is. For them it’s something very important. [00:34:22] Nathan Wrigley: I suppose WordPress is a victim of its own success in that sense. And it would be a bit like, I guess a good analogy might be if you’ve got a car manufacturer and they produce a thousand cars a year and you compare them to Ford who make, let’s say, I don’t know, 20 million a year. And the question is, well, whose cars break down more often? [00:34:41] Maciek Palmowski: Yeah. Do we look at the percentage of the number? [00:34:44] Nathan Wrigley: Right. And if you say, well, 400,000 Fords broke down last year, and one of these other manufacturer, you can immediately see why there’s a problem there. And that I think is the landscape in which WordPress is often painted. The reason there’s lots of publications like yours bringing out WordPress information is because it’s the most popular thing. It makes sense to write about the most popular thing and to try to find the vulnerabilities and disclose them in a sensible way. So I don’t know what we do with that. It is just the way it is. [00:35:15] Maciek Palmowski: I would also say there is one more interesting aspect because WordPress is considered unsecure because of the plugins. But what’s funny, for example, Elementor is also considered unsecure because there are plugins for Elementor. This is a very weird moment when the thing that brought WordPress to its bigger success, security wise, is its biggest problem right now. Because WordPress did a lot of, I mean it was always great to, being as it’s kind of, let’s call it entry level CMS. For many people, it was also the way how they began the adventure with PHP development because it was so easy. Now we kind of have the, all the consequences of being that easy. [00:36:06] Nathan Wrigley: Yeah, in a sense, this is going to sound ridiculous, we should be glad that there’s people talking about WordPress vulnerabilities, because it means the project is successful. And it also means that it’s, there’s an industry of WordPress security solutions, and there are people who take this very seriously and dedicate their lives to it. And you may not find that in some of these other ones, you know, some of the smaller CMSs and things like that. I think we’ve probably hit about the sweet spot for the amount of time. But Maciek, I don’t know if there was anything in that report that you have got lined up in your presentation that I never got to. If there was a particular thread that you wanted to pull. If there is, go for it. [00:36:46] Maciek Palmowski: No, I think we covered all the important things. And as you kind of said, this AI aspect, this will change so many things. [00:36:55] Nathan Wrigley: Yeah, we’ll come back in two years and this conversation will be a very different thing. [00:36:57] Maciek Palmowski: Oh, I think even in few months which will be very interesting. Yeah, so this aspect, it’s really very surprising. And I think that everyone who is right now kind of giving somewhere a talk about AI and security is in a very difficult spot because. [00:37:14] Nathan Wrigley: Yeah, your content is going to look stale quickly. [00:37:16] Maciek Palmowski: Yeah because you know it’s like, but a week ago everything changed. Yeah, I have to rewrite everything. [00:37:20] Nathan Wrigley: Speaking of which, by the time that this goes out, hopefully you have managed to give out your presentation at WordCamp Europe. I will link to it and anything else that we’ve mentioned today in the WP Tavern post. So go and check that out. But I will specifically link to the wordpress.tv version of your presentation, which no doubt will have been created by then. So Maciek, thank you for chatting to me today. Good luck. I hope presentation goes well. [00:37:43] Maciek Palmowski: Thank you. Thank you so much. Yes. I might need a bit because, you know, it’s WordCamp Europe. It’s a big conference. [00:37:49] Nathan Wrigley: It is, yeah. Good luck. I hope that you manage to stay calm. [00:37:52] Maciek Palmowski: Thank you. On the podcast today we have Maciek Palmowski. Maciek is based in Poland and works at Patchstack, one of the companies in the WordPress ecosystem dedicated specifically to security. At Patchstack, Maciek collaborates with other security professionals on industry reports, bug bounty programs, and solutions for agencies, product owners, and hosting companies aiming to secure their client sites. I met up with Maciek at WordCamp Europe in Kraków, and we discussed his presentation there. It examined the claims of “secure hosting” made by many WordPress hosting providers. He describes how Patchstack set out to test these claims with real-world penetration testing, using 30 known plugin vulnerabilities across multiple hosts, employing standardised methodologies, and validating their results independently. The findings are sobering. The majority of WordPress-specific attacks still get through, and there’s a significant gap between the marketing hype and real protection. The conversation starts with Maciek’s background and how his journey in the WordPress security space led to a focus on the promises made by hosts. From there, the discussion gets into the research approach: the selection of well-known vulnerabilities, consistent testing across different hosting environments, and the surprising result that even hosts with identical security tooling produced drastically different outcomes, showing it’s not just about what tools you use, but how you use them. We talk about the “Swiss cheese” model of security, every layer will have holes, so you need multiple, overlapping defenses, and honest communication from hosts about their limitations. We also explored whether an industry-wide standard or badge for “secure hosting” is feasible or even desirable, given how easy it is for strong marketing claims to outpace reality. AI also enters the conversation, increasing both the speed and sophistication of attacks, and making patching and processes even more important, especially as the volume of vulnerabilities continues to rise and the time to exploitation drops. If you’re interested in understanding what “secure hosting” really means, how to ask intelligent questions of providers, and the realities of WordPress security in 2026, this episode is for you. Useful links Patchstack Checkout Summit Testing the promise: does secure hosting deliver? – Maciek’s presentation at WordCamp Europe 2026. It includes the video of the presentation. State of WordPress Security in 2026 Report WPScan

Auxiliar de contabilidad

Capacity Building Officer

Senior Food Monitor – Badulla

WASH and Construction Engineer

Senior Community Mobilizer – Trincomalee

Roving Safer Partnership Officer

Coordenador – Administracao (Gaza)

Coordenador Senior – Financas de Programa (Maputo)

Oficial de Controlo Interno e Salvaguarda (Matola)

Motorista – Camiao (Matola)