Wordpress Planet

Subscribe to Wordpress Planet feed
WordPress Planet - http://planet.wordpress.org/
Updated: 10 hours 26 min ago

WPTavern: Gallery Block Refactor Expected To Land in WordPress 5.9

Tue, 08/24/2021 - 00:37

Last week, a GitHub pull request I had been watching since October 2020 on the Gutenberg repository was finally merged into the codebase. It changes the structure of the WordPress Gallery block to be a container for nested Image blocks. The new format is expected to land in WordPress 5.9.

For those who want to begin testing it early, it should ship with Gutenberg 11.4 next week. However, you can grab the nightly test version from Gutenberg Times to see it in action now. To use the new Gallery format, you must enable it from the Gutenberg > Experiments admin screen.

“If you have ever added a custom link to an image block and then tried to do the same on a Gallery image, you will understand the frustration and confusion of not having consistency between different types of image blocks,” wrote Glenn Davies in the refactor announcement post. “This inconsistency is because the core Gallery block stores the details of the included images as nested <img> elements within the block content. Therefore, the images within a gallery look and behave different from images within an individual image block.”

At the surface level, the Gallery block refactor does not change much for many users. They will still add images to galleries as they have for years. However, for more advanced usage, it opens a world of possibilities.

One oft-requested feature is the ability to add links to individual images in galleries. In the past, users could only link to attachment pages or the media file itself. Both options applied to all images. With the most recent change, users can modify each Image block, including customizing its link.

Adding a link to an Image block within a Gallery.

While this allows for handling something as simple as links, there is so much more that users could do.

In a theme that I have been building, I have a custom Gallery block style that allows users to create a group of images with a Polaroid-style frame around them. It is something fun for folks who do not want the all-business-all-the-time look. Sometimes, I like to throw in a bit of whimsy.

Polaroid-style frame for galleries.

The problem with that block style is that it does not go far enough. For example, I also have Tilted Right and Tilted Left styles for individual Image blocks. However, users are unable to apply those within a Gallery. It would be easy to make those available to the entire set or randomize different “tilt” styles. However, the ideal method would be to control the design at the Image level.

The same is true for other options. Users could do something fun like add block styles and mix in custom colors, borders, and more.

Colored Polaroid-style frames with different “tilts.”

There are other fun things users might be able to do, such as alternating square and rounded styles:

Alternating square and circle images.

The new structure may not be without some issues early on. WordPress will likely continue supporting the old format for a while for backward compatibility. All new Gallery blocks will be in the new. However, core should eventually automatically transform the old markup over.

Theme authors who have added custom CSS will be those with the most potential work ahead. Attempting to support both the new and old markup could be an exercise in frustration. The new Gallery block has broken output with my custom theme — margins and widths are off.

All styles for the new format begin with, at least, .wp-block-gallery.blocks-gallery-grid.has-nested-images. This will likely overrule custom theme styles. I have yet to figure out the obsession with chaining selectors in the core code. It creates a ton of code bloat and forces theme authors into a specificity battle. I am hoping this gets dialed back a bit. Either way, theme authors have plenty of time to test and implement any fixes if needed.

In the long term, I am excited about the potential of breaking away from the idea of just adding images to galleries. For example, I would love to see a grid option for something like the following:

Gallery with quote.

Nesting a quote in the middle of my image gallery could be a fun block pattern idea that does not rely on a mishmash of stacked Column blocks. We will see what the future holds.

For now, turning Gallery blocks into containers is a welcome step.

WordPress.org blog: WP Briefing: Episode 15: A Very WordPress Blooper

Mon, 08/23/2021 - 22:14

Ever wonder what it’s like behind the scenes of WP Briefing? Listen in on this episode for a little levity and Josepha’s bloopers.

Have a question you’d like answered? You can submit them to wpbriefing@wordpress.org, either written or as a voice recording.

Credits Transcript

[contemporary intro music]

Josepha Haden Chomphosy  00:10

Hello, everyone, and welcome to a bonus briefing. Normally I talk to you about WordPress and stuff, but I figured that we all need a little levity in our lives right now. So today’s episode is actually just a series of bloopers and mistakes that I’ve made while recording. When I was preparing for this podcast, no one mentioned the deep weirdness of standing alone in your closet talking to yourself, nor did they realize just how lost I can get in the surpassingly, lovely lyricism of a lilting line, and then just have no idea what I’m supposed to be reading in the script that I wrote for myself. So, my dear friends, I hope these bring you a little laugh. And if we’ve got any luck at all, you may also hear me singing to myself, my computer, or about how terrible my talking just was. Here we go!

Josepha Haden Chomphosy  01:12

Hello, everyone, and welcome to a bonus briefing. I know I wasn’t going to sit boop, boop. 

Josepha Haden Chomphosy  01:21

I messed up the thing where I’m talking about how I mess up, of course. I’m going to do it one more time, and you can choose whatever is a reasonable thing there. 

Josepha Haden Chomphosy  01:33

Because we had such a lengthy WP Briefing, WordPress, I’m going to just start that over again. Sorry, everyone.

Josepha Haden Chomphosy  01:42

My friends. Oh, no. I don’t know how I end my own show. How do I end my own show? There we go. Sorry. 

Josepha Haden Chomphosy  01:52

That was a weird way to say that. I’m going to start over again from the transition. And then we’re just going to go straight through to the end. Maybe.

Josepha Haden Chomphosy  02:03

The names that… I sound weird. I sound like I don’t know what my words are. And I said I wrote the words. I said I was all going to go in one go, and I’m a liar today. Okay, here we go. For realsies!

Josepha Haden Chomphosy  02:16

Final first last take. Here we go. Sorry, I made myself laugh. 

Josepha Haden Chomphosy  02:22

Matt Mullenweg. And, and I, I’m also in that group. I don’t know why I said that like it was a surprise. I have me too. I’m also in there. 

Josepha Haden Chomphosy  02:33

Ugh, I ran out of air. For reasons, it was a short sentence. I don’t know why I ran out of air. 

Josepha Haden Chomphosy  02:43

Coming out on April 14. That’s not true. It’s April 13. Right?

Josepha Haden Chomphosy  02:50

On the form below to share the. Pfft – what are the things! 

Josepha Haden Chomphosy  02:58

This is WP Briefing episode seven, no title because I don’t know what to call it because I gave it a title already. I gave it two titles, and then couldn’t remember why I gave it those titles. So I’ll come up with a title before we publish it. But I also have no idea what it is. I’m going to ask for help. 

Josepha Haden Chomphosy  03:17

Testing project since I have too many commas, and I really believed in my comma when I said it. 

Josepha Haden Chomphosy  03:24

Prior to Gutenberg… pfft. Open source software like WordPress. I was going to smash that sentence into half a sentence. I was going to say when you know what you’re workussing on you have a solution which is not my friends of thing. So, I am just going to say the sentence again. 

Josepha Haden Chomphosy  03:47

I was sitting over here wringing my hands for some reason during that entire list. And so if you can hear me wringing my hands, which would be a whole new height of anxiety for anyone, you let me know, and I will rerecord that also.

Josepha Haden Chomphosy  04:00

Get a concept of. Nope, this is a lie. Get a concept of where to get your tickets is the silliest thing. I’m starting over from the small list of big things. Also, because I got too excited about how big my list is. I am going to get that excited again. But I will try not to shout about it. 

Josepha Haden Chomphosy  04:17

“Humming intro song” Dun dun dun dun dun. 

Josepha Haden Chomphosy  04:23

Sorry, I had to scroll up, and I try not to scroll up when I’m talking in case maybe my whole computer turns into a microphone. Sorry, I’m just going to keep going because this has been a fine take so far. 

Josepha Haden Chomphosy  04:34

Mercy! I have words that I can say with my mouth. They aren’t these words today. It seems.

Josepha Haden Chomphosy  04:45

Build up to… Oh my goodness. My stomach grumbled, and this microphone, I know,  picked it up. And so I’m going to redo bullet two so that we don’t just have a small monster under the bed in the middle of the podcast. 

Josepha Haden Chomphosy  05:03

Also, like DEI, I feel s—Eh – maybe I should say, DEI, somewhere in there, so it’s clear for people cause I’m talking to people and not actually a screen. 

Josepha Haden Chomphosy  05:17

Before I joined the WordPress project, the majority of my work with accessibility was in the context of the digital divide. Now, when talking about the digital divide, there are three concepts around quote-unquote, getting things to people. And those concepts are… I guess I could say the thing, hold on one second, I can do it. I feel like I’m chopping up my words like I’m not really breathing very well. So I apologize. But here we go again.

Josepha Haden Chomphosy  05:58

Don’t include that one. Sorry, I’m so nervous about this episode that, like, my mouth is getting dry, and I worry that you can hear it, and it drives me nuts every time I hear podcasters with a dry mouth, and you can just like hear it clicking and always stresses me out. I’m like, someone should give that poor thing a drink of water. And I just know I’m going to feel that way about myself later. And so I’m trying to stay hydrated, but it also means that I have to stop every two paragraphs and take a drink of water. I apologize for that interlude. I am about to start again, at my next section, which is like, halfway through.

Josepha Haden Chomphosy  06:39

Also, I learned that you can hear me swallowing my water with this microphone because it is a spectacular microphone. And so, I apologize for that as well. All right. Here I go. I’m going to do it all in one take. Watch me. 

Josepha Haden Chomphosy  06:56

But I also have questions, especially about how to move everything forward. Mm-hmm. Whoops. I put especially in the wrong spot. But I also thought…

