WordPress.org

WordPress Planet

December 01, 2020

WordPress.org blog: WordPress 5.6 Release Candidate 2

The second release candidate for WordPress 5.6 is here!

WordPress 5.6 is slated for release on December 8, 2020, and we need your help to get there—if you haven’t tried 5.6 yet, now is the time!

You can test WordPress 5.6 release candidate 2 in two ways:

Thank you to all of the contributors who tested the Beta releases and gave feedback. Testing for bugs is a critical part of polishing every release and a great way to contribute to WordPress.

Plugin and Theme Developers

Please test your plugins and themes against WordPress 5.6 and update the Tested up to version in the readme file to 5.6. If you find compatibility problems, please be sure to post to the support forums. That way, those can be figured out before the final release.

For a more detailed breakdown of the changes included in WordPress 5.6, check out the WordPress 5.6 beta 1 post. The WordPress 5.6 Field Guide is also out! It’s your source for details on all the major changes.

How to Help

Do you speak a language other than English? Help translate WordPress into more than 100 languages!

Think you found a bug? Post it to the Alpha/Beta area in the support forums. We would love to hear from you! If you’re comfortable writing a reproducible bug report you can file one on WordPress Trac. Don’t forget to check the list of known bugs!

by Josepha at December 01, 2020 10:09 PM under Releases

WPTavern: Block-Based Bosco, Second Full-Site Editing Theme Lands in the WordPress Directory

Fränk Klein, a Principal Engineer at Human Made, is now the second theme developer to release a block-based theme to the WordPress theme directory. Block-Based Bosco is a recreation of his Bosco theme, which he released in 2014.

Block-based themes, also called FSE (full-site editing) themes, are currently experimental. They require the use of the Gutenberg plugin, which will automatically detect their structure and activate the beta version of the site editor. This system allows users to experience a WordPress install that is comprised entirely of blocks. Widgets, nav menus, and the customizer screens are out. Everything from posts to site headers to navigation is handled through HTML templates, which users can customize via the site editor. It is still a raw experience but continually improves with each update of the Gutenberg plugin.

Just over a month ago, Themes Team representative Ari Stathopoulos released the first block-based theme, named Q, to the official theme directory. It was both a milestone in WordPress theming history and an invitation for developers to follow his lead.

We have since seen the initial work toward a block-based version of the upcoming Twenty Twenty-One default theme. It is not yet in the directory, but the community should expect it soon.

Developers like Klein and Stathopoulos are paving the way for others. For those who do not have the time or the inclination to scour the Gutenberg plugin’s code or follow dozens of tickets, they can take the easy route. Study the code of people who have done the legwork.

Klein has also written a detailed post titled What I Learned Building a Full-Site Editing Theme in which he goes into detail about his experience. Despite his optimism for the future of theming, he does not shy away from the problems he stumbled upon. It is a must-read for any theme author who is preparing to take the plunge into block-based theme building.

One thing that some developers may find surprising or may even make them feel slightly uncomfortable is that Klein spent much of his development time working from the site editor rather than in a code editor. “It’s likely that this will be the future workflow for creating themes,” he wrote. “Because not only can you edit a theme visually, but it’s also much more practical than writing block markup by hand. Especially because the interface makes it easy to discover the different options offered by blocks, so that you can adjust them as needed for your desired theme design.”

About the Theme

Block-Based Bosco in the site editor.

Block-Based Bosco is relatively simple. It is a one-column, no-sidebar theme, which is what most block-based themes will look like at the moment.

“Full-site editing themes are still missing a lot of essential features,” wrote Klein. “Therefore it’s important to choose a theme design that fits with these constraints. Else you’re going to have a very frustrating experience.”

Unlike Q, which is a bare-bones theme primarily for testing theme-related features, Block-Based Bosco is based on a design that users might want to actually use on a site, at least someday. Currently, full-site editing is not yet ready for use with production sites. The theme design holds up well for a simple personal blog.

There are things the theme could do better in the short term. Offering support for wide and full alignments would be ideal, particularly for a one-column theme. The editor and front-end content width also do not match, so it is not a perfect what-you-see-is-what-you-get experience. These are not make-or-break features for these types of experimental themes at this point. We are simply in the testing ground stage.

Right now, end-users need to start tinkering with themes like Block-Based Bosco — please do so on a test install and not a live site — and offering feedback. They also allow other developers to get more comfortable with a new system before it suddenly feels like it comes crashing down in 2021.

Opening Up the Theme Directory

One thing is obvious at this point. The WordPress theme directory needs to allow theme authors to upload block-based themes without hacks or other workarounds. Block-Based Bosco and similar themes are currently being shipped with dummy files, such as header.php and footer.php, and unnecessary PHP code in functions.php to bypass the Theme Check system. With these extra files and code removed, block-based themes are minuscule in comparison to traditional WordPress themes.

There is an open ticket on the WordPress Meta Trac and a patch for the Theme Check plugin. Someone needs to pull the trigger and make it happen.

by Justin Tadlock at December 01, 2020 09:19 PM under Themes

November 30, 2020

WPTavern: Admin 2020 Version 2 Introduces New Lite Version, Better Plugin Compatibility, and Modular Architecture

Six months ago, Admin 2020 captured the attention of WordPress users with its fresh approach to skinning the admin screens. Version 2 of the plugin has been completely rewritten to support a modular architecture so users can enable or disable features, or selectively enable them by user role or username. Some users prefer the default menu but want to be able to categorize their media into folders with the plugin’s CMS-friendly architecture for organizing media and posts. This update significantly improves performance for those who don’t require the analytics, admin bar, menu, or other features.

The plugin now has a new settings interface that is less cluttered than the previous version.

“Admin 2020 started off as a WordPress admin theme, and that was always at the core of the plugin,” developer Mark Ashton said. “As we grew, we added more and more features on top of that and it became very difficult in its current iteration to separate those feature sets, or disable some features and let others carry on.”

Version 2 also greatly improves compatibility with other plugins. Ashton was spending a lot of time adding support for other plugins, which slowed down development. The new approach to compatibility causes fewer styling conflicts and works without having to add custom stylesheets for other plugins. Prior to this version, Admin 2020 disabled 90% of WordPress admin styling and applied its own.

“While this gave us complete control over layouts and styling, it was one of the reasons we had to spend a lot of time adding support for other plugins,” Ashton said. “So for version 2, we kept the WP styling (most of it anyway) and applied a lightweight theme on top of it. The end result is a theme that is more refined, quicker, and the most compatible we have ever put out.
Usually the only plugins we have problems with these days are the ones that actively disable non standard WP scripts and styles, which obviously breaks admin 2020’s layout.”

In the interest of keeping Admin 2020 lightweight, the plugin now uses a custom build of the UIkit framework that is more tailored to its specific use case.

“Instead of having uikit as a base, and then layering on top of it, we just tailored it to suit the plugin needs and thanks to the wonders of scss it is an incredibly easy framework to modify,” Ashton said. “Doing this also allowed us to support RTL much easier which was a very common feature request.”

New Admin 2020 Lite Version Offers Basic Features, Coming to WordPress.org in 2021

Admin 2020 is now available on the plugin’s website in a Lite version for free. In recognition of WordPress.org’s undeniable force as a distribution channel, Ashton is considering changing his previous strategy of pursuing a fully commercial model to embrace the idea of marketing a free plugin with a paid upgrade.

“Admin 2020 has grown so much since we launched in May this year and it’s no longer just an admin theme,” Ashton said. “In fact, we see it as more of an admin extension now that also has a theme. Because of this, we felt there are now enough features to be able to offer the lite and pro versions.”

With the new modular system in version 2, the free and commercial versions are the same plugins, except the lite version has the paid modules removed.

“This means the development of the two versions is synched and updates, new features and bug fixes all rollout at the same time,” Ashton said. “For the time being we are going to stick to our own distribution channel just to keep everything streamlined, but releasing through wordpress.org is something we have planned for next year.”

Launching a new business during a pandemic is no easy feat but Ashton has grown Admin 2020’s user base to 3,642 active installations and is still looking to hire someone to assist in developing and maintaining the plugin.

“This has grown dramatically since the release of version 2 and will likely be around 5,000 or more in a week due to the sales from the Black Friday/Cyber Monday event,” he said.

Next up on the roadmap, Admin 2020 users can expect more customization options and deeper integration with WooCommerce. Ashton is currently working on the custom admin pages feature set that will allow users to create admin pages using the block editor and some of the more popular page builders.

“We are also working on expanding our WooCommerce integration with the idea of having a full suite of cards and data available on the overview page to help better visualize your business and sales,” Ashton said. “We are also going to be changing admin 2020’s name towards the end of the year but I won’t say what to just yet.”

by Sarah Gooding at November 30, 2020 11:36 PM under admin

WPTavern: Block Navigation Plugin Provides Missing Context-Based Outline for the WordPress Editor

Álvaro García wrote the first code for his Block Navigation plugin back in November 2018. It is one of those hidden gems that I wish I had known about two years ago as I began using the block editor. It has been available. I simply did not know about it until blindly stumbling upon it in a discussion in the WordPress Gutenberg Community group on Facebook.

The goal of the plugin is to provide an alternative to the editor’s current navigation. For the most part, it excels. WordPress has set the bar so low that any improvement seems like a godsend.

The plugin adds a new sidebar panel titled Block Navigation. That panel then lists each block with the added context needed to understand what block it is associated with in the content. For example, a Paragraph block in the navigation list will display its first few words. Other blocks do the same. Images and galleries in the list display their respective thumbnails. It handles nested blocks too.

All users must do is search for and click on the block they want to jump to in the content.

Navigating to specific paragraph in the document.

The plugin is packed with several other features. Users can shift blocks up and down from the navigation panel. They can also move blocks anywhere in the document with the click of a button or remove them altogether.

One of the more interesting features of the Block Navigation plugin is its ability to log a block’s data to the console. For developers, this could be a handy feature to quickly look up information for a block. While I doubt the average user would use it, there might be some potential applications for support requests, particularly with third-party block plugins.

Console log of a block’s data.

The downside of the plugin is that it does not provide a color scheme that simply matches the default WordPress color palette. However, it does provide a dozen color options for users to choose from. The Banana (light) scheme seemed the least out of place.

With the navigation being handled in the sidebar, it could interfere with some users’ workflows. For users who prefer to keep the block options sidebar available at all times, they will need to switch back and forth between sidebars. The plugin does provide a button for switching to each block’s setting via its submenu (vertical ellipsis icon) in the navigation list.

The thing that would make this plugin better would be putting it into the editor toolbar, replacing the current Outline dropdown.

It Should Be a Core WordPress Feature

The block editor’s Outline dropdown is lackluster at best. For short posts, it is unnecessary. For long posts, there is no context for any of the blocks in the list. The goal is to be able to jump to specific points in the document without scrolling. However, unless you know the exact location in the block you want to jump to, it can sometimes be impossible to use the feature.

Outline dropdown.

The Document Outline section of the Details dropdown provides some much-needed context. It displays the post’s headings. However, this outline does not allow users to click on an item and jump to its associated block.

Details dropdown.

Paal Joachim Romdahl proposed a fix for the Outline dropdown in October 2018. “What about just using the icon and then showing some of the text in the beginning of the paragraph?” he asked in a GitHub ticket that has seen no discussion for nearly a year.

