WordPress.org

Last week, Yext launched its Yext Answers plugin to the WordPress community. The goal was to bring a platform that won the Best Software Innovation category of the 2020 Global Search Awards to WordPress. However, my experience was far from satisfactory.

“For people searching on a WordPress website, the Answers Connector provides a seamless search experience,” said Alexandra Allegra, the Senior Product Marketing Manager at Yext. “For businesses and organizations that integrate it, it drives higher rates of conversion, which generates more revenue. It helps lower support costs because when businesses can deliver detailed, official answers, customers don’t have to call customer service. And finally, it unveils valuable customer insights, because businesses can see new questions coming in — in real-time.”

Yext Answers is essentially trialware. Technically, the plugin itself is free. However, Yext is currently running a 90-day free trial for access to its Answers platform. The website does not seem to provide an easy way to find what the true cost will be after that initial 90 days. To upgrade, users must contact the Yext team via email or phone.

The website does provide an estimated cost calculator. The lowest tier available via this calculator is for 20,000 searches per month at $5,000. It is unclear if there are lower pricing options. The Yext team provided no further details when asked about billing.

The plugin is marketing itself primarily toward business users. It can replace a WordPress site’s traditional search, which is customizable to suit various site owner’s needs, according to the Yext team.

Over the past week, I have discussed this plugin with a representative from the company, watched demo videos, and attempted to test the plugin. Thus far, it has been a subpar experience. I typically forgo writing about plugins that do not pan out. However, after the initial investment into what looked to be an interesting project, I wanted to share my experience, and my hope is that it helps the team build a better product in the long term.

I have yet to get the Yext Answers plugin to work. It requires an account with the Yext website. It also requires that end-users enter multiple fields on the plugin settings screen in WordPress. Unfortunately, after a frustrating amount of searching, I was never able to successfully find all of the correct information or get the information I did have to work. I gave up on the endeavor.

The demo video does show the promise of a somewhat interesting plugin:

Perhaps people who are already familiar with the Yext platform may have better luck. However, I would not recommend it to anyone new, at least in its current state.

There are far better options for connecting via third-party APIs that would be simpler for the average end-user (or even a developer of 15+ years such as myself). The one-click login process provided via the MakeStories plugin, which I covered recently, is a prime example of how to do things right.

We are at a point in the internet era in which end-users should have simple, no-fuss connections between sites. Entering IDs, keys, and other complex fields should be tucked under an “advanced” section of the options screen, not as part of the default experience. Or, they should be so easily available that no one should have trouble finding them.

Launching with Shortcodes Instead of Blocks

Two years after the integration of the block editor into WordPress, the Yext team is launching its Yext Answers plugin with shortcodes, which require manual entrance by end-users. Currently, the plugin does not have block equivalents for its shortcodes.

The team was either unwilling or unable to answer even the most fundamental questions about their decision to use shortcodes rather than launching their plugin — in the year 2020 — with at least block alternatives. At points, they even seemed confused about the subject altogether.

The closest the team came to providing feedback after a lengthy discussion was the following, attributed to Rose Grant, the Associate Product Manager:

We’re looking forward to feedback on the initial release of our plugin before iterating further on it, including introducing custom blocks. For this version of the plugin, we wanted to prioritize supporting clients who are using older versions of WordPress.

Packaging a set of shortcodes within a plugin is still a good practice, even for plugin developers who have transitioned fully to supporting the block editor. It allows them to support users who are still working with the classic editor. However, at this point, developers should be building from a block-first mindset. Blocks do not require that users remember specific shortcode names. They provide instant, visual feedback to users in the editor. And, block options (as opposed to shortcode arguments) do not rely on the oftentimes faulty input of user typing.

At this point, all plugin developers should consider shortcodes a legacy feature and useful only as a backward-compatible option for users on the classic editor.

The Communications Strategist for the company pointed out that this is Yext’s first venture into WordPress plugins and that the team may not be able to provide perspective or commentary on such questions related to blocks and shortcodes. However, this is the third Yext-related plugin associated with the plugin author account on WordPress.org.

Gutenberg 9.2 was released this week and is the last release of the plugin to be rolled into WordPress 5.6. It features the long-awaited video tracks functionality, closing a ticket that has been open for more than two years under development.

Video tracks includes things like subtitles, captions, descriptions, chapters, and metadata. This update introduces a UI for adding video tags, which can contain multiple track elements using the following four attributes:

• srclang (Valid BCP 47 language tag)
• label (Title for player UI)
• kind (Captions, Chapters, Descriptions, Metadata or Subtitles)
• src (URL of the text file)

The ability to edit tracks is exposed in the video block’s toolbar:

This update closes a major gap in video accessibility and greatly improves the user experience of videos.

Gutenberg 9.2 also introduces the ability to transform multiple selected blocks into a Columns block. For example, users can select three image blocks and instantly change them into a three-column section. Columns can be created from any kind of block, including InnerBlocks. The transform option will appear if the number of selected blocks falls between 2-6. (The maximum number is derived from the maximum number of columns allowed by the Columns block.)

Another notable feature in 9.2 is the expansion of Cover blocks to support repeated background patterns. This gives users more flexibility in their designs, opening up a new set of possibilities.

This release brings in more than a dozen improvements to the new Widgets screen, as well as updates to the Query Block and Site Editor experiments. The most notable smaller enhancements to existing features include the following:

• Add dropdown button to view templates in sidebar. (26132)
• Gallery block: Use image caption as fallback for alt text. (26082)
• Table block: Use hooks + API v2. (26065)
• Refactor document actions to handle template part titles. (26043)
• Info panel layout improvement. (26017)
• Remove non-core blocks from default editor content. (25844)
• Add very basic template information dropdown. (25757)
• Rename “Options” modal to “Preferences”. (25683)
• Add single column functionality to the Columns block. (24065)
• Add more writing flow options: Reduced UI, theme styles, spotlight. (22494)
• Add option to make Post Featured Image a link. (25714)

Since the Gutenberg 9.2 release was delayed by a week, it includes many more bug fixes and code quality improvements than most releases. Check out the full changelog for more details.

ESLint, one of the most popular JavaScript linting utilities, quickly eclipsed more established early competitors, thanks to its open source license. The clear licensing enabled the project to become widely used but did not immediately translate into funds for its ongoing development. Despite being  downloaded more than 13 million times each week, its maintainers still struggle to support the utility.

A little over a year since launching ESLint Collective to fund contributors’ efforts, the project’s leadership shared some of the successes and challenges of pursuing the sponsorship model. One effort that didn’t pan out was hiring a dedicated maintainer:

This was a difficult thing for the team to work through, and we think there’s an important lesson about open source sustainability: even though we receive donations, ESLint doesn’t bring in enough to pay maintainers full-time. When that happens, maintainers face a difficult decision: we can try to make part-time development work, but it’s hard to find other part-time work to make up the monthly income we need to make it worthwhile. In some cases, doing the part-time work makes it more difficult to find other work because you are time-constrained in a way that other freelancers are not.

One somewhat successful experiment ESLint explored is paying its five-person Technical Steering Committee (TSC), the project leadership responsible for managing releases, issues, and pull requests. Members receive $50/hour for contributions and time spent on the project, capped at a maximum of $1,000/month. The cap prevents TSC members from spending too much time on the project in addition to their day job so they don’t get burned out.

The team reports that this stipend arrangement has worked “exceedingly well” and contributions have slowly increased: “There is something to be said for paying people for valuable work: when the work is explicitly valued, people are more willing to do it.”

On larger projects like WordPress, corporate contributions are critical to its ongoing development. In recent years, the Five for the Future campaign has helped compensate many contributors as their employers pay them a salary while donating their time to work on WordPress.

Some of the major advancements in WordPress require an immense investment of time and expertise. It’s problem solving that requires working across teams for months to build complex solutions that will work for millions of users. That’s why you don’t see armies of people building Gutenberg for free. Much of the development is driven by paid employees and might not otherwise have happened without corporate donations of employee time. Automattic, Google, Yoast SEO, 10up, GoDaddy, Human Made, WebDevStudios, WP Engine, and many other companies have collectively pledged thousands of hours worth of labor per month. The diversity of companies and individuals supporting WordPress helps the project maintain stability and weather the storms of life better.

Smaller open source projects like ESLint rarely have the same resources at their disposal and have to experiment. Summarizing the one-year review of paying contributors from sponsorships, the team states: “Maintaining a project like ESLint takes a lot of work and a lot of contributions from a lot of people. The only way for that to continue is to pay people for their time.”

When even the most popular utilities struggle to gain enough sponsorships, what hope is there for smaller projects? Many utilities that have become indispensable in developers’ workflows are on a trajectory towards becoming unsustainable.

“Unfortunately, utilities like these rarely bring in any meaningful amount of money from donations, no matter how widely used or beloved they are,” OSS engineer Colin McDonnell said in his proposal for a new funding model. “Consider react-router. Even with 41.3k stars on GitHub, 3M weekly downloads from NPM, and nearly universal adoption in React-based single-page applications, it only brings in ~$17k of donations annually.”

McDonnell proposed the concept of “sponsor pools,” to fund smaller projects that are unable to benefit from existing open-source funding models. Instead of making donations on a per-project basis, open source supporters could donate a set amount into a “wallet” every month and then distribute those funds to projects they select for their sponsor pools. The key part of the implementation is that adding new projects to the pool should only take one click, reducing the psychological friction associated with supporting additional projects.

McDonnell suggested that GitHub is the only organization with the infrastructure to implement this model as an extension of GitHub Sponsors. One commenter on Hacker News proposes that Sponsors and the idea of “sponsors pool” could exist in parallel.

“I believe that there’s a meaningful difference between being the patron of a developer and feeling like you’re backing a creator with feelings and a story and a family… and wanting to be a good citizen that has an approved list of projects that I benefit from and want to support,” Pete Forde said.

“I can sponsor Matz, get his updates and feel good about knowing I am counted as a supporter AND set aside $$$ per month to contribute to all of the tools I use in my projects simply because it’s the right thing to do and I want those projects to exist for the long term. They are completely different initiatives. Patreon vs Humble Bundle, if you will.”

Tidelift is another concept that was highlighted in the HN discussion. It has a different, unique approach to funding open source work. Tidelift pools funds from the organizations using the software to support the maintainers.

“I maintain ruby grape, a mid-sized project,” Daniel Doubrovkine said. “We get $144/month from Tidelift. As more companies signup for corporate sponsorship the dollar amount increases. It’s a pool.”

Snowdrift takes a more unusual approach to pooling sponsorships where patrons “crowdmatch” each others donations to fund public goods. It runs as a non-profit co-op to fund free and open projects that serve the public interest.

Flossbank is more specifically targeted at funding open source projects and takes technical approach to ensuring equitable contributions to the the entire dependency tree of your installed open source packages. The organization claims to provide “a free and frictionless” way to give back to maintainers. Developers can opt into curated, tech-focused ads in the terminal when installing open source packages. As an alternative, they can set a monthly donation amount to be spread across the packages they install.

No single funding model is suitable for all projects but the experiments that pool sponsorships in various ways seem to be trending, especially for supporting maintainers who may not be as skilled in marketing their efforts. The conversation around supporting utilities continues on Hacker News. WordPress developers who depend on some of these utilities may want to join in and share their experiences in funding small projects.

Version 4.1.7 of the Akismet plugin for WordPress is now available. It contains the following changes:

• Stops using the deprecated wp_blacklist_check function in favor of the new wp_check_comment_disallowed_list function.
• Shows the “Set Up Akismet” banner on the comments dashboard page, where it’s appropriate to mention if Akismet has not yet been configured.
• Miscellaneous text changes.

To upgrade, visit the Updates page of your WordPress dashboard and follow the instructions. If you need to download the plugin zip file directly, links to all versions are available in the WordPress plugins directory.

Q WordPress theme screenshot.

