Author: Sarah Gooding

Gutenberg 15.1 was released this week with Openverse integration in the Media tab. The Openverse library of openly licensed and public domain works has also moved to its own website with an updated design. It contains more than 600 free-to-use images and audio files that are now available inside WordPress’ editor:

Clicking on an Openverse image will instantly insert it as an Image block with the proper attribution and license automatically added to the caption. The experience is so much faster than downloading from the Openverse website and then uploading to the Media Library.

Another major highlight in 15.1 is the ability to add custom CSS on a per-block basis. This can be done through the Global Styles menu in the Site Editor. For each block you can add your own CSS to customize the block appearance by scrolling to the bottom of the panel to the “Additional Block CSS” button. These CSS edits will be applied to all instances of the block on the site.

Gutenberg 15.1 also introduces support for shadow presets in Global Styles, with four defaults available (Natural, Crisp, Sharp, and Softy), and the ability for theme authors to add custom presets via ‘theme.json’. The announcement post included a video that demonstrates the new UI:

In 15.1 Navigation has been added to the browse mode sidebar in the Site Editor, so users can quickly access their menus and menu items, rearrange them via drag and drop, or navigate the links.

This release makes some changes to the “paste styles” feature that was introduced in version 15.0. The Options menu in the block toolbar now displays both “Copy styles” and “Paste Styles” to make it easier to understand how to use the feature, as it previously was unclear with just the “Copy Styles” option available.

Gutenberg 15.2 improves the Site Editor loading state for better initialization. This is an important update for making the Site Editor ready to come out of Beta. It’s not a complete solution but makes it a bit more polished with the following changes, as outlined by Riad Benguella in the PR:

• A CanvasSpinner that can be used in components that have a “ready” state. So instead of rendering an empty white page, the spinner is rendered when these components are not ready.
• Makes sure the iframe has a “white” background by default to avoids too much background color switches during initialization.

These are just a few of the highlights. Check out the 15.1 release post for the full list of enhancements, bug fixes, performance improvements, and tooling changes.

WordPress.com is currently testing two new blocks for generating images and paragraph content using AI. The blocks, which are currently labeled as experimental, were first spotted by Jen T of WPcomMaven who published a few examples on her blog this week.

WordPress.com developed the blocks through a partnership with OpenAI, creators of ChatGPT and DALL·E. Automattic engineer Artur Piszek gave a quick overview of the experimental blocks in a post on the WordPress.com support forums, calling the new feature “Jetpack AI – your writing assistant on WordPress.com.”

I took both blocks for a test drive, starting with the image generator. Users put in a prompt in a simple UI and the block generates four images, which can be expanded before selection. Here are a few examples:

I was not terribly impressed with the images, which every time seemed blurry and ill-conceived. Some of them bore an almost cruel likeness to the prompts, with living creatures and humans faring poorly compared to images of inanimate objects. The faces are almost always distorted with what appears to be bits of flesh melting off. Unless a user is unusually skilled in crafting the prompts, they may struggle to get any useful images.

The AI-generated paragraphs are a somewhat better experience but need more flexibility. The block will automatically generate new paragraphs based on your existing content. It does a decent job, but it would be more useful if you could start from a blank page and feed it a prompt instead, as one of the main benefits of using AI for generating content is that it can offer a starting place from which the writer can improve.

The content can be further edited by transforming the block into a paragraph. This isn’t easy to discover and would need to be emphasized better in the UI.

“We were considering making the block outright editable, and I see that we may need to create a more intuitive editing experience,” Piszek said after reviewing feedback from users in the forum.

When using this experimental paragraph-generating block, users may want to familiarize themselves with how AI-generated content can impact their search rankings. Google recently published guidance stating it will reward high-quality content however it is produced but cautions that “those seeking success in Google Search should be looking to produce original, high-quality, people-first content demonstrating qualities E-E-A-T (expertise, experience, authoritativeness, and trustworthiness).” This is not always possible when using automation.

WordPress.com’s AI-generated content blocks are in the earliest stages of testing and are not guaranteed to be publicly launched or make it into Jetpack. With some refinements, the blocks could prove useful but will more than likely only be available to paying customers, as the costs of AI-generated processing resources can stack up fairly quickly.

“AI models and tools are a bit unpredictable,” Piszek said. “We want to be mindful of how those tools behave, what impact they have on your creativity, and how we can make them support you.

“At the same time, we are still learning and adapting, so please keep in mind that these features can change or disappear anytime.

“Once we announce them, they are most likely be paid extra (on top of existing plans) depending on how much we have to pay OpenAI for their services.”

WordPress.com users who test the experimental blocks are encouraged to leave their feedback in the announcement thread.

WordPress 6.2 Beta 1 was released on time today, and can be tested by using the WordPress Beta Tester plugin or downloaded directly. In just seven weeks, the upcoming major release will roll in the last nine Gutenberg plugin releases, which account for 292 editor enhancements and 354 bug fixes.

The beta 1 announcement confirms that WordPress 6.2 will be removing the Beta label from the Site Editor. Although the remaining required items for removal, namely a ticket for refining the Site Editor loading state, remains open, Editor Triage co-lead Anne McCarthy confirmed that work has “quickly progressed over the last few weeks to to get some items in place for 6.2 and to start a new PR for improving the loading state further,” beyond the initial effort from Gutenberg engineer Riad Benguella.

WordPress 6.2 contributors have published a detailed testing guide, with information on setting up a testing environment and key features to test with videos, screenshots, and information on what features should do and how they can be tested.