Merged dropdowns.

There is currently an open pull request on GitHub to merge the Details and Outline dropdowns in the toolbar. The original proposal added a tabbed interface. However, an alternative patch without the tabs proposed in the same ticket would merge the best of both worlds by adding the more-detailed structural outline while linking to the blocks in the document.

The only question left now is whether I can still update my WordPress 5.7 wish list to include this feature.

by Justin Tadlock at November 30, 2020 11:03 PM under Plugins

November 27, 2020

BuddyPress: BuddyPress 6.4.0 Maintenance and Security Release

BuddyPress 6.4.0 is now available. This is a security and maintenance release. All BuddyPress installations are strongly encouraged to upgrade as soon as possible.

The 6.4.0 release addresses one security issue: non-capable users could add a style attributes to “span” and “p” elements in possible rich text fields of their profile page. The vulnerability has been fixed.

Version 6.4.0 also fixes 7 bugs, including compatibility updates to welcome PHP 8.0 release (Congratulations to all PHP 8.0 contributors!).

For complete details, visit the 6.4.0 changelog.

Update to BuddyPress 6.4.0 today in your WordPress Dashboard, or by downloading from the WordPress.org plugin repository.

Many thanks to 6.4.0 contributors 

John James Jacoby (johnjamesjacoby), Zeldatea, Dion Hulse, Ray (r-a-y), David Cavins (dcavins)Mathieu Viet (imath).

by Mathieu Viet at November 27, 2020 10:32 PM under security

WordPress Foundation: Open Source Workshops: November 2020 report

The WordPress Foundation has been organizing Introduction to Open Source workshops, as part of our continuing efforts to educate the public about WordPress and related open-source software (OSS). In 2019, as part of our goal of organizing workshops in parts of the world with less participation in open source, we held four successful workshops in India, Pakistan, Bhutan, and Thimphu. 

By March 2020, the COVID-19 pandemic had engulfed the world, forcing community organizers to cancel all in-person events. Unfazed by these challenges, our community organizers pivoted to online events by organizing four successful online charity hackathons in Japan, South Africa, India, and Nigeria, so far. The Introduction to Open Source workshops have also moved online. The workshop is now available online as part of Learn WordPress, which is a brand new initiative from WordPress contributor teams to help people learn how to use, build for, and contribute to WordPress. Community members across the world can now learn about Open-Source safely from the comfort of their homes and test their knowledge using the embedded quiz. The workshops are also followed by discussion groups, where participants can discuss their learnings in real-time and find answers to their questions.  

As of November 2020, the Introduction to Open-source workshop video has been viewed 757 times. Three online discussion group events with over 152 RSVPs were also held successfully. Sign-ups are open for two more discussion groups that are listed below:

You can watch the workshop video and participate in these discussion groups to learn about open-source software and find answers to your questions on open-source.

In addition to these scheduled discussion groups, community organizers can organize their own online discussion groups or hold online watch parties for the Introduction to Open-Source workshop

Given the global spread of the COVID-19 pandemic, WordPress Foundation events are likely to be held online in 2021. We will be announcing our plans for 2021 events later this year.

by Hari Shanker at November 27, 2020 09:05 AM under open source

November 25, 2020

WPTavern: Something To Be Thankful For

Over the past several weeks, I have received around four dozen emails, texts, PMs, and other messages related to Black Friday and Cyber Monday deals. Last year, we ran a roundup of deals happening throughout the WordPress ecosystem. However, we are not running such a post this year. It took a solid week to compile and piece together the previous article. It was a lot of work for what was a statistical dud. Readership tends to wane around holidays as people spend more time offline and with their families.

Plus, I firmly believe that our readers would rather see what we have to say about a particular product than simply scroll through a list of offers that are already widely shared on Twitter, Facebook, and elsewhere.

As George Olaru, the CEO of Pixelgrade, wrote in I discount, you discount, we both lose, software is not a perishable food item. It is not at risk of spoilage in a few days, and if it is, we have a real problem. On the flip side, some small businesses rely on this holiday to generate a large portion of their yearly revenue. However, we should all have some serious conversations about whether it is healthy for discounted software to permeate the WordPress plugin and theme markets every time a holiday rolls around. Whatever your stance, Olaru’s piece is worth reading and thinking on.

It is also tough to get into the holiday spirit this year. With Covid-19, the Black Friday markets have changed, which is probably not a bad thing on the whole — do we all really need to pile into stores to fight over the latest gadgets? The pandemic has also meant that families have had to make hard decisions about gatherings. The Tadlock family decided to cancel our pre-Thanksgiving/reunion we have in early November. We host it early because the doctors and nurses in the family often have to work on the holiday, and they agreed that a large gathering was not ideal. Fortunately, we live in an era where we can connect with each other in moments and from vast distances.

No, it did not feel right to do a sales roundup this year. Instead, I wanted to get back to the root of the Thanksgiving holiday, at least what I was taught the holiday was supposed to be about.

While tomorrow’s Thanksgiving holiday is an American tradition, I am certain our readers abroad can join in the celebration. It is a day of giving thanks for the blessings of the previous year. In times past, this has often meant being thankful for the harvest and having food on the table. Today, it still means the same to many. However, the holiday is all about counting our blessings, and that is something we should all take time to do.

This year, the thing I am most thankful for is the community, the people who all band together to create the most used CMS on the web, the people who evangelize the platform, and the people who continually take part in this grand experiment.

One of the things I attempt to do when writing is to share exciting things happening in our little corner of the world. Yes, I am often critical too. This is because I want to see people and companies strive to create better themes, plugins, and other products. For those times when I stretch to hyperbole or perhaps lean toward the negative, know that it comes from a place that is hoping for your success. It is hard to balance at times, but I am thankful that I can do this day in and day out.

After writing for the Tavern for over a year now, I feel like I am on a wondrous journey with so many of you. Whether it is a random message just to say hello or a ping about a new product, I look forward to seeing it all.

These human-to-human connections were not something I was expecting as I began this gig. Thank you to everyone who has made that possible.

Let’s all take a day and share some of the WordPress-related things we are thankful for this year — we can all save our block editor criticisms for tomorrow. It has been a rough year. We could all really use some positivity right now.

What are you thankful for?

by Justin Tadlock at November 25, 2020 07:51 PM under Opinion

WPTavern: Getting Your WordPress Plugins and Themes Ready for PHP 8

On Monday, WordPress core contributor Jonathan Desrosiers published a detailed post on the Make WordPress Core blog about the upcoming PHP 8 release and how it affects WordPress.

PHP 8 Is Coming

Scheduled for release on November 26, 2020, PHP 8 is the next major update to our favorite scripting language. While previous PHP releases have not had too much of an adverse effect on the WordPress ecosystem, this update has some breaking changes that could affect backward compatibility. It should also be noted that many features that were deprecated in PHP 7.x will now be removed in PHP 8.

The Status of WordPress Core

In his post, Desrosiers highlights the work that has been done to keep the core software up to date. “WordPress Core aims to be compatible with PHP 8.0 in the 5.6 release (currently scheduled for December 8, 2020),” he wrote.

However, this does not mean it is safe to upgrade to PHP 8 when WordPress 5.6 is released. WordPress is rarely run just on its own and usually relies on at least one theme and a collection of plugins to function as a blog or web site. As such, he points out, “The state of PHP 8 support within the broader ecosystem (plugins, themes, etc.) is impossible to know. For that reason, WordPress 5.6 should be considered ‘beta compatible’ with PHP 8.

What this means, essentially, is that until most major themes and plugins are PHP 8 compatible, WordPress cannot be considered fully compatible.

Understand How PHP 8 Could Affect Your Plugin or Theme

Companies like Yoast have been preparing for this for a little while now. In late October, Yoast CTO Omar Reiss, along with fellow contributors Juliette Reinders Folmer, maintainer of the WordPress Coding Standards Sniffs for PHPCS, and Yoast DevOps manager Herre Groen, compiled and published a comprehensive WordPress/PHP 8 compatibility report.

While I highly recommend you take the time to read through the entire report, it does outline the main reason that the PHP 8 upgrade could have such a drastic effect on large WordPress sites, especially the plugin and theme ecosystem.

“However, PHP 7.* versions have seen a far larger set of deprecations than previous versions of PHP. Where PHP 5.6 to PHP 7 was a relatively simple migration, going from 7.x to 8 could be very painful, especially for very old codebases, like WordPress and many of the plugins that are available for it. For well-typed codebases or codebases which have stayed up-to-date with the latest PHP versions, there isn’t a big problem.”

As a maintainer of a few plugins, some built on code dating back eight years, it is worrisome that this upgrade could cause sites to break.

PHPCompatibility repository.

How to Prepare Yourself

I asked Reiss and Folmer what plugin and theme developers can do to get ready, and they shared some pointers.

First and foremost, developers should inform themselves about the changes coming in PHP 8: read the Make post about PHP 8, read the Yoast PHP8 Compatibility report, read the “Migrating from PHP 7.4 to PHP 8.0” section of the PHP manual, and potentially dig deeper by reading the UPGRADING doc in the PHP 8 branch and the RFCs for PHP 8.

Some available tools can be used to help look for incompatibilities:

  • Run PHP lint on PHP 8 over their code, either via the  php -l command (making sure to iterate over all files) or by using PHP Parallel Lint.
  • Run PHPCompatibility over their code: it should be noted that nearly all PHP 8 related sniffs are in the as-of-yet-not-yet-released version 10.0.0 of PHPCompatibility, so people would need to use the develop branch or via Composer dev-develop for the time being, until version 10.0.0 is released.
  • Run the unit/integration tests for the plugin or theme on PHP 8 and fix anything which that comes up as an error. This will often mean that the test suite first needs to be made compatible with PHPUnit 9.3+. The PHPUnit Polyfills package and WP Test Utils package (both published under the Yoast GitHub organization) can help with this. It’s also important to note a considerable test coverage is needed to make this reliable.
  • Run the WordPress unit tests and WordPress e2e tests with your plugin activated, and fix any issues that arise.
  • Check whether the (strict) code coverage of said tests is high enough and if not, add more tests, making sure both happy and unhappy paths are covered.
  • If there are no tests, test everything manually, focusing especially on the “unhappy paths”, and expect to receive bug reports for the foreseeable future. At the same time, this is probably a good time to look into implementing unit/integration tests for your plugin or theme.

There Is Still Time, But It Is Running Out

As Desrosiers pointed out in the Make post, WordPress is only officially aiming to be PHP 8 ready by the time 5.6 is released in early December. Potentially, this means that many WordPress-focused hosting companies will only consider offering upgrades to their customers once WordPress core is compatible. So as plugin and theme developers, we have some time to test our products and get them ready, but that window is closing fast.

Fortunately for us, the knowledge and tools to get up to date are out there. We merely need to put them into action.

by Jonathan Bossenger at November 25, 2020 05:03 PM under php

November 24, 2020

WPTavern: WordPress 5.7 Wish List: Save Block Editor Settings Per User

WordPress 5.6 development is winding down as we begin to close out the beta testing round, inching toward the final release on December 8. That means it is time to think about what WordPress 5.7 will look like. This is one of my favorite times of the WordPress development cycle because I get to see what others want to be added to the core platform. I also get to share a feature request of my own.

