Posted on

WordPress 5.5 “Eckstine” Introduces Block Directory, Block Patterns, and Automatic Updates for Themes and Plugins

WordPress 5.5 “Eckstine” landed today, named for American jazz singer Billy Eckstine. This release introduces major improvements for the block editor and the security of WordPress. It was made possible by the contributions of 805 volunteers (with 38% of them being new contributors.) The 5.5 update is a testament to the stability of WordPress during uncertain times, as well as its unstoppable, distributed contributor base, who continue to get things done despite the pandemic’s unique challenges.

WordPress continues refining the editing experience with more than 1,500 updates from 10 releases of the Gutenberg plugin included in 5.5. (The plugin is where all the magic is tested prior to landing in WordPress releases, and features are periodically rolled in.) Some of the most notable changes include inline image editing, device previews, and smoother block movement with better drag-and-drop, block movers, block selection, and block relocation.

Block Patterns are making their debut in WordPress 5.5, with a handful of default patterns already available in the block inserter. This new feature helps users build pages faster by allowing them to instantly place sets of blocks that are already artfully arranged. We have written extensively about why block patterns will change everything and it will be exciting to see what developers do with them now that the feature is in core.

Block Directory Enables Block Discovery and Installation Inside the Editor

WordPress recently launched a block directory for single-block plugins and users can now search for and install blocks directly inside the editor. Selected blocks are downloaded seamlessly in the background and automatically activated and placed in the content. The advantage is that users don’t have to break their workflows in order to install new functionality. Blocks installed via the editor can also be uninstalled from the plugins page in the admin.

Search for and Install Blocks from the Block Directory

Block patterns, combined with the new block directory, will make page building much faster inside the editor by enabling users to quickly spin up layouts and add blocks on the fly.

WordPress Security Takes a Giant Leap with Automatic Updates for Themes and Plugins

Version 5.5 introduces a new UI for enabling auto-updates for themes and plugins. This is an exciting new era for WordPress that brings a higher level of website security while requiring less effort from users. Those who choose to get on the automatic updates train will no longer have to log into their sites and be greeted with a slew of nagging update notices. These updates will happen the same day they are available, so users don’t have to check in as often and sites are better protected from plugin and theme vulnerabilities getting exploited.

WordPress uses wp-cron to fetch updates for plugins and themes twice per day. The feature ships turned off by default in WordPress 5.5, so users will need to visit the theme and plugin pages in the admin to enable automatic updates. The bulk actions menu dropdown now has options for enabling or disabling auto-updates on all plugins, but users can always enable the updates for select plugins if they have any concerns.

Other notable updates in WordPress 5.5 include the following:

  • XML Sitemaps: WordPress now includes extensible core sitemaps, and many users will no longer need a plugin for this functionality. This basic implementation was completed in a way that will not impact performance or cause conflicts with other plugins that add sitemaps.
  • Lazy Loading Images: WordPress images will now wait to load until users scroll them into view, speeding up performance, especially on mobile.
  • Improved Accessibility: Metaboxes can now be moved with the keyboard, assistive devices can see status messages in the image editor, copying links in media screens and modal dialogs can now be done with a click of a button, and more.
  • Update Themes and Plugins by Uploading ZIP files: – Users can now update plugins and themes manually by uploading a ZIP file, an improvement for scenarios where one does not have server access.
  • Final Dashicon Library Update: The Dashicons project has been discontinued in favor of the new Icon Component. This last update to the library adds 39 block editor icons and 26 other icons.

For a more technical breakdown of some of the changes under the hood, check out the developer notes and the 5.5 field guide.

Posted on

Revised Block Directory Guidelines Proposal Updates Wording but Changes Little Else

Yesterday, Alex Shiels posted an update to the proposed guidelines for the WordPress block directory. The document adds eight rules for plugin authors to follow if they plan to add their one-off blocks to the directory. The guidelines are additional requirements on top of the existing plugin directory guidelines.