Themes Team representative Ari Stathopoulos is now officially the first theme author to have a theme in the directory that supports full-site editing (FSE). With a slimmed-down beta release of FSE shipping in WordPress 5.6 this December, someone had to be the first to take the plunge. It made sense for someone intimately familiar with theme development and the directory guidelines to step up.

In many ways, it is a huge responsibility that Stathopoulos has taken on. Until one of the default Twenty* themes handles FSE, the Q theme will likely be one of the primary examples that other theme authors will follow as they begin learning how to build block-based themes.

Earlier this month, I used Q to test FSE and determine how much it had advanced. It is at least months away from being ready for use in production. The beta release in 5.6 is more or less just to get more people testing.

Stathopoulos has no plans to make Q much more than a bare-bones starter or experimental theme. It is almost a playground to see what is possible.

“Q was born out of necessity,” he said. “I couldn’t work on full-site editing or global styles without having a base theme for them, so for a while, I had it in a GitHub repository. I decided to release it to the WordPress.org repository because I think I might not be the only one with those issues. Downloading a theme in the dashboard is easier than cloning a repository for most people.”

Existing block-based themes are few and far between. Automattic and some of its employees have some experimental projects, but none of those are in the official directory for anyone to test. Stathopoulos wanted a base theme that was unopinionated in terms of design that would allow him to work on FSE, test pull requests, and experiment with various ideas.

“It has some ideas for things that ultimately I’d like to see implemented in FSE, and it’s a playground,” he said. “For example, the addition of a skip-link for accessibility in the theme, an implementation for responsive/adaptive typography, and conditional loading of block styles only when they are used/needed. These are things that I hope will be part of WordPress Core at some point, and the Q theme explores ideas on how to implement them.”

He began work on the theme over a year ago and continues working on it as a side project. He said Yoast, his employer, fully supports the idea of creating things that are beneficial for other theme designers and WordPress core.

Developing an FSE-Capable Theme

Editing the Q theme single post template in the site editor.

End-users must install the Gutenberg plugin and activate the experimental FSE feature to use the theme or any similar theme. Currently, FSE is missing many key features that make it viable for most real-world projects. However, theme developers who plan to work with WordPress over the next several years will need to begin testing and experimenting. Q makes for a good starting point to simply get a feel for what themes will look like.

“The biggest issue was — and still is — keeping up with Gutenberg development,” said Stathopoulos. “Many things are currently fluid, and they happen at a very high pace. The reason I created the theme was because other themes I was testing, as part of my contribution to the Themes Team, were not properly maintained or updated. I wanted to create a starter theme that can be used as a starting point for others as well.”

One of the biggest questions still hanging in the air is what the timeline will look like for publicly-available, block-based themes. Will 2021 be the year they take over? That is unlikely given the feature’s current state. However, there will be a point where developers are no longer building classic or traditional themes.

“I think we’re going to see a lot more FSE themes in 2021,” said Stathopoulos. “It might take a couple of years before they become the standard, but after the release of WordPress 5.6, I hope there will be a lot more development and focus on FSE and global styles. Whether we see more FSE themes or not depends on when some things get merged in WordPress core.”

He pointed out some critical missing features from Gutenberg at the moment. The big one is that the Query block, which is the block that displays posts on the front end, does not inherit its options from the global query. Essentially, this means that, regardless of what URL a visitor is on, it displays the latest posts.

“Once these things are addressed, and blockers for theme builders get resolved, I expect we’ll see an explosion of good FSE themes being built,” he said.

Stathopoulos is most excited about the prospect of seeing more design standards come to core. Currently, there is no consistency between themes. Theme authors can use any markup they want. Switching themes affects a site’s structure, SEO, accessibility, speed, and many other things.

“My advice to theme developers who want to start tinkering would be to start with something simple,” he said. “It’s tempting to add extremely opinionated styles, for buttons for example, but more and more things get added every day to the editor like a border-radius setting for buttons. Theme authors should avoid the trap of designing an FSE theme having in mind what the editor currently does. Instead, theme authors should strive to build something having in mind a vision of what the editor will eventually become.”

The Future of Theme Reviews

Because Stathopoulos is a representative of the Themes Team, he also has some insight into the shift in the coming years for guidelines and what steps authors might need to take. While it is too early for the team to begin making decisions, its members are already thinking about forthcoming changes.

“Change is always difficult, especially when it’s for something this big,” said Stathopoulos. “It will be a bumpy ride, and it will take time. WordPress theming is a huge industry. For a while, ‘classic’ (for lack of a better word) themes will continue to be a viable solution for theme developers who didn’t have time to catch up. But not forever.”

Some may look back at previous major shifts and worry about what the future theme directory guidelines may ask. In 2015, the team required all theme options to use the customizer. This was after a three-year wait for theme authors to organically make the switch. Given that FSE will be a much larger departure from norms and dislike of the Gutenberg project from segments of the development community, it could be a rough transition.

“At some point, FSE themes will become the industry standard and what the users want,” said Stathopoulos. “Personally, I hope no one will want to upload a classic theme in the w.org repository in 2025 when the industry has moved on. It would be like uploading today a theme that is using tables and iframes for layouts.”

He said that sufficient time would be given for the eventual transition. However, the team will likely prioritize FSE-based themes. They are cognizant of how much of a shift this will be and will plan accordingly when the time comes.

WordPress.org has pushed out a forced security update for the Loginizer plugin, which is active on more than 1 million websites. The plugin offers brute force protection in its free version, along with other security features like two-factor auth, reCAPTCHA, and PasswordLess login in its commercial upgrade.

Last week security researcher Slavco Mihajloski discovered an unauthenticated SQL injection vulnerability, and an XSS vulnerability, that he disclosed to the plugin’s authors. Loginizer version 1.6.4 was released on October 16, 2020, with patches for the two issues, summarized on the plugin’s blog:

1) [Security Fix] : A properly crafted username used to login could lead to SQL injection. This has been fixed by using the prepare function in PHP which prepares the SQL query for safe execution.

2) [Security Fix] : If the IP HTTP header was modified to have a null byte it could lead to stored XSS. This has been fixed by properly sanitizing the IP HTTP header before using the same.

Loginizer did not disclose the vulnerability until today in order to give users the time to upgrade. Given the severity of the vulnerability, the plugins team at WordPress.org pushed out the security update to all sites running Loginizer on WordPress 3.7+.

In July, 2020, Loginizer was acquired by Softaculous, so the company was also able to automatically upgrade any WordPress installations with Loginizer that had been created using Softaculous. This effort, combined with the updates from WordPress.org, covered a large portion of Loginizer’s user base.

The automatic update took some of the plugin’s users by surprise, since they had not initiated it themselves and had not activated automatic updates for plugins. After several users posted on the plugin’s support forum, plugin team member Samuel Wood said that “WordPress.org has the ability to turn on auto-updates for security issues in plugins” and has used this capability many times.

Mihajloski published a more detailed proof-of-concept on his blog earlier today. He also highlighted some concerns regarding the systems WordPress has in place that allowed this kind of of severe vulnerability to slip through the cracks. He claims the issue could have easily been prevented by the plugin review team since the plugin wasn’t using the prepare function for safe execution of SQL queries. Mihajloski also recommended recurring code audits for plugins in the official directory.

“When a plugin gets into the repository, it must be reviewed, but when is it reviewed again?” Mihajloski said. “Everyone starts with 0 active installs, but what happens on 1k, 10k, 50k, 100k, 500k, 1mil+ active installs?”

Mihajloski was at puzzled how such a glaring security issue could remain in the plugin’s code so long, given that it is a security plugin with an active install count that is more than many well known CMS’s. The plugin also recently changed hands when it was acquired by Softaculus and had been audited by multiple security organizations, including WPSec and Dewhurst Security.

Mihajloski also recommends that WordPress improve the transparency around security, as some site owners and closed communities may not be comfortable with having their assets administered by unknown people at WordPress.org.

“WordPress.org in general is transparent, but there isn’t any statement or document about who, how and when decides about and performs automatic updates,” Mihajloski said. “It is kind of [like] holding all your eggs in one basket.

“I think those are the crucial points that WP.org should focus on and everything will came into place in a short time: complete WordPress tech documentation for security warnings, a guide for disclosure of the bugs (from researchers, but also from a vendor aspect), and recurring code audits for popular plugins.”

David Bisset interviews Joe Casabona, an independent creator and teacher, and discusses what it's like to be a creator as his job, plus some news topics.

Links

• W3C drops WordPress from consideration for its redesign
• W3c selects Craft and selection report
• Disabling full screen mode
• Creator Courses
• How I Built It recording notes
• Camo

Partner: Sandhills Development

Sandhills Development crafts ingenuity, developed with care:

• Easy Digital Downloads – Sell digital products with WordPress
• AffiliateWP – A full-featured affiliate marketing solution
• Sugar Calendar – WordPress event management made simple
• WP Simple Pay – A lightweight Stripe payments plugin

Recipe slide from the MakeStories WordPress plugin.

Earlier today, MakeStories launched version 2.0 of its plugin for creating Web Stories with WordPress. In many ways, this is a new plugin launch. The previous version simply allowed users to connect their WordPress installs to the MakeStories site. With the new version, users can build and edit their stories directly from the WordPress admin.

Version 2.0 of the plugin still requires an account and a connection with the MakeStories.io website. However, it is simple to set up. Users can log in without leaving their WordPress admin interface. This API connection means that user-created Stories are stored on the MakeStories servers. If an end-user wanted to jump platforms from WordPress to something else, this would allow them to take their Stories with them.

“One of the things we would like to assure is your content is still yours, and none of the user data is being consumed or analyzed by us,” said Pratik Ghela, the founder and product manager at MakeStories. “We only take enough data to help serve you better.”

The plugin is a competing solution to the official Web Stories plugin by Google. While the two share similarities in the final output (they are built to utilize the same front-end format for creating Stories on the web), they take different paths to get there.

The two share similarities on the backend too. However, MakeStories may be more polished in some areas. For example, it allows users to zoom in on the small canvas area. Having the ability to reorder slides from the grid view also feels more intuitive.

“The main unique selling proposition of our plugin is that it comes with a guarantee of the MakeStories team,” said Ghela. “We as a team have been building this for over two years, and we are proud to be one of the tools that has stood the test of time, and competition and is still growing at a very fast pace.”

The team also wants to make the Story-creating process faster, safer, and rewarding. The goal is to cater to designers, developers, and content creators. Ghela also feels like his team’s support turnaround time of a few hours will be the key to success and is a good reason for users to give this plugin a try before settling on something else.

“We feel that our goal is to see Web Stories flourish,” he said. “And we may have different types of users looking out for various options. So, the official plugin from Google and the one from MakeStories at least opens up the options for users to choose from. And we feel that the folks at Google are also building a great editor, and, at the end of the day, it’s up to the user to select what they feel is the best.

Technically, MakeStories is a SaaS (software as a service) product. Even though it is a free plugin, there will eventually be a commercial component to it. Currently, it is free at least until the first quarter of 2021, which may be extended based on various factors. There is no word on what pricing tiers may be available after that.

“There will always be a free tier, and we have always stood for it that your data belongs to you,” said Ghela. “In case you do not like the pricing, we will personally assist you to port out from using our editor and still keep the data and everything totally intact.”

Diving Into the Plugin

Story management screen.

MakeStories is a drag-and-drop editor for building Web Stories. It works and feels much like typical design editors like Gimp or Photoshop. It shares similarities with QuarkXPress or InDesign, for those familiar with page layout programs. In some ways, it feels a lot like a light-colored version of Google’s Web Stories plugin with more features and a slightly more intuitive interface.

The end goal is simple: create a Story through designing slides/pages that site visitors will click through as the narrative unfolds.

The plugin provides a plethora of shapes, textures, and animations. These features are easy to find and implement. It also includes free access to images, GIFs, and videos. These are made possible via API integrations with Unsplash, Tenor, and Pexels.

MakeStories includes access to 10 templates at the moment. However, what makes this feature stand out is that end-users can create and save custom templates for reuse down the road.

Editing a Story from a predesigned template.

