Frontity co-founders Pablo Postigo and Luis
Herranz

Automattic has acquired Frontity, the company behind an open source framework for building WordPress themes with React. The acquisition comes more than a year after the company raised €1M in funding in a round led by K Fund, with Automattic covering 22%. Frontity co-founders Pablo Postigo and Luis Herranz and their team will no longer be developing and maintaining the framework. Their new focus will be on contributing to the WordPress open source project and improving the full site editing developer experience.

“After a series of conversations, Automattic offered to sponsor our team to work directly on the WordPress open source project,” Frontity’s founders said in the announcement. “In particular, to contribute our expertise in developer experience, frontend tooling, performance, and UX to the WordPress core itself, instead of doing so only for an external tool.”

In a separate FAQ document, Frontity clarified that this acquisition does not mean the framework will be merged into WordPress, nor does it mean the team plans to bring React into the WordPress PHP or full site editing themes. The founders intend to apply their expertise to the Gutenberg project full time:

Even though Frontity is a React framework, it doesn’t mean that we are going to push React to the WordPress frontend. We will look at the Gutenberg and full site editing space to identify those areas in which our work could have the most significant impact, and work closely with the WordPress community to help improve its developer experience.

WordPress is already the best content platform on the web. We want to help it become the best development platform on the web.

In addition to putting the Frontity team on improving developer experience, Automattic is also investing in other ways that expand its support of the Gutenberg project. The company has recently hired a new head of developer relations who is building out a team tasked with improving the developer experience with Gutenberg and full-site editing. Birgit Pauli-Haack is a new member of that team and Automattic is also sponsoring her curation of the Gutenberg Times publication and the Changelog Podcast.

Frontity Framework Will Transition to a Community-Led Project

As the result of the acquisition and the team’s reassignment to working on Gutenberg, Frontity’s founders are transitioning the framework to be a community-led project. The team has prepared to leave the project in “a stable, bug-free position,” with documentation regarding what features they were working on. The framework is used by many companies and agencies, including high profile sites like the TikTok Creator Portal, popular Catholic news site Aleteia, and Diariomotor, a popular Spanish automotive publication.

“As far as we know, Automattic is not using Frontity Framework in any of its products,” Frontity CEO and co-founder Pablo Postigo said. “But we know there are a lot of Automatticians who have been following our progress closely. 

“We are aware that WordPress VIP does recommend Frontity for decoupled solutions, too. We are sure our experience and knowledge might be of help for this team as well.”

The departure of Frontity’s founders and team introduces some uncertainty into the future of the framework. When asked if it can survive as a community-led project, Postigo was optimistic but not certain.

“We still think that Frontity Framework is the best way to run a decoupled WordPress site with React and that this will be the case for a long time,” Postigo said.

“It is still too early to know what will happen. Frontity has a great community behind it, there are a lot of great projects which are using the framework in production, and there’s also a nice group of really active contributors. We feel really positive about the future of the framework.”

The easiest way to kill your WordPress plugin is to fail to let the world know about it. If you cannot manage a tweet, blog post, or quick note on Facebook, you may as well sign the death certificate then and there.

I get it. I have been there. Not everyone is a marketing guru, so putting out the right messaging might seem like speaking in a foreign language. But no messaging at all? That will not bode well for your young project.

Part of my job is finding plugins and sharing them with the community. Every week, I am on the lookout for that next great idea. Or, at least, a sort-of-good idea. I scour Twitter, regular blogs that I read, and official WordPress directories for plugins and themes. What I like most about writing about our beloved platform is not big business deals or the latest drama. While those pieces can be fun, I am most interested in what people create on top of the software. Whether a large company or an individual builds a new plugin, I am always excited when Monday rolls around. I can begin my search anew.

Often, I will find a new plugin that looks promising, so I dive into it. I install and activate it. At times, I find something so interesting that I have no choice but to share it. However, most of the time, I need a little push. To understand “the why” behind it. I do a quick check to see if they have written a blog post, tweeted about it, or shared it in some way. More often than not, nothing exists about it other than its listing in the plugin directory. And, reaching out to devs via email is often a hit-or-miss affair.

When you do not announce your new project to the world, it feels like you are not passionate about it.

I understand that some people simply hash out an idea and decide to drop it in the plugin directory. They are not in it for glory or even recognition. For them, it is just a piece of code they thought might come in hand for others. But, usage is the lifeblood of software. If no one else downloads, installs, and activates your plugin, can we really call it software?

Like the proverbial tree falling in the forest, whether it makes a sound is irrelevant if no one is around to hear it.

I have been mulling over whether to finishing writing this post for months, unsure if I was ever going to hit the publish button. I initially scratched down some notes in early April, attempting to understand why so few go through the trouble of doing any marketing of their plugins. I reached out to Bridget Willard to get insight from someone with a rich history in the marketing world. She had just published How to Market Your Plugin the month before, so the timing made sense.

However, I still felt too frustrated with the status quo in the WordPress community. A message from a reader wishing that we would mention alternative choices for plugin-related posts prompted me to revisit this. The truth is simple. So many projects fly under the radar because their authors begin and end their marketing by submitting to WordPress.org.

“Marketing is communication,” said Willard. “At the basic level, you must ‘tell people’ you have a product. The basic minimum is a blog post with social posts on Twitter, Facebook, and LinkedIn. It’s scary to market while you build, but that’s what the automobile industry does (along with others). You have to create the desire for the product — more than fixing a problem.”

While she tends to focus on products and services, I asked her what developers should be doing regardless of whether their plugins are commercial or free.

“I advocate with all of my being having a landing page on your main site (not a new site) promoting your plugin — while you’re building it,” paraphrasing from a chapter in her book. “Take signups for beta testers, start email marketing. The blog post is anti-climatic in many ways, and one or two tweets aren’t enough. Even better is to customize the sign-up ‘thank you page’ with something special — a video talking about your goals, for example. It’s not the time to have a tutorial or demo. This is about communicating your vision.

“The sad thing is that many plugin developers don’t see the need to spend money on a ‘free’ plugin. The axiom is true, ‘it takes money to make money.’ If you want sales, you need marketing. The sale for a free plugin is a download, and those are just as important.”

Part of me missed the old Weblog Tools Collection era. Every few days, the site would share a post with the latest plugins (themes too) with short descriptions of each. It was an easy win if you had no marketing skills. Developers could submit their new projects, and the team would share them with the community. When I was a young and upcoming developer, it was one of the only ways I knew how to reach folks in the WordPress community aside from pushing stuff from my own blog.