Josepha Haden Chomphosy  07:10

 Ta da, we did it. Gosh, that’s a short one. 

Josepha Haden Chomphosy  07:16

I did it. Where’s my where’s my turning offing button. 

Josepha Haden Chomphosy  07:22

Tada! And scene and done.

Akismet: Version 4.1.11 of the Akismet WordPress Plugin is Now Available

Mon, 08/23/2021 - 18:05

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

  • Added support for Akismet API usage notifications on Akismet settings and edit-comments admin pages.
  • Added support for the deleted_comment action when bulk-deleting comments from Spam.

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.

WPTavern: WordPress Contributors Actually Do Listen to Feedback and Engage With the Community

Sat, 08/21/2021 - 00:51

I am a writer. That gives me a license — not to be overused — to steer into hyperbole once in a while. I get to be critical, sometimes overly, because I can come back the next day and shower the WordPress project with praise. Perhaps, at times, I forget to be as fair or kind as I should be. Maybe I miss the mark when pointing out faults once in a while. I am sometimes simply wrong (as one reader recently pointed out, that was the case with 90% of what I wrote). And, for those times that I do step out of bounds, I am sorry.

However, it always comes from a genuine love of our community and loyalty to the WordPress mission.

I had planned on writing about an upcoming feature change for WordPress today, but something more pressing came up. As I was working through that article, a new comment landed in my inbox for approval. It was on the borderline, that gray area where I had to determine whether it added enough value to the discussion. I felt like it needed a thoughtful reply and not the knee-jerk reaction I had initially written. It was gnawing at me because I knew few things could be further from the truth:

When Matias and Justin respond to comments and ask the commenters to supply more details about the problems they mentioned, I doubt many will do that, since many of us already know that the WordPress developers don’t listen to us. They maybe pretend to listen, but the evidence shows that they do not. As one other commenter mentioned, we are suffering the tyranny of the minority.

Christian Nelson

It is disheartening when I see comments that state that the core contributors do not listen to users. However, I do understand where some of that sentiment may come from. There have been many pet features I have been passionate about that have never gotten the green light. Tickets that seemingly die out from lack of interest. Unresolved disagreements. It can become easy to think that you are shouting into the void.

However, it is not because developers are not listening. That is not a fair statement to make.

In my line of work, I follow nearly every aspect of the WordPress project. From Trac tickets to GitHub pull requests, from business acquisitions to theme development, I tend to dabble in a bit of it all.

More often than not, I see others who care as deeply about the project as I do. I watch the core/inner developers — the folks who do the bulk of the work — gather and act upon as much feedback as possible. I see the same from people who are less in the public spotlight but just as vital to the community. Everything I see stands as overwhelming evidence that they listen. There is so much engagement on GitHub, Slack, and the Make blogs that I cannot keep up with it all.

Matías Ventura, the Gutenberg project lead, has always been approachable and seems to care deeply about the project’s success. I cannot recall ever reaching out to anyone working on WordPress who did not respond, even when I approached them outside of my role as a writer for WP Tavern.

I am amazed at how much time and energy Anne McCarthy puts into the FSE Outreach Program. Mostly, it is because I do not think I could do that job. For every complaint, criticism, or issue I have mentioned, she has dug up an existing ticket or filed a new one. She routinely does this for everyone who provides feedback on FSE.

I could list name after name after name of others who do the same, going above and beyond their typical roles.

Today, I was reminded that we all — including myself — sometimes need to step back and evaluate how we view this project and the people who are working on it.

Thousands of people contribute code, documentation, design mockups, translations, and much more. There are plugin authors who see a problem they want to solve. Developers who figure out how to do something and write a tutorial. This, still, is barely scratching the surface.

Contributing directly to the core project or being involved with the Make WordPress teams is often a thankless job. But, I am happy that so many are willing to bear the brunt of the criticism and continue working.

Not everything we want will be implemented how or when we want it. Developers must balance each new feature or change against different, often conflicting, feedback. They do not always make the “right” call, but the best thing about software is that you can iterate upon it, bettering the platform from feedback on the earlier implementation.

Sometimes, WordPress simply needs more folks contributing to create a new feature or implement a change. Developers are only human.

We are all riding this ship together. We should strive to be kind and fair, avoiding blanket statements of the people who pour their hearts and souls into the project.

If nothing else, let’s take folks at their word when they ask for more details about a problem. That could very well be the first step in actually finding a solution.

Before stepping off my soapbox, I want to simply say one thing to those who contribute in any capacity to the WordPress project: thank you.

WPTavern: Get Your Free Tickets to WordCamp US Online 2021

Sat, 08/21/2021 - 00:49

WordCamp US 2021 will be held online this year on October 1. The free, one-day event will be packed with speaker sessions, workshops, and networking opportunities for attendees.

Organizers opened the call for speaker nominees earlier this month to speak on topics within the scope identified for this year: Connection, Contribution, and Inspiration:

We want to hear about unsung heroes doing great things with the latest WordPress releases, about successful businesses that could only have happened with WordPress, educators who are using WordPress with their students, and inspirational stories of community and connection. We also want to hear about innovative technology implementations and cutting edge design methods that can inspire site owners to do even more with WordPress. 

The themes seem to be centered around the kinds of the stories one might hear at an in-person WordCamp around a meal, all of the organic connection that WordPress enthusiasts around the world have craved for the past 18 months. It’s impossible to recreate online but the event’s organizers are committed to spotlighting stories that will “help WordPress users find success with WordPress no matter how they use it.”

The deadline to nominate speakers has passed, but those who were nominated can find a list of recommended topics on the talk submission page. Recommendations include block development, making and using block patterns, FSE (full site editing), why companies should prioritize open source contribution, inspiring WordPress stories, entrepreneurship, marketing, e-commerce, SEO, and more.

Organizers seem set on bolstering the community during this difficult year of mostly online-only events. The talk submission page encourages speakers to find topics that will help users be successful on their journeys with WordPress:

As our goals with programming this year aim towards creating content that will help WordPress users become more successful with the platform, your first submission could ideally be focused on teaching users something they didn’t know when they signed on for WordCamp US 2021. We want to ensure that the content covered at this year’s WCUS is memorable and shared, ensuring that, no matter if online, in-person or hybrid, all future WCUS events are seen as those not to be missed.

The deadline to submit talk ideas is August 22 and prospective speakers are limited to three ideas. Organizers receive hundreds of submissions every year (more than 500 in both 2018 and 2019) and speakers are encouraged to send only their best ideas. Selected speakers will be contacted by August 27 and announced August 31. All sessions will be recorded prior to the event and recorded talks are due September 23.

Tickets for WordCamp US went on sale this week. They are free but you must sign up on the registration page for your entrance pass.

WPTavern: Jeremy Keith Resigns from AMP Advisory Committee: “It Has Become Clear to Me that AMP Remains a Google Product”

Fri, 08/20/2021 - 17:07

Jeremy Keith, a web developer and contributor to the web standards movement, has resigned from the AMP Advisory Committee. Keith was selected for the committee last year, despite his well-documented criticisms of the AMP project. In his resignation email, he cites Google’s control of the project and its small percentage of open source parts as reasons for his growing resentment:

I can’t in good faith continue to advise on the AMP project for the OpenJS Foundation when it has become clear to me that AMP remains a Google product, with only a subset of pieces that could even be considered open source.

If I were to remain on the advisory committee, my feelings of resentment about this situation would inevitably affect my behaviour. So it’s best for everyone if I step away now instead of descending into outright sabotage. It’s not you, it’s me.

During his time with the committee, Keith worked on defining what AMP is and pushing for clarification on whether the project encompasses more than just a collection of web components. The Google-controlled AMP cache and validation aspects of the project were the most concerning in evaluating his continued participation. Although the AMP Validator is open source, the rules for validation are controlled by Google:

I was hoping it was a marketing problem. We spent a lot of time on the advisory committee trying to figure out ways of making it clearer what AMP actually is. But it was a losing battle. The phrase “the AMP project” is used to cover up the deeply interwingled nature of its constituent parts. Bits of it are open source, but most of it is proprietary. The OpenJS Foundation doesn’t seem like a good home for a mostly-proprietary project.

When AMP joined the OpenJS Foundation in 2019, skeptics hailed the transfer as “mostly meaningless window-dressing.” What Keith witnessed during his time with the advisory committee lends credit to these early doubts about AMP being able to gain independence from Google:

Whenever a representative from Google showed up at an advisory committee meeting, it was clear that they viewed AMP as a Google product. I never got the impression that they planned to hand over control of the project to the OpenJS Foundation. Instead, they wanted to hear what people thought of their project. I’m not comfortable doing that kind of unpaid labour for a large profitable organisation.

Even worse, Google representatives reminded us that AMP was being used as a foundational technology for other Google products: storiesemailads, and even some weird payment thing in native Android apps. That’s extremely worrying.

Keith’s experience echoes some of the claims in the ongoing antitrust lawsuit against Google, led by Texas Attorney General Ken Paxton and nine other state attorneys general. The complaint states that the transfer of the AMP project to the OpenJS Foundation was superficial:

Although Google claims that AMP was developed as an open-source collaboration, AMP is actually a Google-controlled initiative. Google originally registered and still owns AMP’s domain, ampproject.org. In addition, until the end of 2018, Google controlled all AMP decisionmaking. AMP relied on a governance model called “Benevolent Dictator For Life” that vested ultimate decision-making authority in a single Google engineer. Since then, Google has transferred control of AMP to a foundation, but the transfer was superficial. Google controls the foundation’s board and debates internally [REDACTED].