Francesca Marano opened the discussion on the Make Core blog. She asks that people link to a specific ticket, which can be from WordPress Trac or the Gutenberg repository.

One consideration for everyone’s wish list is that 2021 will potentially see four major WordPress releases rather than the typical three. WordPress 5.7 is tentatively scheduled to land on March 9, 2021. The team has scheduled future releases in three-month intervals. While the dates are not written in stone, it could mean each release’s feature set might need to be scaled back to some small degree.

Most features that land in WordPress 5.7 will be items that are already under development. Enhancements like block-based widgets and nav menus that were punted from the 5.6 release should land early and be ready for a full three months of testing. The development team will also focus heavily on pushing an early/beta version of the site editor into core WordPress.

There is still room for other things to land, and now is the time for everyone to make their case for their pet feature.

Unlike past wish-list discussions, I am going to take a step back and control myself. Instead of asking for one of those big-ticket items that I know is unlikely to happen — hello, completed post type API and homepage post type selection —, I will simply ask for something more practical.

In WordPress 5.7, I want the block inspector tabs and some block option defaults to remain the same each time I write a new post.

One of my biggest pet-peeves is with the image block in particular. Each time I add an image, I first close the Styles tab in the sidebar. I do not use it often, so it is not important enough to always be open. Then, I must switch the Image Size setting to Full Size from its default Large. I typically format my images for display before uploading and simply want to use the image at the size I uploaded. These are small things, but they break my workflow. As a daily writer, it has become a nuisance over time.

Configuring image block settings.

These should be per-user settings. Each user’s workflow is different, so WordPress likely needs to handle this as user metadata or a similar method.

I was unable to track down an open ticket for saving the tab state. There are over 2,600 currently-open issues. Maybe I did not nail down the right search terminology. Or, it may be a non-issue for other users.

However, there is a two-year-old ticket for remembering the last image size used. I was happy to find like-minded peers who share my frustration in this case. There is also a more recent ticket about storing the default image size on a per-user basis. The feedback in the tickets shows a clear and present need for WordPress to fix this problem.

A representative of Feast Design Co. noted in the first ticket, “Every time somebody inserts an image they have to change the image size. This seems small but at 10 seconds per image x 5 images per post x 2 posts per week x 52 weeks per year, this is 86 minutes per year.” I believe I can manage it in a little less than 10 seconds per image, but it stills knocks me out of my flow each time. It is a seemingly trivial issue, but the time wastage adds up for those who add many images to posts throughout the year.

What is on your wish list for WordPress 5.7?

by Justin Tadlock at November 24, 2020 09:43 PM under wishlist

November 23, 2020

WPTavern: Genesis Block Theme Beta, StudioPress Pursuing a Block-First Future

On November 11, StudioPress announced an open beta for its Genesis Block Theme. This is a pivotal moment, or at least one moment in a series of significant moments, for adoption of the block editor. Feel free to call me on this in a year or two if it does not pan out.

The original Genesis theme is the foundational tool that 1,000s of developers use to build many 1,000s more websites across the web. Over the past decade, StudioPress has remained one of the top-tier commercial WordPress theme companies, and it has done so on the back of its Genesis product. It has also remained an important part of the company’s offering since WP Engine acquired it in 2018.

While WP Engine and StudioPress have bet big on the block editor with products like Genesis Blocks, the Genesis Block Theme will be a game-changer when it launches as a finished product, likely sometime next year.

This is not necessarily because StudioPress will offer a better product than what many others are creating. It is about one of the largest theme development companies shifting toward a block-first approach. Others will fall in line. Or be left behind.

WP Engine and StudioPress have done this slowly and strategically, thoughtfully transitioning their user base into the block world. With WP Engine’s acquisition of Atomic Blocks (now Genesis Blocks) and bringing on the Block Lab team earlier this year, the company is setting itself up to continue pushing what developers and users can do with WordPress’s block system. The Genesis Block Theme is the next step in what I am assuming is a long list of product ideas the company is pursuing.

Using the Genesis Blocks plugin with the Genesis Block Theme beta.

Typical Genesis-based child themes, at least those directly sold by the StudioPress team, have always catered to those who prefer a more minimalist-get-out-of-the-user’s-way approach to design. Many of them should make an easy transition to the block editor. Add a few style adjustments here, make a few tweaks there, and, you have a theme that is fully capable of handling the block editor. It is a testament to the company’s design chops when it does not really matter what WordPress is doing under the hood. The theme designs hold up regardless.

Times are changing, however. The StudioPress team is looking at WordPress 5.7, which is expected to land in the spring of 2021, and getting ready to handle the launch of the WordPress site editor.

David Vogelpohl, the VP of Growth for WP Engine, left specific instructions on how to test the Genesis Block Theme beta in the announcement. One of the key items in that list is to skip modifying the theme directly or using the customizer settings. The goal is to identify pain points when approaching site design via blocks. It is good to start shifting how the Genesis user base approaches building sites in general.

He also asks testers to install the Genesis Blocks plugin. It is a library of various blocks, sections, and layouts for building block-based content. This will help both developers and users become more accustomed to the shift in building with the company’s key product.

Vogelpohl teased a “Genesis X” project in May that would focus on pushing the boundaries of the block editor and, eventually, full-site editing. Deciding against launching a separate product, the team has been pushing features from this project into Genesis Blocks. Three weeks ago, StudioPress launched its new Collections feature, which was born from Genesis X.

“You can think of Collections like a theme’s block-based demo content, but available on-demand as you build out content vs. only during one-click-theme-setup features within the framework today,” said Vogelpohl.

The Slate Collection from the Genesis Blocks plugin.

Collections are essentially categorized page sections or entire layouts that share a similar design aesthetic. Genesis Blocks currently has one Collection titled Slate available for free. In practice, a user can already build out nearly an entire site with just this single Collection. This seems to be the direction that Genesis and its line of products are heading. Everything is pretty much plug-and-play. Select a few layouts for various pages. Click a few buttons. Customize the content. And, voilà — a turnkey system for building websites.

StudioPress must wait for the site editor to land in WordPress 5.7 before it can handle everything. Site headers, footers, and sidebars still require customization outside of the block editor.

Right now, the Genesis Block Theme beta is nothing out of the ordinary. It is essentially a base theme that allows the accompanying Genesis Blocks plugin to shine. It will also allow the development team to test ideas based on user feedback in the coming weeks and months. Vogelpohl said they will eventually tackle full-site editing based on what they learn from the beta run’s feedback.

by Justin Tadlock at November 23, 2020 10:11 PM under wp engine

November 20, 2020

BuddyPress: BuddyPress 7.0.0 Release Candidate

Hi BuddyPress community members!

The first release candidate for BuddyPress 7.0.0 is ready for a last round of testing!

This is an important milestone as we progress toward the BuddyPress 7.0.0 final release date. “Release Candidate” means that we think the new version is ready for release, but with more than 200,000 active installs, hundreds of BuddyPress plugins, thousands of WordPress themes, and many possible specific WordPress configurations it’s possible we missed one or more details.

BuddyPress 7.0.0 is slated for release on December 9th, 2020. Do you want to help us get there? Here’s how you can:

  1. This release candidate also marks the string freeze point of the 7.0.0 release schedule, so if you you speak a language other than English, please help us translate BuddyPress into many languages!
  2. You are a BuddyPress Plugin and/or Theme developer? You should test your code against BuddyPress 7.0.0. If you find compatibility problems, please report a ticket on our Trac environment.
  3. You are using BuddyPress and can easily set up a staging environment? Please use our Beta Tester plugin or directly install the Release Candidate on your staging site to make sure everything works as expected for you. If not: tell us what’s wrong on Slack or reply to this specific support topic with a detailed explanation of your trouble.
  4. You are a WordPress news writer? We’d love you to share this post with your readers: the more testers, the better!

It’s always best to anticipate than having a bad surprise after updating the plugin from your WordPress Dashboard: get involved!

What to expect from BuddyPress 7.0.0

First, note that BP 7.0.0 will require at least version 4.9 of WordPress. Then, read an overview of its top features in the post we published to announce the first beta of 7.0.0. If you would like more detail, you can read our 7.0.0 developer notes.

Thanks in advance for your contributions!

by Mathieu Viet at November 20, 2020 10:15 PM under release candidate

WPTavern: Build Editor Blocks for Clients With the Genesis Custom Blocks Plugin

In early September, WP Engine announced the launch of Genesis Custom Blocks, a block-creation plugin made possible by its StudioPress team. The concept should feel familiar to developers who have made use of Advanced Custom Fields and similar plugins. However, the focus of this new plugin is entirely on blocks.

The plugin is more of a framework than a plug-and-play extension for WordPress. It requires some PHP knowledge to handle the front-end output. The goal is to make it easy for developers to create custom blocks without JavaScript knowledge. It allows them to render blocks on the server-side via custom templates.

Genesis Custom Blocks handles all the dirty work on the backend while leaving the basic PHP, HTML, and CSS of the front end completely up to developers.

The plugin seemed to slip through the cracks of the plugin directory’s guideline against frameworks — the Plugin Review Team started disallowing new framework-type plugins in 2016. Team rep Mika Epstein confirmed that the plugin should not have been approved. She also said that she would talk to the developers, explain why it’s not good, and see about finding a path forward.

Setting guideline issues aside, the plugin is a nice addition to the toolbox of any developer who needs to quickly knock out custom blocks for clients.

How the Plugin Works

Genesis Custom Blocks is currently a lightweight field manager for custom blocks. It provides an admin interface for creating, editing, and managing those blocks. Developers use this interface to essentially create block options in which a user can configure via the editor.

The free version of the plugin includes 13 standard form fields, such as text, image, URL, color, and more. The commercial version includes an additional six field types and allows users to import or export their custom blocks.

Editing the test block included with the plugin.

For the block to output anything on the front end, the developer must create custom templates and use the Genesis Custom Blocks API. This template will render the output in the editor too, at least until the user clicks on the block, which takes them into editing mode.

Inserting and editing a custom block in the editor.

Without anything other than a cursory reading of the docs, I was able to build a custom block and its associating template in minutes. What makes the plugin stand out is the simplicity of its system. It does not try to do too much. It provides enough basic fields for most developers to create the custom blocks they need for clients. I am certain that many of them will get a ton of mileage out of it.

It also does the extra things that developers should expect from a StudioPress-caliber product like allowing developers to create custom block categories, pick an icon, and set up keywords for each block.

One missing element is the ability to set custom blocks to full and wide-width. Developers may need to write custom CSS for both the editor and front end to handle such use cases. They can create custom inspector (block options sidebar) controls for width or alignment too. However, it would be a nice bonus if the plugin handled the standard WordPress alignments.

The Big Problem

The plugin commits the greatest sin of WordPress development. It fails to prefix or namespace its custom functions. It is a mistake that is expected of rookie developers. However, for a seasoned company such as StudioPress to create block_field(), block_value(), and similarly-named functions in the global namespace is almost unforgivable.

The problem this creates, particularly given the size of the Genesis development community, is that it is basically stealing potential function names from WordPress. If the core platform ever decides to add these functions, fatal errors will ensue on 1,000s of sites.