Today, we have far more avenues for sharing our work via social networking. Of course, the downside is that you have to cut through the noise.

In the long run, I would like to see an overhaul of the WordPress.org directory, focusing on the discoverability of plugins by feature instead of only popularity. Not all developers are known for their marketing skills. Having a little help from the directory they feed into could make it easier for budding developers to jump from hobby to business.

Until then, let the world know about your plugin. Even if it seems like you are shouting into the abyss, you may just hear an answer from someone who noticed your passion. If nothing else, let us know about it here at WP Tavern.

Since Frontity launched their open source framework, they have been making the integration between React and WordPress easier. Their proven drive and experience with clean technological solutions will benefit our efforts as we continue to make the block and theme APIs a joy to use and WordPress the best development platform on the web.

The next step in the growth of this relationship is for Frontity and its team to join Automattic and contribute to core WordPress.org as part of our commitment to Five for the Future.

I believe there’s still a lot that we can learn from decoupled systems and we can incorporate those learnings into WordPress itself as we emphasize performance, flexibility, and ease of development. I look forward to Frontity joining WordPress and channeling their efforts into the WordPress APIs, documentation, and Gutenberg’s full-site editing tools.

Howdy!

Greetings from Germany, where the weather is moody and federal election campaigns heat up. As the American rule to avoid politics and religion at dinner table discussions doesn’t apply, we have lots to talk about with family and friends we haven’t seen for over two years. You can view my photos, mostly landscapes, on Instagram.

As mentioned in the last edition, I have fabulous news.

I am thrilled to announce that on Monday, August 30th, I will start as developer advocate at Automattic. Automattic will also sponsor the Gutenberg Times and the Changelog Podcast. 

To be part of the WordPress developer relations team feels to me like coming home, and I am deeply grateful to Automattic for offering me the position. The best is yet to come for Gutenberg and publishing with blocks. I am elated, to be part of an astonishing team to take the world-wide WordPress community on the next journey.

Via previous surveys, you shared a considerable amount of great ideas on how to improve the Gutenberg Times, Live Q & As or Changelog Podcast. Now I will have the resources (= time) to implement some of them. We can hold more Live Q & As covering the topics suggested in the surveys, or invite guests to the podcast.

Share your ideas or comments via email [email protected] or leave a comment below. I want to read them all!

Now without further ado: There is a heap of links to share with you, after I skipped a week.

Yours, 💕
Birgit

Classic Editor plugin extended for one Year

The WordPress core committers officially extended the support for the Classic Editor plugin all through 2022. This gives everyone another year to migrate to blocks. 

Josepha Haden Chomphosy also wrote: “Still, if you’ve been putting off using the block editor, this is an excellent time to give it another shot. Since it first appeared in 2018, hundreds of WordPress contributors have made a lot of updates based on user feedback. You will be pleasantly surprised at how far it’s come!”

On the WordPress Tavern, Justin Tadlock interviewed, core committer, Jonathan Derosiers and has more details on the core team’s approach toward maintaining the plugin beyond 2022.

 “Keeping up with Gutenberg – Index 2021” 
A chronological list of the WordPress Make Blog posts from various teams involved in Gutenberg development: Design, Theme Review Team, Core Editor, Core JS, Core CSS, Test and Meta team from Jan. 2021 on. Updated by yours truly. The index 2020 is here

Gallery Block Refactor landed and needs testing

The Gallery block hasn’t had any significant update since the release in WordPress 5.0. It was clear that a different approach would be needed for the next iteration. Glen Davies spearheaded the Refactor of the Gallery block. The main change was to use the InnerBlock feature to create Galleries as collection of single image blocks.

This empowers content creators to assign different styles and links to individual images of the Gallery. Although the refactor progressed well, it didn’t make it into WordPress 5.8 as backwards compatibility with the earlier version and migration for existing gallery blocks needed more attention.

The code changes made it into the Gutenberg plugin and are available via the Experiments section. You can use the Gutenberg Nightly version, or the 11.4 Release Candidate, or wait until Wednesday (Sept 1) for the stable 11.4 release.

• Glen Davies posted the Gallery Block Refactor Dev Note.
• Justin Tadlock shares his experience: Gallery Block Refactor Expected To Land in WordPress 5.9

Need a plugin .zip from Gutenberg’s main (trunk) branch?
Gutenberg Times provides daily build for testing and review.
Have you been using it? Hit reply and let me know.

Gutenberg 11.3 released

Vicente Canales from Chile, wrangled the release of Gutenberg 11.3 and you can read What’s new in Gutenberg 11.3? (18 August) in his release post.

Justin Tadlock tested the new Gutenberg plugin version and has the details: Gutenberg 11.3 Introduces Dimensions Panel, Adds Button Padding Support, and Speeds Up the Inserter

In the new Episode of the Gutenberg Changelog #50, Grzegorz (Greg) Ziolkowski and I discuss the preliminary roadmap to WordPress 5.9, Gutenberg 11.3 release and Navigation Screen and Block.

As mentioned, Gutenberg 11.4 is already in the works. For testing purposes, the release candidate 11.4 RC is available for download. Final release is schedule for Wednesday, September 1st.

Subscribe to the Gutenberg Changelog podcast
🎙️ Spotify | Google | iTunes | PocketCasts | Stitcher |
🎙️ Pod Bean | CastBox | Podchaser | RSS Feed 

Navigation Blocks and Screen updates

The Gutenberg developers working on the Navigation Blocks and Screen met for a Hallway Hangout to discuss the current issues. (Github Tracking Issue). The goal of the discussion was to identify those that need to be resolved to take the block-based Navigation feature out of the experimental state and get it ready for the merge into WordPress Core, possibly for 5.9 in December. Dave Smith posted links to the recording and relevant issue on the Make/Core blog.

Building Blocks

Rich Tabor updated his tutorial How to add and remove Gutenberg block styles with Javascript. “And while it is relatively simple to add block styles using PHP, removing them is not quite as easy — especially block styles added by WordPress core (or any added client-side). Enter JavaScript… and I promise, it’s not as daunting as you might think.”

---

Ryan Welcher explains how to request data with the getEntityRecord selector and expands on some details and use cases. Welcher provides a series of query examples and then walks you through the method on how to create a loading state and update the queries.

Block Editor for site implementors and content creators

Justin Tadlock explored the new plugin Block Attributes, that empowers users to add attributes to blocks via the advanced section in the sidebar. This is handy when you need to add a click event or aria-labels to blocks. Tadlocks tutorial explain the how: Adding Custom HTML Attributes With the Block Attributes Plugin