One of the major highlights in this release includes the new distraction-free mode, which offers a more focused writing experience that hides unnecessary interface elements from the editor. The testing guide demonstrates how it can be enabled and disabled.

WordPress 6.2 also makes major strides towards improving the Navigation experience, which has proven to be one of the more complicated problems to solve on the full-site editing journey. The testing guide offers a quick tour of the updated Navigation Block UI, which now contains an editable view in the block settings sidebar, along with inline editing for menu items.

A few other highlights of the upcoming 6.2 release include the completely revamped Site Editor interface, block settings with split controls for Styles and Settings, improved Pattern insertion, a new Style Book for previewing block styles, custom CSS for specific blocks, and Openverse integration with the WordPress media library.

Following a few more beta releases, RC 1 is expected on March 7, and the final release is scheduled for March 28, 2023.

During the most recent BuddyPress development meeting, contributors decided to focus the upcoming 12.0 release on merging the BP Rewrites feature plugin into core. This plugin is the result of a ten-year-old effort to migrate BuddyPress’ custom URI parser to use WordPress’ Rewrite API.

One year ago, BP Rewrites went into beta. It’s not certain how the change will interact with different plugins, so BP developers recommended it be tested for at least two major BuddyPress core releases before considering a merge. Early testers uncovered many incompatibilities and conflicts with various BuddyPress features.

In order to move forward confidently with support for users who may experience plugin conflicts, BP Rewrites’ maintainers have decided to create a new plugin that will provide backward compatibility. This new plugin will be called BP Classic and will also contain BuddyPress’ legacy widgets, a change that BuddyPress core developer Mathieu Viet said “will be our first move towards progressively rebooting BuddyPress.” BP 9.0.0 (released July 2021) gave users the ability to transform legacy widgets into a block with two clicks. Moving these widgets out into BP Classic will be a significant step towards their eventual retirement.

The BP Attachments Add-on, a new component for managing BuddyPress attachments, is ready to move into beta testing. Viet has updated the plugin’s README file to include the features it will launch with in the plugin on WordPress.org:

• Front-end and back-end Media library for all your members
• Administrators can moderate Members media from the back-end Media library
• Members can upload public or private media into their personal Media Library as well as organize them creating file directories, photo albums, movie or music playlists
• User media blocks for all your site’s content contributors
• Members can upload and attach public media to their activity updates (Needs the BP Activity component to be active)
• Members can upload and attach private media to their private messages (Needs the BP Messages component to be active)
• All members public media can be browsed from the Community Media directory.
• (beta) A new avatar Upload UI

Future versions of the feature plugin will include a new cover image upload UI, and the ability to share media with friends and between group members.

BuddyPress contributors anticipate bumping the required WordPress version to 5.8 in the 12.0 release. Beta 1 is planned for April 15, with the official release landing May 31.

WordPress Core Committer Adam Silverstein has published a proposal for adding automated performance tooling that would offer continuous monitoring for performance issues so they can be resolved before major regressions are committed to core.

“Similar to our unit test suite, automated performance testing would help protect core from introducing large performance regressions by catching problems immediately and tracking performance over time,” Silverstein said. “Automating testing also means saving contributor effort by replacing a time consuming manual process.”

As the Performance team is focused on introducing new features with measurable gains, as well as testing new WordPress releases before they ship, they have haphazardly uncovered what Silverstein described as “significant performance regressions.” A few examples include a regression found before WP 6.1 in theme.json processing and another issue with changes for loading the textdomain.

“Automated testing would catch this type of regression as soon as it was introduced, making it much easier to resolve,” he said.

Silverstein highlighted the Gutenberg project as a good example of performance tracking, as each release publishes metrics for changes in loading time, typing time, and block selection time. The team has also begun tracking TTFB (time to first byte) for classic versus block themes in their code health dashboard, which is helping them see the immediate impact of the latest commits.

“It’s making visible the performance regression in block theme rendering when compared with classic themes for a simple ‘hello world’ page,” WordPress Performance team contributor Emily Clarke said in the team’s most recent meeting. “As a team, we would like to make sure we’re properly prioritizing the tickets we have for 6.2 that would positively impact this metric—particularly anything that we need to land before the beta 1 milestone next week.”

A few contributors have already been working on improving the server response times for block themes, with PRs that should be landing in 6.2.

“Similar to Gutenberg, WordPress core would gather a set of automated performance metrics along with the existing test runs (e.g. unit tests, coding standards) we already have for each new commit,” Silverstein said. “These metrics can be used to identify the exact point a performance regression is introduced into core. At milestones like a major release, the metrics can be compared against the previous release to gauge progress.”

Silverstein proposes WordPress start small with by simply running a set of automated tests on each core commit for things like load time and total query time for classic and block themes. In the future, the team could capture additional server timing metrics and metrics for other contexts beyond the home page, such as the admin and single post post.

Response to the proposal so far has been positive, as the only alternative is relying on individuals to manually uncover new performance bottlenecks and report them. Better tools will help pinpoint these issues faster, before they get rolled out to millions of people.

“Given how much emphasis peer CMS platforms place on ‘advertising’ their performance and benchmarking it against the industry leaders, investing in tools to ensure WordPress continues to perform optimally makes a lot of sense,” WordPress marketing contributor Dan Soschin said. “And, given how many sites are powered by WordPress, even minor gains in performance (including those unnoticeable to most people) add a lot of value to web hosts and lowering overall internet traffic burdens/bandwidth.”