If the functions were limited in scope to the plugin itself, it would be an easy fix. However, these functions are meant for direct use by developers who are building with the plugin.

Given the plugin’s short time out in the wild, I hope the development team reconsiders their naming scheme and transitions it to something that does not run the risk of a future fatal error.

by Justin Tadlock at November 20, 2020 07:46 PM under genesis

WPTavern: Gutenberg 9.4 Introduces Button Width Selector and Typography Controls for List Block

Gutenberg 9.4.0 was released this week with many small improvements to existing features, while work on full site editing continues. This release will not be included in the upcoming WordPress 5.6 release but those who are using the Gutenberg plugin will have access to the improvements right away.

The button block now has a width selector, which allows the user to set the button to 25%, 50%, 75%, or 100% of the parent container. By default, a button’s width is determined by the size of its content. If you like bigger buttons, this update will give you more flexibility. Button margins are also included in the width calculations, so users can create multiple buttons in a row, or a grid of buttons, and have them properly fit together and aligned.

Making a button is easier than it has ever been before. Gone are the days of using shortcodes or hunting for the correct CSS class to apply in order to match the theme. Button creation used to be so needlessly difficult with a fragmented, unfriendly workflow, but the block editor continues to chip away at the complexity with each new release.

Version 9.4 also introduces typography controls for the list block. Gutenberg contributors have been discussing adding color and text size customizations to all text-based blocks since 2018, and the list block is finally getting some font size controls.

Social icons can also be resized now. Users can select from several preset sizes, including small, normal, large, and huge.

The 9.4 update adds support for <kbd> tags with a new button in the overflow rich text menu. These tags are useful for displaying content in the browser’s default monospace font, which helps when writing documentation or articles with inline code.

This release lays the groundwork for handling block variation transformations. Block variations are essentially the same block with registered variations that appear as a separate block in the block inserter. For example, the navigation block has horizontal and vertical variations. The editor now introduces a transform option for the scope field in block variations, so developers can control how to handle these transformations.

Enhancements in this release add polish to many aspects of the UI, including the inserter search, custom select menu styles, the link interface, Search block styling, shortcode block styling, and reduces the UI on hover (an optional setting in preferences).

One handy new feature for writing is that users can now add a header by typing /h1 to /h6 followed by enter/return. While I like the idea of this, it seems unintuitive to have to use enter/return to change the block to a header. This feature would be easier to remember if it mimicked the existing feature that allows users to add a header by typing ### followed by a space. Changing the trigger action to a space instead of a return would make more sense here.

Version 9.4 also includes a great deal of progress behind the scenes on experiments, including the full site editing framework, FSE blocks, the site editor, and global styles. Check out the changelog for a full list of bug fixes and enhancements.

by Sarah Gooding at November 20, 2020 07:00 AM under gutenberg

November 19, 2020

WPTavern: WordPress To Combine Its Long-Neglected Theme Previewer With Starter Content

Six weeks ago, WordPress 5.6 release lead Helen Hou-Sandí breathed new life into two almost-forgotten features around the WordPress website and platform. The idea was to take the starter content feature, which themes can optionally add for new installs, and apply it to the WordPress.org theme preview system. It was not a new idea. However, it finally had some teeth because a core lead was making it a priority.

“I’m revisiting this in the context of 5.6 and Twenty Twenty-One — could we possibly consider a combination of starter content (the core feature) and the existing theme unit test data (with room for more later)?” wrote Hou-Sandí in a ticket that seemed to be going nowhere after seven years. “I don’t think we’d want to have just starter content, as that should ideally be a much more limited amount of content pieces, but unifying somewhat would help with the overall goal of aligning the demo with what users can actually accomplish on their sites.”

Yesterday, Hou-Sandí formally announced the launch of the project. Currently, the Twenty Twenty-One, Twenty Twenty, and Twenty Seventeen demos display their respective starter content.

Block-based starter content in the Twenty Twenty-One theme preview.

The initial goal was to turn the feature on selectively, testing it with a few default themes. This would give the meta team time to iron out any bugs. It would also give the Themes Team time to decide on any additional guidelines considerations before opening it to everyone.

The Themes Team reps do not seem to think there will be any need for new guidelines, so there should not be much to do on their end.

“I’m up for having a discussion about it but I do think that, in general, guidelines already cover it (we might need to reword the guideline about excluding advertising for clarity), but theme devs aren’t gonna want to give a bad impression in their public-facing previews,” said Themes Team representative William Patton. “We probably want to just check the guidelines to make sure they cover things here, but from my perspective, I think guidelines already cover things quite well.”

This is the sort of thing that could get theme authors excited again. Themers can sometimes feel like they are second-class citizens. More often than not, plugin authors get the shiny, new toys long before — if they ever — roll out to the theme directory. It is always an exciting time when themes are shown a little love.

Hou-Sandí pointed out that the theme previewer changes would not be forever limited to a handful of core themes. This is merely the first step.

The big question: why now?

There is no doubt that the theme previewer has been a problem area for years. Users have complained about it. Theme authors and reviewers have relentlessly discussed it and called for a change. Some authors have even attempted various, hacky workarounds, sometimes finding themselves on the shortlist for banishment. At the end of the day, most people just want to see themes in all their glory. They are the face of WordPress. As Hou-Sandí wrote in the announcement, “The theme previewer site in today’s context does a serious disservice to themes.”

To answer the why now question, the block system has a lot to do with it. Internally, the system opens up a world of possibilities that are much easier to implement. Whether it is starter content or custom front page templates, blocks will be a huge part of the equation going forward.

“I also believe that between blocks, block patterns, and eventually full site editing, it is more important than ever to the broad success of the WordPress project for themes to showcase their ideal states and make it easier for users to achieve the same thing on their sites,” wrote Hou-Sandí. “Starter content, introduced in 4.7, was a step in this direction, but has languished for quite some time.”

It is also part of an ongoing rethinking of what should happen with starter content. On October 6, she opened a discussion for feedback on the feature’s future. The post received a few useful responses. However, it could still use feedback from a wider range of people involved with the WordPress project, particularly theme authors.

I also explored some possibilities in response to that post in The Future of Starter Content: WordPress Themes Need a Modern Onboarding and Importing Tool.

The biggest concern at this point should be whether theme authors consider this too little too late. There is a little excitement brewing from a few short conversations I have seen in theming circles. However, this is a time for theme authors to jump on board, provide feedback, and pitch in. This is the first step in gaining the sort of control over theme previews that many have long sought.

by Justin Tadlock at November 19, 2020 09:40 PM under Themes

WPTavern: Local 5.9.2 Adds Image Optimization via New Free Add-On

Local 5.9.2 was released this month with a new image optimization feature. The Pro version of Flywheel’s local WordPress development product got a revamp four months ago, bringing in a new collection of pre‑launch tools. While image optimization falls into that category, the company decided to make this new feature available to both free and pro tiers via an optional add-on.

Users can install the new add-on directly in the app and then navigate to Tools › Image Optimizer. After enabling the add-on and relaunching the app, Local will be able to scan the installation for image files and compress them offline, without using cloud-based services. The add-on allows users to navigate away from an active optimization session and carry on with development while it works in the background.

Before proceeding, users can also navigate to the Image Optimizer settings and elect to strip the metadata (i.e. focal length, date, time, and location) to further reduce the file size and, as a byproduct, remove potentially identifying data. The default optimization simply reduces file size and does not strip metadata.

After optimization is complete, an overview of the total reductions and disk space saved will be displayed.

The add-on currently uses jpeg-recompress to optimize images, a utility from the open source JPEG Archive project. Here is how it works:

Compress JPEGs by re-encoding to the smallest JPEG quality while keeping perceived visual quality the same and by making sure huffman tables are optimized. This is a lossy operation, but the images are visually identical and it usually saves 30-70% of the size for JPEGs coming from a digital camera, particularly DSLRs. 

Local’s development team plans to expand this in the future to add more options like lossless compression. Version 5.9.2 also fixes several bugs with the UI and adds improvements to make it more consistent.

by Sarah Gooding at November 19, 2020 03:19 AM under local

November 18, 2020

WPTavern: Should WordPress Notify Users of Plugin Ownership Changes?

Potential idea for showing plugin ownership change.

That is the question posed by Ian Atkins in a recent ticket for WordPress.

“I’ve experienced a few plugins change ownership, and it’s really not clear as a user, developer, and maintainer of sites when that has happened,” he wrote in the ticket. “Whilst having a plugin continue to be developed is admirable — I do think it would be wise to inform users of that change.”

For full disclosure, the ownership change that prompted Atkins to create the ticket was from the Members plugin. I am the former owner of the plugin and sold it to the MemberPress team in 2019 (I was a full-time plugin and theme developer before joining WP Tavern). Having been both a plugin author and user in this scenario before helps mold my viewpoint.

I agree with the idea. WordPress should have some mechanism for notifying users of changes of ownership. The more transparency that exists in the ecosystem, the healthier it is for all.

As a plugin author who was letting go of a project that I had worked nearly a decade on, it was tough to say goodbye. I had built friendships and trusted users who walked beside me on my journey. I posted on the company blog, Twitter, Facebook, and the WordPress support forums. I replied to emails, PMs, and more. I wanted to be as transparent with my plugin users as possible. When the plugin was out of my hands, there was no way for me to reach out to the 1,000s of users who did not follow me on social media or the blog. The new owner was as transparent. Even today, a year later, some users are just now realizing someone else is running the show.

In hindsight, perhaps there was more we could have done. Maybe there was more WordPress could have also done and can do in the future. There are valid concerns from users.

Atkins lists three primary reasons for his proposal:

  • There might be privacy policy changes that have impacts on what data is shared and how it is shared. Legally, depending on location, this may have to be communicated to end-users (under GDPR, etc.).
  • The plugin may change direction or add features that were not originally included or required under the stewardship of the prior owner.
  • The plugin may have changed hands to a developer or development house that a user knows isn’t as reliable as the previous owner.

He also asked whether the plugin team reviewed ownership changes. Changing owners is a simple task, and these changes are tracked internally.

Mika Epstein, a Plugin Review Team representative, said that the team could make such changes public. The biggest flaw with that system is that it is not always possible to know when a plugin’s owner changes. Sometimes, an entire company is sold, which would include ownership of the WordPress.org account. She also cited situations where serviceware plugins change hands in unobvious ways.

“I want to be clear, I’m not against this!” she said in a follow-up response. “I’m for this! I just want to be clear that we’re going to get MAYBE half of the changes.”

Half would be better than none. An automated system may work to create notices in some situations. However, an addition to the plugin review guidelines may also be part of the solution.

Plugin authors could also take it upon themselves to implement an ownership-change notification. This may be one of those use cases for the much-maligned admin notices that is worth exploring.

At this point, we are just asking the question of whether WordPress should create a system in which users are notified of plugin ownership changes. What would you like to see in terms of solutions?

I want to see continued progress on the transparency front. Atkins’ first list item is the most important. If there are privacy policy changes or a plugin deals with personal data in any way, users need to know when the plugin has a new owner. They should be able to make a decision about their continued use of the plugin with all the facts laid bare.

by Justin Tadlock at November 18, 2020 05:09 PM under Plugins

HeroPress: Final Day to Apply to Speak at WordFest Live 2021