While the wording and organization of the block guidelines received a revamp in comparison to the original proposal, the overall sentiment is unchanged. Shiels thanks community developers for the feedback on the original guidelines but does not go into detail about the things that changed as a result.

The primary guidelines are mostly expected, run-of-the-mill requirements for blocks. Developers need a block.json file. They should name stuff appropriately. Plugins should contain only a single block. Plugins should only touch the block editor. Blocks should work seamlessly once activated.

The remaining guidelines are certain to be a disappointment or point of contention for some developers.

Monetization Still Not Allowed

The largest feedback on the guidelines we received here at the Tavern surrounded what is essentially a blanket ban on commercial interests for block developers. Blocks still cannot hook into a paid service or advertise within the admin. This limitation will obviously turn away many businesses that may have been looking forward to the block directory as a potential avenue for profit. Right now, one-off blocks will need to be built by those with altruistic interests, giving back to the community simply out of the kindness of their hearts.

While there is nothing inherently wrong with wanting to do that, it is not attractive to developers who are primarily focused on putting food on the table. Hobbyists and larger businesses with the resources to give back will be well-suited to add blocks to the directory. However, it will give a lot of developers pause because it is unlikely a good return on investment. Instead, those developers are more likely to submit their blocks to the normal plugin directory with their normal upsell methods. This will only serve to make block discoverability harder for end-users.

This is a missed opportunity to build a well-rounded system that is fair to both users and developers who need to make a living. Whether it is through the plugin tag system or specific guidelines on monetization, we could have built something that made everyone a little happy and a little mad, a compromise that merged a good user interface and experience.

It is not like there have been no proposals. In January, Luke Carbis wrote a detailed outline of how WordPress could provide a middle ground between sustainability (business models) and accessibility (free options) with the upcoming block directory. His fear was that the block directory would be full of blocks without updates in a few years because the completely free model is unsustainable. His proposal was a badge-based system that let users know if a block contained ads, used a freemium model, or required a sign-in to a third-party service.

The current guideline is not set in stone. This is the first version of the block directory. It is not out of the question that the team could change things as the directory grows over time.

No Love for Server-Side Blocks

The block directory guidelines are still heavily geared toward static blocks. PHP must be kept at a minimum and primarily be used to load any necessary scripts and stylesheets. Server-side blocks are not getting much attention at the moment, which may be a limitation of the software.

It would be great to see a way for some server-side blocks to be included in the block directory. For example, a breadcrumbs block would need to rely heavily on PHP to render its output. It is a dynamic block rather than static. This particular block would not be useful until full-site editing lands in WordPress, which is still several months away. However, I am getting the itch to turn an old breadcrumbs plugin of mine into a block. It would be neat to see it listed in the block directory.

There are countless other scenarios. Post lists, product grids, and data pulled from external APIs are all good use cases for one-off blocks.

Dependencies Are Not Allowed

Given the way that WordPress works, it makes sense to ban dependencies on other plugins for any particular block to function. This is an old limitation that is rearing its head again. Every other modern framework uses some sort of dependency management to address this problem.

The block directory has the potential to exacerbate the problem even further. Because plugins coming from this directory will be single blocks, it will often mean that developers are using the same bits of code across multiple projects. For example, an end-user may activate multiple block plugins that rely on the same JavaScript library. Because there is no 100%, sure-fire way to make sure only one instance of this library is loaded, users may be running multiple instances of it on their sites. It is not a new problem, but smaller block plugins mean that users are more likely to install more plugins. It increases the probability of running into this issue.

If there was any sort of basic dependency management for plugin authors to use in WordPress, it would solve a world of problems. Over the years, developers have created methods to minimize the issues stemming from the lack of such a system. However, nothing is foolproof without a standard to follow.

This has also held developers back from building libraries, scripts, and tools that could benefit the entire development community as a whole. Everyone builds their own things in-house, and the block directory is making a promise for more of the same.

Posted on

Can the Block Directory and Business Interests Coexist?

WordPress.org is not an official marketplace for plugins and themes. Except for some plugins that are strictly SaaS products, all extensions to the platform are publicly available for the low cost of $0.