---

Jamie Marsland of PootlePress (WooCommerce Blocks) wrote a tutorial on How to create an Industry News Page with the Gutenberg Block Editor. Marsland walks you through the usage and display options of the RSS block.

Theme development for Gutenberg

Matias Ventura, the ‘spark of Gutenberg’ gave in his post The Theme.json horizon a bird’s-eye view on the broader impact and opportunities the Theme.json file provides for the WordPress ecosystem.

---

Tammie Lister shared her fun with group block borders, with instructions on how to control borders via theme.json.

---

Frank Wazeter explored a way to use the new theme features of WordPress 5.8 without depending on the Gutenberg plugin to be present. Wazeter wrote: “This code shows how a WordPress theme can support and mimic Gutenberg Plugin’s templating system for the block editor/template editor, while not having a dependency on the Gutenberg Plugin itself. “.

---

Don’t want to miss the next Weekend Edition?

Type in your Email address to subscribe.

Subscribe

We hate spam, too and won’t give your email address to anyone except Mailchimp to send out our Weekend Edition

Thanks for subscribing.

---

In December 2020, WordPress launched its new “Learn” platform with free courses, workshops, and lesson plans. Since then, the Training Team has continued adding more material. The latest proposal is an open discussion for the community on adding participatory badges for completing coursework.

“I’d like to nail down what kind of thing we would like to see regarding recognising learner achievements on profiles,” wrote WordPress community manager Hugh Lashbrooke in the announcement earlier this month.

The proposal, which now has a GitHub ticket, includes showing the following on a user’s WordPress.org profile page:

• A course’s completion in the activity stream.
• The user’s average grade from Learn WordPress.
• A new “Learning” tab for displaying completed courses with dates and the possibility of individual completed lessons, relevant grades, and other learning data.
• A new “Learner” badge for anyone who has completed one course.

Currently, there are only two courses available. “That is changing as we develop new content,” wrote Lashbrooke in the post. “So my hope is that we will have these rewards in place now, and as content is created, the rewards will flow naturally.”

One downside to the proposal may be publicly showing a user’s grades. “I’d be against showing the learner’s average grade publicly because it could lead to anxiety, stress, etc., and maybe even stop some people from participating in the courses,” wrote Stephen Cronin in the comments. “Eg: ‘What if I only get a C, will anyone take me seriously? Will it harm my chances of getting a job in the WP space?’ etc. Some people will thrive on that sort of competition, some people … not so much. And I feel like we should be as inclusive as possible.”

Lashbrooke responded that showing grades could be an opt-in feature. However, I would question why it would be necessary to show grades at all. Bragging rights? Maybe. If we could somehow make it shareable via social media, it might be a fun way to get more people to participate.

Several people in the comments were encouraged by the idea of social sharing. Adam Warner even proposed adding the Learn badges to the oEmbed WordPress block, making it easy for users to share their accomplishments on their sites.

However, the first step should be to provide badges for completing a course. It is an easy win and could be automated.

Most user profile badges are for direct contributions to the project, such as writing code or working on a team. However, at least some user-based participatory badges are available already. For example, there is a “Test Contributor” badge for providing feedback on calls for testing.

One side advantage of a Learn achievement system could be for employers who are looking through an applicant’s history. It may help potential employees show off their competency in specific areas of the WordPress platform.

Courtney Engle Robertson, Web Design and Developer Advocate at GoDaddy, questioned Matt Mullenweg during 2020’s State of the Word Q&A session on the role of the Learn platform as it pertains to the job market.

Mullenweg said the first step is organizing the platform and making high-quality educational material available. However, he seemed open to the idea of having a self or administered certification down the line. It would allow people to show that they have completed or tested out of a course.

“It wouldn’t be a perfect system, but it could be a nice way for people to learn more about WordPress,” he said. “And, hopefully, as they go through, since WordPress is open-source, improve the materials as we go through it, both from the point of view of making it more intuitive or easier to understand and also translating, as well. Because there is a huge demand for WordPress really all over the world now.”

View the clip below from the State of the Word Q&A:

“As someone who hires WordPress professionals, I would love to have a request in the job application to link up their WP profile so we can see competency through that learning platform,” commented Chris Badgett, the founder and CEO of LifterLMS, on the proposal.

He also agreed with Mullenweg that people should be able to test out of a course. It would not make sense for those who have already acquired specific skills or knowledge to go through the motions of completing coursework they are already proficient in.

“Creating quizzes or ‘post tests’ in the LMS with a standard minimum passing requirement to earn the achievement badge would help fulfill this,” he said.

For now, some simple gamification via profile badges could boost participation and, perhaps, get more people involved in contributing to the Learn platform. This could also be the first step toward a WordPress certification system.

We Can Be Organized In How We Multitask.

In this episode, David and Cory have a conversation about another way to prevent Developer Overload: organization. Cory shares how he benefited from a mentor, while David feels that documentation, commenting code, and following some best practices can help reduce anxiety overall — if you can convince yourself to adopt new habits. This show is worth a listen just for Cory's “going on a hike” metaphor.

Also covered in this episode: Cory encourages David to take the Kolbe A Index test.

Every week Post Status Excerpt will brief you on important WordPress news — in about 15 minutes or less! Learn what's new in WordPress in a flash. ⚡

Browse our archives, and don’t forget to subscribe via iTunes, Google Podcasts, YouTube, Stitcher, Simplecast, or RSS. 🎧

🔗 Mentioned in the show:

• David Bisset (Twitter)
• Cory Miller (Twitter)
• Post Status (Twitter)
• kolbe.com
• strengthsfinder.com
• Get Hired

🙏 Sponsor: Sandhills Development

No matter what you're working on with your WordPress website, Sandhills Development has a tool that can help you. Sell digital products with Easy Digital Downloads. Use AffiliateWP as your affiliate marketing solution. Sugar Calendar is event management made easy. And WP Simple Pay is a lightweight Stripe payments plugin. Craft superior experiences with the ingenuity of Sandhills’ plugins.

Advanced Custom Fields (ACF) has released version 5.10, the first major release since the plugin was acquired by Delicious Brains. It introduces several new features that were previously experimental, closing out tickets that were started by previous owner Elliot Condon.

The release enables HTML escaping by default, which helps prevent Cross-Site Scripting (XSS) attacks. It runs content rendered by ACF through the WordPress wp_kses() function. There was a little confusion about how this works and the release post has been updated to clarify:

“It’s important to note that this only affects content rendered by ACF in your WordPress dashboard or any front-end forms rendered through acf_form(),” Iain Poulson said. “This will not affect field values loaded through API functions such as get_field() and the_field(). We don’t make any assumptions about where you are using your field values within your theme and do not escape to them as a result.”

Version 5.10 also introduces support for the WordPress Blocks API v2 for ACF blocks. WordPress 5.6 came with a new Block API that makes it easier for theme and plugin developers to style the block content with more consistent results matching the front end. The ACF team has created a Block API v2 help doc with examples that help developers update their blocks and make use of the new block filters included in the update.

Other features introduced in this release include block preloading turned on by default, a new full-height setting for blocks, opacity support for the color-picker, and many bug fixes. Next up on the roadmap for the plugin is adding WordPress REST API support to ACF field groups.

“As API-powered JavaScript front-ends become more and more popular in the WordPress space, it’s clear that many of our customers want this functionality included in ACF core,” Poulson said.

“We also plan to improve the performance of the plugin and work on other quality of life features. Now that our development team has a solid handle on the codebase and the release process, we can start working on these more complicated but long-requested features.”

Shortly after the acquisition, Delicious Brains representatives published a pinned thread in the forum, clarifying expectations for free support and response times. The official support forum for both free and PRO users can be found at support.advancedcustomfields.com, which is more active than the WordPress.org forums. Since the plugin is more developer-focused, the team is taking a looser approach to support by giving the community a place to help each other:

We rarely provide support in either forum. The exception is after a major release, when we keep an eye on both forums to spot any problems caused by the release.

The primary purpose of both forums is for people in the WordPress community who are having trouble with Advanced Custom Fields to help each other. Response times can range from a few days to a few weeks and will likely be from a non-developer. We jump in now and then when the description sounds suspiciously like a bug. 

The release of version 5.10 is a good sign that ACF will continue to make progress under its new ownership and a reassuring milestone for the small minority of users who were unsure about the plugin’s future.

WordPress Community members in the state of Karnataka, India organized a do_action charity hackathon from 07 to 15 August 2021. The event, which was supported by 12 volunteers, helped create websites for 3 non-profits. do_action Karnataka was held completely online due to the COVID-19 pandemic, and it concluded symbolically on August 15th 2021 — the 75th Independence Day of India. This is the second do_action Hackathon in Karnataka — the first one being do_action Bengaluru, which was held in 2019.

Efforts behind do_action Karnataka kicked off three months prior, in April 2021. N Suresha, Prem Tiwari, UC Riyaz, Sagar Vora, SR Venkatesh, and Yogesh Londhe (myself) from the WordPress Community of Karnataka, joined hands to support local non-profits by helping them build websites. The following non-profits signed up for our hackathon: 

• Luv Kush Foster Home: A foster home that aims to care for animals in need
• Vridhi Foundation: which aims to support the education of underprivileged children
• Peacespark Foundation: Welfare of women and children

12 volunteers immediately signed up to build websites for these non-profits. Not everyone could participate due to personal challenges related to COVID-19, but the teams worked hard to complete the work within the stipulated time. As a result of all that hard work, two non-profit sites were launched, and one is in the pipeline!

Peacespark Foundation: https://www.peacespark.org/

A screenshot of the Peacespark Foundation website created by the do_action Karnataka 2021 team.

The website of Peacespark Foundation was built by SR Venkatesh (project manager) and Hari Shanker (content writer). Venkatesh collected all the content and the photos from the non-profit, and he was also in constant communication with the team. He also single-handedly designed and developed the website for the team! Since the content manager volunteer could not join on time, Hari stepped in to prepare the content for the site. As a result, the site was ready well within the deadline, and the non-profit was happy and grateful!

Vridhi Foundation: https://vridhifoundation.org/: 

A screenshot of the Vridhi Foundation website created by the do_action Karnataka 2021 team.

N Suresha (project manager), along with Hussna Hussain (content writer) and UC Riyaz (designer) built the website for Vridhi Foundation. Makarand Mane helped with the multilingual translation plugin, the theme, and the required templates. Prem Tiwari set up the site and provided technical support during the development, as well. Together, the team worked in synergy to burn the midnight oil and deliver the site for the non-profit, which formally launched the same in a function at their premises, on August 15th! 

Representatives of the Vridhi Foundation at their website launch event on August 15, 2021

Since representatives of Luv Kush foster home were out of the country during the hackathon,  they couldn’t collaborate to give the content and the photos for the website. Most of the technical groundwork for their website is done, and it will formally be launched once the non-profit provides content for the teams. 

The hackathon would not be possible without the support of our kind sponsors who provided hosting, domain names, WordPress plugins/themes, and post hackathon support guarantees for all the non-profits. A big thanks to all of them! Our sponsors include:

• Give WP – Who kindly sponsored a premium license for their flagship donation plugin
• Yoast – Who kindly sponsored a premium license for their SEO plugin
• Themeisle – Who provided premium licenses for their theme
• WP Job Openings – Who provided a license for their job board plugin
• WPGenius – Who provided a translation plugin, templates, and themes
• Prem Tiwari – Who has offered post-hackathon tech support for non-profits
• Bluehost India – Who provided hosting and domain names for all three non-profits

In addition to our sponsors, I wish to thank all stakeholders who helped make our event a grand success — especially our team of passionate volunteers and organizers who battled several personal challenges and a global pandemic to build an ever-lasting online presence for non-profits. Special thanks to the WordPress Foundation for supporting these do_action charity hackathons which empower non-profits across the globe, especially in these tough times.

As we were wrapping up the event on the final day of the hackathon, I asked our team of organizers and volunteers one question: “Despite all the challenges, would you do this again?” They all answered in one resounding voice: “YES!”  

On behalf of the do_action Karnataka 2021 Organizing team,
Yogesh Londhe

---

Feeling inspired, already? You can use WordPress for social good, by organing a do_action charity hackathon in your own city! Check out our handbook for more information. It just takes five minutes to fill out the application form. So why wait? Apply now!

Earlier this week, websevendev released its fourth WordPress plugin to the official directory named Block Attributes. The extension allows end-users to add any HTML attribute to nearly any block.

One of the problems with the WordPress editor is that it can be a bit fussy about customizing HTML. Blocks are built on a set of standards, and the markup is supposed to meet those expectations. If something does not fit, users see an invalid markup warning.

However, there are times when users need to drop in a custom HTML attribute for various reasons. For example, I sometimes need to add a custom data- attribute for working with a bit of JavaScript. Since I know my way around code well enough, I typically write out the HTML in those situations via the Custom HTML block. But, that does not make sense when minor attribute additions are called for.