Keith was originally inspired by fellow dissenter Terence Eden to join the committee in hopes of making a difference. Eden eventually resigned from the committee in December 2020, after concluding that Google has limited interest in making AMP a better web citizen:

“I do not think AMP, in its current implementation, helps make the web better,” Eden said. “I remain convinced that AMP is poorly implemented, hostile to the interests of both users and publishers, and a proprietary and unnecessary incursion into the open web.”

Three days after Keith’s resignation, the foundation published a post titled, “An update on how AMP is served at the OpenJS Foundation.” The post seems to address Keith’s impression that Google does not intend to hand over control of the project.

“When the AMP project moved to the OpenJS Foundation in 2019, our technical governance leaders shared a plan to separate the AMP runtime from the Google AMP Cache, and host the AMP runtime infrastructure at the vendor-neutral OpenJS Foundation,” OpenJS Foundation Executive Director Robin Ginn said. “OpenJS is happy to report that this complex task of re-architecting the AMP infrastructure is making tremendous progress thanks to input and guidance from the AMP Technical Steering Committee (TSC) and AMP Advisory Committee, as well as thanks to the AMP Project and OpenJS teams for coming together despite the work and life challenges that were sometimes faced during the pandemic.”

The statement reiterated AMP’s status as an open source project multiple times. Ginn did not elaborate on the “tremendous progress” but did announce a new development – the decision to be more hands-on in hosting AMP infrastructure.

“What’s new is that after disentangling the AMP runtime from the Google AMP Cache, the OpenJS Foundation will manage the servers that deliver the AMP runtime files (the download server and the CDN),” Ginn said. “As planned, the OpenJS Foundation has been involved in the implementation of hosting the CDN and has been spending additional time to fully understand the technical requirements.”

The OpenJS blog had not communicated any updates on the AMP project for nearly a year. While this post seems like a reaction to the news of Keith’s resignation, it publicly confirms that the teams are still working on the infrastructure transfer. In the end, this may not be enough to convince critics that AMP is not simply a Google product with a fancy affiliation designed to make it more appealing to detractors. So far, the project’s new home at the OpenJS Foundation has done little to bolster public opinion in the face of allegations that identify AMP as having an important role in Google’s anti-competitive practices.

WPTavern: Second Annual WPMRR Virtual Summit To Kick Off September 21

Fri, 08/20/2021 - 00:21

WPMRR is gearing up for its second annual WPMRR Virtual Summit after the success of last year’s event. This year’s online-only conference will run from September 21 – 23. WPMRR and WP Buffs founder Joe Howard is hosting the event alongside guest host Brian Richards, the organizer behind WordSesh and WooSesh.

The event is free to attend for everyone. Even for those unable to make it, each session’s recording will be available via the WP Buff’s YouTube channel at no cost.

WPMRR and WP Buffs will be donating $1 per registrant and $1 per comment posted during all three summit days to Lawyers for Good Government, a non-profit organization of lawyers with a mission to fight for equal rights, opportunities, and justice.

A formal announcement of the speaker lineup and schedule is expected next week. As of now, all speakers are confirmed.

“The WPMRR Virtual Summit is a three-day online conference that helps us fulfill our mission: to actively help as many people as possible responsibly achieve their MRR goals,” said Howard.

He also said the WPMRR Podcast carries this mission forward by telling unfiltered stories of successful entrepreneurs. On the WPMRR Community side, the goal is for members to grow their MRR together. The summit provides an onramp for newcomers into the community.

Like 2020, the event’s talks and roundtables will be held over Vimeo Live. However, this year, they will be streamed directly into the WPMRR Virtual Community space. The goal is to make it easier to transition attendees into becoming full-fledged community members, continuing their education and experience beyond a once-per-year event.

“The virtual summit will be a fantastic event, but often it’s difficult for conferences to provide ongoing support, advice, and community to make sure what was learned at the event is actually implemented, tested, and integrated into attendees’ businesses,” said Howard. “This will make it far simpler to give direct access to our community to those who want to responsibly build their MRR alongside others all year round, not just for three days.”

The three-day event will be broken down as follows:

  • September 21: Sales & Marketing
  • September 22: Operations & Systems
  • September 23: Website Management

The summit will use Circle to handle discussions via its commenting system. This should allow communication to happen at everyone’s preferred pace.

“Our plans are to do a Q&A, manage the ‘Hallway,’ and provide a space for attendees, speakers and sponsors to all interact via asynchronous communication via the WPMRR Community,” said Howard.

All About MRR

MRR is an acronym for Monthly Recurring Revenue. It is about generating repeated income every month instead of getting paid once for a product or service — a subscription-based model.

I asked Howard to break down why this concept is crucial for new or potential business owners in the WordPress space. He responded with several reasons for going this route over a one-time revenue model.

“If you’re selling a product for $100 and want to make $100K in a year, you need to find 1,000 new customers to sign up,” he said. “If you’re selling something for $100/mo instead, you need far less because customers are paying you every month instead of just once. In most situations (especially because lead generation is a pain point for most businesses), delivering ongoing value to ~100 customers is far less work than finding 1,000 new customers!”

This leads to having multiple avenues to growing your business. With recurring revenue, entrepreneurs can continue attracting new customers and selling new features to existing ones.

Howard also pointed out that subscriptions representing a chunk of total revenue creates a more predictable financial situation. This can lead to making easier budgeting decisions. Focusing on recurring revenue means constantly delivering value to customers instead of always chasing new sales.

“Running a subscription business is way less stressful because the business model is simply more resilient,” said Howard. “If you rely on SEO to drive new leads to your business and Google penalizes you, your business will literally stop generating any revenue whatsoever if you only serve one-time customers. But if you have subscription revenue and this happens, you still have a collection of customers who pay you every month, giving you far more runway to figure out next steps before the business fails.”

I also asked Howard about the different levels of MRR and how the game changes as revenue increases.

“Often, what gets you to $10K MRR evolves significantly if/when you’re on your way to $83K MRR ($1M/year),” he said. “This is what makes the WPMRR Community so valuable, as we have different spaces folks can join based on what their MRR goals are.”

He also pointed out the crossover between those starting out and those running larger businesses, saying that it was important for both audiences to learn from the other.

“We can listen to advice and best practices all day, but we don’t know when inspiration will hit us,” he said. “That’s why I think it’s important for those starting out to tune into some more advanced talks and for those running larger businesses to listen to beginners as well.

“All our speakers will be instructed by Brian Richards (our day-of technical director and speaker preparer) to be really explicit about the context around any advice they’re giving and how it could apply to businesses of different sizes and scales. That way, we can help people at whatever stage they’re at!”

The entire written interview with Howard is available via the WPMRR Community site. It is worth reading for those who want to learn more about the event and MRR from his experience or an unfiltered version of this story.

WPTavern: Gutenberg 11.3 Introduces Dimensions Panel, Adds Button Padding Support, and Speeds Up the Inserter

Thu, 08/19/2021 - 01:16

Earlier today, Gutenberg 11.3 landed in the WordPress plugin directory. The latest update introduces a new dimensions panel for toggling spacing-related block options. The Button block now supports the padding control, and the Post Featured Image block has new width and height settings.

One of the release’s highlights was a speed improvement for both opening and searching within the inserter. The opening time dropped over 200 ms, from 370.35 ms to 137.28 ms. Search speed went from 190.37 ms to 67.24 ms.

The latest release includes a simplified color picker library. Rich previews for links, a feature introduced in Gutenberg 10.9 for external URLs, now works with internal site links.

Theme authors should enjoy the reduced specificity of the reset and classic editor stylesheets. Such changes always make it a little easier for theme authors to match editor and front-end styling.

Dimension Panel for Spacing Controls Toggling the padding and margin controls for the Site Tagline block.

Gutenberg 11.3 introduces a new Dimensions panel for blocks that support either margin or padding controls. The feature adds an ellipsis (...) button in place of the typical open/close tab arrow. Users can select which controls they want to use.

The long-term goal is to clean up the interface, only exposing controls that a user actually needs. Because such needs are subjective, allowing users to toggle them on/off is an ideal route to take.

The current downsides are twofold. Once choosing to display margin or padding controls, the panel itself cannot be collapsed. This exacerbates the very problem that the new feature attempts to solve — decluttering the sidebar interface. For me, at least, I always want quick access to spacing controls. However, I do not always need them shown.

The second issue is that the user choice of what to display does not seem to be stored. Each time you work with a block, you must select which controls should appear.

The new Dimensions panel is only one part of the process of wrangling sizing (width and height), spacing (padding and margin), and related controls for blocks. Work toward a more well-rounded solution is still underway. Presumably, the development team will address these issues and others in future releases. However, those who run the Gutenberg plugin in production should expect oddities with usage.

The Block Visibility plugin has the most user-friendly version of such a toggle control right now. It is not yet a perfect solution, but it works a little better than what is currently in Gutenberg.

Button Block Padding Testing the new Button block padding option with TT1 Blocks.

It is no secret that I dislike the default padding of the Button block when using the TT1 Blocks theme (block-based version of Twenty Twenty-One). I have made it one of my missions to routinely point it out, even going so far as refusing to use the block in the last call for testing as part of the FSE Outreach Program.

An oversized button is not always the wrong stylistic choice on a webpage. Context matters and I somehow continue to run into scenarios where I need something a bit more scaled back. Control over the Button block’s padding has been on my wish list for months, and the Gutenberg development team delivered.