Friends across the globe, today is your last chance to get in your talk for WordFest Live. You only have until midnight tonight, UTC, so don’t delay!

If you’re interested but not sure which talk to choose, learn more here: https://www.wordfest.live/2020/11/speaking-at-wordfest-live-2021/

Share your knowledge across this 24 hour global celebration of WordPress. Support the team at Big Orange Heart by being involved. Let’s continue to go farther together!

The post Final Day to Apply to Speak at WordFest Live 2021 appeared first on HeroPress.

November 18, 2020 04:10 PM under WordFest Live

WPTavern: WordPress.com Gives Conservative Treehouse the Boot, Citing TOS Violations

The Conservative Treehouse, a political publication hosted on WordPress.com for the past 10 years, is moving to a new host after receiving a notice from Automattic regarding violations of its Terms of Service. The site’s owner, previously identified as Florida resident Mark Bradman, claims to have a 500,000 – 1,000,000 unique readers per day. He has been ordered to find a new hosting provider and migrate the site away from WordPress.com by December 2, 2020.

Bradman followed up with Automattic to inquire about the specific infractions that put the site in violation of Automattic Ads Terms of Service. A representative from WordPress.com referred him to Section 5’s guidelines on “Prohibited Content,” and the prohibition against calls to violence in WordPress.com’s User Guidelines.

The Conservative Treehouse was characterized by The Daily Beast as “Patient Zero for a number of hoaxes that have percolated through [the] right-wing media ecosystem” after President Trump tweeted a conspiracy theory that originated on the site. Trump referenced an incident in Buffalo where police officers shoved an elderly protestor during the anti-police brutality protests that happened in June. The notion that the protester was an “ANTIFA provacateur” was originally seeded by an article on The Conservative Treehouse.

A cursory review of the past several months of posts on the anonymous blog shows it is home to a steady stream of misinformation. NewsGuard, an organization that assigns trust ratings based on transparent criteria, recommends readers proceed with caution because the website “severely violates basic journalistic standards.” The Conservative Treehouse gets a rating of 30/100 due to publishing false information and unsubstantiated conspiracy theories on numerous topics:

Because The Conservative Treehouse has published false and misleading claims, including about the COVID-19 pandemic, NewsGuard has determined that the website repeatedly publishes false content and does not gather and present information responsibly.

Bradman said he received the notification about the website being removed after publishing his post on what he calls “the COVID-19 agenda.” The conclusion of the article includes an image of a knife with the word “resist” written on it, followed by the words “whatever it takes.” The site’s comments are home to a “Rag Tag Bunch of Conservative Misfits,” as the tagline suggests, and there are more than 1,800 comments on the post announcing its upcoming move to a new host.

Despite the publication’s poor reputation, the site ranks #3,294 in the US, according to Alexa, with a largely American audience. Its owner claims to have more than 200,000 subscribers.

“We will take this challenge head-on and we will use this attack against our freedom as fuel to launch CTH 2.0, a new version of The Conservative Treehouse,” Bradman said.

by Sarah Gooding at November 18, 2020 05:24 AM under wordpress.com

November 17, 2020

WordPress.org blog: WordPress 5.6 Release Candidate

The first release candidate for WordPress 5.6 is now available!

This is an important milestone in the community’s progress toward the final release of WordPress 5.6.

“Release Candidate” means that the new version is ready for release, but with millions of users and thousands of plugins and themes, it’s possible something was missed. WordPress 5.6 is slated for release on December 8, 2020, but we need your help to get there—if you haven’t tried 5.6 yet, now is the time!

You can test the WordPress 5.6 release candidate in two ways:

Thank you to all of the contributors who tested the Beta releases and gave feedback. Testing for bugs is a critical part of polishing every release and a great way to contribute to WordPress.

What’s in WordPress 5.6?

The final release of 2020 continues the annual tradition of a new default theme that is custom built to showcase the new features and functionality of the software. Continued progress on the block editor is especially clear in this release, which brings more blocks to more places, and fewer clicks to implement your layouts.

WordPress 5.6 also has lots of refinements to polish the developer experience. To learn more, subscribe to the Make WordPress Core blog and pay special attention to the developer notes tag for updates on those and other changes that could affect your products.

Plugin and Theme Developers

Please test your plugins and themes against WordPress 5.6 and update the Tested up to version in the readme file to 5.6. If you find compatibility problems, please be sure to post to the support forums, so those can be figured out before the final release.

The WordPress 5.6 Field Guide, due very shortly, will give you a more detailed dive into the major changes.

How to Help

Do you speak a language other than English? Help us translate WordPress into more than 100 languages! This release also marks the hard string freeze point of the 5.6 release schedule.

If you think you’ve found a bug, you can post to the Alpha/Beta area in the support forums. We’d love to hear from you! If you’re comfortable writing a reproducible bug report, file one on WordPress Trac, where you can also find a list of known bugs.

by Josepha at November 17, 2020 10:43 PM under Releases

WPTavern: Proposal to Create an Expanded View or Overlay for the Block Patterns Inserter

The “version 1.0” launch of block patterns in WordPress 5.5 was overall successful. However, it was easy to overlook the problems while waiting for this feature to land after months of anticipation. Now that we have had a couple of months of seeing the block pattern system baked into core WordPress, it is time to address issues that are becoming more evident.

As much as I love block patterns as a feature, I cannot say the same for the user interface and overall experience. The pattern category dropdown added in Gutenberg 9.1 was a marked improvement over the endless list of patterns. However, it did not go far enough in presenting them in a user-friendly way.

WordPress has long had a habit of sticking too much into a tiny panel — many theme authors never felt like the customizer panel offered enough space, for example. The same seems to be the case for the block editor’s inserter panel. It is good enough for allowing end-users to pick and choose blocks. However, patterns are much larger than the smaller block icons. When users start scrolling through dozens of patterns at a time in the coming months and years, it will become a usability nightmare.

Paal Joachim Romdahl is proposing an alternative. His idea is to add an “expander” icon/button that would allow users to view more patterns at once via an overlay. At least this would be the case for larger screen sizes, such as desktop users.

“Viewing a lot of patterns in the small inserter panel does not work too well,” he wrote in the GitHub ticket. “It gets tiring needing to scroll one pattern at a time. Having a larger view will help the user to compare multiple patterns at once.”

Preview of how the current pattern overlay proposal would work.Current pattern overlay proposal.

Romdahl has also created a Figma prototype for people to test what the system would look like in a live demo. The UI is not polished, but it looks like a promising start.

He created the proposal after reading the Tavern’s recent coverage of WordPress.com’s launch of over 100 block patterns. Some of the pattern categories are easy to work through and find the right layout. Others, such as the Text and Call to Action categories, may have 20 or more patterns to scroll through.

Inserting a block pattern on WordPress.com.

If WordPress creates an official block pattern directory, which is currently under consideration, adding new patterns could be as simple as clicking a button. It would be an easy way to rack up dozens of patterns in moments, particularly if a user is trying out various layouts and does not uninstall unused patterns afterward.

Not many users are exposed to the hundreds of patterns WordPress.com’s users have access to. We should move forward with this proposal before they are.

An overlay for inserting patterns and templates is not a new concept. It is common in the WordPress development community. Plugin and theme developers solved this problem ages ago.

The Redux plugin handles hundreds of templates with an overlay:

Viewing templates from the Redux library.

The Layout block from the Genesis Blocks plugin is essentially just a custom pattern inserter with a much nicer UI than WordPress:

Overlay created by the Layout block from Genesis Blocks.

Mikael Korpela added similar thoughts to a ticket related to the next steps for the inserter. He proposed a full-screen experience for browsing patterns.

“The patterns sidebar is great if you just want to keep it open while you modify your page, but it’s harder for browsing because of limited space, especially when you’ve registered a lot of patterns,” he wrote in the ticket.

He shared an image of how Sections on Squarespace are handled:

Selecting a Section on the Squarespace website.

An overlay might also help drive the pattern directory proposal. It would be easy enough at that point to create a new tab in the overlay interface, hook into the WordPress.org API, and allow users to browse through installable patterns — no need to leave the comfort of the block editor.

Another common feature that many of these types of systems share is a way to save patterns as favorites. This makes them easy to locate in the future. Paul Lacey makes the same argument in episode #136 of the WP Builds Weekly WordPress News podcast. He wants his clients to have easy access to their most-used block patterns. This would be a nice bonus to help clean up the block patterns user experience.

by Justin Tadlock at November 17, 2020 09:02 PM under gutenberg

November 16, 2020

WPTavern: WPGraphQL 1.0 Released, Now Available in WordPress.org Plugins Directory

Version 1.0 of the WPGraphQL plugin is now available in the official plugins directory on WordPress.org. This is the first stable version recommended for use in production, landing nearly four years from when the project started in November 2016.

In an effort to keep WPGraphQL in line with WordPress’ commitment to preserving backwards compatibility, Jason Bahl, the creator and maintainer, held it off from a 1.0 release until he could minimize the potential for breaking changes.

“WPGraphQL turning 1.0 isn’t a statement that there will never be breaking changes, instead it’s a statement of stability and long term support,” Bahl said.

WPGraphQL has already had quite a bit of real world usage ahead of its first stable release. The plugin is in use on high profile sites like QZ.com, DenverPost.com, and ApolloGraphQL.com. Installs of WPGraphQL grew from 50,000 in June 2020, to 71,573 installs in November 2020, according to Packagist.org. Having the plugin available on WordPress.org will make it easier for users to install it and keep it updated.

“One of the big reasons I didn’t want WPGraphQL on the .org repo was that the nature of it being an API could expose sites to potential security vulnerabilities,” Bahl said. “As we worked on stabilizing the plugin I wanted it to be a pretty conscious decision to add a GraphQL API to your WordPress site. Leaving the plugin on Github meant that the audience finding it and installing it was a more technical audience and could do at least some of the technical vetting to make sure it made sense for their project.”

In September, Gatsby, the company that sponsors Bahl’s time on WPGraphQL’s development and maintenance, hired Pen Test Partners to perform an audit of the plugin and has resolved all the issues they discovered. The full report and resolutions will be published to the project’s website soon.

“Now that the plugin is stable and secure, we’re happy to have it on the WordPress.org repo where users will be able to find it by searching for plugins in the repo and take advantage of some new features of WordPress such as auto-updates,” Bahl said.

The 1.0 release does not contain any technical changes – it simply bumps the version number. The project has been publishing pre-1.0 releases leading up to this, logging 33 releases in the past 12 months. Bahl said the biggest difference between 1.0 and pre-1.0 is the new WPGraphQL.com website. Previously, the project’s documentation was hosted on a subdomain but it is now been rolled into the main site.

“Previously, WPGraphQL.com was a traditional WordPress site with the front-end using the classic WordPress theme layer,” Bahl said. “The new site is built with WordPress as the CMS, Gutenberg as the content editor, Gatsby as the front-end, and WPGraphQL as the layer that allows Gatsby and WordPress to communicate with each other. We’re dogfooding our own technology.”

The project has also added close to 300 pages of new documentation. It includes a Developer Reference section with documentation on Actions, Filters, and Functions for customizing and extending WPGraphQL, along with a new Recipes section with code snippets for implementing solutions faster.

by Sarah Gooding at November 16, 2020 11:40 PM under WPGraphQL