One of the more interesting, almost hidden, features is the available text patterns. The plugin allows users to insert these patterns from a couple of dozen choices. This makes it easier to visualize a design without having to build everything from scratch.

Inserting a text pattern and adjusting its size.

While the editing process is a carefully-crafted experience that makes the plugin worth a look, it is the actual publishing aspect of the workflow that is a bit painful. Traditional publishing in WordPress means hitting the “publish” button to make content live. This is not the case with the MakeStories plugin. It takes you through a four-step process of entering various publisher details, setting up metadata and SEO, validating the Story content, and analytics. It is not that these steps are necessarily bad. For example, MakeStories lets you know when images are missing alt text, which is needed information screen readers. The problem is that it feels out of place to go through all of these details when I, as a user, simply want my content published. And, many of these details, such as the publisher (author), should be automatically filled in.

Updating a Story is not as simple as hitting an “update” button either. The system needs to run through some of the same steps too.

Ghela said the publishing process might be a bit tough but will prove fruitful in the end. The plugin takes care of the technical aspects of adding title tags, meta, and other data on the front end after the user fills in the form fields.

“We will definitely work on improving the flow as the community evolves and improve it a lot to be easier, faster, and, most importantly, still very customizable,” he said.

The MakeStories team has no plans of stopping at its current point on the roadmap. Ghela sounded excited about some of the upcoming additions they are planning, including features like teams, branding, easy template customization, polls, and quizzes.

On the Web Stories Format

UN report on COVID-19 and poverty published with MakeStories.

Many will ultimately hesitate to use any plugin that implements Web Stories given Google’s history of dropping projects. There is also a feeling that the format is a bit of a fad and will not stand the test of time.

“We greatly believe in AMP and Web Stories as a content format,” said Ghela. “We, as an agency, have been involved a lot in AMP and have done a lot of experiments with it, including a totally custom WooCommerce site in fully-native, valid AMP with support for variable products, subscriptions, and other functionalities.”

The company is all-in on the format and feels like it will be around for the long term, particularly if there is a good ecosystem around monetization.

“We think that the initial reactions are because there are not enough proven results and because we never imagined the story format to come to the web,” said Ghela. “There were definitely plugins that did this. Few folks tried to build stories using good ol’ HTML, CSS, and JavaScript. But, the performance and UX were not that great. On the other hand, the engineers at the AMP Team are making sure that everything is just perfect. The UX, load time, WCV Score, just everything.”

He feels that some of the early criticisms are unwarranted and that the web development community should give the format a try and provide feedback.

“The more data we all get, actually gives the AMP team a clear idea of what’s needed, and they can design the roadmap accordingly,” he said. “So, just giving out early reactions won’t help, but constructive criticism and getting back to the AMP team with what you are doing will.”

WordPress 5.6 Beta 1 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:

• Try the WordPress Beta Tester plugin (choose the “bleeding edge nightlies” option).
• Or download the beta here (zip).

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

Improvements in the Editor

WordPress 5.6 includes seven Gutenberg plugin releases. Here are a few highlighted enhancements:

• Improved support for video positioning in cover blocks.
• Enhancements to Block Patterns including translatable strings.
• Character counts in the information panel, improved keyboard navigation, and other adjustments to help users find their way better.
• Improved UI for drag and drop functionality, as well as block movers.

To see all of the features for each release in detail check out the release posts: 8.6, 8.7, 8.8, 8.9, 9.0, 9.1, and 9.2 (link forthcoming).

Improvements in Core

A new default theme

The default theme is making its annual return with Twenty Twenty-One. This theme features a streamlined and elegant design, which aims to be AAA ready.

Auto-update option for major releases

The much anticipated opt-in for major releases of WordPress Core will ship in this release. With this functionality, you can elect to have major releases of the WordPress software update in the background with no additional fuss for your users.

Increased support for PHP 8

The next major version release of PHP, 8.0.0, is scheduled for release just a few days prior to WordPress 5.6. The WordPress project has a long history of being compatible with new versions of PHP as soon as possible, and this release is no different.

Because PHP 8 is a major version release, changes that break backward compatibility or compatibility for various APIs are allowed. Contributors have been hard at work fixing the known incompatibilities with PHP 8 in WordPress during the 5.6 release cycle.

While all of the detectable issues in WordPress can be fixed, you will need to verify that all of your plugins and themes are also compatible with PHP 8 prior to upgrading. Keep an eye on the Making WordPress Core blog in the coming weeks for more detailed information about what to look for.

Application Passwords for REST API Authentication

Since the REST API was merged into Core, only cookie & nonce based authentication has been available (without the use of a plugin). This authentication method can be a frustrating experience for developers, often limiting how applications can interact with protected endpoints.

With the introduction of Application Password in WordPress 5.6, gone is this frustration and the need to jump through hoops to re-authenticate when cookies expire. But don’t worry, cookie and nonce authentication will remain in WordPress as-is if you’re not ready to change.

Application Passwords are user specific, making it easy to grant or revoke access to specific users or applications (individually or wholesale). Because information like “Last Used” is logged, it’s also easy to track down inactive credentials or bad actors from unexpected locations.

Better accessibility

With every release, WordPress works hard to improve accessibility. Version 5.6 is no exception and will ship with a number of accessibility fixes and enhancements. Take a look:

• Announce block selection changes manually on windows.
• Avoid focusing the block selection button on each render.
• Avoid rendering the clipboard textarea inside the button
• Fix dropdown menu focus loss when using arrow keys with Safari and Voiceover
• Fix dragging multiple blocks downwards, which resulted in blocks inserted in wrong position.
• Fix incorrect aria description in the Block List View.
• Add arrow navigation in Preview menu.
• Prevent links from being focusable inside the Disabled component.

How You Can Help

Keep your eyes on the Make WordPress Core blog for 5.6-related developer notes in the coming weeks, breaking down these and other changes in greater detail.

So far, contributors have fixed 188 tickets in WordPress 5.6, including 82 new features and enhancements, and more bug fixes are on the way.

Do some testing!

Testing for bugs is an important part of polishing the release during the beta stage and a great way to contribute.

If you think you’ve found a bug, please post 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, file one on WordPress Trac. That’s also where you can find a list of known bugs.

Props to @webcommsat, @yvettesonneveld, @estelaris, @cguntur, @desrosj, and @marybaum for editing/proof reading this post, and @davidbaumwald for final review.

Current block-based widgets admin screen design.

I was wrong. I assured our readers that “the block-based widget system will be ready for prime time when WordPress 5.6 lands” in my previous post on the new feature’s readiness. I also said that was on the condition of not trying to make it work with the customizer — that experience was still broken. However, the 5.6 team pulled the plug on block-based widgets for the second time this year.

One week ago, WordPress 5.6 release lead Josepha Haden seemed to agree that it would be ready. However, things can change quickly in a development cycle, and tough decisions have to be made with beta release deadlines.

This is not the first feature the team has punted to a future release. Two weeks ago, they dropped block-based nav menus from the 5.6 feature list. Both features were originally planned for WordPress 5.5.

A new Widgets admin screen has been under development since January 2019, which was not long after the initial launch of the block editor in WordPress 5.0. For now, the block-based widgets feature has been punted to WordPress 5.7. It has also been given the “early” tag, which means it should go into core WordPress soon after the 5.7 release cycle begins. This will give it more time to mature and more people an opportunity to test it.

Helen Hou-Sandì, the core tech lead for 5.6, provided a historical account of the decision and why it was not ready for inclusion in the new ticket:

My question for features that affect the front-end is “can I try out this new thing without the penalty of messing up my site?” — that is, user trust. At this current moment, given that widget areas are not displayed anything like what you see on your site without themes really putting effort into it and that you have to save your changes live without revisions to get an actual contextual view, widget area blocks do not allow you to try this new feature without penalizing you for experimenting.

She went on to say that the current experience is subpar at the moment. Problems related to the customizer experience, which I covered in detail over a month ago, were also mentioned.

“So, when we come back to this again, let’s keep sight of what it means to keep users feeling secure that they can get their site looking the way they want with WordPress, and not like they are having to work around what we’ve given them,” said Hou-Sandì.

This is a hopeful outlook despite the tough decision. Sometimes, these types of calls need to be made for the good of the project in the long term. Pushing back a feature to a future version for a better user experience can be better than launching early with a subpar experience.

“The good part of this is that now widgets can continue to be ‘re-imagined’ for 5.7, and get even more enhancements,” said lead WordPress developer Andrew Ozz in the ticket. “Not sure how many people have tested this for a bit longer but having blocks in the widgets areas (a.k.a. sidebars) opens up many new possibilities and makes a lot of the old, limited widgets obsolete. The ‘widget areas’ become something like ‘specialized posts with more dynamic content,’ letting users (and designers) do a lot of stuff that was either hard or impossible with the old widgets.”

After the letdown of seeing one of my most anticipated features of 5.6 being dropped, it is encouraging to see the positive outlook from community leaders on the project.

“You know, I was really hopeful for it too, and that last-minute call was one I labored over,” said Haden. “When I last looked, it did seem close to ready, but then more focused testing was done and there were some interactions that are a little rough for users. I’m grateful for that because the time to discover painful user experiences is before launch rather than after!”

Despite dropping its second major feature, WordPress 5.6 still has some big highlights that will be shipping in less than two months. The new Twenty Twenty-One theme looks to be a breath of fresh air and will explore block-related features not seen in previous default themes. Haden also pointed out auto-updates for major releases, application passwords support for the REST API, and accessibility improvements as features to look forward to.

WordPress 5.6 Beta 1 is expected to ship today.

Adding New Features To an Old Project

At times, it feels like the Gutenberg project has bitten off more than it can chew. Many of the big feature plans continually miss projections. Between full-site editing, global styles, widgets, nav menus, and much more, it is tough to get hyper-focused on one feature and have it ready to ship. On the other hand, too much focus one way can be to the detriment to other features in the long run. All of these pieces must eventually come together to create a more cohesive whole.

WordPress is also 17 years old. Any new feature could affect legacy features or code. The goal for block-based widgets is to transition an existing feature to work within a new system without breaking millions of websites in the process. Twenty-one months of work on a single feature shows that it is not an easy problem to solve.

“You are so right about complex engineering problems!” said Haden. “We are now at a point in the history of the project where connecting all of the pieces can have us facing unforeseen complications.”

The project also needs to think about how it can address some of the issues it has faced with not quite getting major features to completion. Is the team stretched too thin to focus on all the parts? Are there areas we can improve to push features forward?

“There will be a retrospective where we can identify what parts of our process can be improved in the future, but I also feel like setting stretch goals is good for any software project,” said Haden. “Many contributors have a sense of urgency around bringing the power of blocks to more spaces in WordPress, which I share, but when it’s time to ship, we have to balance that with our deep commitment to usability.”

One problem that has become increasingly obvious is that front-end editing has become tougher over the years. Currently, widgets and nav menus can be edited in two places in WordPress with wildly different interfaces. Full-site editing stands to add an entirely new interface to the mix.

“I think one of the problems that we’re trying to solve with Gutenberg has always been a more consistent experience for editing elements across the WordPress interface,” said Haden. “No user should have to learn five different workflows to make sure their page looks the way they imagined it when it’s published.”

In the meantime, which may be numbered in years, end-users will likely have these multiple interfaces to deal with — overlap while new features are being developed. This may simply be a necessary growing pain of an aging project, one that is trying to lead the pack of hungry competitors in the CMS space.

“There’s a lot of interest in reducing the number of workflows, and I’m hopeful that we can consolidate down to just one beautiful, intuitive interface,” said Haden.

Instagram’s checkout feature, which allows users to purchase products without leaving the app, has become an even more important part of Facebook’s long-term investment in e-commerce now that the pandemic has so heavily skewed consumer behavior towards online shopping. When Instagram introduced checkout in 2019, it reported that 130 million users were tapping to reveal product tags in shopping posts every month.

image credit: Instagram