As of 11.3, users can control the padding of individual Button blocks. It will now appear as an option within the new Dimensions panel mentioned earlier.

Prayer answered. Now, let us move toward adding padding controls to all the blocks.

The one potential issue some users might run into is maintaining consistent spacing when using multiple Button blocks together. The easiest way to do this is to add and style the first, then duplicate it to create others with the same spacing. This is not a new issue; it applies to all Button options where users want consistency within a group.

Featured Image Dimension Controls Adjusting a Post Featured Image block’s dimensions.

The Post Featured Image block has finally received a small but handy upgrade. In the past, users and theme authors only had a single option of deciding whether to link it to the post. Now, they can control the width and height of the image.

If a user sets a height for the image, the editor will reveal a separate “Scale” option with the following choices:

  • Cover (default)
  • Contain
  • Stretch

What do these options actually do? That would be a good question. Even as someone in the web design and development loop for close to two decades, I sometimes forget and must look them up. They are values for the object-fit CSS property and are likely to confuse users in many instances.

Cover and contain allow the image to fit within the containing element’s box while maintaining its aspect ratio (no stretching the image). The difference is that the cover value will be clipped if it does not fit and the contain value may be letterboxed. A stretch value will fill its container regardless of the aspect ratio.

Depending on the image’s aspect ratio on its container, each of the values could essentially display the same thing on the screen. Or, they could provide wildly different results. Coupling these dimensions controls with wide and full alignments (also width-related options) could make for some unpredictable experiments too.

The theme designer in me wants to disable the UI for this altogether and present something slightly more controlled: an image size selector.

Such a selector should not be confused with width and height controls. WordPress theme authors have been registering custom image sizes for years. The primary use case for this was featured images. Users can use these sizes with the current Image and Latest Posts blocks. However, they do not yet have this option with Post Featured Image.

I am in the camp that believes image size controls should have been the first addition to the block. It is such an integral part of WordPress theme design that it cannot be left out, and I have been fightingor at least nagging — to make sure that theme authors can control featured images via custom sizes.

Fortunately, there is an open ticket for custom image size support. Among other still-missing features, it is a blocker for many theme authors looking to take the leap toward block themes.

There are plenty of use cases for the new options, such as automatically cropping a post grid’s featured images to a square. I am just impatiently awaiting a more robust set of tools for the Post Featured Image block.

WPTavern: WordPress.org Experiments with Rejecting Plugin Submissions with the “WP” Prefix to Mitigate Potential Trademark Abuse

Wed, 08/18/2021 - 17:32

Many in the WordPress developer community were surprised to learn that WordPress.org is rejecting plugins with the “WP” prefix in the name after Joe Youngblood tweeted the rejection note he received. Although that restriction was put into place approximately seven months ago, there was no official communication on the change.


As the result of the controversy gaining attention on social media and other channels, WordPress Plugin Team member Mika Epstein posted an explanation on the original meta trac ticket, the reasoning for how and why “wp” is being blocked:

Using wp- at the beginning of plugin permalinks, yes. Due to how we built this out, the display name is what gets checked and flagged. You can use WPPluginName (no space) and Plugin Name for WP.

This stems from part of a longer conversation going on with the Foundation, regarding handling the actual misuse of ‘WordPress’ in plugin names (which, as we all know, is actually trademarked and as such should not be used in your plugin name at all).

Because using WP Blah Blah as a name tends to lead to people changing it after approval to “WordPress Blah Blah” we put a pause on it to try and get a handle on how bad is this, what’s the depth of the problem (vs the actual headache of WC -> WooCommerce in names) and so on.

There is also the reality that using ‘WP’ or ‘Plugin’ in a plugin permalink is unnecessary and can be harmful to SEO due to repetitive words.

No one is claiming WP is trademarked, we’re just trying to minimize confusion and prevent people from accidentally violating trademarks in the future because they change WP to WordPress later on.

Whether or not “wp” was trademarked became a particular point of confusion because the commit message on the change said: “Adding in some more things to block based on use and trademarks.”

The conversation with the WordPress Foundation that Epstein was referencing was a private discussion about how the team can mitigate trademark abuse.

“This came up in the midst of an ad hoc brainstorm about the ways that the loophole could be more effectively managed, and so there wasn’t a lengthy public discussion on it,” WordPress Executive Director Josepha Haden Chomphosy said.

“It was part of an experiment for handling that loophole more effectively and wasn’t meant to be permanent. The great thing about experiments in WordPress is that when we see that we’re throwing out the good along with the bad, we can make the necessary changes to do it better.”

Haden Chomphosy said that although the original discussion was private, the team plans to make it public via the new meta ticket that was opened yesterday for improving the checks on plugin submissions.

“All future discussions will be on the ticket, so as people work on it, then the conversations will be available there,” she said when asked how the trademark abuse mitigation experiment will be evaluated.

The WordPress Foundation does not have any employees, but Haden Chomphosy said the representatives who can help with the grey areas of trademark guidelines include herself, Andrea Middleton, and Cami Kaos. She also confirmed that “WP” is not a WordPress trademark and the Foundation is not pursuing trademarking the term.

Although each of these individuals referenced have a long track record of protective care for the WordPress community and have demonstrated a sincere desire to see the project grow, they are all employed by Automattic. The Foundation could use some outside representation if those running it are engaging in private decision making and giving directives to the WordPress.org Plugin Team that have significant ramifications for the ecosystem as a whole.

For years, the WordPress community has been encouraged to use WP instead of WordPress in plugin names, so the decision to reject plugins with WP in the name is a major, controversial change.

The problem for me is 1. you are penalizing everyone for something a few people do. 2. it doesn't actually fix the problem because I could change any of my plugin names to WordPress after the fact and 3. There's NO official announcement explaining this.

— Brad Williams (@williamsba) August 17, 2021

Those who oppose the current experiment have pointed out that it unfairly penalizes everyone for the few who change their plugin names after approval. It polices potential misuse instead of providing a solution that can flag actual trademark abuse.

Some plugin developers have noted that having WP in the plugin name is necessary to differentiate it from extensions for other platforms, since WordPress.org is not the only place where their products are distributed. Many successful businesses have been created on top of plugins with WP as a prefix in the name, such as WP Mail SMTP, WP Fastest Cache, WP Migrate DB, to name just a few.

Whether it is beneficial or detrimental to use WP in a brand’s name is immaterial to the discussion at hand. With the current trademark abuse mitigation experiment in place, all new plugin developers hoping to use the WP prefix will have their plugins rejected. Fortunately it isn’t retroactive, but if the team decides the experiment of banning WP in plugin names is a success, it may be up for discussion.

Springing experiments on the community without publicly communicating the intent is a misstep for the Foundation. If allowing WP in the name creates wrong expectations for plugin developers regarding their ability to change the name to use WordPress, then the problem needs to be fixed at the root. WordPress.org needs to find a better way to inform developers about which terms are actually trademarked and develop a technical solution to flag name changes that do not comply. This may be a difficult technical problem to solve regarding plugin submission and updates, but it’s worth investing in it to respect plugin authors’ freedoms.

BuddyPress: BuddyPress 9.1.1 Security and Maintenance Release

Wed, 08/18/2021 - 00:49

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

The 9.1.1 release addresses three security issues:

  • The activation key was included into the responses of the create_item method of BP REST API Signup controller. Discovered by Brajesh Singh.
  • An SQL Injection vulnerability was fixed in BP_Notifications_Notification::get_order_by_sql(). Discovered by David Cavins.
  • An SQL Injection vulnerability was fixed in BP_Invitation::get_order_by_sql(). Discovered by David Cavins.

These vulnerabilities were reported privately to the BuddyPress team, in accordance with WordPress’s security policies. Our thanks to the reporters for practicing coordinated disclosure.

BuddyPress 9.1.1 also fixes 3 bugs. For complete details, visit the 9.1.1 changelog.

Get BuddyPress 9.1.1

You can get it clicking on the above button, downloading it from the WordPress.org plugin directory or checking it out from our Subversion repository.

If for a specific reason you can’t upgrade to 9.1.1, we also included the security fixes to our branches from 2.9 to 8.0. Here’s the list of the available downloads for the corresponding tags, you can also find on our WordPress.org Directory Advanced page:

  • If you are using BP 2.9.4 and can’t upgrade to 9.1.1, please upgrade to
  • If you are using BP 3.2.0 and can’t upgrade to 9.1.1, please upgrade to 3.2.1
  • If you are using BP 4.4.0 and can’t upgrade to 9.1.1, please upgrade to 4.4.1
  • If you are using BP 5.2.0 and can’t upgrade to 9.1.1, please upgrade to 5.2.1
  • If you are using BP 6.4.0 and can’t upgrade to 9.1.1, please upgrade to 6.4.2
  • If you are using BP 7.3.0 and can’t upgrade to 9.1.1, please upgrade to 7.3.2
  • If you are using BP 8.0.0 and can’t upgrade to 9.1.1, please upgrade to 8.0.2

WPTavern: A Discussion With Gutenberg Project Lead Matías Ventura on the Barrier to Entry

Tue, 08/17/2021 - 23:20

Last week, I published an opinion piece on the barrier to entry in the modern WordPress era. The article followed a tweet and post by Chris Wiegman that stated the current learning curve was extremely high, regardless of past experience. Members of the community responded with a flurry of articles, podcasts, and videos.