WordPress currently allows users to add classes and IDs (called an “HTML anchor” in the admin) to almost every block. It does not allow for direct input of the dozens of other possible attributes that HTML supports. The use cases for the average user are few and far between.

For those scenarios where some users could use the extra feature, the Block Attributes plugin is handy.

The plugin is straightforward to use. It adds a new field named “Additional attributes” under the Advanced tab of every block. Users can add the attribute name and click the “Add” button. From there, it creates a new field for adding the attribute value.

Adding an onclick attribute to a Button block.

The plugin also supports multiple attributes. Once you add one, you simply use the same input field to create more.

For my first test drive, I added a simple onclick attribute with a value of myFunction(). Then, I hopped over to my theme and created that function via JavaScript to output a simple message in the console. Everything looked good under the hood, and it worked.

HTML view and console with custom JS for a Button block.

Most of the use cases I have in mind are for integrating with JavaScript, and this was a simple example of what is possible. There are far more complex things a developer could do with such a feature. That is reason enough to keep this plugin in the toolbox — sometimes you need a wrench instead of a hammer.

I could also see Block Attributes being used for adding ARIA attributes in other situations where it might aid accessibility.

Users could add custom styles to a specific block via a style attribute with the plugin. However, unless this is a simple one-off, I would recommend against it. For more advanced use cases, Blocks CSS is a far more suitable plugin. It has a built-in syntax highlighter. Plus, a textarea is friendlier than a one-line text input box.

The only downside to Block Attributes I have seen is upon deactivation. You will see the dreaded “this block contains unexpected or invalid content” message in the editor if you have added any custom attributes. The editor has managed to resolve any issues I have run into with the core blocks.

Resolving block warning after deactivating plugin.

Deactivating the plugin should not affect the front-end output. Because the custom attributes are a part of the HTML markup, they will still be there. The error message should only show in the editor.

Last week, I reached out to several members of the core WordPress committers to see if we could get an official word on whether Classic Editor support would continue beyond the mere months it seemingly had left to live. I received a semi-official answer but was asked to hold off on publishing for a more detailed and nuanced response.

Earlier today, WordPress executive director Josepha Haden Chomposy announced the official decision. It was just as expected. The WordPress project would continue supporting the Classic Editor plugin for a while longer.

“At the time, we promised to support the plugin through 2021 and adjust if needed as the deadline got closer,” she wrote. “After discussing this with Matt [Mullenweg], it’s clear that continuing to support the plugin through 2022 is the right call for the project as well as the community.”

As of now, classic users have a one-year extension.

However, the plugin will not suddenly stop working on December 31, 2022. That is merely the current deadline for the “full support” phase. It should continue working well beyond whatever date is set for that support window to close.

Designer Mark Root-Wiley reached out to WP Tavern via Twitter last week, but others had been asking the same question for a while. For some, they needed to know if they could continue supporting specific client needs. For others, it was a bludgeon to use in conversations for all editor-related things. Whatever the reason, before today, the last word had been from a Make Core post in November 2018.

“The Classic Editor plugin will be officially supported until December 31, 2021,” wrote core contributor Gary Pendergast in that three-year-old announcement. It was a shock for many at the time, uncertain whether the new block system would meet their needs.

While three years may have seemed like plenty of time to ditch the classic in favor of the modern WordPress editor, the current stats show that the project still has a few miles yet to go.

Currently, there are over 5 million active installations of the Classic Editor plugin. I am still waiting for a more specific tally, but no one has provided an answer yet. At best, we think the counter turns over at 10+ million, so we can speculate on the floor and ceiling for possible usage.

Active installs are not the entire picture either. For example, we have the plugin installed here at the Tavern for legacy reasons but do not use it in our day-to-day work. We can likely disable it altogether. WordPress has no telemetry system for tracking the usage of such features. While the install total will not always make the picture clear, the current number supports the push for continued maintenance.

“I think it’s important to note that the plugin is not going anywhere,” said core committer Jonathan Desrosiers. “It will continue to be listed on the .ORG repository for the foreseeable future.”

He pointed out that understanding the next phase of the Classic Editor plugin meant looking into the level of effort required to support it since 2018. The overwhelming majority of the changes in that nearly three-year timeframe have come down to keeping up with:

• Text changes.
• Adjustments to prevent warnings/errors and promote consistency across supported PHP versions.
• Changes to deprecated action/filter hook calls.

“It’s been almost three whole years, and the plugin has largely required very little maintenance to continue functioning, and the bulk of maintenance has been to limit warnings and notices in debug logs,” he said.

The goal of the Classic Editor plugin was to help ease the transition to the block editor. Thus far, there have been eight major WordPress releases since the switch in version 5.0.

“There’s a theory called the diffusion of innovations that looks to explain how, why, and at what rate new technology spreads,” said Desrosiers. “It separates adopters into several groups based on when they are willing to take the jump: innovators, early adopters, early majority, late majority, and laggards. I truly think that we have seen a good portion of the late majority beginning to move towards using the block editor. This can also be confirmed by the plugin’s install growth, which has been slowing and plateauing this year.”

He had expected the previous deadline to mark the next stage of the Classic Editor plugin, called the “sunset” phase. It would be a time when the WordPress project moved from full support to encouraging late adopters to transition to the current editor to get the plugin’s numbers down.

“The context I gave previously shows that, until now, that the level of effort needed to keep the plugin working on newer versions of WP has been pretty minimal,” said Desrosiers of the potential sunset phase. “I expect that pattern to continue thanks to backward compatibility. If any security issues or major problems are encountered, they’ll, of course, be fixed. Any incompatibilities with the plugin and newer versions of WP will be considered on a case by case basis, but little to no time will be put towards bug fixes.”

However, this sunset phase will have to wait. We will not see it until at least the current support window closes on December 31, 2022. WordPress project leaders will need to reevaluate the plugin’s lifespan at that point.

The other looming question would be whether core WordPress would move specific pieces of its system to the Classic Editor plugin, such as allowing custom post types to support the old editor or the meta box API.

“There are no plans at this time to move any of the underlying ‘classic’ parts from core to the plugin,” said Desrosiers. “I’m sure that removing these parts will be evaluated at some point in the future, but when that will be is not clear.”

Even when official Classic Editor support reaches a hard deadline, it does not mean such a traditional editing experience will cease to exist. Plugins like Disable Gutenberg have promised longer lifespans than the initial support window, and other editor projects will undoubtedly arise if there is wide enough demand.