Business owners who operate an existing store can extend their audience to Instagram by funneling orders from the social network into their own stores, without shoppers having to leave Instagram. Checkout supports integration with several e-commerce platform partners, including Shopify and BigCommerce, and will soon be available for WooCommerce merchants.

WooCommerce is testing a new Instagram Shopping Checkout feature for its Facebook for WooCommerce plugin. The free extension is used on more than 900,000 websites and will provide the bridge for store owners who want to tap into Instagram’s market. The checkout capabilities are currently in closed beta. Anyone interested to test the feature can sign up for consideration. Businesses registered in the USA that meet certain other requirements may be selected to participate, and the beta is also expanding to other regions soon.

WooCommerce currently supports shoppable posts, which are essentially products sourced from a product catalog created on Facebook that are then linked to the live store through an Instagram business account. Instagram’s checkout takes it one step further to provide a native checkout experience inside the app. Merchants pay no selling fees until December 31, 2020. After that time, the fee is 5% per shipment or a flat fee of $0.40 for shipments of $8.00 or less. 

On the customer side, shoppers only have to enter their information once and thereafter it is stored for future Instagram purchases. Instagram also pushes shipment and delivery notifications inside the app. Store owners will need to weigh whether the convenience of the in-app checkout experience is worth forking over 5% to Facebook, or if they prefer funneling users over to the live store instead.

Instagram Shopping Checkout is coming to WooCommerce in the near future but the company has not yet announced a launch date, as the feature is just now entering closed beta.

Mel Choyce-Dwan, the Default Theme Design Lead for WordPress 5.6, kick-started 10 tickets around two months ago that would bring new features to the old default WordPress themes. The proposal is to add unique block patterns, a feature added to WordPress 5.5, to all of the previous 10 Twenty* themes. It is a lofty goal that could breathe some new life into old work from the previous decade.

Currently, only the last four themes are marked for an update by the time WordPress 5.6 lands. Previous themes are on the list to receive their block patterns in a future release. For developers and designers interested in getting involved, the following is a list of the Trac tickets for each theme:

• Twenty Twenty – 5.6
• Twenty Nineteen – 5.6
• Twenty Seventeen – 5.6
• Twenty Sixteen – 5.6
• Twenty Fifteen – Future release
• Twenty Fourteen – Future release
• Twenty Thirteen – Future release
• Twenty Twelve – Future release
• Twenty Eleven – Future release
• Twenty Ten – Future release

If you are wondering where Twenty Eighteen is in that list, that theme does not actually exist. It is the one missing year the WordPress community has had since the one-default-theme-per-year era began with Twenty Ten. It is easy to forget that we did not get a new theme for the 2017-2018 season. With all that has happened in the world this year, we should count ourselves fortunate to see a new default theme land for WordPress this December. WordPress updates and its upcoming default theme are at least one consistency that we have had in an otherwise chaotic time.

More than anything, it is nice to see some work going toward older themes — not just in terms of bug fixes but feature updates. The older defaults are still a part of the face of WordPress. Twenty Twenty and Twenty Seventeen each have over one million active installs. Twenty Nineteen has over half a million. The other default themes also have significant user bases in the hundreds of thousands — still some of the most-used themes in the directory. We owe it to those themes’ users to keep them fresh, at least as long as they maintain such levels of popularity.

This is where the massive theme development community could pitch in. Do some testing of the existing patches. Write some code for missing patterns or introduce new ideas. This is the sort of low-hanging fruit that almost anyone could take some time to help with.

First Look at the New Patterns

None of the proposed patterns have landed in trunk, the development version of WordPress, yet. However, several people have created mockups or added patches that could be committed soon.

One of my favorite patterns to emerge thus far is from Beatriz Fialho for the Twenty Nineteen theme. Fialho has created many of the pattern designs proposed thus far, but this one, in particular, stands out the most. It is a simple two-column, two-row pattern with a circular image, heading, and paragraph for each section. Its simplicity fits in well with the more elegant, business-friendly look of the Twenty Nineteen theme.

Services pattern for Twenty Nineteen.

It is also fitting that Twenty Nineteen get a nice refresh with new patterns because it was the default theme to launch with the block editor. Ideally, it would continually be updated to showcase block-related features.

While many people will focus on some of the more recent default themes, perhaps the most interesting one is a bit more dated. Twenty Thirteen was meant to showcase the new post formats feature in WordPress 3.6. According to Joen Asmussen, the theme’s primary designer, the original idea was for users to compose a ribbon of alternating colors as each post varied its colors.

“The alternating ribbon of colors did not really come to pass because post formats were simply not used enough to create an interesting ribbon,” he wrote in the Twenty Thirteen ticket. “However, perhaps for block patterns, we have an opportunity to revisit those alternating ribbons of colors. In other words, I’d love to see those warm bold colors used in big swathes that take up the whole pattern background.”

Patterns designed to match post formats.

This could be a fun update for end-users who are still using that feature that shall not be named post formats.

There is a lot to like about many of the pattern mockups so far. I look forward to seeing what lands along with WordPress 5.6 and in future updates.

Establishing Pattern Category Standard

With the more recent Twenty Twenty-One theme’s block patterns and the new patterns being added to some of the older default themes, it looks like a specific pattern category naming scheme is starting to become a standard. Of the patches thus far, each is creating a new pattern category named after the theme itself.

This makes sense. Allowing users to find all of their theme’s patterns in one location means that they can differentiate between them and those from core or other plugins. Third-party theme authors should follow suit and stick with this convention for the same reason.

Developers can also define multiple categories for a single pattern. This allows theme authors to create a category that houses all of their patterns in one location. However, they can also split them into more appropriate context-specific categories for discoverability.

BuddyPress 7.0.0-beta1 is now available for testing!

Please note the plugin is still in development, so we recommend running this beta release on a testing site.

You can test BuddyPress 7.0.0-beta1 in 4 ways :

• Try the BP Beta Tester plugin.
• Download the beta here (zip file).
• Check out our SVN repository: svn co https://buddypress.svn.wordpress.org/trunk/
• Clone our read-only Git repository: git clone git://buddypress.git.wordpress.org/

The 7.0.0 stable release is slated to the beginning of December, and we’d love you to give us a hand to get there!

Please note BuddyPress 7.0.0 will require at least WordPress 4.9.

Testing for bugs is an important part of polishing the release during the beta stage and a great way to contribute. Here are some of the big changes and features to pay close attention to while testing (Check out this report on Trac for the full list).

New Administration screens to manage BuddyPress types

In BuddyPress 7.0.0 site administrators will be able to add, edit or delete Member & Group types using their WordPress Administration Screens just like they would do for Post tags.

Read this development note to learn more about it.

Let’s welcome 3 new BP Blocks into our Block Editor

• The Activity Embed block let authors embed an activity into their post or page.
• Use the BP Members block to select community users you want to feature into a post or a page.
• Enjoy the BP Groups block to pick the groups you want to highlight into a post or a page.

Get to know these new blocks reading this development note.

Improved support for WP CLI

WP-CLI is the command-line interface for WordPress. You can update plugins, configure multisite installs, and much more, without using a web browser. In 7.0.0, you will be able to Enjoy new BuddyPress CLI commands to manage BuddyPress Group Meta, BuddyPress Activity Meta, activate or deactivate the BuddyPress signup feature and create BuddyPress specific testing code for plugins.

Discover more about it from this development note.

And so much more such as improvements to the BP REST API, our Template pack, images and iframes lazy loading support…

How You Can Help

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

If you think you’ve found a bug, you can post in the support forums. We’d love to hear from you! If you’re comfortable writing a reproducible bug report, file one on BuddyPress Trac.

Web Stories dashboard screen in WordPress.

What comes as a surprise to few, Google has updated its content guidelines for its Web Stories format. For users of its recently-released Web Stories for WordPress plugin, they will want to follow the extended rules for their Stories to appear in the “richer experiences” across Google’s services. This includes the grid view on Search, Google Images, and Google Discover’s carousel.

Google released its Web Stories plugin in late September to the WordPress community. It is a drag-and-drop editor that allows end-users to create custom Stories from a custom screen in their WordPress admin.

The plugin does not directly link to Google’s content guidelines anywhere. For users who do not do a little digging, they may be caught unaware if their stories are not surfaced in various Google services.

On top of the Discover and Webmaster guidelines, Web Stories have six additional restrictions related to the following:

• Copyrighted content
• Text-heavy Web Stories
• Low-quality assets
• Lack of narrative
• Incomplete stories
• Overly commercial

While not using copyrighted content is one of those reasonably-obvious guidelines, the others could trip up some users. Because Stories are meant to represent bite-sized bits of information on each page, they may become ineligible if most pages have more than 180 words of text. Videos should also be limited to fewer than 60 seconds on each page.

Low-quality media could be a flag for Stories too. Google’s guidelines point toward “stretched out or pixelated” media that negatively impacts the reader’s experience. They do not offer any specific resolution guidelines, but this should mostly be a non-issue today. The opposite issue is far more likely — users uploading media that is too large and not optimized for viewing on the web.

The “lack of narrative” guideline is perhaps the vaguest, and it is unclear how Google will monitor or police narrative. However, the Stories format is about storytelling.

“Stories are the key here imo,” wrote Jamie Marsland, founder of Pootlepress, in a Twitter thread. “Now we have an open format to tell Stories, and we have an open platform (WordPress) where those Stories can be told easily.”

Google specifically states that Stories need a “binding theme or narrative structure” from one page to the next. Essentially, the company is telling users to use the format for the purpose it was created for. They also do not want users to create incomplete stories where readers must click a link to finish the Story or get information.

CNN’s Web Story on Remembering John Lennon.

Overly commercial Stories are frowned upon too. While Google will allow affiliate marketing links, they should be restricted to a minor part of the experience.

Closing his Twitter thread, Marsland seemed to hit the point. “I’ve seen some initial Google Web Stories where the platform is being used as a replacement for a brochure or website,” he wrote. “In my view that’s a huge missed opportunity. If I was advising brands I would say ‘Tell Stories’ this is a platform for Story Telling.”

If users of the plugin follow this advice, their Stories should surface on Google’s rich search experiences.

The big news in the world of e-commerce today is Stripe’s acquisition of Paystack, a Nigeria-based payments system that is widely used throughout African markets. The company, which became informally known as “the Stripe of Africa” picked up $8 million in Series A funding in 2018, led by Stripe, Y Combinator, and Tencent. Paystack has grown to power more than 60,000 businesses, including FedEx, UPS, MTN, the Lagos Internal Revenue Service, and AXA Mansar.

Stripe’s acquisition of the company is rumored to be more than $200M, a small price to pay for a foothold in emerging African markets. In the company’s announcement, Stripe noted that African online commerce is growing 21% year-over-year, 75% faster than the global average. Paystack dominates among payment systems, accounting for more than half of all online transactions in Nigeria.

“In just five years, Paystack has done what many companies could not achieve in decades,” Stripe EMEA business lead Matt Henderson said. “Their tech-first approach, values, and ambition greatly align with our own. This acquisition will give Paystack resources to develop new products, support more businesses and consolidate the hyper-fragmented African payments market.”

Long term, Stripe plans to embed Paystack’s capabilities in its Global Payments and Treasury Network (GPTN), the company’s programmable infrastructure for global money movement.

“Paystack merchants and partners can look forward to more payment channels, more tools, accelerated geographic expansion, and deeper integrations with global platforms,” Paystack CEO and co-founder Shola Akinlade said. He also assured customers that there’s no need to make any changes to their technical integrations, as Paystack will continue expanding and operating independently in Africa.

Paystack is used as a payment gateway for thousands of WordPress-powered stores through plugins for WooCommerce, Easy Digital Downloads, Paid Membership Pro, Give, Contact Form 7, and an assortment of booking plugins. The company has an official WordPress plugin, Payment Forms for Paystack, which is active on more than 6,000 sites, but most users come through the Paystack WooCommerce Payment Gateway (20,000+ active installations).