Because modern WordPress is primarily centered on Gutenberg, I reached out to the project’s lead, Matías Ventura. The goal was to bring some balance to the discussion. Unfortunately, he could not get back to me until a few days after the story was published. However, given his unique insight and perspective on the project, his views should be shared.

In our discussion, we covered the topic of the barrier to entry from multiple viewpoints. Depending on where a specific developer, designer, or user steps onto the ramp, each will have a different experience.

Why Are We Having the Same Discussions?

The block editor shipped with WordPress 5.0 in December 2018. We are closing in on three years, but it often feels like we are having the same discussions. One has to wonder why we have not yet moved beyond that point.

“I think this is a case of the size of the WordPress community, its diversity of perspectives, and the fact that we do still have a lot of work to do to continue to make things accessible,” said Ventura. “I’ve seen people that start with no prior WP knowledge get flying super quickly.”

He recounted one story of a popular block library that launched last year. The creators were designers but did not recognize themselves as developers. However, the APIs allowed them to build an entire plugin that would not have been possible with their previous skillset.

“To me, this was a triumph of the block APIs that are available for builders,” said Ventura. “But this is just one person’s perspective. It doesn’t invalidate PHP developers expressing frustration at the complexities of modern front-end tools.”

Theme Creation and New Onramps

On the theme creation front, we were in agreement. There are new ways (and more on the way) for non-developers to ease into visually building various parts of a website without needing the entire weight of theme development knowledge.

Ventura began his WordPress journey with theme development after first being exposed to Flash in the early 2000s. He recalled downloading a bunch of PHP files and thought he could execute by opening them. It is safe to say that he has learned a lot since then.

“Being able to edit pieces of a theme is a crucial aspect of democratizing access to code,” he said. “I think we are going to be seeing a lot of people get started by diving into how templates work. Or by playing with the Query block, which used to be a hidden piece unless you knew a bit of PHP already.”

He mentioned that, in some ways, this aspect of the block editor allowed solo creators or small teams to build unique projects, pointing to Aino as an example.

“I’m seeing a ton of designers for whom contributing to WordPress was difficult or a gated experience,” he said. “There’s a lot of developer entitlement when we say things used to be easy. They were not easy for a large chunk of the population that might have been excellent contributors if there were more avenues to contribute.”

Patterns may be the first official stepping stone, one avenue among many that WordPress could facilitate in the future. Ventura envisions a possible .ORG-hosted visual theme builder that would allow users to create and publish without ever touching code. We are likely years from seeing such a project come to fruition, but lofty goals can lead to innovative ideas that we have yet to think of.

Building Block Plugins

Block plugins are a different beast than themes. The barrier is undoubtedly higher, but how big is this hurdle for traditional WordPress developers?

“Going from contributing a pattern to building a block is a big leap right now,” said Ventura. “While there are folks that can learn it quickly, it’s still a big barrier for people. I think there are several layers to this: documentation could be an order of magnitude better in both organization and presentation. I hope we can do a lot more there.”

He is also curious about tools for building blocks, such as a blend of BlockBook and CodePen. He mulled over the possibility of blocks used for creating other blocks, a scenario in which developers might only need to write HTML with the tool interpreting features like Rich Text fields. At the very least, he believes we are barely scratching the surface of what the block-building experience could be.

“The biggest challenge is that there’s a tendency in PHP trained folks to neglect a bit the implications on the UX if it means the developer experience is simpler,” he said. “I think this is most visible in the shortcode/forms approach to UX as opposed to direct manipulation, which is hard to codify from a PHP set of APIs.”

WordPress/Gutenberg Contribution and the Bus Factor

Outside of building themes or plugins, the third and arguably the highest level of participating in the WordPress development ecosystem is direct contributions to the block system. Is contributing to core harder today than it was just a few years ago?

“I think this is a good point, but I think it partially misses that contributing to WP internals like WP_Query was also very difficult,” he said. “We just got used to it. We have received more contributions to Gutenberg from people than what I have seen in Trac in my years there.”

Ventura did admit that GitHub could be a factor in the amount of contribution, which many developers tend to favor over Trac.

While building an editor is a difficult task and requires certain levels of expertise, other parts of the system, such as the component library or smaller packages, might offer alternative paths for some people to get involved.

“Apart from this, I do agree that there’s also a higher level of expectations for what software should be capable of doing these days that make contributing meaningfully a harder task than before,” he said.

Historically, other parts of WordPress that relied on the JavaScript model, such as the media library, have not had high levels of contribution.

“I don’t think this is a topic we’ll exhaust any time soon, and it’s important to not become complacent and just say ‘oh things are just hard’ because an important part of the WP project being open source is that users can modify said software, and for that, they need to understand it,” he said. “I think we can introduce a new generation of people to coding if we do things right and work together more.

The secondary aspect of this is whether there is a bus factor for WordPress. If so, what is the number? This is a common question around the most technically challenging pieces of software. If X number of contributors with the requisite knowledge of the most complex pieces of a project were hit by a bus (sorry for the grim imagery), would the development grind to a halt?

It is not something often discussed in WordPress circles because it has never seemed to be an issue. However, if contributing to core carries too high of a barrier to entry, is there a number where the project cannot continue?

“I think, in some ways, it’s more sustainable now,” said Ventura. “We have been a lot more open with contribution permissions on the Gutenberg repo, and it has resulted in a larger amount of folks contributing. I think we might see a split between contributors that are comfortable with the back-end side of WP and those that are more comfortable with the interactive pieces.”

One thing the team did not entirely anticipate was Gutenberg’s use in projects outside of WordPress. This can add to its sustainability factor. He pointed to the WordPress mobile app being an example where others can meaningfully contribute. And other mobile apps are wanting to use it for their tools. At Automattic, where Ventura is employed, they are also working on adopting editor technologies for Tumblr.

“I think a broader topic of discussion, in general, is that contributing meaningfully to WP has become the privilege of those sponsored to work on it full time,” he said. “I think that’s in some ways natural but also a bit of a tragedy.”

WPTavern: New Boilerplate Speeds Up Building “Nearly Headless” WordPress Themes

Tue, 08/17/2021 - 22:00

Alex Standiford, a WordPress developer at AffiliateWP, has released a boilerplate for what he is calling a “nearly headless” WordPress theme. It uses Underpin ,Nicholas, and AlpineJS to provide an app-like experience for a website while providing the flexibility for rendering specific pages using PHP instead of Javascript.

In a post titled “Headless WordPress is Overrated: A Case for The Nearly-Headless Web App,” Standiford describes a few of the drawbacks of going fully headless.

One problem with fully-headless WordPress is routing. Behind the scenes, WordPress has a lot of logic built-in to handle routing, and with a headless approach you have to build something to handle that on the front end. Ultimately, you’re re-inventing the wheel, and it takes a lot of extra time to build.

Another problem with headless WordPress quickly becomes apparent the moment you try to use most WordPress plugins. The ugly truth is that you usually have to re-invent a lot of things just to get the plugin working properly. 

Standiford’s nearly headless system is a product of his rethinking headless WordPress. He wanted to preserve the app-like feel as well as all of WordPress’ built in capabilities and those available through the plugin system.

The Nearly Headless WordPress theme uses AlpineJS for rendering, which Standiford says is light, easy-to-understand, and “plays exceptionally nice with PHP server-side rendering.” It is loaded around HTML template tags that source post content using WordPress’ REST API. The system uses session storage to keep things speedy and minimize the number of REST API calls.

Standiford’s WP Dev Academy learning site and his agency, DesignFrame Solutions, are both using beta versions of the nearly headless system. Since the time those sites were developed, Standiford has completely rewritten the system and made significant improvements based on what from what he learned from earlier versions. He has a live demo of the current version available at nearly-headless.dev.

.@DFS_Web’s website redesign will make it possible to visit any page without an internet connection shortly after the first page is loaded. This makes this site FAST even if your internet connection is slow. pic.twitter.com/keOxyMU8cq

— Alex Standiford (@AlexStandiford) December 9, 2020

The nearly headless approach is comparable to a traditional headless approach in terms of performance, thanks to Standiford’s Nicholas library, which includes client-side caching and a routing layer as the application support for the theme.

“Nicholas will load content via REST, much like how a headless site does,” Standiford said. “In these cases, the load times are very similar to what you’d see on a headless site. In fact, they behave, and fundamentally work in the same manner. The key is Nicholas also stores the data in session storage after the page is visited, and any time that page is loaded thereafter, it is loaded instantly.”

How far can the boilerplate take you? Developers who use it should be ready to extend or replace the basic templates it includes to load WordPress. It doesn’t enqueue any CSS. Key functionality is broken into separate dependencies so users can stay up to date as the project evolves.

“For all intents and purposes, the boilerplate is a blank slate,” Standiford said. “You can think of the boilerplate as _s for the nearly headless approach. All of the dependencies, scripts, and items needed to run the engine are included in the boilerplate. All of the dependencies are packaged up in Composer or Node, so your theme can be updated as the system improves without re-writing your entire theme.”

Standiford has some major improvements planned for the future of the boilerplate. It is currently compatible with the block editor and many plugins but requires a compatibility mode.

“The big up-front improvement is going to be removing the need for compatibility mode on as many pages as possible,” Standiford said. “Many block libraries, forms plugins, and other things have specific scripts that they expect are loaded on the page that the app has no way to know about, and because of this, some plugins won’t work without turning on compatibility mode. It is possible to make these work, but I would benefit from help from plugin developers to help me understand what styles/scripts need to be included when the app runs.”