Despite not directly selling through WordPress.org, the plugin directory is a huge source of income for many individual developers and companies via product and service upsells. Plugins are big business. Besides a bounty of third-party marketplaces and individual shops, commercial interests often flow directly in and out of the official WordPress site. For many developers, it essentially serves as a marketplace.

In December, we dove into an early proposal of the WordPress block directory. The new directory should land within the WordPress software itself in version 5.5 and will house a new type of plugin. The idea behind the block directory is that it will allow plugin developers to create and share one-off blocks that users can install on their websites.

This is the future of WordPress.

Love it or hate it, there will come a time when end-users are primarily looking to install individual blocks to solve their problems. This is not to say that other types of plugins won’t exist or have their place. They will continue to be a major part of the platform. However, blocks will be a big deal once users can install them at the click of a button via the WordPress admin.

The question is whether blocks can also be big business.

Tavern reader Matt Gowdy believes the guidelines for the block directory could be an issue. “There’s a lot to like here,” he said. “Though I’m still troubled by the directory submission rules that are fairly stringently not allowing for any sort of promotional link or defined up-sell of any kind so as not to ‘disrupt the flow.'”

Currently, the block directory guidelines make it clear that advertising of any kind is disallowed:

Block Plugins are blocks. They must not include advertisements, prompts, or promotional messages.

On the one hand, it makes sense, particularly for something that is not yet built and will eventually serve as a version 1.0. If every block a user installs begins advertising, it could be a recipe for disaster without some type of standard.

On the other hand, would the idea of not having an upselling route turn WordPress businesses away? While many developers would be willing to submit blocks, is this sustainable? Many of the most popular plugins are backed by businesses. The more popular any particular piece of software becomes, the more likely it is that the software will need funding to cover maintenance, feature updates, and support.

“More often than not these days, people don’t have as much free time to invest in coding just for the fun of it,” said Gowdy. “I speak mainly of myself, but I have the notion that while WordPress is still grounded pretty firmly in Open Source (not a bad thing), it’s been the open markets that have allowed it to grow as much as it has. I don’t think it’s wrong to allow people the opportunity (within reason) to make something back off their hard work should they choose. Donations are non-viable in my experience as the vast majority of humanity are way cheaper than they would like to admit.”

Currently, the upcoming directory has a limited number of blocks available. The WordPress Meta and Plugin teams should expect more. However, it is unclear whether the guideline will slow its growth.

“Without any sort of up-sell channel (rule-defined or element defined in blocks), we aren’t going to see the plethora that we are hoping for, nor in some cases the quality that could be brought in by people working professionally on a block plugin,” said Gowdy. “The time to define these up-sell and link options is right now.”

Gowdy is not alone in his concerns. Several others expressed similar opinions in the comments on the block directory announcement post.

“Where WordPress started and where it is now are two separate points in time,” said Gowdy. “I hope the Open Source community and the marketplaces can find a way to co-exist here in order to really rev up the platform for the future.”

This post is part of a new From the Comments series where we highlight interesting points of discussion from comments on WP Tavern articles. The hope is to give these comments, which can sometimes get lost, the attention they deserve.

Posted on

Gutenberg 6.5 Adds Experimental Block Directory Search to Inserter and New Social Links Block

Gutenberg 6.5 was released today with a rough prototype that adds one-click search and installation of blocks from the block directory to the inserter. Selected blocks are automatically installed as a plugin in the background and inserted into the editor with one click.

The pull request for the experiment indicates that it’s still very much a work in progress. It extends the inserter to fetch a list of suggestBlocks similar to reusableBlocks, and the list is currently served from a mock API.

The prototype is can be turned on under the Gutenberg > Experiments menu, a relatively new Settings page that was added in Gutenberg 6.3. This menu also allows testers to enable the experimental Navigation Menu Block, Widgets Screen, and Legacy Widget Block.

Block Navigation has also been added to the experimental Navigation Block in this release. This addition is considered a first start that is expected to evolve over time.