Stripe’s acquisition was a bit of positive news during what is currently a turbulent time in Nigeria, as citizens are actively engaged in peaceful protests to end police brutality. Paystack’s journey is an encouraging example of the flourishing Nigerian tech ecosystem and the possibilities available for smaller e-commerce companies that are solving problems and removing barriers for businesses in emerging markets.

Created by Donna Peplinskie, a Product Wrangler at Automattic, the Book Review Block plugin is nearly three years old. However, it only came to my attention during a recent excursion to find interesting block plugins.

The plugin does pretty much what it says on the cover. It is designed to review books. It generally has all the fields users might need to add to their reviews, such as a title, author, image, rating, and more. The interesting thing is that it can automatically fill in those details with a simple ISBN value. Plus, it supports Schema markup, which may help with SEO.

Rain or shine, sick or well, I read every day. I am currently a month and a half shy of a two-year reading streak. When the mood strikes, I even venture to write a book review. As much as I want to share interesting WordPress projects with the community, I sometimes have personal motives for testing and writing about plugins like Book Review Block. Anything that might help me or other avid readers share our thoughts on the world of literature with others is of interest.

Admittedly, I was excited as I plugged in the ISBN for Rhthym of War, the upcoming fourth book of my favorite fantasy series of all time, The Stormlight Archive. I merely needed to click the “Get Book Details” button.

Success! The plugin worked its magic and pulled in the necessary information. It had my favorite author’s name, the publisher, the upcoming release date, and the page count. It even had a long description, which I could trim down in the editor.

Default output of the Book Review block.

There was a little work to make this happen before the success. To automatically pull in the book details, end-users must have an API Key from Google. It took me around a minute to set that up and enter it into the field available in the block options sidebar. The great thing about the plugin is that it saves this key so that users do not have to enter each time they want to review a book.

Book Review Block a good starting point. It is straightforward and simple to use. It is not yet at a point where I would call it a great plugin. However, it could be.

Falling Short

The plugin’s Book Review block should be taking its cues from the core Media & Text block. When you get right down to it, the two are essentially doing the same thing visually. Both are blocks with an image and some content sitting next to each other.

The following is a list of items where it should be following core’s lead:

• No way to edit alt text (book title is automatically used).
• The image is always aligned left and the content to the right with no way to flip them.
• The media and content are not stackable on mobile views.
• Cannot adjust the size of the image or content columns.
• While inline rich-text controls are supported, users cannot add Heading, List, or Paragraph blocks to the content area and use their associated block options.

That is the shortlist that could offer some quick improvements to the user experience. Ultimately, the problems with the plugin essentially come down to not offering a way to customize the output.

One of the other consistent problems is that the book image the plugin loads is always a bit small. This seems to be more of an issue from the Google Books API than the plugin. Each time I tested a book, I opted to add a larger image — the plugin does allow you to replace the default.

The color settings are limited. The block only offers a background color option with no way to adjust the text color. A better option for plugin users is to wrap it in a Group block and adjust the background and text colors there.

Book Review block wrapped inside a Group block.

It would also be nice to have wide and full-alignment options, which is an often-overlooked featured from many block plugin authors.

Using the Media & Text Block to Recreate the Book Review Block

The Book Review Block plugin has a lot of potential, and I want to see it evolve by providing more flexibility to end-users. Because the Media & Text block is the closest core block to what the plugin offers, I decided to recreate a more visually-appealing design with it.

Book review section created with the Media & Text block.

I made some adjustments on the content side of things. I used the Heading block for the book title, a List block for the book metadata, and a Paragraph block for the description.

The Media & Text block also provided me the freedom to adjust the alignment, stack the image and content on mobile views, and tinker with the size of the image. Plus, it has that all-important field for customizing the image alt attribute.

The Media & Text block gave me much more design mileage.

However, there are limitations to the core block. It does not fully capture some of the features available via the Book Review block. The most obvious are the automatic book details via an ISBN and the Schema markup. Less obvious, there is no easy way to recreate the star rating — I used emoji stars — and long description text does not wrap under the image. To recreate that, you would have to opt to use a left-aligned image followed by content.

Overall, the Media & Text block gives me the ability to better style the output, which is what I am more interested in as a user. I want to put my unique spin on things. That is where the Book Review Plugin misfires. It is also the sort of thing that the plugin author can iterate on, offering more flexibility in the future.

This is where many block plugins go wrong, particularly when there is more than one or two bits of data users should enter. Blocks represent freedom in many ways. However, when plugin developers stick to a rigid structure, users can sometimes lose that sense of freedom that they would otherwise have with building their pages.

One of the best blocks, hands down, that preserves that freedom is from the Recipe Block plugin. It has structured inputs and fields. However, it allows freeform content for end-users to make it their own.

When block authors push beyond this rigidness, users win.

WooCommerce 4.6 was released today. The minor release dropped during WooSesh, a global, virtual conference dedicated to WooCommerce and e-commerce topics. It features the new home screen as the default for all stores. Previously, the screen was only the default on new stores. Existing store owners had to turn the feature on in the settings.

The updated home screen, originally introduced in version 4.3, helps store admins see activity across the site at a glance and includes an inbox, quick access to store management links, and an overview of stats on sales, orders, and visitors. This redesigned virtual command center arrives not a moment too soon, as anything that makes order management more efficient is a welcome improvement, due to the sheer volume of sales increases that store owners have seen over the past eight months.

In stark contrast to industries like hospitality and entertainment that have proven to be more vulnerable during the pandemic, e-commerce has seen explosive growth. During the State of the Woo address at WooSesh 2020, the WooCommerce team shared that e-commerce is currently estimated to be a $4 trillion market that will grow to $4.5 trillion by 2021. WooCommerce accounts for a sizable chunk of that market with an estimated total payment volume for 2020 projected to reach $20.6 billion, a 74% increase compared to 2019.

The WooCommerce community is on the forefront of that growth and is deeply invested in the products that are driving stores’ success. The WooCommerce team shared that 75% of people who build extensions also build and maintain stores for merchants, and 70% of those who build stores for merchants also build and maintain extensions or plugins. In 2021, they plan to invest heavily in unlocking more features in more countries and will make WooCommerce Payments the native payment method for the global platform.

A new report from eMarketer shows that US e-commerce growth has jumped 32.4%, accelerating the online shopping shift by nearly two years. Experts also predict the top 10 e-commerce players will swallow up more of US retail spending to account for 63.2% of all online sales this year, up from 57.9% in 2019.

The increase in e-commerce spending may not be entirely tied to the pandemic, as some experts believe this historic time will mark permanent changes in consumer spending habits. This is where independent stores, powered by WooCommerce and other technologies, have the opportunity to establish a strong reputation for themselves by providing quality products and reliable service, as well as by being more nimble in the face of pandemic-driven increases in volume.

Image credit: picjumbo.com on Pexels.

Starter content. It was a grand idea, one of those big dreams of WordPress. It was the new kid on the block in late 2016. Like the introduction of post formats in 2011, the developer community was all in for at least that particular release version. Then, it was on to the next new thing, with the feature dropping off the radar for all but the most ardent evangelists.

Some of us were burned over the years, living and dying by the progress of features that we wanted most.

Released in WordPress 4.7, starter content has since seemed to be going the way of post formats. After four years, only 141 themes in the WordPress theme directory support the feature. There has been no movement to push it beyond its initial implementation. And, it never really covered the things that theme authors wanted in the first place. It was a start. But, themers were ultimately left to their own devices, rolling custom solutions for something that never panned out — fully-featured demo and imported content. Four years is an eternity in the web development world, and there is no sense in waiting around to see if WordPress would push forward.

Until Helen Hou-Sandí published Revisiting Starter Content last week, most would have likely assumed the feature would be relegated to legacy code used by old-school fans of the feature and those theme authors who consider themselves completionists.

“Starter content in 4.7 was always meant to be a step one, not the end goal or even the resting point it’s become,” wrote Hou-Sandí. “There are still two major things that need to be done: themes should have a unified way of showing users how best to put that theme to use in both the individual site and broader preview contexts, and sites with existing content should also be able to take advantage of these sort of ‘ideal content’ definitions.”

Step two should have been this four-year-old accompanying ticket to allow users to import starter content into existing, non-fresh sites.

Since the initial feature dropped, the theme landscape has changed. Let’s face it. WordPress might simply not be able to compete with theme companies that are pushing the limits, creating experiences that users want at much swifter speeds.

Look at where the Brainstorm Force’s Starter Templates plugin for its Astra theme is now. Users can click a button and import a full suite of content-filled pages or even individual templates. And, the Astra theme is not alone in this. It has become an increasingly-common standard to offer some sort of onboarding to users. GoDaddy’s managed WordPress service fills a similar need on the hosting end.

Astra’s starter templates and content.

As WordPress use becomes more widespread, the more it needs a way to onboard users.

This essentially boils down to the question: how can I make it look like the demo?

Ah, the age-old question that theme authors have been trying to solve. Whether it has been limitations in the software or, perhaps, antiquated theme review guidelines related to demo and imported content, this has been a hurdle that has been tough to jump. But, some have sailed over it and moved on. While WordPress has seemingly been twiddling its thumbs for years, Brainstorm Force and other theme companies have solved this and continued to innovate.

This is not necessarily a bad thing. There are plenty of ideas to steal copy and pull into the core platform.

One of the other problems facing the WordPress starter content feature is that it is tied to the customizer. With the direction of the block system, it is easy to ask what the future holds. The customizer — originally named the theme customizer — was essentially a project to allow users to make front-end adjustments and watch those customizations happen in real time. However, new features like global styles and full-site editing are happening on their own admin screens. Most theme options will ultimately be relegated to global styles, custom templates, block styles, and block patterns. There may not be much left for the customizer to do.

Right now, there are too many places in WordPress to edit the front-end bits of a WordPress site. My hope is that all of these things are ultimately merged into one less-confusing interface. But, I digress…

Starter content should be rethought. Whoever takes the reins on this needs a fresh take that adopts modern methods from leading theme companies.

The ultimate goal should be to allow theme authors to create multiple sets of templates/content that end-users can preview and import. It should not be tied to whether it is a new site. Any site owner should be able to import content and have it automagically go live. It should also be extendable to allow themes to support page builders like Elementor, Beaver Builder, and many others.

This seems to be in line with Hou-Sandí’s thoughts. “For a future release, we should start exploring what it might look like to opt into importing starter content into existing sites, whether wholesale or piecewise,” she wrote. “Many of us who work in the WordPress development/consulting space tend not to ever deal in switching between public themes on our sites, but let’s not forget that’s a significant portion of our user audience and we want to continue to enable them to not just publish but also publish in a way that matches their vision.”

Let’s do it right this go-round, keep a broad vision, and provide an avenue for theme authors to adopt a standardized core WordPress method instead of having everyone build in-house solutions.

I haven’t even touched on the recent call to use starter content for WordPress.org theme previews. It will take more than ideas to excite many theme authors about the possibility. That ticket has sat for seven years with no progress, and most have had it on their wish list for much longer. It is an interesting proposal, one that has been tossed around in various team meetings for years.

Like so many other things, theme authors have either given up hope or moved onto doing their own thing. They need to be brought into the fold, not only as third parties who are building with core WordPress tools but as developers who are contributing to those features.

Google announced an expansion of listener engagement metrics today for those using its Podcast Manager. Previously, audience insights included data about the types of devices listeners are using, where listeners tune in and drop off during a given episode, total number of listens, and listening duration, but the service lacked analytics regarding how visitors were discovering the podcast.

Google is remedying that today by expanding the dashboard to show impressions, clicks, top-discovered episodes, and search terms that brought listeners to the podcast. This information can help podcasters understand how their content is getting discovered so they can better tailor their episodes to attract more new listeners.

The podcasting industry has seen remarkable growth over the past five years, which previously led experts to project that marketers will spend over $1 billion in advertising by 2021. After the pandemic hit, podcast listening took a downturn in the U.S. but at the same time, podcast creators have found more time to create new shows and episodes. Businesses are turning to the medium to supplement traditional marketing methods that no longer have the same impact now that consumer spending habits heavily favor online products.