Standiford said he sees an opportunity to create npm packages that integrate other plugins, and ensure they work as expected.

“Yoast and other SEO plugins for example set the SEO information in the head of each page, and right now that doesn’t happen without writing another piece of middleware,” he said. “It’s not too difficult to add it, but it’s one of those things that could be packaged up and included instead of manually being written for every theme that uses this approach.”

Another item on the Nearly Headless WordPress theme boilerplate roadmap is improvements to how dependencies are compiled to better avoid plugin and theme conflicts. Standiford thinks this would make it easier to distribute themes built using this method on the WordPress.org directory, or even to sell them commercially. He has also been experimenting with automatically caching all the content on a page when it loads, without bogging down the browser or overloading the server with requests. The result would be instantaneous page loads with reduced server loads.

The Boilerplate for Nearly Headless WordPress Themes is available on GitHub and Standiford is also creating a course that will help developers build sites using this nearly headless paradigm. He anticipates it will be released in November 2021.

WPTavern: A Second Look at ElmaStudio’s Aino Theme and Companion Block Plugin

Mon, 08/16/2021 - 22:09

I am about a month away from my second anniversary writing for WP Tavern. There has been one project that I have followed since the beginning of this journey. In some ways, we are learning the ropes and growing in this block-based WordPress era together.

In 2019, just before taking on this role, one of the first story notes I jotted down was some thoughts on ElmaStudio’s Aino Blocks plugin. However, it was not until nearly a year later when the team took the project out of beta testing, and I followed up with a review of the flagship Aino theme and plugin.

Perhaps it is fortuitous that the team recently released version 2.0 of its theme at just about the same time I started taking stock of my time at the Tavern. Maybe this is fate’s way of telling me that we should always have a yearly update on Aino — sound like a good idea?

It also did not hurt that Matías Ventura, the Gutenberg project lead, name-dropped their work in a conversation we had last week. “It fills me with joy when I see initiatives like [Aino] built by just a couple folks,” he said. “Apart from the user aspects of our work, it’s what makes it all worth it.”

This was part of a more in-depth discussion related to the barriers to entry in the modern WordPress era. We agreed that one of the easier onramps was theme creation and site design, a focus area for Aino.

It was time to dive back into the project. I had not looked into it deeply enough since my last review a year ago.

Admittedly, at the time, I had mixed feelings about it. I initially thought the plugin launched too late. It seemed to be yet another block library after larger companies beat them to the punch.

Ellen Bauer, who co-owns the company alongside Manuel Esposito, encouraged me to check back in as they continued building. They were merely setting the stage for their vision.

“We wanted to release the Aino blocks and theme on WordPress.org since they are stable to use right now,” she wrote in the comments. “But the actual work is just starting for us, since we are now creating block patterns for our system, and I think it is only then that users will see why we built the theme and blocks in a certain way.”

A Year Later One of multiple feature patterns from the Aino theme.

The ElmaStudio team is taking that leap that most theme companies will inevitably need to take. They announced that Aino 2.0 ditched its classic garb and moved to 100% blocks earlier this month.

For this particular theme, the move was not as monumental as it would be for others with more intricate layouts. Aino itself was always a minimal design, more of an open canvas for blocks than anything. It is the sort of theme meant to get out of the way and allow the user to create individual pages from the ground up.

That may have been its downside a year ago. The team had built a plugin for easing users into the page-building process, but its single block pattern did not provide much of a starting point. Its Grid block is a powerful tool but also feels like it is catered more toward designers/developers. Its options may be too advanced to some end-users depending on their familiarity with CSS terminology.

Today, this looks much different. The Aino theme comes with — count ’em — 42 block patterns. It is also where this project shines. I may have mentioned something about this being the route to go last year:

The company’s best bet is to focus on building patterns. Its first pattern shows some promise. I am holding out hope for more interesting work to come.

The team took that dev-friendly base of the Grid block and built a system of easy-to-use layouts on top of it. Users merely need to click to insert and customize.

Aino’s Grid block used in a portfolio pattern.

Because Aino’s patterns are built upon this grid foundation, the design studio’s layouts are fine-tuned for each screen size.

Unless other theme authors build on top of the same plugin or a similar grid-based block, they are left with stock WordPress/Gutenberg. This provides limited options for responsively designing more complex layouts. This should be a focal point of the WordPress 5.9 release cycle, but it could be a while before we have something as powerful as the various grid blocks available via plugins.

ElmaStudio’s groundwork in the previous two years is bearing fruit, at least in terms of what the team can create. With the foundational elements in place, nothing should stop them from building the next 42 patterns and more.

A team pattern from the Aino theme (also built on the Grid block).

I am still lukewarm about most of the blocks in the plugin, think the Hero and Testimonial blocks should just be patterns, and the [Aino] Buttons block should be an options extension for the one in core. The Grid layout is the feature that all the best things about the Aino project hinge on.

The Aino theme itself seems unimpressive on its own, at least at first glance. However, the project is not whole until it is coupled with the Aino Blocks plugin.

The theme needs some design work on its default spacing. For example, paragraphs that follow a wide or full-aligned block have no gap above them. Blockquote text butts against the side of the left border. Trivial bugs like these are easy fixes. Sometimes, it is not evident that there is an issue until a Gutenberg plugin update, which often leaves theme authors chasing changes. Such is the life of a designer living on the bleeding edge, supporting the latest features via a block theme.

I am happy I once again had the opportunity to dive back into the Aino project. A year makes a difference, and the duo behind the theme and plugin has made use of the time. Right now, they have a solid project for users who want to build out their pages with blocks. There are enough patterns for just about any website owner.

Matt: Funding, Buyback, and Hiring

Mon, 08/16/2021 - 17:22

In February of this year, Automattic closed a new primary funding round of $288M, bringing in some great new partners including BlackRock, Wellington, Schonfeld, and Alta Park. Existing investors ICONIQ and Aglaé (Bernard Arnault) also participated. This round was common stock, and like all funding since 2011, included a proxy assigning me the right to vote the shares.

Automattic was very busy during this time frame, as we were working on what would become the Parse.ly, Day One, and Pocket Casts acquisitions, our investments in Element and Titan, plus more acquisitions and partnerships we haven’t announced yet, so we haven’t mentioned the February funding round until now. And while we are a bit surprised the fundraise did not leak to the press, it’s now been an awkwardly long time since February and I’m pleased to formally announce it now.

And since then, Automattic has continued to grow at a rapid pace and we recently took the opportunity to do a $250M share buyback at a $7.5B valuation that just closed last week. The buyback was primarily targeted at current and former employees. 

We’ve grown and increased our valuation at a rate higher than most other alternate investments available to investors. However, some of Automattic’s employees and former employee shareholders have been part of our journey for a very long time. Selling a bit of their equity holdings could have a significant impact on their lives. 

Automattic was founded 16 years ago and is still private, so it’s important for us to try to provide liquidity to any shareholder who wants it. We do the same with our internal A12 stock plan where we let our employees buy our shares and also offer an opportunity for all holders to sell them back to Automattic, every quarter. (I need to do a longer post on that.)

One interesting thing we’ve been doing in these buybacks is holding the shares as treasury stock within the company instead of canceling the shares at purchase. This allows us to buy shares that come onto the market, and then when an investor comes and wants to put a larger quantum of capital into the company, we can re-sell the treasury shares that the company bought earlier. In effect, we are providing both a sell-side and buy-side for Automattic stock, serving previous and new investors and making money on these trades since we bought and took the risk earlier. We’ve established a logical valuation methodology, which is based on a simple multiple of the last twelve month’s revenue, so shareholders can track and anticipate performance.

All of this has been a lot of fun and we’ve seen a great amount of success, but it’s not all smooth sailing; we still have our share of challenges, probably the biggest being hiring. We have significantly scaled up our ability to find and hire great folks, with 371 accepted offers already in 2021 and it’s only August. However, with the growth of WooCommerce (hiring a Head of Payments) and our enterprise business, WPVIP, in particular, we need to move faster to keep up with the opportunity. For me and many other of the most-tenured Automatticians within the company hiring is the top priority. To that end, I’m also looking for someone to partner with me and our top executive group (which we call Bridge) in Creative Talent Development, an executive recruiter to help craft the highest performing teams of executives for each of our businesses. 

We have a multi-decade opportunity ahead of us to create the best solutions for the open web platform of WordPress, and WooCommerce is doing the same thing for commerce; growing together over the long-term with people passionate about the same mission is my favorite part of my job.

Matt: Funding, Buyback, and Hiring

Mon, 08/16/2021 - 17:22

In February of this year, Automattic closed a new primary funding round of $288M, bringing in some great new partners including BlackRock, Wellington, Schonfeld, and Alta Park. Existing investors ICONIQ and Aglaé (Bernard Arnault) also participated. This round was common stock, and like all funding since 2011, included a proxy assigning me the right to vote the shares.

Automattic was very busy during this time frame, as we were working on what would become the Parse.ly, Day One, and Pocket Casts acquisitions, our investments in Element and Titan, plus more acquisitions and partnerships we haven’t announced yet, so we haven’t mentioned the February funding round until now. And while we are a bit surprised the fundraise did not leak to the press, it’s now been an awkwardly long time since February and I’m pleased to formally announce it now.

And since then, Automattic has continued to grow at a rapid pace and we recently took the opportunity to do a $250M share buyback at a $7.5B valuation that just closed last week. The buyback was primarily targeted at current and former employees. 