“The block editor has come a long way, and I encourage everyone that has not yet given it a second chance (late adopters) to do so,” said Desrosiers. “You may be pleasantly surprised.”

Before the release of WordPress 5.0 in 2018, the Classic Editor plugin was published to help ease the transition to the new block editor. At the time, we promised to support the plugin through 2021 and adjust if needed as the deadline got closer. After discussing this with Matt, it’s clear that continuing to support the plugin through 2022 is the right call for the project as well as the community.

Still, if you’ve been putting off using the block editor, this is an excellent time to give it another shot. Since it first appeared in 2018, hundreds of WordPress contributors have made a lot of updates based on user feedback. You will be pleasantly surprised at how far it’s come!

Big thanks to everyone who has been working on WordPress, Gutenberg, and the Classic Editor plugin. And thank you to every WordPress user and tester who has provided the feedback we need to make the software even better.

~ Josepha

Returning to the block editor for the first time in a long time? You can give feedback early in the process by joining the outreach program! Looking at it for the first time ever? Get your bearings with some workshops or check out this demo!

Die opstel is ook beskikbaar in Afrikaans.

For years and years, I always wanted to do websites. I dabbled in coding with HTML and CSS had one website go live within 3 months, but everybody who has done coding, also know, that it is very time consuming, something as a mom, I don’t have much of. I made the decision to not pursue my dream of website designing. But I never gave up on that dream.

Right now, I am a 41 mom of two teenagers, ages 17 and 12, I was pretty set in my ways in terms of my career for a very long time. But when getting closer to my 40’s, I knew I wanted more. I knew I had the capabilities for WordPress, but never had to opportunity or given the chance to dabble in it.

How It All Began

My journey in Graphic Design started way back in 2003 with Photoshop Version 6 and Coreldraw X3. I loved it right from the start, but knew there was more to graphic design, then just that. Websites was a pretty new thing to me, but always felt intrigued by it.

Fast-forward to the beginning of 2020, 17 years later with loads of experience in Graphic Design, it was time for a change. There was always this gap, that just couldn’t get filled in terms of my career. Yet, I still remembered my dream. On 3 February 2020, I started a new job, but still in graphics and just before Covid hit our shores. Needless to say, that job turned into a freelance work from home job.

It was a really rocky period financially, as in freelancing, you get paid for what you do, and it just wasn’t happening.

In August of the same year, I received a text from someone, wanting to know if I am still available for work, knowing that I don’t know anything about Website/WordPress design. I had a background in HTML and CSS, but not enough. I still got the job, it’s not a high paying salary, but I get to work from home.

Everything After

WordPress changed my life in a big way, I don’t know other WordPress designers as I am self-taught. Fortunately, with Google and Youtube, as well as some connections made with the new job, my journey in WordPress started.

I have designed 4 websites that I maintain, with another one that is under construction as well as one or two more in the pipeline.

I asked a lot of questions when all this happened, like why did this happen?

Why did it have to be me? A year later, I know the answer. I had to go through some struggles to really learn the value of what we have, it’s not how much you have, but what you have. At the moment, I work from home and absolutely love what I do.

If there is one lesson to be learnt from my story, don’t give up on your dreams, you are never too old to achieve that dream and be really good at it.

Moet nooit jou drome laat vaar nie

Vir jare en jare wou ek altyd webwerwe doen. Ek het begin om met HTML en CSS te kodeer, het een webwerf binne 3 maande gehad, maar almal wat kodering doen weet dat dit baie tydrowend is, iets wat ek as ‘n ma, nie veel van het nie. Ek het die besluit geneem om nie my droom van webwerf-ontwerp na te streef nie. Maar ek het nooit die droom opgegee nie.

Huidiglik, is ek is ‘n 41 jarige ma van twee tieners, hulle is 17 en 12 jaar oud. Ek was baie lank gevestig in my loopbaan. Maar hoe nader ek aan my veertigerjare gekom het, het ek geweet, ek wou ek meer hê. Ek het geweet dat ek die vermoëns vir WordPress gehad het, maar ek het nooit die geleentheid gehad of was nooit geoffer om dit te gebruik nie.

Hoe dit alles begin het

My reis in grafiese ontwerp het al in 2003 begin met Photoshop weergawe 6 en Coreldraw X3. Ek was van die begin af mal daaroor, maar ek het geweet dat daar meer aan grafiese ontwerp was, dan net dit. Webwerwe was vir my ‘n redelike nuwe ding, maar ek was altyd daarin gefassineer.

Spoed vorentoe na die begin van 2020, 17 jaar later en met baie ervaring in grafiese ontwerp, dit tyd vir ‘n verandering. Daar was altyd hierdie leemte wat in my loopbaan net nie gevul kon word nie. Tog onthou ek nog my droom. Op 3 Februarie 2020 het ek ‘n nuwe werk begin, maar nog steeds in grafies en net voor covid ons oewers getref het. Nodeloos om te sê, die werk het verander na ‘n vryskutwerk wat van die huis af gedoen was.

Dit was finansieel ‘n baie rotsagtige periode, met vryskut werk, word jy betaal vir wat jy doen, ek het gesien, dit gaan nie werk nie.

In Augustus van dieselfde jaar het ek ‘n whatsapp van iemand ontvang wat wil weet of ek nog beskikbaar is vir werk. In die wete dat ek niks weet van webwerf of WordPress – ontwerp nie. Ek het ‘n agtergrond in html en css gehad, maar dit was nie genoeg nie. Ek het nog steeds die pos gekry, dit is nie ‘n hoë salaris nie, maar ek werk van die huis af.

Alles Daarna

WordPress het my lewe grootliks verander, ek ken nie ander WordPress ontwerpers nie, aangesien ek myself geleer het. Gelukkig, met Google en Youtube, asook ‘n paar verbintenisse met die nuwe werk, het my reis in WordPress begin.

Ek het vier webwerwe ontwerp wat ek onderhou, met nog een wat gebou word, asook nog een of twee wat in die pyplyn is.

Ek het baie vrae gevra toe dit alles gebeur het, soos hoekom het dit gebeur?

Waarom moes dit ek wees? ‘n Jaar later weet ek die antwoord. Ek moes bietjie sukkel om werklik die waarde van wat ons het te leer, dit is nie hoeveel jy het nie, maar wat jy het. Op die oomblik werk ek tuis en hou absoluut van wat ek doen.

As daar een les uit my verhaal is om te leer is, moenie moed opgee om jou drome te volg nie; jy is nooit te oud om die droom te verwesenlik nie.