Along with the new metrics available inside Google Podcasts Manager, the company also published a guide to optimizing podcasts for Google Search. It highlights four important items for making sure a podcast can be found:

• Detailed show and episode metadata
• Ensure the podcast’s webpage and RSS data match
• Include cover art
• Ensure Googlebot can access your audio files

A detailed breakdown of your audience’s listening habits isn’t worth much if you’re having trouble getting your podcast discovered. Any podcasting plugin for WordPress should handle these basic optimization recommendations, but if you are still having trouble being found via Google, you can dig deeper into the podcast setup guide for more detailed recommendations.

Two weeks ago, the Gutenberg team put out an open call for block-based widgets feedback. I had already written a lengthy review of the new system earlier in September but was asked by a member of the team to share my thoughts on the most recent iteration. With the upcoming freeze for WordPress 5.6 Beta 1 just a week away, I figured it would not hurt to do another deep dive.

For reference, my latest testing is against version 9.2.0-alpha-172f589 of the Gutenberg plugin, which was a build from earlier today. Gutenberg development moves fast, but everything should be accurate to that point.

Ultimately, many of the problems I pointed out over a month ago still exist. However, the team has cleaned most of the minor issues, such as pointing the open/close arrows for sidebars (block areas) in the correct direction and making it more consistent with the post-editing screen. The UI is much more polished.

Before I dive into all the problems, I want to answer the question I am proposing. Yes, the block-based widget system will be ready for prime time when WordPress 5.6 lands. It is not there yet, but it is at a point where there is a clear finish line that is reachable in the next two months.

I will ignore the failure of block-based widgets in the customizer, which landed in Gutenberg 8.9 and was removed in 9.1. I will also look past the recent proposal to reconstruct the widgets screen to use the Customize API, at least for now. There is a boatload of problems that block-based widgets present for the customizer, and those problems are insurmountable for WordPress 5.6. Long term, WordPress needs to have a single place for editing widget/block areas. Users will likely have to live with some inconsistencies for a while.

Assuming the team does not try to throw a last-minute Hail Mary and implement full editing of blocks in the customizer this round, it is safe to say that block-based widgets are well on their way toward a successful WordPress 5.6 debut.

The User Experience

Block-based widgets screen.

As a user, I genuinely enjoy using the new Widgets admin screen. The open-ended, free-form block areas create untold possibilities for designing my WordPress sites. Traditional widgets were limited in scope. Users were buckled down to a handful of core widgets, possibly some plugin widgets, and whatever their theme author offered up. However, with blocks, the pool of choices expands to at least triple the out-of-the-box options (I am not counting embed-type blocks individually). Plus, blocks provide a far more extensive set of design options than a traditional widget.

In comparison, traditional widgets are outdated. Blocks are superior in almost every way. However, there are still problems with this new system.

The biggest issue right now is that end-users can exit the Widgets screen without saving their changes. There is no warning to let them know that all their work is about to be lost in the ether. This is one of those OMGBBQ-level items that need to happen before WordPress 5.6 drops.

One nice-to-have-but-not-necessary feature would be the ability to drag blocks from one block area to another. In the old widgets system, users could move widgets from sidebar to sidebar. The current alternative is to copy a widget, paste it in a new block area, and remove the original.

I am also not a fan of not having an option for the top toolbar, which is available on the post-editing screen. One of the reasons for using this toolbar is because I dislike the default popup toolbar on individual blocks. It is distracting and often gets in the way of my work.

Legacy widgets seem to still be a work in progress. The Legacy Widget block did not work at all for me at times. Then, it magically began to work. However, Gutenberg does now automatically add registered third-party widgets to the block inserter just as if they were blocks.

Getting a plugin’s widget to work.

This presented its own problems. The only way I managed to make third-party plugin widgets work was to insert the widget, save, and refresh the widgets screen. At that point, the widgets appeared and became editable.

The Theme Author Experience

One of my biggest concerns for theme authors right now is that there does not seem to be any documentation in the block editor handbook. There is plenty of time to make that happen, but there are things theme authors need to be aware of. Having a centralized location, even while the feature is under development, would help them gear up for the 5.6 release.

Some of these questions, which may be answered in various Make blog posts, should exist on a dedicated documentation page:

• How can a theme opt out of block-based widgets?
• What are the hooks to add custom styles for the Widgets screen?
• Can themes target specific sidebar styles on the Widgets screen?
• Is it possible to consistently style sections like traditional widgets on the front end?
• Can themes opt into wide and full-alignment within block areas, which could essentially be used similarly to the post content area?

These are some of the questions I would want to be answered as a former theme author. I am no longer in the thick of the theme design game and presume that those who are would have a larger list of questions.

One less-obvious piece of documentation should center on how to handle fallbacks or default widgets. Traditionally, themes that needed to show a default set of widgets would check if the sidebar has widgets and fall back to using the_widget() to output one or more defaults. While theme authors can still do that, we should start to transition them across the board to the block system.

Should theme authors copy/paste block HTML as a fallback? Would the starter content system be better for this, and can starter widget content handle blocks? What is the recommended method for widget fallbacks in WordPress 5.6?

There is still the ongoing issue of how theme authors should handle the traditional widget and widget title wrapper HTML in the new block paradigm. One patch added since the Gutenberg 9.1 release wraps every top-level block with the widget wrapper. If this lands in the 9.2 release, it will likely make the issue worse.

In the traditional system, both the widget title and content are wrapped within a container together. However, if a user adds a Heading block (widget title) and another block (widget content), each block is wrapped separately with the theme’s widget wrappers. The only way to rectify the situation as it stands is for end-users to add a Group block for each “widget” they want, which would require an extensive amount of re-education for WordPress users. It is not an ideal scenario.

Each block is wrapped as an individual section.

Instead of attempting to directly “fix” this issue, WordPress should instead do nothing to the output. Blocks and traditional widgets are fundamentally different.

Let theme authors take the reins on this one and explore possibilities. However, give them the tools to do so, such as supporting block patterns.

WordCamp Austin 2020 attendees are raving about their experiences attending the virtual event last Friday. It was no secret that the camp’s organizers planned to use Hubs Virtual Rooms by Mozilla to create a unique environment, but few could imagine how much more interactive and personalized the experience would be than a purely Zoom-based WordCamp.

After selecting a custom avatar, attendees entered the venue using a VR headset or the browser to check out sessions or network in the hallway track.

Speaker and Q&A sessions were broadcast through Zoom but organizers can also embed YouTube videos and streams within the standalone VR environment.

“The VR experience was the most life-like WordCamp experience I’ve had since the start of global lockdowns,” attendee and speaker David Vogelpohl said. “You could attend sessions in one of two virtual presentation halls depending on what track you wanted to see at that time. The speaker presented on a virtual stage and you could see the other attendees watching the presentation.”

Vogelpohl said he enjoyed his experience getting to know others in the Slack and VR venue. Organizers preserved the general vibe of the “hallway track” to recreate what is arguably one of the most valuable aspects of in-person WordCamps.

“In the hallway track between the virtual presentation halls was a large foyer where you could meet new people, spot a friend speaking with someone else, and virtually step aside from a group conversation to have a private conversation,” Vogelpohl said.

“It was great to see folks like Josepha circling around speaking with attendees, Josh Pollock nerding out in a corner with a group of advanced WP developers, and having random friends drop into a conversation I was having with a group of others. While VR WordCamp doesn’t wholly replace the value of attending a WordCamp live, a lot of the best parts of meeting and collaborating with others was captured in the VR context.”

The live music interludes, which showcased talents from around the community, also provided a way for virtual attendees to stay connected while waiting for the next session.

Behind the Scenes with Anthony Burchell: Creative Director for WordCamp Austin’s Virtual World

WordPress core contributor Anthony Burchell, who started a company dedicated to creating interactive XR sound and art experiences, was the creative director behind the WordCamp Austin’s VR backdrop.

“For WordCamp Austin we wanted to give folks something to be excited about outside of the typical webcam and chat networking,” Burchell said. “I feel that virtual events are not utilizing the networking layer nearly enough to make folks feel like they are really at an event. I’ve seen many compelling formats for virtual events utilizing webcams and chat rooms, but in the end, it feels like there’s been a missing element of presence; something video games and virtual reality excel at.”

Setting up the virtual world involves spinning up a self-hosted instance of Hubs Cloud, which Burchell said is very similar to the complexity of making a WordPress site.

“The most time consuming part of creating a 3D world for an event is making the 3D assets for the space,” Burchell said. “In total I streamed 11 hours of video leading up to the event to give a glimpse into the process.”

Burchell’s YouTube playlist documents the incredible amount of work that went into creating the WordCamp’s virtual venue for attendees to enjoy.

“While it took quite a bit of time to prepare, the code and assets are completely reusable for another event,” Burchell said. “A lot of the time was spent trying to make the space purpose built for the goals of the camp. Much like a real WordCamp, I found the majority of folks packing into the theater rooms for presentations and dipping out a little early to network with friends in the hallway area. That was very much by design!”

Burchell and the other organizers were careful to ensure that the Hubs space was not the primary viewing experience of the camp but rather an extension of the networking activities that attendees could drop in on. The event had nearly identical numbers of attendees joining the virtual space as it did for those joining the video channels. At the end of the afterparty, Burchell turned on flying for all attendees to conclude the successful event:

“With Hubs we were able to give attendees the ability to express themselves within a venue vs within a camera and chat box,” Burchell said. “It was incredible to see characteristics of folks in the community shine through a virtual avatar! Just the simple act of seeing your WordCamp friends in the hallway joking and chatting just as they would at a real life event was enough to make me feel like I was transported to a real WordCamp.”

Ari Stathopoulos released his new Local Gravatars plugin last week. The goal of the plugin is to allow site owners to take advantage of the benefits of a global avatar system while mitigating privacy concerns by hosting the images locally.

In essence, it is a caching system that stores the images on the site owner’s server. It is an idea that Peter Shaw proposed in the comments on an earlier Tavern article covering local avatar upload. It is a middle ground that may satisfy some users’ issues with how avatars currently work in WordPress.

“I am one of the people that blocks analytics, uses private sessions when visiting social sites, I use DuckDuckGo instead of Google, and I don’t like the ‘implied’ consents,” said Stathopoulos. “I built the plugin for my own use because I don’t know what Gravatar does, I don’t understand the privacy policies, and I am too lazy to spend two hours analyzing them. It’s faster for me to build something that is safe and doesn’t leave any room for misunderstandings.”

He is referring to Automattic’s extensive Privacy Policy. He said it looks benign. However, he does not like the idea of any company being able to track what sites he visits without explicit consent.

“And when I visit a site that uses Gravatar, some information is exposed to the site that serves them — including my IP,” said Stathopoulos. “Even if it’s just for analytics purposes, I don’t think the company should know that page A on site B got 1,000 visitors today with these IPs from these countries. There is absolutely no reason why any company not related to the page I’m actually visiting should have any kind of information about my visit.”

The Local Gravatars plugin must still connect to the Gravatar service. However, the connection is made on the server rather than the client. Stathopoulos explained that the only information exposed in this case is the server’s IP and nothing from the client, which eliminates any potential privacy concerns.

The Latest Plugin Update

Stathopoulos updated the plugin earlier today to address some performance concerns for pages that have hundreds or more Gravatar images. In the version 1.0.1 update, he added a maximum processing time of five seconds and changed the cache cleanup process from daily to weekly. Both of these are filterable via code.

“Now, if there are Gravatars missing in a page request, it will get as many as it can, and, after five seconds, it will stop,” said Stathopoulos. “So if there are 100 Gravatars missing and it gets the first 20, the rest will be blank (can be filtered to use a fallback URL, or even fall back to the remote URL, though that would defeat the privacy improvement). The next page request will get the next 20, and so on. At some point, all will be there, and there will be no more delays.”