WPTavern: The Plus Addons for Gutenberg Plugin to Launch Soon

WordPress development company POSIMYTH is getting set to announce its venture into block development in the coming days. The new plugin, The Plus Addons for Gutenberg, is a collection of blocks, templates, and additional features for building sites with the block editor. The plugin is currently awaiting review for inclusion in the WordPress.org plugin directory. I was able to snag a test version and have been using it for around a week.

The POSIMYTH team began working as an outsourcing agency in 2013. Since then, it has worked on over 1,000 projects. The company eventually began building WordPress themes and plugins for the Envato Marketplace. It has continued to grow and currently serves more than 50,000 customers.

“Being an outsourcing company in the past, we have always felt the need for one-stop solutions for agencies and freelancers,” said Sagar Patel, the founder and director at POSIMYTH Innovations. “We have built many Gutenberg field components from scratch as well as in-depth options in blocks, which will not just be for simple tasks, it will be for complex layouts and options as well.”

One of the company’s most-used products is its The Plus Addons for Elementor plugin. The free version currently has over 9,000 active installations. Patel describes it as a “complete package” for building Elementor-based websites.

“Our Gutenberg version will be kind of a recreation of our Elementor version, but on top of that, we are adding more options and features based on our feedback from Elementor users,” he said. “Some blocks are completely revamped and made with a unique concept, but some are just a recreation of the Elementor version. For example, our Popup Builder, Countdown, Global Features, and some others are completely made from scratch with a new structure.”

The company recently surveyed over 1,000 its users. One of the points they noted is that many of those users wanted to use WordPress’s built-in block editor. However, they were unable to find reliable options for building complex websites. The results of this survey are one of the primary reasons the company is building this plugin.

The Plugin

TP Row block for building columns.

The free version of The Plus Addons for Gutenberg will launch with 29 blocks, 16 of which are free and 13 freemium ones with commercial upgrades. The commercial/pro version of the plugin will add an extra 11 blocks along with several shapes, tooltips, effects, and other options. Pricing is expected to start at $39 per year for its lowest tier.

The plugin also has global color and typography options. These should not be confused with WordPress’s upcoming Global Styles system. The two features work similarly. However, the plugin’s system only works with its blocks instead of the entire website.

The terminology could pose some confusion for users. There will also be some crossover between the two systems, both handling the same needs. Patel said he is aware of this and will always work to make sure the plugin respects WordPress’s built-in Global Styles system. “We will always keep that in sync with our global options,” he said. “It’s still in the initial stage. We will keep on updating based on feedback from users and as per the updates of the Gutenberg team.”

Many of the block options are similar to what Editor Plus is doing for the core WordPress blocks. However, the options are for the plugin’s custom blocks only. The UI feels polished enough that you feel like the design team has been here before and knows what it is doing. Some plugins do not get to that point until version 2 or 3. I was able to navigate the block options with ease.

However, some blocks were out of place. For example, the Style Lists block could have simply been custom options tacked onto the WordPress List block. Adding list items in the block sidebar is not as natural as in the editor’s content area. The end-goal is to simply make a standard list. Everything else is simply eye-candy. Ideally, the plugin would relegate those options to the core block.

The same could be said of the Blockquote, TP Button, TP Image, and others. These could be extensions of the core WordPress blocks. Other blocks like the TP Heading, TP Paragraph, and Testimonials might be better served as custom patterns.

Adding a testimonial from the plugin to the editor.

The concept of building custom, in-house blocks seems to be more prevalent each day as more plugin companies release block libraries. The trend will likely continue. The block system is reasonably extendable. Recreating the wheel is unnecessary.

The Plus Addons for Gutenberg’s blocks are well done, and it is hard to fault a plugin for having a consistent experience across its custom blocks.

Overall, the plugin does not offer any groundbreaking ideas for new blocks. Most of these are available in other, similar block libraries. What sets this plugin apart is the development team’s work on packing a ton of block options into an easy-to-use interface.

Patel said he does not consider the team to be in competition with anyone else in the market. “We are on a mission to provide a one-stop solution for all needs of WordPress website designers and developers.” The goal is to make it easy for freelancers and agencies to build complex layouts in the block editor without writing code.

The project’s website currently touts the availability of predesigned templates. The team decided not to include this feature in its initial free version, focusing on the other features in the plugin instead. Patel wants to assure users that templates will be available in both the free and pro versions of the plugin.

“[Templates] will be available in a couple of months or early after the initial free version’s launch,” he said. “We will have UI blocks, homepage templates, as well as full-site demos with multiple pages in that.”

by Justin Tadlock at November 16, 2020 10:32 PM under Plugins

November 13, 2020

WPTavern: Google Webmasters Central Rebrands to Google Search Central

Twenty years ago, every aspect of developing a website and putting it online was more complex than it is today – an enchantment of Merlin’s wand to most common folks. The term “webmaster” hasn’t aged well, but it was commonly used in a different era when tech wizards were the only people creating and managing websites. The term has become outmoded as online publishing and website building has become more user-friendly.

Google recently ran a study that showed usage of the term webmaster is in sharp decline, as web professionals now prefer more specialized terms, such as blogger, developer, SEO, or online marketer. In recognition of this change, the company is rebranding “Google Webmasters Central” to “Google Search Central.” The change will be rolled out to Google’s websites and social media within the next couple days.

In addition to the rebranding, Google is also centralizing its help information on one site and consolidating its blogs:

Moving forward, the Search Console Help Center will contain only documentation related to using Search Console. It’s also still the home of our help forum, newly renamed from “Webmasters Help Community” to “Google Search Central Community“. The information related to how Google Search works, crawling and indexing, Search guidelines, and other Search-related topics are moving to our new site, which previously focused only on web developer documentation. 

The Google Webmasters blog and 13 other localized blogs are being moved to the new site for better discovery and easier language switching. Google is going to redirect current RSS and email subscribers to the new blog URL, so readers only need to update their bookmarks.

Google is also introducing a new jumping spider bot to accompany its Googlebot mascot in crawling the internet. The creature doesn’t yet have a nickname, but the company is soliciting suggestions.

by Sarah Gooding at November 13, 2020 10:46 PM under News

November 12, 2020

WordPress.org blog: WordPress 5.6 Beta 4

WordPress 5.6 Beta 4 is now available for testing!

This software is still in development, so we recommend that you run this version on a test site.

You can test the WordPress 5.6 beta in two ways:

The current target for the final release is December 8, 2020. This is just over three weeks away, so your help is needed to ensure this release is tested properly.

Thank you to all of the contributors that tested the beta 3 development release and provided feedback. Testing for bugs is an important part of polishing each release and a great way to contribute to WordPress.

Some Highlights

Since beta 3, 42 bugs have been fixed. Here is a summary of a few changes included in beta 4:

To see all of the features for each Gutenberg release in detail, check out the release posts: 8.68.78.88.99.09.19.2, and 9.3.

Developer notes

WordPress 5.6 has lots of refinements to the developer experience. To keep up, subscribe to the Make WordPress Core blog and pay special attention to the developers’ notes for updates on those and other changes that could affect your products.

How to Help

If you think you’ve found a bug, you can post to the Alpha/Beta area in the support forums. We’d love to hear from you!

If you’re comfortable writing a reproducible bug report, file one on WordPress Trac, where you can also find a list of known bugs.

Props to @tonyamork, @audrasjb for technical notes and @angelasjin, @yvettesonneveld@cguntur, @cbringmann for final review.

by Josepha at November 12, 2020 11:49 PM under Releases

WPTavern: Envato Passes $1 Billion in Community Earnings While Continuing to Aggressively Market Its Elements Subscription Against Marketplace Authors

Envato has passed $1 billion in community earnings after 14 years in business. The company reached the goal a year earlier than anticipated, thanks to the contributions of 81,000 different creators around the globe and millions of customers who have purchased products from Envato MarketEnvato StudioEnvato Tuts+ and Envato Elements.

“To this day, we’re very proud that our community earns more money than our company does,” Envato co-founder Collis Ta’eed said. Last month Ta’eed stepped down from his position as CEO to pursue a new ethical chocolate e-commerce venture. He was replaced by former HotelsCombined.com CEO, Hichame Assi.

Due to the pandemic, the Australian tech company recently transitioned to all employees working from home during the global lockdown. Along with the announcement of Ta’eed’s exit, Envato delivered a 20% profit share payout, totaling $3.75m AUD, to its 630-person workforce. The company reported that this is an increase on the 10% allocation from the previous financial year.

“Profit share has become an integral part of Envato and helps connect the team with a share of the success they create through their efforts,” Ta’eed said.

During the past several years, the company has focused heavily on driving profits through Envato Elements, its subscription service. Ta’eed said the business is now “more subscription oriented than at any time in our history.”

One WordPress plugin author, who sells on Codecanyon, commented on the milestone post, urging Envato to renew its focus on the marketplaces.

“Please focus on the marketplaces as well,” FWDesign said. “In the past 2-3 years, you guys focused on Elements, cannibalizing the marketplace, is time to give us something back. Personally, I feel forgotten.”

While the community earnings have allowed creators to improve their lives in various ways – from paying family medical bills to buying apartments – the increase in focus on Envato Elements has been highly controversial. Envato’s forums are replete with complaints about Elements “poaching clients from existing marketplaces,” after many authors spoke out about Envato advertising Elements on authors’ marketplace product pages.

Authors employ various marketing channels to bring traffic to their items, such as Facebook ads or Adwords, and have complained for years that potential customers were whisked away from their product pages by Elements ads. Many authors reported declining sales on individual products as a result.

In May 2018, Envato rolled out a critical change that made all items across all item types available to all subscribers (monthly and annual). This was particularly controversial for WordPress theme authors and many reported significant decreases in sales as a direct result.

At that time, former Envato employee James Giroux responded to authors’ concerns, characterizing the new subscription service as “a long-term play:”

“With Elements, you are buying into a revenue stream rather than a one-time transaction. So, when you compare the value of a Market customer vs an Elements subscriber, you may see less from the subscriber in the first month, but more in their cumulative lifetime revenue.”

Elements may not be the right choice for every Envato creator, but the company’s investment in the service is now pulling in $40 million in annual recurring revenue as of 2018-2019, accounting for 35% of Envato’s $113M in revenue for 2019.

“This year we continued to reinvent ourselves as a subscription company, with a major uptick in subscribers across Envato,” Ta’eed said in Envato’s 2019 Annual Public Impact Statement. However, this new business model is coming at the expense of authors who sell exclusively through the marketplaces.

Envato authors have begged the company’s leadership to take down the banners that boost Elements’ sales by siphoning customers off the marketplace, but the aggressive push towards subscriptions prevails. The frustration is palpable in numerous threads across the company’s various marketplaces.

“It’s one thing to advertise Elements on the web or wherever Envato likes, but to have this banner on all of our item pages is actively poaching potential customers away when they are moments away from buying our items,” AudioJungle author Alister Bunclark said.

Many authors have seen a decline in sales that is outside their control. No amount of marketing traffic to their own portfolios can make up for the $16.50 “all you can eat” offer that is plastered to the top of every page. The banner for the in-house competitor even appears directly in the cart for customers who are trying to checkout with products from non-Elements authors.