We’ve grown and increased our valuation at a rate higher than most other alternate investments available to investors. However, some of Automattic’s employees and former employee shareholders have been part of our journey for a very long time. Selling a bit of their equity holdings could have a significant impact on their lives. 

Automattic was founded 16 years ago and is still private, so it’s important for us to try to provide liquidity to any shareholder who wants it. We do the same with our internal A12 stock plan where we let our employees buy our shares and also offer an opportunity for all holders to sell them back to Automattic, every quarter. (I need to do a longer post on that.)

One interesting thing we’ve been doing in these buybacks is holding the shares as treasury stock within the company instead of canceling the shares at purchase. This allows us to buy shares that come onto the market, and then when an investor comes and wants to put a larger quantum of capital into the company, we can re-sell the treasury shares that the company bought earlier. In effect, we are providing both a sell-side and buy-side for Automattic stock, serving previous and new investors and making money on these trades since we bought and took the risk earlier. We’ve established a logical valuation methodology, which is based on a simple multiple of the last twelve month’s revenue, so shareholders can track and anticipate performance.

All of this has been a lot of fun and we’ve seen a great amount of success, but it’s not all smooth sailing; we still have our share of challenges, probably the biggest being hiring. We have significantly scaled up our ability to find and hire great folks, with 371 accepted offers already in 2021 and it’s only August. However, with the growth of WooCommerce (hiring a Head of Payments) and our enterprise business, WPVIP, in particular, we need to move faster to keep up with the opportunity. For me and many other of the most-tenured Automatticians within the company hiring is the top priority. To that end, I’m also looking for someone to partner with me and our top executive group (which we call Bridge) in Creative Talent Development, an executive recruiter to help craft the highest performing teams of executives for each of our businesses. 

We have a multi-decade opportunity ahead of us to create the best solutions for the open web platform of WordPress, and WooCommerce is doing the same thing for commerce; growing together over the long-term with people passionate about the same mission is my favorite part of my job.

WPTavern: Early WordPress 5.9 Look: The Road Toward Deeper Responsive Block Design

Sat, 08/14/2021 - 00:31

Gutenberg project lead Matías Ventura announced the Preliminary Road to 5.9 on the Make Core blog earlier today. He covered several big picture items, including several sub-points for each. He also linked to a GitHub issue with specific tasks and tickets that need work.

The post covers notes on block patterns, navigation menus, the theme.json interface (global styles), design tools, and editing flows for block themes. There is a lot of information to take in and enough areas to cover various interests.

The most exciting focus of 5.9 might just be going deeper into responsive design at the block level, whether this is under-the-hood code or block options available via the UI.

“One of the biggest points of friction for pattern and theme builders are the lack of responsive tools available at a block level,” wrote Ventura. “This needs to be solved in a way that doesn’t disproportionally increase interface complexity.”

Intrinsic Web Design With Blocks Mobile design patterns shared by Ventura.

It is easy to become disgruntled at the slow progress toward responsive block options over the last few years. I am not entirely unhappy with it because I want the team to be methodical and approach this in a future-proof way, at least to the extent that it can.

Far too often, what we have seen with requests and even third-party plugins is the use of viewport-based media queries for controlling how blocks respond to different devices (e.g., desktop, tablet, and mobile). While such controls can sometimes be the right tool for the job, they are not always the correct path for component-based design.

Media queries tend to favor holistic design methodologies. However, component-based design is the modern face of the web. Blocks are just another component, and because developers or even users can place them anywhere in the overall design, we must approach how they respond to their surroundings more so than the browser viewport.

“The block model is a good case to apply some intrinsic design principles, since a block can occupy a place in many different layouts and containers, for which prescriptive media queries that don’t take context into account are inflexible,” wrote Ventura.

A simple example to look at is the core WordPress Columns block. We could easily add media query options for when each inner Column block breaks. However, how should the typography respond for three columns vs. four and at different widths? That is a function of the container’s size rather than the viewport.

And, how do such media queries work when Columns are nested within another Column? This becomes a more complex problem to solve if you are putting layout controls into the hands of users. Pushing the fast-forward button on responsive block options might feel good at the moment, but it could also create legacy baggage that will be hard to drop when a better solution rolls around.

Even something as seemingly simple as a basic website header can become complex when designing for user input. For theme designers, there is no way to know how many characters are in the site title, for example, or how many items are in the nav menu. The block system can complicate that further by allowing end-users to drop in other unknowns.

“Each block area should be intrinsically responsive allowing blocks to compose together, wrap, stack, and organize themselves to fit the different spaces and screens,” wrote Ventura. “For this to work well, container blocks need to absorb more layout controls.”

He also mentioned container queries as a possible expansion point when they are fully supported by browsers in the future. Chrome Canary currently has a support flag to enable the feature.

Container queries are a bit of a Holy Grail for designers. As web designer Ethan Marcotte wrote four years ago:

Maybe I’ll start here: in the last few years, my design work has focused much more on patterns, and less on “pages.” Instead of treating a responsive design as a holistic, unified thing, where every part of the layout changes and adapts at the same rate, it’s more helpful to break a responsive layout down into smaller, reusable bits of design, including things like “masthead,” “footer,” “image caption,” and so on.

In other words, my design process involves looking at a responsive design as a network of small layout systems. Each of those components are basically little responsive designs themselves, with their own sets of breakpoints.

Sound familiar? Yes, the WordPress block system is built on that same foundation of small layout components.

Anything that WordPress does today at the UI level needs to account for the container queries of the future. Or, at least make use of existing tools that could replicate the feature in some ways, such as the min(), max(), and clamp() CSS functions.

The trouble is figuring out which features should be exposed as block options vs. being handled under the hood. The development team must strike a balance between the user experience and flexibility for designers. Some things should “just work” out of the box, and others should be configurable on a case-by-case basis.

This should be one of the more interesting, complex, frustrating, and rewarding problems to solve in the WordPress 5.9 cycle. For those looking for a challenge, it might be the perfect entry point.

WPTavern: Wordfence and WPScan Publish Mid-Year WordPress Security Report

Fri, 08/13/2021 - 04:14

WPScan is on track to post a record-breaking year for WordPress plugin vulnerabilities submitted to its database, according to a collaborative mid-year security report the company published with Wordfence. In the first half of 2021, WPScan has recorded 602 new vulnerabilities, quickly surpassing the 514 reported during all of 2020.

The report is based on attack data from Wordfence’s platform and data from WPScan’s vulnerability database, providing a more comprehensive picture of the current state of WordPress security than either company could present alone.

One of the trends highlighted in the report is the increase in password attacks. Wordfence blocked more than 86 billion password attack attempts in the first half of 2021. Attackers use a variety of methods to gain access to WordPress sites, including testing sites against lists of compromised passwords, dictionary attacks, and more resource intensive brute force attacks.

Source: 2021 Mid-Year WordPress Security Report

Wordfence found the standard login to be the primary password attack target for 40.4% of attempts, followed by XML-RPC (37.7%). Since these attacks seem to be increasing, the report recommends that site owners use 2-factor authentication on all available accounts, use strong secure passwords unique to each account, disable XML-RPC when not in use, and put brute force protection in place.

Data from Wordfence’s Web Application Firewall shows more than 4 billion blocked requests due to vulnerability exploits and blocked IP addresses. The report includes a breakdown of the percentage of requests blocked by firewall per firewall rule. Directory Traversal accounts for 27.1% of requests. This is when an attacker attempts to access files without being authorized and perform an action such as reading or deleting a site’s /wp-config.php file, for example. This breakdown also highlights the fact that certain older vulnerabilities are still frequently targeted by attackers.

Source: 2021 Mid-Year WordPress Security Report

The vast majority of the vulnerabilities you hear about in the WordPress ecosystem come from plugins, with themes making up a much smaller portion. The report notes that only three of the 602 vulnerabilities catalogued by WPScan in the first half of this year were found within WordPress core.

In analyzing vulnerabilities by type, WPScan found that Cross-Site Scripting (XSS) vulnerabilities accounted for more than half of all them (52%), followed by Cross-Site Request Forgery (CSRF) at 16%, SQL Injection (13%), Access Control issues (12%), and File Upload issues (7%). Using scores from the Common Vulnerability Scoring System (CVSS), WPScan found that 17% of reported vulnerabilities were critical, 31% high, and 50% medium in severity.

Both Wordfence and WPScan claim that the greater number of vulnerabilities reported this year is indicative of the growth of the WordPress ecosystem and a maturing, healthy interest in security. Themes and plugins aren’t getting more insecure over time but rather there are more people interested in discovering and reporting vulnerabilities.

“First and foremost, we aren’t seeing a lot of newly introduced vulnerabilities in plugins and themes but rather we are seeing a lot of older vulnerabilities in older plugins and themes being reported/fixed that just weren’t detected until now,” Wordfence Threat Analyst Chloe Chamberland said. 

“Vulnerabilities aren’t being introduced as frequently and more vulnerabilities are being detected simply due to the higher activity of researchers which is in turn positively impacting the security of the WordPress ecosystem. Considering it isn’t newly introduced vulnerabilities that are being frequently discovered, I feel confident in saying that the increase in discoveries doesn’t indicate that the ecosystem is getting less secure at all but rather getting more secure.”

Chamberland also said she believes there is a domino effect when vulnerabilities are disclosed to vendors and they learn from their accidents, causing them to develop more secure products in the future.  