He did point out that performance could temporarily suffer when installing it on a site that has individual posts with 1,000s of comments and a lot of traffic. However, nothing would crash on the site, and the plugin should eventually lead to a performance boost in this scenario. For such large sites, owners could use the existing filter hooks to tweak the settings.

Right now, the plugin is primarily an itch he wanted to scratch for his own purposes. However, if given enough usage and feedback, he may include a settings screen to allow users to control some of the currently-filterable defaults, such as the cleanup timeframe and the maximum process time allowed.

The Growing List of Alternatives

With growing concerns around privacy in the modern world, Local Gravatars is another tool that end-users can employ if they have any concerns around the Gravatar service. For those who are OK with an auto-generated avatar, Pixel Avatars may be a solution.

“I’ve seen some of them, and they are wonderful!” Stathopoulos said of alternatives for serving avatars. “However, this plugin is slightly different in that the avatars the user already has on Gravatar.com are actually used. They can see the image they have uploaded. The user doesn’t need to upload a separate avatar, and an automatic one is not used by default.”

He would not mind using an auto-generated avatar when commenting on blogs or news sites at times. However, Stathopoulos prefers Gravatar for community-oriented sites.

“My Gravatar is part of my online identity, and when I see, for example, a comment from someone on WordPress.org, I know who they are by their Gravatar,” he said.

In 2015, WordPress 4.4 introduced a REST API, but one thing that has severely limited its broader use is the lack of authentication capabilities for third-party applications. After considering the benefits and drawbacks of many different types of authentication systems, George Stephanis published a proposal for integrating Application Passwords, into core.

Stephanis highlighted a few of the major benefit that were important factors in the decision to use Application Passwords: the ease of making API requests, ease of revoking credentials, and the ease of requesting API credentials. The project is available as a standalone feature plugin, but Stephanis and his collaborators recommended WordPress merge a pull request that is based off the feature plugin’s codebase.

After WordPress 5.6 core tech lead Helen Hou-Sandi gave the green light for Application Passwords to be merged into core, the developer community responded enthusiastically to the news.

“I am/we are 100% in favor of this,” Joost deValk commented on the proposal. “Opening this up is like opening the dawn of a new era of WordPress based web applications. Suddenly authentication is not something you need to fix when working with the API and you can just build awesome stuff.”

Stephanis’ proposal also mentioned how beneficial a REST API authentication system would be for the Mobile teams‘ contributors who are relying on awkward workarounds while integrating Gutenberg support.

“This would be a first step to replace the use of XMLRPC in the mobile apps and it would allow us to add more features for self hosted users,” Automattic mobile engineer Maxime Biais said.

After the REST API was added to WordPress five years ago, many had the expectation that WordPress-based web applications would start popping up everywhere. Without a reliable authentication system, it wasn’t easy for developers to just get inspired and build something quickly. Application Passwords in WordPress 5.6 will open up a lot of possibilities for those who were previously deterred by the lack of core methods for authenticating third-party access.

Jan Koch, the founder and host of WP Agency Summit, is kicking off his second annual event on October 12. The five-day event will feature 37 speakers from a wide range of backgrounds across the WordPress industry. It is a free virtual event that anyone can attend.

“The focus for the 2020 WP Agency Summit is showing attendees how to bring back the fun into scaling their agencies,” said Koch. “It is all about reducing the daily hustle by teaching how to successfully build and manage teams, how to work with enterprises (allowing for fewer customers but bigger projects), how to build sustainable recurring revenue, and how to position your agency to dominate your niche.”

This year’s event includes three major changes to make the content more accessible to a larger group of people. Each session will be available between October 12 – 16 instead of the previous 48-hour window that attendees had to find time for in 2019.

After the event has concluded, access to the content will be behind a paywall. Koch reduced the price to $77 for lifetime access for those who purchase pre-launch, which will increase to $127 during the event. Last year’s prices ballooned to $497, which meant that it was simply not affordable for many who found it too late.

Some of the proceeds this year are going toward transcribing all the videos so that hearing-impaired users can enjoy the content.

This year’s event will also focus on a virtual networking lounge for attendees. “I’ve seen how well it worked at the WP FeedBack Summit — we even had BobWP record a podcast episode on the fly in that lounge!” said Koch. “I’ve seen many new friendships develop, people connecting with new suppliers or getting themselves booked on podcasts, and sharing experiences about their businesses.”

The lounge will be open during the entirety of the summit, which will allow attendees to jump into the conversation on their own time.

A More Diverse Speaker Lineup

Koch received some backlash for the lack of gender diversity last year. The 2019 event had over 20 speakers from a diverse male lineup. However, only four women from our industry led sessions.

When asked about this issue in 2019, Koch responded, “I recognize this as a problem with my event. The reason I have so much more male than female speakers is quite simple, the current speaker line-up is purely based on connections I had when I started planning for the event. It was a relatively short amount of time for me, so I wasn’t able to build relationships with more female WP experts beforehand.”

The host said he paid attention to the feedback he received. While not hitting the 50/50 split goal he had for 2020’s event, 16 of the 37 speakers are women.

Koch said he strived to get speakers from a wider range of backgrounds. He wanted to bring in both freelancers and multi-million dollar agency owners. He also focused on getting people from multiple countries to represent WordPress agencies.

“I did reach out to around 130 people four months before the event to make new connections,” he said. “The community around the Big Orange Heart (a non-profit for mental well-being) also helped a lot with introducing me to new members of the WP community.”

Koch said he learned two valuable lessons when branching out beyond his existing connections for this year’s event:

Firstly, don’t hesitate to reach out to people you think will never talk to you because they’re running such big companies. For example, I immediately got confirmations from Mario Peshev from Devrix, Brad Touesnard from Delicious Brains, or Marieke van de Rakt from Yoast. When first messaging them, I had little hope they’d set aside time to jump on an interview with me – but they were super supportive and accommodating! The WordPress community really is a welcoming environment if you approach people in a humble way.

Secondly, build connections with sincerity. Do not just focus on what you can get from that connection but how you can help the other person. I know this sounds cheesy and you’ve heard this quite often — but it is true. Once I got the first response from new contacts and explained my goal of connecting fellow WordPress community members virtually, most immediately agreed because they also benefit from new connections and being positioned as a thought-leader in this event.

WP Agency Summit? WP FeedBack Summit?

For readers who recall the Tavern’s coverage of the WP FeedBack Summit earlier this year, the article specifically stated that the WP FeedBack Summit was a continuation of 2019’s WP Agency Summit. The official word at the time from WP FeedBack’s public relations team was the following:

Last year’s event, the WP Agency Summit has been rebranded under the umbrella of WP FeedBack’s brand when Jan Koch the host of last’s year WP Agency Summit joined WP FeedBack as CTO.

Koch said that it was a standalone event and not directly connected to WP Agency Summit but had the same target audience. However, the WP FeedBack Summit did use the previous WP Agency Summit’s stats and data to promote the event.

“The WP FeedBack Summit was hosted under the WP FeedBack brand because I joined their team as CTO in March this year,” he said. “Vito [Peleg] and I had the idea to host a virtual conference around WordPress because of WordCamp Asia being canceled — we wanted to help connect the community online through our summit.

Koch left WP FeedBack soon after the summit ended and is currently back on his own and has a goal of making WP Agency Summit a yearly event.

The new block-based navigation screen is once again delayed after it was originally slated for WordPress 5.5 and then put on deck for 5.6. Contributors have confirmed that it will not be landing in WordPress core until 2021 at the earliest.

“The Navigation screen is still in experimental state in the Gutenberg plugin, so it hasn’t had any significant real-world use and testing yet,” Editor Tech Lead Isabel Brison said. She made the call to remove it from the 5.6 lineup after the feature missed the deadline for bringing it out of the experimental state. It still requires a substantial amount of development work and accessibility feedback before moving forward.

Contributors will focus instead on making sure the Widgets screen gets out the door for 5.6 and plan to pick up again on Navigation towards the end of November.

WordPress 5.6 lead Josepha Haden gave an update this week on the progress of all the anticipated features, including the planned public beta for full-site editing (FSE).

“I don’t expect FSE to be feature complete by the time WP5.6 is released,” Haden said. “What I expect is that FSE will be functional for simple, routine user flows, which we can start testing and iterating on. That feedback will also help us more confidently design and build our complex user flows.”

Frank Klein, an engineer at Human Made, asked in the comments of another update why full-site editing is being tied to 5.6 progress in the first place, since it will still only be available in the plugin at the time of release.

“The main value is that it provides a good checkpoint along the path of FSE’s development,” Kjell Reigstad said. “Full-site editing is very much in progress. It is still experimental, but the general approach is coming into view, and becoming clearer with every plugin release.”

Reigstad posted an update on what developers can expect regarding block-based theming and the upcoming release, since the topic is closely tied to full-site editing. He emphasized that the infrastructure is already in place and that, despite it still being experimental, future block-based themes should work in a similar way to how they are working now.

“The focus is now shifting towards polishing the user experience: using the site editor to create templates, using the query block, iterating on the post and site blocks, and implementing the Global Styles UI,” Reigstad said.

“The main takeaway is that when 5.6 is released, the full-site editing feature set will look similar to where it is today, with added polish to the UI, and additional features in the Query block.”

Theme authors are entering a new time of uncertainty and transition, but Reigstad reassured the community that themes as we know them today are not on track to be phased out in the immediate future.

“There is currently no plan to deprecate the way themes are built today,” Reigstad said. “Your existing themes will continue to work as they always have for the foreseeable future.” He also encouraged contributors to get involved in an initiative to help theme authors transition to block-based themes. (This project is not targeted for the 5.6 release.)

Developers can follow important FSE project milestones on GitHub, and subscribe to the weekly Gutenberg + Themes updates to track progress on block-based theming. A block-based version of the Twenty Twenty-One theme is in the works and should pick up steam after 5.6 beta 1, expected on October 20.

Munir Kamal shows no signs of slowing down. He continues to push forward with new features for his EditorPlus plugin, which allows end-users to customize the look of the blocks in their posts and pages. He calls it the “no-code style editor for WordPress.”

The latest addition to his plugin? Animation styles for every core block.

My first thought was that this would bloat the plugin with large amounts of unnecessary CSS and JavaScript for what is essentially a few bells and whistles. However, Kamal pulled it off with minimal custom CSS.

Inspired by features from various website builders, he wanted to bring more and more of those things to the core block editor. The animations feature is just another ticked box on a seemingly never-ending checklist of features. And, so far, it’s all still free.

Since we last covered EditorPlus in June, Kamal has added the ability to insert icons via any rich-text area (e.g., paragraphs, lists, etc.). He has also added shape divider, typography, style copying, and responsive editing options for the core WordPress blocks.

How Do Animations Work?

In the version 1.9 release of EditorPlus, Kamal added “entrance” animations. These types of animations happen when a visitor sees the block for the first time on the screen. For example, users could set the Image block to fade into visibility as a reader views the block.

Currently, the plugin adds seven animations:

• Fade
• Slide
• Bounce
• Zoom
• Flip
• Fold
• Roll

Adding a Slide animation for the Cover block text.

Each animation has its own subset of options to control how it behaves on the page. The bounce animation, for example, allows users to select the bounce direction. Other options include duration, delay, speed curve, delay, and repeat. There are enough choices to spend an inordinate amount of time tinkering with the output.

One of the best features of this new feature is that Kamal has included an Animation Player under the block options. By clicking the play button, users can view the animation in action without previewing the post.

Watch a quick video of the Animations feature:

After testing and using each animation, everything seemed to work well. The one downside — and this is not limited to animations — is that applying styles on the block level sometimes does not make sense. In many cases, it would help users to have options to style or animate the items within the block, such as the images in the Gallery block. When I broached the subject with Kamal, he was open to the idea of finding a solution to this in the future.

What Is Next for EditorPlus?

At a certain point, too many block options can almost feel like overkill and become unwieldy. EditorPlus does allow users to disable specific features from its settings screen, which can help get rid of some unwanted options. Kamal said he would like to continue making it more modular so that users can use only the features they need.