The post Never give up on your dreams – Moet nooit jou drome laat vaar nie appeared first on HeroPress.

Google announced today that it has completed its rollout of the link spam update, which was started a month ago. In an effort to combat sites using spammy links to manipulate rankings, the search engine has developed more effective ways to identify and nullify link spam across multiple languages. The update took a couple weeks longer than anticipated but the algorithmic changes that re-assess the ranking of improperly qualified links has now been fully rolled out.

Commercial linking can be differentiated from link spam by specifying the appropriate rel attribute. For example, affiliate links must be identified to the search engine by  rel=”sponsored” in order to not trigger any negative effects from the most recent update. Website owners and content creators should be aware of the search engine’s requirements when publishing affiliate links or sponsored/guest posts. While it is appropriate and ethical to disclose commercial links in the content of the post, this is no longer sufficient for Google.

A post on the Google Search Central blog warns that this update carries a more strict response for sites that do not properly qualify commercial links:

When we detect sites engaging in either publishing or acquiring links with excessive sponsored and guest posting without proper link tags, algorithmic and manual actions may be applied, similar to affiliate links.

WordPress users who rely on plugins to manage sponsored and affiliate links will want to check to ensure they support the proper tagging for commercial links. Pretty Links, a link management and tracking plugin used by more than 300,000 WordPress sites, added support for the sponsored rel tag in version 3.1.0, along with sponsored toggle support in the block and TinyMCE editors. ThirstyAffiliates, another popular plugin active on more than 40,00 installs, has a global setting for adding rel attribute tags to links, which can also be adjusted on a per-link basis.

The are many other affiliate link management, tracking, and cloaking plugins out there that may not have been updated with settings for easily designating relattributes in links. Those who do not want to have negative effects from the link spam update may need the ability to bulk update their links to comply. If you rely on a link management plugin, it’s a good idea to check the plugin’s settings, and alternatively the plugin’s changelog, to see what features are supported.

If there was a question that ever made me start feeling old, it might be this one. Last week, Marcel Bootsman asked via Twitter, “Why did you start to use WordPress?”

WordPress community members chimed in with all sorts of reasons for hopping aboard, and Jeff Chandler of WP Mainline shared his journey on his site. These are the sort of discussions of nostalgia that I live for. What follows is my story.

I began blogging in 2003. A friend had introduced me to a now-defunct service called Expage. We mostly used it similarly to the early Myspace craze, adding things such as shout-outs to friends, random GIFs, scrolling marquee text, and midi files that blared as soon as a visitor landed on the page. But, I soon began learning how to link together multiple “Expages” (you only got one page), eventually building something of a journal.

After realizing the limitations of creating multiple accounts and passwords for different pages, I found Yahoo! GeoCities. After a short-lived stint with the service and being stifled by its roadblocks, I soon upgraded to a web hosting plan offered by Yahoo! with full PHP support. That meant I could do dynamic things like having multiple text files to store my blog post entries.

Thus, began my journey into building my own blogging system. Over the next couple of years, I kept my online journal open to the world with what felt like duct tape and old-fashioned grit. I tried WordPress at some point along the way and took a dive into PHP-Nuke and a couple of others. I then jumped back to my own system. I knew just enough PHP to be a flashing beacon for hacker-bots to push those little blue pills if they had ever bothered looking in my direction. Of course, my blog was so obscure that its glaring security holes did not register on any radar.

It was a week after I turned 21. On May 8, 2005, I had decided to get serious — yet again — about fixing my digital playground of a website. I would ditch any efforts of moving everything over to WordPress or another CMS. I was a lone wolf and was going to trek into the world wild web with nothing but my existing knowledge and instincts.

It was a fun era on the web for me. I was also a college student with an ever-changing list of interests, often varying by the day. Building a custom blogging system has never been an easy feat, and managing it all through plain text files had become a burden.

A mere five days later, I caved on my dream of managing a custom platform, but I needed to do so for my own sanity.

I simply began using WordPress because it made it easy to manage blog posts.

There were no special features like the editor, custom post types, or anything else that has brought so many others to the project. It was simply having a nicely organized posts management screen and the output of those posts on the front end. Relative to other systems at the time, it was also easy to install.

At the time, I probably did not think much of it. It was just another project in a line of others that I had tested, but I am happy I took the leap. WordPress has given me a career and, often, a purpose in life. It allowed me to grow as a developer, designer, and writer.

It may be blasphemy to say such things in WordPress circles, but my personal blog no longer runs on our beloved platform. After all these years, I have come full circle. My original goal was to build a flat-file blogging system, even though I did not know there was a name for such a thing back in the early-to-mid 2000s. I also did not have the requisite knowledge to build it at the time. However, in 2018, I coded my own system from scratch, and I loved every minute of that initial build. In part, I had a new project to tinker with, but it also carried a bit of the nostalgic factor of re-pioneering my early foray into the web.

While a custom blogging platform works for my own purposes, it makes me appreciate WordPress even more. It is hard to understand how much work goes into something as seemingly simple as the front-end architecture until you build it from the ground up. And, let us just skip over any talk of creating a secure and accessible admin interface that is user-friendly.

For any serious endeavor, WordPress is still my go-to solution — my personal site is a playground where I can afford to break things, after all. After our 16-year relationship, I do not see that changing at any point soon. As always, something exciting is around the corner. The platform keeps me on my toes, and I cannot imagine a world without it.

How or why did you begin using WordPress?

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.

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 [email protected], either written or as a voice recording.

Credits

• Editor: Dustin Hartzler
• Logo: Beatriz Fialho
• Production: Chloé Bringmann
• Song: Fearless First by Kevin MacLeod

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.

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.

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.

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.

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: stories, email, ads, 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.

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.

Avoiding ego, reinventing the wheel, and shiny objects.

In this episode, David and Cory discuss Developer Overload, which David defines as what happens when “when you receive too much information and are unable to process it, resulting in negative responses and unhealthy effects.” David shares tips on how developers can focus on what to pay serious attention to, how to avoid creating more work for themselves, how to increase focus, and what project managers can do to help.

Also covered in this episode: “As developers, we often bite off more than we can chew… we also tend to take that bite from the wrong side of the sandwich.”

Every week Post Status Excerpt will brief you on important WordPress news — in about 15 minutes or less! Learn what's new in WordPress in a flash. ⚡

Browse our archives, and don’t forget to subscribe via iTunes, Google Podcasts, YouTube, Stitcher, Simplecast, or RSS. 🎧

🔗 Mentioned in the show:

• David Bisset (Twitter)
• Cory Miller (Twitter)
• Post Status (Twitter)
• Max Böck on Simplicity

🙏 Sponsor: Yoast

Yoast is SEO for everyone. Yoast SEO Premium gives you 24/7 support and extra features like internal linking, social previews, a redirect manager, tutorial videos, and integration with Google Webmaster Tools. Get on board today with the premiere SEO plugin for WordPress — Yoast.

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 fighting — or 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.

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.

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 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.

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 2.9.5.1
• 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

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.”

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.

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.

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.

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.

Howdy!

It’s summer, and I am almost on vacation! Finally. This is the view from the hotel room where I write today’s newsletter. As always, you don’t have to consume today’s edition all at once, you can always come back to it. The next newsletter will arrive in your inbox on August 28th, 2021. The next Gutenberg Changelog episode will be recorded on August 20th, 2021. So, you won’t be entirely deprived of Gutenberg updates. Just make sure you to subscribe to the podcast, if you haven’t already.

Furthermore, the Keeping up with Gutenberg Index can serve as a fall backspace to get your Gutenberg fix.

Let’s keep this short. The lake is waiting ⛱️. No Red Tide insight.

Be well, stay safe!

Yours, 💕
Birgit

📢 New Episode #49 is now available! 🎙️ (with transcript!)
Birgit Pauli-Haack and Grzegorz Ziolkowski discuss Gutenberg plugin release 11.2, drag and drop, flex layout, core data shortcuts and modern WordPress development.

Subscribe to the Gutenberg Changelog podcast
🎙️ Spotify | Google | iTunes | PocketCasts | Stitcher |
🎙️ Pod Bean | CastBox | Podchaser | RSS Feed 

‘Roadmap’ for Gutenberg (preliminary)

In his latest post, Preliminary Road to 5.9 Matias Ventura lists and describes the work before the Gutenberg contributors regarding Block Patterns, Global Styles, Navigation Block and overall Site Editor interface for theme.json configuration and settings. Ventura also identified a few shortcomings of first iterations, especially regarding responsiveness of blocks, block patterns used in different contexts.

Justin Tadlock‘s article Early WordPress 5.9 Look: The Road Toward Deeper Responsive Block Design goes into a lot more details. WordPress 5.9 is scheduled for December 2021 and Feature freeze will be about two months prior.

There are a few overview GitHub issues, you can follow along and add your opinion and ideas for some features mentioned:

• Updated scope for site editing projects (#33094)
• Open issues WordPress Pattern-Directory
• Navigation Block Tracking Issue (#27593)
• Global Styles: Design Tools Overview (#33447)

This might not be all important overview issues. Please notify me if you are missing one!

---

In his post, Matt Chowing writes on what it takes to build an Editor by sharing code Between Android, iOS, and web with React Native. For all of us emerged in web development it is an interesting read, about the difference between ideas, hopes, and the reality of programming for the mobile devices.

 “Keeping up with Gutenberg – Index 2021” 
A chronological list of the WordPress Make Blog posts from various teams involved in Gutenberg development: Design, Theme Review Team, Core Editor, Core JS, Core CSS, Test and Meta team from Jan. 2021 on. Updated by yours truly. The index 2020 is here

Full Site Editing & Theme development

After a break, Anne McCarthy published is a new FSE Call for testing (#9) for the FSE outreach program: Handling HigherEd Headers. This test takes you along a deep dive into Navigation block and screens, and its goal is to expose the experimental features to a larger community and figure out what it takes to promote it out of the experimental state.

---

Status of Child Themes for FSE an update by Carolina Nymark for Theme developers.

---

In Keeping up with block supports, Lister share her approach to discovery and maintaining block via block.json files of core blocks and came up with a spreadsheet on which core block supports which features. It is quite a helpful resource, that could be integrated into the Block editor handbook

---

Sarah Norris provided this week’s (number 60) round-up post from the Themes team around Gutenberg & Themes. Check it out to learn about the discussion FSE, Themes, and Global Styles. Norris also share a few tracking issues to keep you updates.

---

The team of Metabox published “Full Site Editing (FSE) – All You Need To Know” for WordPressers, who need to catch up around the FSE discussion.

---

Dario Jazbec Hrvatin of Toolset team posted Full Site Editing Future Of WordPress And What It Means For You. He shared what he learned talking to authors behind Astra, Page Builder Framework, and Sydney Pro themes!

Need a plugin .zip from Gutenberg’s main (trunk) branch?
Gutenberg Times provides daily build for testing and review.
Have you been using it? Hit reply and let me know.

WordPress Development is hard (Part 2)

Last week, I also missed listing the Mainline podcast episode “Contributing and Developing for WordPress Is Not as Easy as It Used to Be“ with Jeff Chandler, John James Jacobi and Chris Wiegman.

---

Video: “Is Gutenberg Killing WordPress Themes? Challenges for a Theme Developer in a Gutenberg World.” by David Vongries, who shares the hard time a theme developer can have when keeping pace with Gutenberg development.

My advice for people depending on themes for their revenue and who don’t have an army of developers keeping up with the new thing: Keep doing what you are doing until things settle with the next two or three releases.

---

Does WordPress Have a Gutenberg Problem? Asked David Bushell listing a few problems building blocks cause in creating sites for customers. It’s comes across like the other rant of a developer who is fighting change. However, Bushell touches on recurring themes we hear before and outlines the hurdles for WordPress developer when starting to switch to Gutenberg for their development:

Opinionated styling of core blocks is another pain point for WordPress developers. The mechanism to control this via theme.json has now arrived but of course its not yet completely develop.

Deprecation of static blocks: How can post that have earlier version of particular blocks stored be updated to a new rendering. There isn’t a good answer yet, and many developers mostly develop dynamic blocks, rendered in PHP consistently no matter when the block was added to a post. If a new version is available, it’ll get the new design/styling. Or skip native block development altogether and rely on Blocks created via Advanced Custom Fields Pro.

A dynamic block was my first block, too, and I haven’t had the time to experiment with JavaScript blocks and the versioning for static blocks.

---

Is WordPress Development Really All That Hard To Get Into Today? Asked Justin Tadlock in his opinion post on the WordPress Tavern, that collected over 40 comments from the site’s Community, many share great resources to get over initial hurdles, too.

---

Don’t want to miss the next Weekend Edition?

Type in your Email address to subscribe.

Subscribe

We hate spam, too and won’t give your email address to anyone except Mailchimp to send out our Weekend Edition

Thanks for subscribing.

---