“Speaking from experience as I spend a lot of my time looking for vulnerabilities in WordPress plugins, things have definitely been getting more secure from my perspective,” she said. “Today, I frequently find capability checks and nonce checks in all the right places along with proper file upload validation measures in place, and all the good stuff. It’s become harder to find easily exploitable vulnerabilities in plugins and themes that are being actively maintained which is a great thing!”

The mid-year report is available as a PDF to download for free from the WPScan website. WPScan founder and CEO Ryan Dewhurst said he expects there will be an end of the year report for 2021. He has not yet discussed it with Wordfence but the companies are brainstorming about other ways they can collaborate.

WPTavern: Yoast Joins Newfold Digital, Team To Stay in Place

Thu, 08/12/2021 - 20:25

Earlier today, Yoast CEO Marieke van de Rakt announced the company had been acquired by NewFold Digital. Yoast and its SEO-related business are expected to continue operating as usual with its current team and maintaining its product line.

Newfold Digital is a global web solutions provider that serves small-to-medium businesses. The company has many brands under its umbrella, such as Network Solutions, Bluehost, and more.

“Yoast never had any funding before, it grew organically into a company with 140 employees maintaining a plugin with over 12 million active installs,” wrote van de Rakt in the announcement. “We don’t want to stop there! We’re planning to grow and improve even further! Joining Newfold Digital provides us with the freedom to build and iterate on ideas to further our mission.”

There are no plans to change the team or the culture around Yoast. One of the goals during the acquisition was to keep everyone in place, continuing work on their product line.

“Of course, some things change,” said Yoast founder and CPO Joost de Valk. “We’ll integrate into their systems (HR and finance). We’ll work on special offers for customers from Newfold. Our company changed so much over the five years, so it will change no matter what. I do feel that this opens up more security for growth and for developing new ideas.”

While Yoast does not plan to change its 140-person team, it is still bringing in fresh talent. The company has been hiring a lot lately and expects that trend to continue with 19 current job openings.

As host Nathan Wrigley and guest Cory Miller discussed on the latest episode of the Jukebox, acquisitions can be a welcome change for all parties. It can provide more financial stability and backing for the acquired company. It may allow the team to explore new features or new products that were not possible before. This can also work in the user’s favor in the long term.

“Marieke and I felt ever since this Covid pandemic hit that we needed a partner or some more financial backing,” said Joost de Valk. “Being totally bootstrapped was getting to us. We worried about the exchange rate of the dollar, for instance. We got risk-averse, and all around us other companies got financial injections.”

The husband-and-wife duo thought about selling part of their stock for additional funding but was worried about potential consequences. One such downside may have been the need to grow fast to keep investors happy.

“We wanted to find a place to keep Yoast SEO growing and to keep working on WordPress,” said de Valk. “We had help from RBC, a company that helps with these types of acquisitions. They introduced us to Newfold, and we had a really good connection right from the start.”

He remained tight-lipped about any new products or features in the pipeline, only saying that a lot is coming and things will speed up.

Newfold is the owner of several high-profile hosting brands, including Bluehost and HostGator — both offer a managed WordPress service. It would not be unheard of to see a company mix and match its various products to draw in more customers. Nor would it be surprising to eventually see Yoast SEO or even some of the commercial Yoast offerings as part of packaged hosting deals. WP Engine fully integrates StudioPress products, for example, into its packages. However, de Valk said they have yet to discuss anything on that front.

“You’re absolutely right that the things you’re proposing here make perfect sense,” he said. “So, I think we’ll work on those deals and, at the same time, team Yoast will work independently on their products.”

WPTavern: FSE Outreach Round #9: Building a Higher Ed Header

Thu, 08/12/2021 - 03:38

It feels like it has been ages since the WordPress community has had a call for testing Full Site Editing (FSE) features. The FSE Outreach Program was on a small hiatus. However, the WordPress 5.8 launch was also underway last month.

The program is an open call for testing various components of FSE. Thus far, volunteers have successfully provided feedback on features that have already landed in core WordPress, such as block-based widgets and template editing. Testers have delved into others that have yet to be released. Each testing round is open to anyone who can spare a little of their free time and share their findings. The goal is to break things and point out problematic areas of the user experience.

FSE Outreach #9 is a community-driven suggestion that calls for building a Higher Ed site’s header. Volunteers are asked to follow a 26-step process using the site editor beta feature in the latest version of the Gutenberg plugin and the TT1 Blocks theme.

I am a fan of this take on testing, and program lead Anne McCarthy seems to favor doing more of it in the future. “If you’d like to suggest an idea for a call for testing, know it’s very welcomed and all ideas will be weighed against current project priorities to figure out what makes the most sense to pursue,” she wrote in the announcement.

Since the project was all about Higher Ed, I decided to pay homage to my alma mater and use the colors that I wore proudly around campus for five years — and still do to this day. The following screenshot is the end result:

Before going forward, I must admit that I cheated to get that final look. The call for testing asked that we build from the TT1 Blocks theme. I was able to get close to that result, but I had to switch to a custom theme I have been working on to get past a few hurdles.

I went through each stage of testing with TT1 Blocks and will cover the issues I encountered.

Building a Higher Ed Header

Just getting off the ground, I ran into my first issue, which turned out to be a non-issue. The internet gods decided to play a trick on me, disallowing me from editing both the Site Title and Site Description blocks. I really wanted my fictional university to be “Gutenberg University,” but I could not do so without saving my progress and refreshing the browser tab. I was unable to replicate the issue, so I am hoping it was simply a fluke.

Using the Navigation block still seems the most troublesome area of site editing. I know how much work the development team has put behind the user experience for this feature but cannot help but wonder if there is a point where users can opt into managing its content (the links) via the traditional Nav Menus screen in WordPress. The site editor works fine for the design aspect, but I have yet to feel comfortable using it to manage links.

This stage of testing calls for adding multiple page links as both top-level and sub-menu items. When clicking the + button to add a link, my first instinct is to search for the page itself. However, the available field is a block search rather than a page search.

Accidentally searching for link in block search field.

To add an actual link, users must first add the Page Link block. Then, they can search for a specific page. This two-step process gets me every time.

I ran into the issue for nav menus mentioned in the call for testing where there is no space between items when used inside a Columns block. It pains the purist in me to admit it, but I had to use the Spacer block between each item to fix this. I did not need to do this with my custom theme because, I am guessing, I addressed this somewhere along the way.

The “space between items” option also failed to work with the Navigation block, ruining one of the early design ideas I had. I decided to go in a different direction.

Using right-alignment with the Search block did not work. Therefore, I used the 100% width option to align it with my right-aligned nav menu.

Time and time again, I needed to rely on the Spacer block to make adjustments. Part of this was because default margins and paddings are inconsistent among different blocks. The still-missing margin controls on nearly every block also played a hand in this. This is not particularly noteworthy. The development team is aware of and working on extending spacing controls — they just can’t get here fast enough for some of us.

A spacing issue is what led me to ditch TT1 Blocks and switch to a custom theme. The following screenshot is my final work with the former. You may notice the gaping green background between the nav menu group and the header image below it.

TT1 Blocks theme version with gap in header.

No amount of tricks or rearrangement of blocks seemed to remove that space, and I simply could not live with that. I had already solved about 90% of Gutenberg’s spacing issues with my own theme and did not feel like writing any new CSS to address this. Making the switch also meant that I could get rid of several Spacer blocks I had in place.

Aside from dropping in a header image, one other modification I made was skipping the addition of a Button block for the latest “Covid update.” I could not bear looking at TT1 Blocks’ overuse of padding. Instead, I nested a paragraph with a link within a column alongside a Navigation block.

As always, I enjoyed the process. This post is meant to be critical of specific areas in the hopes that it helps build a better WordPress. For all its faults, many other parts offer a solid user experience. Overall, the Gutenberg development team continues to impress.

WPTavern: Google Site Kit Plugin Ships Hot Fix for Critical Error That Caused Broken Websites

Thu, 08/12/2021 - 02:34

Google published an update to its Site Kit plugin for WordPress this afternoon with a hot fix for a critical issue affecting an unknown number of users. Reports of broken websites were popping up on Twitter and in the plugin’s support forum on WordPress.org. Users affected by the issue reported having a critical error on all sites using Site Kit, which forced deactivation of the plugin in recovery mode. In some cases it prevented them from accessing their dashboards.

“On Wednesday, August 11, we identified a fatal error in the Site Kit plugin that could be triggered by other plugins or themes using an unprefixed version of Composer,” Google Site Kit Support Lead Bethany Chobanian Lang said in a pinned post on the support forum.

Version 1.38.1 contains a hot fix for this issue, since it was critical enough to take down users’ websites. The plugin’s maintainers began investigating the issue less than 24 hours ago but are still not sure which plugins trigger the error due to their usage of Composer.

“The reports do not include which specific plugins or themes were causing this, but the error message clearly highlighted the code in Site Kit that was the problem,” Google Developer Relations Engineer Felix Arntz said. “Technically, that problematic code had been in Site Kit since several versions ago (months back), so maybe another plugin/theme recently got updated with new code that exposed the problem.”

After looking at popular plugins, Arntz said he hasn’t been able to find one so far that would have triggered the problem. Given Site Kit’s broad usage, other affected sites are bound to turn up once users realize there is a problem. Google launched the plugin in 2019 and has since amassed more than a million active installations. The majority of the plugin’s user base is running older versions, which may or may not be affected by the current issue.

WordPress.org shows 35.6% of the plugin’s users are on version 1.38.x. The hot fix is not backported for older releases, but users running Site Kit version 1.38 with background updates enabled should automatically receive the fix.