“The fact that we are even having to request that Envato stop relentlessly promoting a competing, lower-priced alternative to our portfolios (many of which are exclusively offered at AudioJungle) – on the marketplace where our portfolios are – is discouraging,” one author said.

WordPress authors selling on Themeforest are also frustrated with the banners. In 2019, Envato sold an item every 5 seconds, with WordPress accounting for a third of sales. The company claims to be the “market leader for themes and templates for WordPress,” despite the marketplace’s overall poor reputation among WordPress professionals.

One byproduct of Elements including WordPress products in the subscription is that it tends to encourage the use of outdated themes and plugins. Users can download thousands of products but the WordPress themes do not come with support. Many users are not aware of this when they purchase their subscriptions. Users can get updates only while their subscriptions are active, but they have to be downloaded manually.

“Despite tons of complaints from authors (who made this place what it is in the first place) it is even pointless to promote your items elsewhere to attract some ‘buyers’ because they see the Elements promotions everywhere, even on our own product pages,” Themeforest Elite author Bedros said.

When authors took to the forums to report no sales or declining sales, one user responded, “Don’t panic. They killed the market with Elements.”

Certain marketplaces, like AudioJungle and WordPress themes, are disproportionately impacted by Elements, given the significant time investment to create these types of products.

“I wonder what’s the point, in these circumstances, to spend months (in some cases even a year) to build a decent WordPress theme to sell on Envato,” Bedros said. Another author on the same thread reported working on a theme for 16 months and had only 17 sales two months after it was approved.

“The big buyers (ad agencies and the like) will see an immediate savings on the subscription plan opposed to buying the products individually,” AudioJungle author Daniel Warneke said. “This pulls the high volume purchasers out of the individual market.

“Envato hand picks the authors that have products in Envato Elements, so it stands to reason that they selected a broad range of the most popular products. This would make the service the most appealing.”

Envato Reports 0.18% CTR on Elements Banner Ads But Will Not Remove Them

In the responses to Envato’s 2019 Annual Public Impact Statement, Collis Ta’eed confirmed that market sales are declining. He blames the “movement of the industry” towards other business models as the reason for the decline:

To your question on Market sales, they’re holding up better than we’d hoped, though they are down year on year. Internally we look at the combination of Market and Elements both in gross revenue (which is up) and in authors earnings (which is up). But Market itself is down a few percent on this time last year, and that looks like an ongoing trend (though one that’s not as steep as my worst fears at times!)

It’s tempting to think the driver of Market’s changes are Elements, especially as we drive subscription customers over. But we’d been mapping the trend of the sales curve for years prior to the launch of Elements and had been seeing changes before we ever launched into subscriptions, because of the movement of the industry, first to ‘bundles’ and then to ‘subscriptions’ and ‘free’. From what I can tell the bigger forces on Market are actually industry ones.

Despite the vast undervaluing of their individual products, authors in general do not seem to be opposed to Elements entirely but rather they are opposed to Envato’s aggressive advertisements on their portfolios. The same question surfaces every year and the company’s leadership continues to dance around it.

“Can you explain to authors why they should spend money on advertising their products when as soon as they land on the landing page they see a great big dirty banner saying they can get everything unlimited for a monthly fee?” template author Patchesoft commented. “I feel like this question came up last year and we got a ‘we’ll see what we can do about it’ and yet here we are a year later.”

Ta’eed responded, characterizing the banners as a cross-promotion of traffic between Market and Elements. He claimed that after the company performed some tests, removing the banner “had negligible impact on sales at a daily level.”

Definitely I know that the header bar on Market is up there amongst the most annoying things to authors. But at the same time, it’s important for us to be transparent about the different offerings we have for customers so they can choose what’s best for their needs. While it’s pretty annoying, the traffic diverted from Market item pages is minimal (0.18% of visitors actually click through). That said we’re exploring ways to let customers better know about Elements (and Placeit).

Authors are not buying this justification for the banner ads, and object to the use of the term “cross-promotion,” when the promotion only goes one way. Meanwhile, Elements, which enables non-exclusive sales, is treated like an ad-free, exclusive library.

“’Annoying’ is not the correct word,” AudioJungle member Purple Fog said. “You gotta understand it’s much, much more than that. It’s infuriating, it’s a betrayal, it’s you flipping us the finger.

“If it’s so important for you to let buyers know what all their options are, then why isn’t there a top banner on Elements telling them they can also get the item for a one off fee, in case they don’t want to subscribe?

“That 0.18% is pretty far from the figure you previously gave us (around 2%), and is even harder to believe. Do you mean that you are willing to antagonize the vast majority of authors just for 0.18% CTR? Makes little sense. It’s also hard to believe when there are countless threads opened by buyers who felt they were tricked by that infamous banner. Either your people are lying to you, or you didn’t set up the analytics properly, but in any case, something doesn’t add up here.”

Envato’s Transformation Into a Subscription Company Comes at the Expense of Its Exclusive Market Authors

Envato continues to write its own rules due to its early success and has now amassed a vast labor force who depend on the company’s offerings for their livelihoods. Those who are willing to devalue their work for inclusion in a subscription product (that is guaranteed to sell with a more compelling pricing point) are allowed to continue as cogs in a much more profitable machine.

It’s not wrong for Envato to pivot towards becoming a subscription company. To do so at the expense of market authors is unfair. These authors are paying to advertise for a competing library with lost sales from their own products. It exploits the marketplace authors who were hoping to make a sale, since their higher prices are now just a prop for making Elements look more attractive. Their portfolios become a gateway to the subscription service.

Unless Envato changes how it advertises Elements, the company will remain at odds with exclusive market authors’ interests. This is especially true for creators in markets where having their work available to more customers doesn’t instantly translate into more payments.

“Many authors have chosen to set up shop here exclusively and have supported and promoted this marketplace for years,” AudioJungle author Promosapien said in a thread where authors called on the CEO to remove the banner ads.

“Envato is presently making strategic choices that they obviously feel strongly about and feel are necessary for their own viability. Unfortunately, those choices are diminishing the benefits of being an exclusive author here.

“In fact, you could probably make a good argument that there has never been a worse time to be an exclusive author at a marketplace – when that marketplace is actively and continually using its considerable promotional resources to move website visitors away from your portfolio to a newer, cheaper licensing platform (Elements subscription).”

by Sarah Gooding at November 12, 2020 11:47 PM under themeforest

WPTavern: Do Not Build Theme-Specific Block Plugins for WordPress, Please

A few days ago, I came across a small library of blocks. As always, I was interested in seeing what this new plugin brought to the table. Would it surprise me with a block that has not been done before? Would it present a new take on some old ideas? Or, would it be the same old set of blocks that every other block bundle has? Regardless of what it offered, I was excited to try it all the same.

As I clicked on the description to find out more, I was immediately let down. The plugin specifically stated that it was built for only one theme. I could not use it with my preferred theme.

This was not the first time I had run across this issue. Other theme authors have built their own block bundles in the past. The plugin was not bringing anything particularly new to the WordPress community. It had less than a handful of blocks that had already been done before in numerous other plugins.

The problem was that this felt all too familiar.

Over the years, the WordPress community has created a set of unwritten rules regarding what belongs in a theme vs. what belongs in a plugin. Custom post types, taxonomies, and shortcodes are plugin territory. To an extent, widgets should also be exclusive to plugins. However, because of the way they are handled under the hood, there was always an argument that it was OK for themes to register them.

This theme vs. plugin argument has been ongoing for at least a decade. Because of how themes work, such arguments have been a losing battle. Except in a few edge cases, themes could do everything that a plugin could do. However, there was always supposed to be a clear-cut distinction between the two. Themes were meant to handle the front-end design of a website. Plugins were for everything else.

Today, the WordPress project and its block system are making progress toward solidifying that distinction.

Because of WordPress’s legacy of having various parts that did not all quite fit together in the past, it has created a culture of developers building in-house solutions. Nearly every large theme development company has its own plugins for overcoming the platform’s shortcomings. Most of the blame for this lies with the WordPress project. However, the project’s move to blocks is creating a standardized system that handles everything from a paragraph to the overall site container. With standardization across the board, there will be less and less need for these custom solutions from every theme company.

The block system set a clear line in the sand. It removed the need for shortcodes — good riddance — and will soon phase out widgets. Blocks should be putting those old questions to bed.

For clarity, there is little difference between bundling blocks with a theme and building a separate plugin that only works with a specific theme. The end result is the same. Such a plugin would lock a user into sticking with that theme if they relied on the plugin at all. Few people maintain the same front-end design forever.

The goal is to allow users to switch themes at will while having access to their content and blocks.

These theme-specific block plugins are thinking about blocks in the wrong way. When a user installs a block plugin, the expectation is that they can use those blocks regardless of their theme.

The solution for themes is to use block patterns or styles. Suppose that you wanted to create a slider or carousel as a theme author. There are multiple solutions for this. The first and easiest is to simply recommend a plugin to users or build a plugin of your own that works with any theme. You could also easily add a slider style for the Gallery block. When the user selects it, it transforms the gallery into a slider.

Or, suppose your theme needed to offer a big hero section with a call-to-action button. There is no need for a custom block in this situation. Theme authors can almost exclusively do this by building a custom pattern with existing blocks.

The solution is not to bundle the block in the theme or create a plugin that only works with that one theme.

The beauty of the block system is that most of the pieces are already in place, and they can be rearranged, grouped, and styled in unlimited ways.

Today, there are hundreds of theme-specific plugins in existence. Part of that is because themers were working around the WordPress.org theme review guidelines. Part of that is because some developers did not think creatively enough about solutions. But, the biggest part of it has been because WordPress has not standardized how to build things across the entire platform. Much of that has changed and will continue to change as full-site editing crosses the horizon in 2021. There will be clear paths for themes and plugins.

However, if theme companies continue building theme-specific blocks, we are just lugging along the baggage that the block system is meant to leave behind.

by Justin Tadlock at November 12, 2020 09:58 PM under Opinion

November 11, 2020

BuddyPress: BuddyPress 7.0.0-beta2

First of all, we’d like to thank all the contributors who tested the first beta of our next major release. Beta testing is very important to us as it’s a good way to check the improvements we brought to BuddyPress are behaving as expected on your WordPress/BuddyPress configurations.

BuddyPress 7.0.0-beta2 is now available for testing, and we’d love to have your feedbacks about it!

Since 7.0.0 beta1:

  • We fixed some issues about the newly introduced features (BP Activity Embed block : 12763 ; BP Types Admin UI : 12764, 12767, 12775, 12776 & 12778).
  • We improved the performance of the BP xProfile component : 12768 & 12781.
  • We changed Member Types to behave more like Group Types: 12765, 12767 & 12778.
  • We gave a default avatar to the BP Blogs on multisite configurations : 12772 & 12779.
  • We fixed issues with the BP Nouveau Template pack : 12773 & 12774.
  • We improved the BP Invitations feature : 12771.

We’ve also updated the 7.0.0 release schedule : the 7.0.0 final release is now scheduled to December 9.

And we need you to get there: do test the 7.0.0-beta2 release so that we can eventually solve issues you might find with your plugins, themes or specific WordPress/BuddyPress configurations.

You can test BuddyPress 7.0.0-beta2 in 4 ways :

Thanks in advance for your contributions