“What I plan is to have micro-level feature control for this extension so that a user can switch off individual styling panels like, Typography, Background, etc.,” he said. “Even further, I plan to bring these controls based on the user role as well. So an admin can disable these features for the editor, author, etc.”

That may be a bit down the road though. For now, he wants to focus on adding new features that he already has planned.

“I do plan to add more animation features,” said Kamal. “I got too many ideas, such as scroll-controlled animation, hover animation, text animation, Lottie animation, background animation, animated shape dividers, and more. But, having said that, I will be careful adding only those features that don’t affect page performance much.”

Outside of extra styles and animations for existing blocks, he plans to jump on the block-building train in future releases. EditorPlus users could see accordion, toggle, slider, star rating, and other blocks in an upcoming release.

I’ve been running a photoblog at inphotos.org since 2005 on WordPress. (And thanks to writing this I noticed it’s 15 years old today!)

In that time WordPress has changed dramatically. At first I used Flickr to host my images, but after a short time I hosted the images myself. (Good thing too since Flickr limited free user accounts to 1000 images, so I wrote a script to download the Flickr images I used in posts.)

For quite a long time I used the featured image instead of inserting the image into the post content, but then about two years ago I went back to inserting the photo into the post. Unfortunately that meant the photo was shown twice, once as a featured image, and once in the post content.

The last theme I used supported custom post types, one of which was a photo type that displayed the featured image but hid the post content. It was an ok compromise, but not perfect.

Recently I started using Twenty Twenty, but after 15 years I had a mixture of posts with:

• Featured image with no image in the post.
• Featured image with the same image in the post.

I knew I needed something more flexible. I wanted to hide the featured image if it also appeared in the post content. I procrastinated and never got around to it until this evening when I discovered it was actually quite easy.

Copy the following code into the function.php of your child theme and you’ll be all set! It relies on you having unique filenames for your images. If you don’t then remove the call to basename(), and that may help.

function maybe_remove_featured_image( $html ) {
        if ( $html == '' ) {
                return '';
        }
        $post = get_post();
        $post_thumbnail_id = get_post_thumbnail_id( $post );
        if ( ! $post_thumbnail_id ) {
                return $html;
        }

        $image_url = wp_get_attachment_image_src( $post_thumbnail_id );
        if ( ! $image_url ) {
                return $html;
        }

        $image_filename = basename( parse_url( $image_url[0], PHP_URL_PATH ) );
        if ( strpos( $post->post_content, $image_filename ) ) {
                return '';
        } else {
                return $html;
        }
}
add_filter( 'post_thumbnail_html', 'maybe_remove_featured_image' );

The post_thumbnail_html filter acts on the html generated to display the featured image. My code above gets the filename of the featured image, checks if it’s in the current post and if it is returns a blank string. Feedback welcome if you have a better way of doing this!

Related Posts

• Around Ireland in 80 links on July 9th 2007
• Webalizer – hide the groups!
• dvd::rip – A full featured DVD …

Source

Just a day after launching its new privacy-first web analytics product last week, Cloudflare announced Automatic Platform Optimization (APO) for WordPress. The new service boasts staggering performance improvements for sites that might otherwise be slowed down by shared hosting, slow database lookups, or sluggish plugins:

Our testing… showed a 72% reduction in Time to First Byte (TTFB), 23% reduction to First Contentful Paint, and 13% reduction in Speed Index for desktop users at the 90th percentile, by serving nearly all of your website’s content from Cloudflare’s network. 

APO uses Cloudflare Workers to cache dynamic content and serve the website from its edge network. In most cases this eliminates origin requests and origin processing time. That means visitors requesting your website will get near instant load times. Cloudflare reports that its testing shows APO delivers consistent load times of under 400ms for HTML Time to First Byte (TTFB).

The effects of using APO are similar to hosting static files on a CDN, but without the need to manage a complicated tech stack. Content creators retain their ability to create dynamic websites without any changes to their workflow for the sake of performance.

Version 3.8 of Cloudflare’s official WordPress plugin was recently updated to include support for APO. It detects when users make changes to their content and purges the content stored on Cloudflare’s edge.

The new service is available to Cloudflare users with a single click of a button. APO is included at no cost for existing Cloudflare customers on the Professional, Business, and Enterprise plans. Users on the Free plan can add it to their sites for $5/month. The service is a flat fee and is not metered.

Cloudflare’s announcement has so far been well-received by WordPress professionals and hosting companies and many have already begun testing it.

WordPress lead developer Mark Jaquith called APO “incredible news for the WordPress world.”

“On sites I manage this is going to lower hosting complexity and easily save hundreds of dollars a month in hosting costs,” Jaquith said.

After running several speed tests from six different locations around the world, early testers at Kinsta got remarkable results using APO:

“By caching static HTML on Cloudflare’s edge network, we saw a 70-300% performance increase. As expected, the testing locations furthest away from Tokyo saw the biggest reduction in load time.

“If your WordPress site uses a traditional CDN that only caches CSS, JS, and images, upgrading to Cloudflare’s WordPress APO is a no-brainer and will help you stay competitive with modern Jamstack and static sites that live on the edge by default.”

George Liu, a “self-confessed page speed addict” and Cloudflare Community MVP, performed a series of detailed tests on the new APO product with his blog. After many comparisons, he found that Cloudoflare’s WordPress plugin with APO turned on delivers results similar to his heavily optimized WordPress blog that uses a custom Cloudflare Worker caching configuration.

“You’ll find that Cloudflare WordPress plugin’s one click Automatic Platform Optimization button does wonders for page speed for the average WordPress user not well versed in page speed optimizations,” Liu said.

“Cloudflare’s WordPress plugin Automatic Platform Optimization will in theory beat all other WordPress caching solutions other than you rolling out your own Cloudflare Worker based caching like I did. So you get a good bang for your buck at US$5/month for Cloudflare’s WordPress plugin APO.”

Liu also warned of some speed bumps with the initial rollout, as Cloudflare’s APO supports a limited set of WordPress cookies for bypassing the Cloudflare CDN cache, leaving certain use cases unsupported. APO does not seem to work on subdomains and users are also reporting that it’s not compatible with other caching plugins. It also disables real visitor IP address detection.

Cloudflare is aware of many of these issues, which have been raised in the comments of the announcement, and is in the process of adding more cookies to the list to bypass caching. Due to some plugin conflicts, APO may not be as plug-and-play as it sounds for some users right now, but the product is very promising and should improve over time with more feedback.

Gutenberg 9.1 made a backward-incompatible change to its theme.json file (experimental-theme.json while full-site editing is under the experimental flag). This is the configuration file that theme developers will need to create as part of their block-based themes. Staying up to date with such changes can be a challenge for theme authors, but Ari Stathopoulos, a Themes Team representative, wrote a full guide for developers.

Jon Quach, a Principal Designer at Automattic, has also been busy creating a tool to help theme authors transition to block-based themes. He recently built a UI-based project called Theme.json Creator that builds out the JSON code for theme authors. Plus, it is up to date with the most recent changes in the Gutenberg plugin.

Tools like these will be what the development community needs as it gets over the inevitable hump of moving away from the traditional theme development paradigm and into a new era where themes are made almost entirely of blocks and a config file.

While plugin development is becoming more complex with the addition of JavaScript, theme development is taking a sharp turn toward its roots of HTML and CSS. We are barreling toward a future in which far more people will be able to create WordPress themes. Even the possibility of sharing pieces of themes (e.g., template parts and patterns) is on the table. This could not only empower theme designers by lowering the barrier to entry, it could also empower some end-users to make the jump into theme building.

However, the theme.json file is one aspect of future theme authorship that is extremely developer-oriented. JSON is a universal format shared between various programming languages. It is meant to be read by machines and is not quite as human-friendly as other formats. As the theme.json file grows to accommodate more configuration options over time, the less friendly it will become to simply typing keys and values in.

It makes sense to build tools to simplify this part of the theme building process.

That is where the Theme.json Creator tool comes in. Theme authors pick and choose the options they want to support and input custom values. Then, the tool spits out everything in properly-formatted JSON.

Using the Theme.json Creator tool.

One big thing the tool does not yet cover is custom CSS variables. This feature is a recent addition to the theme.json specification. It allows theme authors to create any custom property that WordPress will automatically output as CSS. In his announcement post, Stathopoulos covered how to create a typographic scale with custom properties and use those variables for editor features, such as line-height and font-size values.

Currently, Theme.json Creator’s primary focus is on global styles. However, Gutenberg allows theme authors to configure default styles on the block level. For example, theme designers can set the color or typography options for the core Heading block to be different from the default global styles. This provides theme authors with fine-tuned control over every block.

Theme.json Creator does not yet support configuration at this level. However, it would be interesting to see if Quach adds it in the future.

The focus on setting up global styles is a good start for now. This is still an experimental feature. The great thing about it is that it can help theme authors begin to see how one piece of the block-based themes puzzle fits in. It is a starting point for an entirely new method of adding theme support for features when most are accustomed to adding multiple add_theme_support() PHP function calls.

With the direction that theme development seems to be heading, it is easy to imagine that it could evolve into a completely UI-based affair at some point down the line. If templates are made up of blocks and patterns, which anyone can already build with the block editor, and if styles will essentially boil down to a config file, there will be little-to-no programming required to build a basic WordPress theme.

If someone is not already at least jotting down notes for a plugin that allows users to create and package a block-based theme, I would be surprised. For now, Theme.json Creator is removing the need to write code for at least one part of the theme design process.

Jetpack’s highly anticipated 9.0 release has landed, introducing some of the new features the team has previewed over the past week. Users can now publish WordPress posts to Twitter as threads. This new feature is available as part of the Publicize module when you have connected a Twitter account.

Posting Twitter threads is a feature that only works with the block editor, as it takes advantage of how content is naturally split into chunks (blocks).

In the comments on his demo post, Automattic engineer Gary Pendergast gave a more detailed breakdown of the logic Jetpack uses to ensure full sentences aren’t broken up in the tweets.

“With the mental model now being focused on mapping blocks to tweets, it’s much easier to make logical decisions about how to handle each block,” Pendergast said. “So, a paragraph block is the text of a tweet, if the paragraph is too long for a single tweet, it tries to split the paragraph up by sentences. If a sentence is too long, then it resorts to splitting by words. Then, if there’s an embed/image/video/gallery block following that paragraph, we can attach it to the tweet containing that paragraph. There are additional rules for other blocks, but that’s the basic process. It then just iterates over all of the supported blocks in the post.”

Pendergast published his post as thread to demonstrate the new feature in action. The advantage of posting a thread from your WordPress site is that it doesn’t end up getting lost in Twitter’s fast-moving timeline. Most important Twitter threads evaporate from public consciousness almost as soon as they are published. Publishing threads from your website ensures they are better indexed and easier to reference in the future.

Jetpack Adds Loom Block for Embedding Screen Recordings

Loom was added to Jetpack as a new oEmbed provider three weeks ago. The video recording service allows for recording camera, microphone, and desktop simultaneously. The service is especially popular in educational settings. Jetpack 9.0 introduces a new Loom block for embedding recordings.

“Loom is growing in popularity as it is being recommended more and more to assist in distance learning efforts,” Jetpack Director of Innovation Jesse Friedman said. “Now more than ever we want to be able to help those working, learning, and teaching from home. The Loom block was a natural addition to join the other Jetpack video blocks which now include YouTube, TikTok, DailyMotion, and Vimeo.”

Loom’s free tier allows users to record up to 25 videos, but the Pro plan is free for educators. Friedman confirmed that Jetpack does not have any kind of partnership with Loom. The team decided to support the product to assist professionals, educators, and students. Having it available as a block also makes it more convenient for those using P2 for communication.

As anticipated, Jetpack 9.0 also provides a seamless transition necessary to ensure Instagram and Facebook embeds will continue working after Facebook drops unauthenticated oEmbed support on October 24. The Jetpack team reports that it “partnered with Facebook” to make sure these embeds continue to work with the WordPress.com REST API.