“Regardless of how the UI evolves for this block, I think there will always be a need for representing the menu structure as a child block tree with all menu hierarchies mapped out consistently and not hidden (dropdowns, etc),” Gutenberg engineer Matias Ventura said.

“Luckily, we already have a view that handles that representation in the ‘block navigator.’ That means if the navigation menu block is represented through child blocks, we’ll get this view for free.”

In the future, Gutenberg engineers may allow for drag-and-drop reordering of items in the navigator and may explore rendering the view inline or in a modal launched from the navigation menu block.

Gutenberg 6.5 Adds New Social Links Block

Gutenberg 6.5 also adds a new social links block under the widgets panel. It allows users to place social links anywhere within the content by clicking on the icons and pasting in their social URLs. The gif below demonstrates how the block works, although the grey placeholder icons have since been removed in favor of opacity changes to indicate unconfigured blocks.

This release introduces a handful of other notable updates, including support for border radius changes in the button block, support for adding captions to images in the Gallery block, and the addition of local autosaves.

The 6.5 release post has not yet been published but the plugin update is available in the admin and a full list of enhancements and bug fixes can be found in the changelog.

Posted on

In Case You Missed It – Issue 28

In Case You Missed It Featured Image
photo credit: Night Moves – (license)

There’s a lot of great WordPress content published in the community but not all of it is featured on the Tavern. This post is an assortment of items related to WordPress that caught my eye but didn’t make it into a full post.

Changes to WordPress PHP Coding Standards

Based on changes that were proposed back in March, the PHP Coding Standards for WordPress have been altered. Note that these changes apply to WordPress core only and Gary Pendergast recommends that developers can and should choose practices that best suit your needs for plugins and themes.

PHP Coding Standards Changes

Excluding Remote Employee Job Applicants Based on the State They Live In

Like Brad, the topic of not hiring job applicants for a remote company based on the state they live in because of tax laws is not something I’ve seen discussed.

In certain situations, companies that go the extra mile to hire a remote worker can also turn that person into an advocate.

If you’re involved in the hiring process for a remote company, I’d love to hear your thoughts on this topic in the comments.

Would You Like to See A Product Hunt for WordPress Products?

Once you create something awesome in the WordPress ecosystem, it’s tough to get the word out. Ben from LyrWP wants to know if anyone is interested in a Product Hunt website for Themes, Plugins, and Services.

I think it’s a great idea and something I’d like to see become a reality. There are probably a ton of great products in the WordPress space that go unseen because there’s no easy way to reach a large mass of people outside of sites like the Tavern.

However, Mario Peshev is concerned that such a site may end up posting infrequently or promote mediocre products.

If Peshev’s concern became a reality, there wouldn’t be much of a point to continue with the site and developers would be back to square one.

Speaking of learning about new products, who remembers the Plugin Release posts on WeblogToolsCollection.com?

Early Look at What A Block Directory in WP-Admin Could Look Like

Mel Choyce has shared a collection of concept images that depict what a Block Directory could look like inside of WP-Admin. She describes the inspiration for each image and how each screen would work.

Block Directory in WP-Admin Concepts

What I find interesting is that users will be able to try out new blocks before installing them. “Inside the modal, you’d also be able to demo a block before installing. @ck3lee has figured out how to make this possible,” Choyce said.

It’s also great to see that the tech behind Shiny Updates will be used for quickly installing and activating new blocks. If you have feedback regarding the conceptual designs, please leave a comment on her post.

Notes From Lead Developer Conference

More than 20 Automatticians are attending the Lead Developer Conference in London, England, and are publishing notes from each day. You can check out Day 1 here.

WPCampus 2019 Will Be LiveStreamed

Thanks to Pantheon, all sessions excluding workshops at WPCampus will be livestreamed with captioning and available to watch for free. Simply visit the livestream page on Friday, July 26 and Saturday, July 27.

Apply for a DonateWC WordCamp Sponsorship