by Mathieu Viet at November 11, 2020 11:15 PM under releases

WPTavern: Themes Team Removes Outdated CSS Guidelines, Adds Stricter Requirement for Links in Content

In yesterday’s twice-monthly meeting, the WordPress Themes Team made a couple of important changes to the official theme directory guidelines. They removed a requirement of some CSS classes that have long been sitting on the chopping block. They also implemented the third stage in their long-term plan to make all WordPress themes accessibility-ready.

For years, theme authors have needed to either style several WordPress classes via CSS or add empty, unused selectors. It was a bit irritating for authors who fell in the latter group. The list includes several classes like .sticky (for sticky posts) and .bypostauthor (for post author comments). Now, styling these classes are optional.

The one question mark in this decision is probably around the classes for handling left, right, and center alignment. While the newer block editor stylesheet does support these classes on the front end, it could leave end-users in the dust if they are using the classic editor and a theme author decides to drop support. Any images in posts could become misaligned. Theme authors should test this and consider any problems before deciding to remove these from their stylesheets. For the other classes, those are mostly design decisions.

This change will not be official until the Theme Check plugin is updated to allow themes without these classes through the system.

The second big change is the reignition of the push toward creating more accessible themes in the directory. All themes in the directory are now required to distinguish links in “content” areas via an underline.

The full guideline is as follows:

When links appear within a larger body of block-level content, they must be clearly distinguishable from surrounding content (Post content, comment content, text widgets, custom options with large blocks of texts).

Links in navigation-like contexts (e.g., menus, lists of upcoming posts in widgets, grouped post meta data) do not need to be specifically distinguished from surrounding content.

The underline is the only accepted method of indicating links within content. Bold, italicized, or color-differentiated text is ambiguous and will not pass.

While this is a simple change, it is a bold one. Thus far, there has not been any pushback from theme authors on the announcement post or in the team meeting. However, some may be expected as the news trickles through the theme design community.

The one question that arose about the requirement was whether theme authors could add an option to allow end-users to opt-out of this behavior. The team said this was allowed as long as the underlined links were enabled by default.

The Road to Accessibility

In July 2019, the Themes Team made a commitment to push theme authors to make their themes more accessible. It was not a switch they were going to flip overnight. Instead, the team made a goal of implementing a new accessibility-related requirement every two months or so. These periods would give both theme authors and reviewers ample time to familiarize themselves with each change.

This is the third requirement added to the guidelines since the team implemented the plan. The team started with some low-hanging fruit and added a requirement that themes ship with a skip-to-content link. That guideline addition went over relatively smoothly. The team quickly added a new guideline requiring that visitors be able to navigate menus via keyboard.

That second guideline landed in August 2019. From the outside looking in, the project was initially going well. However, until yesterday, the team had not added any new accessibility guidelines. Over a year had passed, and the plan seemed to be grinding to a halt. Accessibility advocates were probably wondering what happened.

In a discussion with the Themes Team reps a few months ago, they were not sure when they would implement the next guideline. The project was not going as planned.

“We have not added anything else above that because theme authors are still not releasing themes with working implementations of skip links and usable keyboard navigation,” said team representative William Patton at the time. “When those two things become habitual it will be time to introduce another aspect as a requirement. The fact that this has taken so long for authors to get this right probably indicates that we need to do better at guiding them to resources to learn how to do it and why it is important. Perhaps that is a better avenue to pursue than looking to implement additional asks of them.”

Team rep Carolina Nymark shared similar sentiments. She mentioned that underlined links were up next on the list. However, they did not have a deadline in mind yet.

“Skip links and keyboard navigation are still a headache to some extent for some authors,” said Ganga Kafle, a team representative. He said that theme authors who regularly submit themes are doing so with these requirements in mind. However, keyboard navigation remains the biggest pain point, particularly on mobile views.

“But almost all the themes we get are with skip links working properly,” he said. “That is a good thing so far. The new requirement is not so huge and tough. And I think we need to add such small things in a timely manner.”

For now, the team seems to be picking up where they left off. There is still a long path to go before the project is complete.

The best thing that theme authors can do right now is to follow all of the optional accessibility guidelines. This will prepare them for a future in which they are all required.

by Justin Tadlock at November 11, 2020 06:10 PM under theme review team

WPTavern: Google Search to Add Page Experience to Ranking Signals in May 2021

Six months ago, Google announced its plans to introduce a new ranking signal for Search, based on page experience as measured by Core Web Vitals metrics. At that time, Google promised to give site owners at least six months notice before rolling out the update so they can improve their scores on the metrics before the update. The company reports a 70% increase in users engaging with Lighthouse, PageSpeed Insights, and Search Console’s Core Web Vitals report in preparation for the update.

Today Google confirmed that it will roll out the new page experience signals in May 2021. The search engine also plans to introduce a new visual indicator for pages that fully comply with the page experience requirements:

On results, the snippet or image preview helps provide topical context for users to know what information a page can provide. Visual indicators on the results are another way to do the same, and we are working on one that identifies pages that have met all of the page experience criteria. We plan to test this soon and if the testing is successful, it will launch in May 2021 and we’ll share more details on the progress of this in the coming months.

There are no additional details on what that will look like but AMP’s lightning bolt is a good example of how small graphics can have a meaningful impact on users’ behavior when navigating through search results.

Are WordPress Websites Ready for Page Experience as a Ranking Signal?

The page experience signals Google plans to roll out will include Core Web Vitals (Loading, Interactivity, and Visual Stability metrics), combined with existing search signals for mobile-friendlinesssafe-browsingHTTPS-security, and intrusive interstitial guidelines. Based on where the web is now, in terms of delivering a good page experience (as defined by Google), site owners will undoubtedly need the next six months lead time to become aware of the new ranking signal and prepare.

Google’s Core Web Vitals assessment gives a pass or fail rating, with a “pass” requiring a good result in all three metrics. A cursory test using Page Speed Insights on a few of the websites for the largest companies, hosts, and agencies in the WordPress space shows most of them do not currently meet these requirements.

In August, Screaming Frog, a search marketing agency, published a lengthy report on tests that found only 12% of Mobile and 13% of Desktop results passed the Core Web Vitals assessment. Screaming Frog used the PageSpeed Insights API to test 20,000 websites, which were selected through scraping the first-page organic results from 2,500 keywords across 100 different topics. The report highlighted a few important findings:

  • First Input Delay (FID) on Desktop is negligible with 99% of URLs considered good. And 89% for Mobile.
  • 43% of Mobile and 44% of Desktop URLs had a good Largest Contentful Paint (LCP).
  • 46% of Mobile and 47% of Desktop URLs had a good Cumulative Layout Shift (CLS).
  • URLs in Position 1 were 10% more likely to pass the CWV assessment than URLs in Position 9.

These results suggest that most website owners still have a good deal of work ahead of them in meeting the requirements for passing the Core Web Vitals assessment. Unsurprisingly, Google suggests AMP as the preferred vehicle to get there, but even AMP is not a magic bullet.

At AMP Fest last month, the project reported that 60% of AMP domains pass the Core Web Vitals metrics (meaning 75% of pages on the domain passed), compared to 12% of non-AMP domains passing based on the same criteria.

“Looking ahead to Google Search’s upcoming rollout of using page experience signals in ranking, we challenged ourselves to consider how we could better support the AMP community and reach a point where we are able to guarantee that all AMP domains meet the criteria included in the page experience ranking signal,” AMP Product Manager Naina Raisinghani said.

Those who are already using AMP are encouraged to check out the AMP Page Experience Guide, a diagnostic tool that helps developers improve their page experience metrics with practical advice.

AMP is not required, however, if developers feel confident delivering the kind of performance metrics necessary to pass the Core Web Vitals assessment. Along with the new ranking signal, Google also plans to roll out another promised change that allows non-AMP content to become eligible for placement in the mobile Top Stories feature for Search. Starting in May 2021, sites that can deliver decent page experience metrics will be prioritized, regardless of whether they were built with AMP or through some other means.

by Sarah Gooding at November 11, 2020 05:00 AM under page experience

November 10, 2020

WPTavern: WordPress 5.6 Beta 4 Delayed, Auto-Updates Implementation Changed

Earlier today, release lead Josepha Haden announced the team was pushing back the release of WordPress 5.6 Beta 4 to Thursday, November 12. The beta release was slated to go live today. Questions around the readiness of the auto-updates feature held the beta update back. However, those questions are now resolved.

Haden followed up the Beta 4 announcement with a more in-depth picture of how auto-updates will change for WordPress 5.6. She summarized the current concerns, laid out a path for version 5.6 and 5.7, and discussed plans for the future. The auto-updates feature is not something that will be complete overnight or in just one release. There are complex technical hurdles that must be jumped and a need for a dedicated focus in upcoming releases.

Much of her post focuses on the tactics going forward. However, she mentioned in our chat that she does not want the community to lose sight of the big-picture, vision-setting aspects of the project.

“The subject of auto-updates has resulted in many complicated discussions,” she wrote. “As I reminded the release squad, decisions like these require us to remember that we’re contributing to over 30% of the web, and we have to balance our immediate needs with long term planning.”

The short-term plan is to allow current WordPress users to opt-in to major updates while enabling auto-updates for both minor and major releases for new installations. Some changes to the auto-updates UI are also in the works along with a plan to revise based on feedback in WordPress 5.6.1.

In WordPress 5.7, which is several months away, the goal is to add a nudge on the Site Health screen for anyone opted out of major updates. We could also see a setting to opt-into updates as part of the WordPress installation flow for new sites.

The big picture that Haden is talking about? That is to make sure that all WordPress installations are receiving auto-updates, that these updates are seamless, and that users are running a secure version of WordPress.

Nearly two years ago, WordPress project lead Matt Mullenweg outlined nine goals for 2019. One of those goals was to provide users a method of opting into automatic updates of major releases. It has taken WordPress a while to get there, but it is on the cusp of launching this feature that many have looked forward to.

Haden also further clarified that goal. She said that the long-term plan for both Mullenweg and the other original feature contributors was to always have auto-updates for major releases enabled by default.

Apart from those who already prefer to opt-out of any sort of automatic updates, some users’ trust in the system eroded a couple of weeks ago. The WordPress auto-update system updated sites to version 5.5.3-alpha instead of 5.5.2 — WordPress currently automatically updates only minor releases. While there was no difference between the two versions and the core team quickly resolved the problem, the damage to user trust was already done.

This was not an ideal leadup to the December launch of auto-updates for major releases.

However, one hiccup — one that was effectively not an issue — seven years after WordPress 3.7 launched with security and maintenance updates is not too bad. The system has been a boon to making the web a more secure place. Ultimately, that is what auto-updates are all about. The big goal is to make sure that all WordPress sites are running on the most secure version available.

“It’s important that whatever we implement isn’t taking us further away from our long term goals of having seamless, auto-updates across the project,” wrote Haden. “Auto-updates can help us have a more secure WordPress ecosystem, and in turn can help change the public perception of WordPress being an unsecure choice for users of any skill level.”

by Justin Tadlock at November 10, 2020 09:29 PM under auto updates

Follow our RSS feed: 

WordPress Planet

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

Official Blog

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

Subscriptions

Last updated:

December 02, 2020 01:45 AM
All times are UTC.