DonateWC is looking for applicants for its sponsorship program. DonateWC provides underrepresented and minority groups within the WordPress community with the means to attend a WordCamp.

That’s it for issue twenty-eight. If you recently discovered a cool resource or post related to WordPress, please share it with us in the comments.

Posted on

WordPress Explores Proposal for New Block Directory to Host Single Block Plugins

WordPress core contributor Alex Shiels has published a proposal for a WordPress.org block directory that would host JavaScript-based, single block plugins. The directory would make blocks searchable and installable from within the Gutenberg editor. Building a directory for discovering blocks and seamlessly installing them is one of the nine projects that Matt Mullenweg identified as a priority for 2019.

Block collections have become one of the most popular ways for distributing a group of related blocks but this method can cause bloat. Users currently cannot search for individual blocks by name and plugin names and descriptions are not always a good indication of what the blocks do.

Shiels proposed the new directory be limited to single block plugins, frontend JavaScript blocks with no UI outside of the editor. It would be a separate section inside the Plugins Directory, optimized for users to find blocks by name and description. Developers would be required to use a block.json file with metadata as outlined in the Block Registration RFC, which provides a technical specification for block type registration.

The most controversial part of the proposal is having blocks installable from within the Gutenberg editor. The long term goal is to make that process as seamless as possible. Block collections and blocks that do not meet the requirements of the single block directory would still be available via the normal plugin installation process. This could be confusing for users who do not know that blocks can be found in two separate directories.

“The Gutenberg editor should NOT be a plugin installation source,” Matt Cromwell commented on the proposal. “That just seems ripe for scope-creep. That’s not its purpose or function. Let it be an editor, layout builder, content manager, etc. Moving into searching an external library and installing plugins is the definition of losing site of the purpose of a ‘product.'”

Cromwell suggested a centralized block manager as an alternative that would offer a better experience for searching and installing blocks. He also echoed other participants’ opinions on the importance of including dynamic blocks in the directory, instead of limiting it to “JavaScript only” blocks.

“A centralized Block Manager like has already been suggested is a far better user-experience for searching and installing blocks than doing that in the Gutenberg editor. I like the idea of single-block plugins being the only option in the Directory. But make sure Dynamic Blocks that depend on other existing plugins or outside functionality are able to be added to that very important Directory as well. I really don’t see a benefit to limiting this Directory so much.”

WordPress developer Jamie Schmid also expressed hesitation about pursuing a solution that puts block installation inside the editor, as it may discourage users from thinking about their block usage across the entire site.

“I am not convinced that making blocks searchable and installable from within the editor is the best solution,” Schmid said. “This, along with page level block controls and style overrides, is encouraging a very short-sighted, page-level solution to an issue that is very likely a global site (or content or even business) issue. I’d love to instead see a central view for all installed blocks – similar to how plugins are, but more organized by type/function/etc and with a visual alongside. This will encourage making decisions at the site level, encouraging some bigger-picture reflection. And same to being able to apply access controls to the installation of new blocks.”

The proposal would place the single block plugin search interface inside the block inserter in the Gutenberg editor. This would enable users to quickly search for and install a block if they don’t see one they need among the existing blocks.

A mockup of what inline block installation might look like

Riad Benguella, Gutenberg’s technical lead for phase 2, encouraged participants in the discussion to think about blocks as pieces of content that do not rely on the post editor but can be configured anywhere inside WordPress.

“It is important to think of blocks as its own unit that have a meaning on its own, and that can be used in different contexts,” Benguella said. “A block is a piece of content (static or dynamic) that can be configured and rendered anywhere.” This includes blocks found both inside and outside post_content, content in a full site editor, inside the WordPress admin, a headless application, or even another CMS.

“We should be ambitious and think about all these contexts (the final picture), but at the same time we should be pragmatic and iterate to achieve this goal,” Benguella said.

The discussion regarding the new block directory and block plugin architecture continues across WordPress contributor teams. Shiels said the proposal was meant as a starting place and contributors are still in the preliminary stage of exploring ideas.