WordPress.org

Over the weekend, Matt Mullenweg announced on Twitter that Apple’s App Store had blocked Automattic from shipping updates to WordPress’ official iOS app. Automattic doesn’t sell anything for WordPress.com or Jetpack inside the mobile apps, but the app included external purchasing methods that bypassed Apple’s requirement of selling via in-app purchases.

On the surface it seemed Apple was forcing a free app to add in-app purchases solely to extract its 30% cut of the revenue. The problem was if users drilled down deep enough into web help pages, they could find a window to escape the walled garden. While this seems like an unlikely way that a user would purchase an upgrade, Apple held the app’s updates hostage in order to gain full compliance from Automattic.

“There are a few convoluted ways you can get to our web app from within previews, documentation, etc.,” Mullenweg said in the Twitter conversation. “We offered to block based on user agent server-side, but that was not deemed sufficient.”

In a rare congenial response from Apple, the company apologized and reversed course 24 hours later, but not before Automattic had already acquiesced to adding in-app purchases. In a statement provided to MacRumors, Apple said the issue has been resolved, although it did not specify if this happened weeks ago:

We believe the issue with the WordPress app has been resolved. Since the developer removed the display of their service payment options from the app, it is now a free stand-alone app and does not have to offer in-app purchases. We have informed the developer and apologize for any confusion that we have caused.

The Official WordPress Apps Need to Be Separate from Automattic’s Commercial Interests

Automattic’s control of WordPress’ official mobile apps has long been a controversial issue in the open source community. Since the company heavily subsidizes the apps’ development, its agenda for the apps goes completely unrivaled. This is why the official apps contain WordPress.com and Jetpack-specific features that are unnecessary for many self-hosted site owners.

Although the apps are open source, historically, they have rarely received contribution from developers outside Automattic due to the complexity of the code. This hasn’t changed. In 2016, when version 5.7 of the apps came out for iOS and Android, it looked like Automattic was pushing forward on building an upgrade path for WordPress.com plans. At that time, features for self-hosted sites began to lag behind significantly. Automattic mobile engineer Maxime Biais said the commitment to support both was equal.

“WordPress.com features are not prioritized over self hosted,” he said. “When we can implement things for both we do it, but when we can’t (like when we don’t have the XMLRPC endpoint) we do it for WordPress.com and usually ask Core to do the changes so we can implement the same feature for self-hosted users.”

Developing the app for self-hosted users and Automattic’s customers at the same time was always a delicate balance. This situation with the App Store underscores the need for the official open source apps to be separate from the control of any commercial entity, but the reality is that these apps would not exist without Automattic. Their continued maintenance is entirely funded by the company. Unfortunately, attracting outside contributions from the broader community has been difficult given that Automattic is the only company whose products are allowed to be built into the official WordPress apps.

Prior to Apple backing off of its requirement for Automattic to add in-app purchases, the company had presumably exhausted every other option before giving in to Apple’s demands. At that point Mullenweg started crowd sourcing ideas from his followers on Twitter to look for a way forward for the community. This seemed to mark a new era for the apps where Mullenweg was willing to consider adding other companies’ products into the apps alongside his own and then passing the revenue along.

“New name: The app has always done a ton of work to support WordPresses hosted anywhere, using the XML-RPC API included in core WP since WP 2.6 was released in 2008,” he said. “That’s why we called it ‘WordPress’ and not ‘WordPress.com’ or ‘Jetpack.’

“I am a big believer in the sanctity of licenses. (Open source relies on licenses and copyright.) We agreed to this license when we signed up for (and stayed in) the app store, so going to follow and abide by the rules. Not looking to skirt it, hence doing what they asked us to.

“Allow others IAP: All of the code is open source, if other hosts or plugins wanted to support in-app purchases for their plans we could accept patches and have Automattic pass through the revenue.”

The idea of Automattic becoming the arbiter of which companies have access to selling through the official mobile apps introduces even more conflicts of interest into what was already a murky entanglement. This setup would be wholly objectionable to many in the open source community. For the sake of clarity and simplicity, WordPress’ official mobile apps need to be free from commercial interests.

John James Jacoby suggested Automattic build a new app for its own products if the company wants to add in-app purchases. Mullenweg seemed open to considering the idea.

At the moment, given Apple’s apology, the liberation of the mobile apps is no longer a matter of immediate necessity. Mullenweg seems satisfied with the outcome for now, but the original conflicts of interest in the app remain.

“I did not expect the previous tweet to get attention outside the WP community,” Mullenweg said. “My understanding was the previous decision was final, and we had already made many of the arguments people suggested privately over the several weeks the app was locked.

“We will continue to be responsive and do our best to be within both the spirit and letter of the app store rules, including closing any webview loopholes that pop up. This also made me appreciate the freedom of the open and independent web.”

One of the minor but useful additions to WordPress 5.5 is the new wp_get_environment_type() function. It makes it possible for plugin and theme authors to do some interesting things based on whether a site is identified as staging, development, production, or some other custom environment type. In discussion on the original trac ticket, Marius Jensen suggested a few ways this function could be useful:

• It’s a function used for grabbing the current environment, this is to ensure everyone fetches the values the same way (to avoid using different terms and such).
• Outbound emails could be filtered, and if get_environment() isn’t set to production then send them to the developer, allowing for legitimate email tests in stage setups without worrying about emails reaching end users.
• API endpoints where you want to use a test endpoint when not in production to prevent data pollution.
• Providing a wp-admin notice for non-production sites so it’s much clearer that what you are doing now will/won’t affect the site your business relies on.

The new function is already getting put to use in WordPress developer Roy Tanck’s new plugin called Display Environment Type. It adds a prominent red notice to the top of the admin for Production. Custom environment types will be set to blue with a lightbulb icon. (The colors used in the plugin are fixed and not configurable to help avoid confusion across servers.)

The environment type only displays for admin users. Tankck’s plugin also adds the current environment type to WordPress’ At-a-glance widget:

This is the first plugin on WordPress.org to make use of the new function, but developers are planning to use in other unique ways.

“We are adding our own custom environment vars here at Pantheon so plugin authors have the option of doing this but it would be so nice to have this in core so plugin authors don’t need to write host specific code,” Pantehon developer advocate John Richards commented on the original ticket for the new function.

WordPress plugin developer Rene Hermenau said he will be implementing this new concept in his WP Staging plugin in the next update. WP Staging, which is currently active on more than 50,000 installs, allows users to quickly create an exact copy of their sites for staging or development purposes.

WordPress.com has also added support for environment types in VIP Go, allowing developers to run different code for their sites depending on if it’s in production, development, or any other custom environment type configuration.

Joe Casabona, a freelance web developer and educator, launched WordPress: A Year in Review last week. The project was born out of his passion for helping others and a longing for attending WordCamp US, which has been canceled because of the stress of the pandemic and online event fatigue. He wanted to do something to fill in the void.

His goal is to offer online content that members of the WordPress community may have missed out on in the year. The project will provide learning resources in e-book, print book, video, and audio form. The content will be free, but he is asking community members to chip in and sponsor the project, covering the hard costs of putting it together.

“After WordCamp US got canceled, I started thinking about all of the work that went into it and the amazing amount of content that now wouldn’t be created,” said Casabona of why he decided to begin this project. “I am a big WordCamper and go to between 7-10 per year depending on my schedule, so I’ve definitely missed that experience. My main hope is that this can fill in some of the missing content from those canceled WordCamps. I know there are other efforts too, like the workshops the WordPress Foundation is hosting.”

What the Project Offers

The plan for the project is to offer three types of content to the WordPress community for free:

• An e-book that reviews how WordPress changed in 2020, including a print edition.
• An interview series with WordCamp speakers.
• A video tutorial series that focuses on new things added to WordPress in 2020.

Casabona plans to run between 15 and 20 interviews with people on a special series via his How I Built It podcast. Instead of a formal talk, he wants to provide interviewees an opportunity to explore their own topics. The interview application process is open to those who were scheduled to speak at the canceled WordCamp US through August 31.

“The interview series was the first aspect of this project that I thought of,” he said. “Basically, I will interview people who applied to speak at WCUS 2020 about their talks — each episode will have 3 interviewees who have the opportunity to talk for about 10 minutes each about their topic. I’ll ask them who they are, what their talk was going to be about, and highlight the main points. I’m definitely open to ideas depending on who applies and how many people apply.”

Currently, Casabona has booked only a few podcast interviews. He said he plans on reaching out to more contributors, depending on how funding goes and the finalized outline for the e-book and videos.

He got the idea for the e-book from MacStories. “Every year, Federico Viticci puts out an iOS review in conjunction with the iPhone release, exclusively for his members,” he said. “I think that’s such a great resource and feel something like it would really benefit the WordPress community. Since this is the first one I might have some backstory, but it will mainly be a practical reference for people wondering how the popular CMS changed from January to December — things they might have missed or overlooked.”

If the e-book goes well this year, he will seek to publish it in the following years. The same would hold true for the printed book, which would essentially be the same as the e-book. A print edition would be a nice keepsake for members of the WordPress community. It is something physical, a tangible item that is not made up of bytes stored on a computer, destined for an eventual digital waste bin.

Casabona plans to run 10 video tutorials. He will release one video each week, starting in mid-October, through the end of the year. At the moment, he is planning to run all of the videos himself but may reach out to others who are better-suited for particular topics.

“The video series isn’t a huge departure from the content I put on my YouTube channel right now,” he said. “I’m targeting mostly users and implementors, but there were some cool developer additions in 5.5.”

Funding and the Future

The biggest holdup for the project is funding. Casabona has a goal of $3,000 to cover the hard costs, such as transcripts, editing, and out-of-pocket expenses. Those willing to donate can give a custom amount or make a pledge for one of three tiers with each tier building upon the other:

• Support – $5: Gets your name in the e-book, progress updates, and behind-the-scenes content.
• Early Access – $5: Early draft of the e-book, early access to interviews and videos, and e-book of podcast transcripts.
• IRL! – $19: A printed copy of the e-book.

“I basically wanted to give the community a chance to pledge and support the project, as well as get a print book if they want it,” said Casabona.

He is also asking for sponsors to help fund the project on top of the initial goal of $3,000, which would only cover the minimum to produce content on his own. “Sponsorship will allow me to put more of my time and resources into the project,” he said. “All of this money is going into production — the more funding I’m able to secure, the more time and resources I can put behind it. For example, this could enable me to hire contributors, editors for each medium, etc.”

While it may be a bit early, Casabona is already thinking about the future of the project and has plans if he exceeds his funding goals.

“Excess funding will allow me to find and pay more contributors and better position the project for 2021,” he said. “I’d also like to set up a fund to send someone who can’t afford it to a WordCamp…once we start having in-person events again!”

Last month the WordPress Documentation Team announced a ban on links to commercial websites within the official docs. These include the HelpHub, Code Reference, Plugin and Theme Developer Handbooks, Block Editor Handbook, and the Common APIs Handbook. The reason behind the ban was that heavily policing commercial links placed too much responsibility on the documentation team, when they are already working with limited time and resources.

The decision was instantly controversial, igniting a heated discussion in the comments. A blanket ban on links to commercial sites, without a clear outline of what that includes, was confusing.

“There isn’t clarity what will/won’t be allowed, you state that the rules are expected to change in the future (more lax after some trial and error), and end users lose in the end as a result of excluding actually helpful information because it’s free but at a domain that has non-free content,” Core contributor Clifford Paulick commented on the ban announcement.

The level of opposition seemed to indicate that there may not have been enough discussion up front and that other branches of the WordPress contributor community, including commercial entities who are also contributors, were not considered.

“Discussion on [the] external linking policy is going in the way we wanted to avoid,” Milana Cap said during the July 13th docs team meeting. “I was thinking to explore a different approach.” She gave more background on why the team is reconsidering the ban:

The reason we didn’t want to allow ‘commercial’ links is to avoid abuse and make it ‘fair’ for everyone and not promote any product. We also wanted to save time for our members in a matter of maintenance and sort of automate the process. The further and deeper discussion goes I’m realizing this will not be possible. It won’t be fair, we won’t save time because we’ll have to do through discussion every time someone suggest ‘commercial’ link and I’m pretty sure we’ll never come to agreement on what’s ‘commercial.’ Personal blogs, services, products.. all of it is mixed now. So my suggestion is to allow them all, make process transparent and set strict rules about the actual ‘content.’

A Google document is now home to a collaborative effort on a new policy that Cap says is “fundamentally different from previous discussions.” The new approach proposes a set of criteria for allowing external links, banning things such as product promotion within the tutorial, affiliate links, paywalls, and tracking. The specific criteria and wording of the new policy are still under active discussion.

Sometimes it pays to speak up, if you have a strong opinion about a decision. Reconsideration of this external linking policy is the direct result of feedback on the initial controversial decision, even after it seemed to be final. This may result in a better solution for all stakeholders involved in this discussion.

Next week the Documentation Team will be hosting a Zoom call to discuss the proposal they have been collaborating on in Google docs. This meeting is for anyone who is interested, not just Documentation team members. If you want to get in on the discussion, check out the Doodle poll for the proposed dates and times.

We should be leading the users, not following them.
We should be guiding the users, not coddling them.
We should carve out the road to the future, not continue to fix a broken road to the past.
We should say what we do and do what we say.

Juliette Reinders Folmer wrapped up her final thoughts on a ticket she had opened a mere three days ago. She had opened the ticket in anticipation of movement on WordPress’s minimum supported version of PHP. She had opened it after seeing the plan to no longer support PHP 5.6 in the WordPress 5.6 release plans (note that initial release plans are not necessarily set in stone).

There is no denying the symmetry of dropping support for PHP 5.6 with the release of WordPress 5.6. Fate seemed to be calling down, saying that it was time to move past the platform’s support of a version that reached End of Life in December 2018. It would be a nice sendoff, a farewell that could usher in a new era of maintaining some semblance of staying up to date with the latest and greatest the programming language has to offer.

But the excitement was cut short. WordPress developers, especially those who have longed for WordPress to be more proactive in updating its PHP requirements, will have to continue pushing for modernization into 2021. It does not look like it will happen this year.

Matt Mullenweg, WordPress co-founder and project lead, closed the ticket a few short hours after its opening. “Just so we don’t cherry-pick stats to make a point, it’s worth noting that the PHP distribution across all WP sites we track is the same as when that post was made in 2018: 85% are 5.6 or above,” he wrote. “Only about 66% are 7.1 and above.”

WordPress has required a minimum of PHP 5.6 since its version 5.2 release. Of the WordPress installs on versions 5.2 through the current 5.5 only 10.69% of those are running PHP 5.6, according to Sergey Biryukov, a core committer for WordPress. This percentage is even lower than when the team flipped the switch to PHP 5.6+.

“Given that we’re still releasing security updates for WP 3.7 (released almost 7 years ago), it’s not like we’re leaving PHP 5.6 or 7.0 users without security updates, they just won’t have some latest and greatest features of WP 5.6+, which seems fair,” he said in the comments on the WordPress 5.6 announcement.

“This is obviously a key philosophical decision that should be made by the project lead,” tweeted lead developer Andrew Nacin. “And for what it’s worth, our philosophies and standards on this have been consistent for more than a decade. The numbers strongly suggest it’s too early to drop PHP 5.6.”

While there are certainly arguments to looking at the data in different ways, one of WordPress’s guiding philosophies has been making the platform accessible to as many users as possible over the years. This has meant taking a slow, deliberate approach while also reaching out to web hosts and users alike. Dropping support for old versions of PHP has not been nearly as fast as some — including me — would like.

The need for updating the minimum version of PHP is not simply about developers wanting to use the newest and shiniest tools. There are practical concerns. PHP 8.0 is slated for release on November 26, 2020. Regardless of WordPress’s minimum required version, it must also work with the most up-to-date version of PHP. The wider the range of versions that the platform supports, the harder it is to test.

Such is the case with PHPUnit, a testing framework for PHP applications like WordPress. PHPUnit 8 supports a minimum of PHP 7.2. Technically, it has syntax that requires PHP 7.1 — hence, the need for the WordPress version bump. PHPUnit 9 requires a minimum of 7.3 and is necessary for testing PHP 8.0 compatibility. There is an open ticket for solving issues with PHPUnit testing where the team is exploring options to support the range of PHP versions.

“We also need to work on our messaging around these PHP and core upgrades, so we don’t cry wolf and cause these notices to be ignored,” continued Mullenweg in his explanation for closing the ticket, pointing to the current site health messaging in WordPress. “They do not say what version it is currently on. They do not provide a good way to contact the host. They do not give accurate information about security, as most hosts run backports that patch security on older versions separate from what is officially supported by the core PHP project. These are not free upgrades, and I think the cost vs what we are able to deliver to users, vs the hard caused by leaving so many people behind, needs to be seriously weighed. Right now it feels like we’re a bit trigger happy on these requirements, and I’d even be open to rolling some back.”

WordPress may be joked about in “real” programming circles. Its reliance on outdated tools may be the punchline from developers who are building sites with the Next Big Thing. However, maybe in spite of or maybe because of the platform’s reluctance to quickly drop support for older versions of PHP, it has swallowed up 38% of the web. Any project lead would question meddling too much with its leave-no-users-behind formula that was part of the journey getting here.

It is a tough call for a project lead to make. It is also tough because developers like Folmer have put a ton of work into PHP coding standards tools and do the often thankless job of advocating for pushing WordPress into modern-day coding practices.

WordPress is in a position where it has some leverage. If the software demands an upgraded PHP experience, it can put its massive user base to work by forcing web hosting companies to cater to their needs. Money talks, and if enough users begin looking for greener pastures, perhaps those web hosts will make some adjustments. That is at least the theory that some in the community share. “If there are no consequences to user/host (in-)action, why would they ever bother to take action?” asked Folmer.

It is also a gamble that the WordPress project does not look to be taking, at least for the version 5.6 release.

Yesterday, Automattic dropped version 4.4 of its popular WooCommerce plugin. The new release is a minor update with the biggest changes around the plugin’s blocks and coupon management in the admin. Two dozen people made 450 contributions to the release.

The WooCommerce team brought several updates to the plugin’s blocks. The biggest user-facing change is that the blocks will now use the WooCommerce thumbnail size instead of loading the full-sized image. This change means that images will respect the product image size settings that users can set via the WooCommerce > Product Images section in the customizer. This change will make sites using blocks more performant.

The block editor should be slightly speedier with this update. The team removed front end scripts that were not needed from the post-editing screen.

WooCommerce also updated its flagship theme, Storefront, yesterday. There is nothing in the release notes to suggest that the update corresponds with changes in WooCommerce 4.4, but it is a good idea for users to stay updated regardless.

Coupon Management Moved to the Marketing Hub in the Admin

WooCommerce Coupons admin screen.

In WooCommerce 4.1, the team added a new Marketing section in the WordPress admin. When it was initially launched, some users felt like WooCommerce had added a top-level menu item for little more than the purposes of upselling its extensions. The single admin screen also offered links backed to the WooCommerce knowledge base. Many comments on the launch of the marketing hub asked the team to reconsider making it a top-level menu item, at least until it offered something more than upsells and links back to the WooCommerce website.

Having a centralized marketing location in the WordPress admin makes sense for eCommerce websites though. Creating an online shop is only one part of the process. Successful stores need to have a marketing focus, and WooCommerce is seeking to create an experience that helps more store owners become successful.

While it is a minor change, moving the coupons screen to the marketing hub makes sense. For those end-users who make use of coupons, it should very much be a part of their marketing plan.

WooCommerce 4.4 still has the legacy coupons screen beneath the standard WooCommerce menu. However, clicking on the old link will generate an admin notice that migrates users to the new location. The notice provides a button to remove the legacy admin menu item.

Gary Murray, the Product Focus and Lead for WooCommerce, said the team had larger plans beyond the initial marketing hub in the announcement post. Coupons are merely a second stage in the longer-term roadmap. “Think automations, campaigns, customer segmentation, coupon management, marketing focused analytics, and reporting,” he wrote. While the roadmap for the marketing hub is not public, it will be interesting to see what tools the team adds in future iterations of the plugin.

In just one week since WordPress 5.5 was released, the Enable jQuery Migrate Helper plugin has passed 10,000 active installs, as users look for a fix for broken sites. The plugin was developed by the WordPress Core team to mitigate jQuery-related problems users may face after updating to 5.5. WordPress has removed jQuery Migrate 1.4.1, but many themes and plugins are now broken because they use outdated/deprecated jQuery functions that relied on the script.

The official support forums are inundated with reports of broken sites after updating to 5.5, as most users who don’t follow core development are not aware that jQuery Migrate has been deprecated. Because it’s related to jQuery, many of the sites have very visible problems or broken functionality that prevents users from doing things like viewing and editing content. Those who are still using the Classic Editor have been particularly hardest hit by the 5.5 update, since older plugins that hook into the old editor are more likely to be using deprecated jQuery functions.

The Enable jQuery Migrate Helper plugin has racked up 34 five-star reviews, as it instantly fixes most users’ problems:

“After updating to 5.5 my hero slider images disappeared and this plugin fixed the problem immediately.”

“After updating to WordPress 5.5 my edit a post page and several other things ended up breaking despite having all plugins and my theme updated. This plugin fixed my issue!”

“As a newspaper, not being able to see the content of our posts is a pretty big deal. This fixed it. Thank you.”

The plugin gives users time to figure out which themes or plugins are causing the problems and request the authors of those extensions to update them for compatibility with the latest version of WordPress.

One user, David Halchester, reported a problem with a vanishing navigation menu to the support forums before discovering the Enable jQuery Migrate Helper plugin.

“Voila,” Halchester said in his review. “It worked like magic. My beautiful custom page is working again. That said — if WP does not want to lose customers, it needs to make sure its updates are compatible with older sites.

“Thank you to the people who created this plug-in. I just saved myself about $300 or more in fees to have someone ‘fix’ it.”

He makes a solid point about the plugin saving users’ money that might otherwise have gone to developers to fix the problem. For those who discover the plugin as a fix, it only costs them the time and frustration of seeking help from their hosting company or volunteers on the support forums. Others who may not be as persistent will likely have to pay for professional troubleshooting.

Justin Tadlock published a post last week that outlines WordPress’ three-stage plan for updating jQuery to the latest version. The plan outlines how a new version of jQuery Migrate will be added in WordPress 5.6 to help users update from jQuery 1.12.4 to 3.5.1 (or later). The tentative plan is to remove the script once more in WordPress 5.7, which is expected in 2021.

In the meantime, the Enable jQuery Migrate Helper plugin functions as a temporary bandaid. Looking ahead towards the prospect of opt-in automatic updates for major Core releases, which is expected to land in WordPress 5.6, it will be important to consider how wide-reaching these breaking changes can be along to path to updating jQuery, especially for those hanging back with the Classic Editor plugin.

Derek Thompson’s writing for the Atlantic has been some of the most interesting this year. His latest, The Workforce Is About to Change Dramatically, is worth a close read. He gives good arguments for and against how remote working will change real estate, entrepreneurship, and something I’ve been meaning to write about but he did a much better job, how the great migration happening away from superstar cities could reshape politics.

I sincerely hope that all the people moving to new places are registering to vote in their new home, as I did when I moved from San Francisco back to Houston in 2011. The following year was 2012 and in Harris County (Houston) with 4.263 million people, Obama won by 585 votes. I was one of those votes.

A couple of years ago, Morten Rand-Hendriksen launched WP Rig for WordPress. The goal was to bring a modern starter theme and build process to the theme development community. Now, he and the current team are hoping to find someone new to keep the project moving. Whoever is chosen will gain outright ownership of the project.

Rand-Hendriksen will be hosting a Zoom meeting on Friday, August 21 at 8 am PST. The meeting is planned to last 30 minutes with a possible additional 30 minutes for a Q&A session. He will update the WP Rig blog with the format and agenda for the meeting this week. Anyone interested in WP Rig’s future is free to attend.

“The ideal candidate is someone who has the interest, time, and drive to keep the project going,” said Rand-Hendriksen. “Future owners, maintainers, peers, etc. will be expected to adhere to the established governance model, which outlines roles, responsibilities, powers, and how to ‘climb the ladder’ if you will.”

Before taking the reins, candidates will meet with Rand-Hendriksen and other legacy maintainers of the project. The goal is to sort out the logistics of the handover.

“Once the project is handed over to new owners and maintainers, the project becomes their project,” said Rand-Hendriksen. “That means they can take it in whatever direction they feel is meaningful and valuable for the community. This is a true handover: we, the legacy maintainers, are not imposing our view of what WP Rig should be in the future onto the new owners and maintainers. We will impart our knowledge and vision, and let the next generation of the WP Rig team lay down their own path into the future.”

Ideally, the official WordPress Themes Team would take on the WP Rig project or at least its own version of a starter theme. However, the team lacks the resources to make it happen. Some members are interested but no one has the time to contribute to it at the moment, according to Themes Team representative William Patton.

“If the TRT wants to adopt the project, they take precedence over all other interested parties,” said Rand-Hendriksen. “The intent of WP Rig was always to donate the project to the larger WordPress Open Source project, and the TRT would be the ideal group to hand the keys to.”

The Unexplored Future of Full-Site Editing

Whoever takes on the WP Rig project will be in a position to explore the great unknown of full-site editing. An early version of the feature is expected to land in WordPress 5.6 later this year. This could mean overhauling the project and taking it in an entirely new direction than originally envisioned. It is a tall order and will require someone with the time and ability to keep up with drastic changes in the coming months.

Rand-Hendriksen and the team did some experimental work with Block Areas and WP Rig Blockade, a variant of the original WP Rig theme that explored blocks outside of the content area. However, the repositories have seen little work in the last year and a half. Rand-Hendriksen said they got too caught up in releasing version 2.0 of WP Rig to see either of those projects come to fruition.

“As the WordPress community starts exploring what blocks everywhere means, it is more important than ever to have this unifying base to start from so everyone is talking the same language and using the same tools,” he said. “When I had to step away, this was my deepest regret: that I wouldn’t be part of shaping this next evolution of the platform and wouldn’t be able to help the community develop this unifying baseline.”

Rand-Hendriksen believes that full-site editing will only be successful with buy-in from the existing theme development community. Without active participation from these developers, full-site editing could split the community into traditional vs. modern theming.

“There is a lot of money at stake, and a lot of developers deeply invested in and financially dependent on the status quo of themes,” he said. “To bring them on board and explore the future of themes, there needs to be a unified baseline to start from, and this is the opportune time to introduce modern code, tools, and standards. WP Rig can be a catalyst for this project and can also be the foundation on which such a project is built. What is it open source evangelists always say? ‘Decisions are made by those who show up.’ This is a chance to not just show up but actively guide the community into a collaborative future.”

He feels like WP Rig’s new owners will be in a position to answer one of the questions looming over the WordPress project: What should full-site editing look like?

Modern Tooling

WP Rig is far more advanced than the starter themes of yesteryear. However, it is not alone. Of the many starter themes available throughout the WordPress development community, many of them have moved on to include modern build systems and tooling that were not a part of earlier projects such as Underscores (_s), which is the closest thing to an “official” starter theme project WordPress has ever seen.

“When I first came up with the idea of WP Rig, it was because I’d been maintaining a very popular LinkedIn Learning (formerly Lynda.com) course on building themes from scratch using _s for years, and I noticed _s and WP themes, in general, were lagging further and further behind the general trends of web development,” said Rand-Hendriksen. “WordPress themes are by and large still built as if it’s 2012, not 2020, and many of the most important advances of the web dev space are not generally in use in theme development. As the project evolved from my personal experiment to a team, we made a decision to start from scratch and say ‘if someone were to build a theme today, in 2018, with today’s tools and best practices, what would that look like?’ The result is a theme building tool using modern build processes and tooling to make theme development easier. Yes, it looks nothing like the standard starter themes, but like I said, the standard starter themes look like the web in 2012.”

There is still some sentiment within the WordPress community that web development is shifting too far from its roots of understanding the basics of HTML, CSS, and entry-level PHP. Have we moved past the point where those simple foundations were enough to build WordPress themes in the modern world?

“Is this harder to understand for beginners?” asked Rand-Hendriksen. “If you start from the assumption that anything other than the good old way of building themes is ‘harder,’ then yes, absolutely. If you start from the perspective of WordPress themes being many people’s first hands-on experience with web development, and WordPress having a responsibility to introduce people to current and forward-thinking web tooling, then I think the answer is no.”

Rand-Hendriksen says that WP Rig makes many parts of modern theme development much easier and that the more complex pieces are extensively documented. From performance improvements to modern JavaScript to object-oriented PHP, the theme covers a wide range of practices that old-hat theme developers may need to start coming to grips with, sooner rather than later. “For most standard theme development, WP Rig is as easy as with any other dev tool,” he said. “It is just different from how WordPress themes normally do things. Which from my perspective is not only good but necessary if WordPress themes want to stay current with the rest of the web.”

WP Rig also gives theme authors a leg up with accessibility out of the box. Rand-Hendriksen has long been a vocal supporter of pushing for accessibility standards in themes, so it makes sense that the starter that he spearheaded approaches development with accessibility at the forefront.

“I’ve developed themes for 15+ years and taught theme development for over a decade,” said Rand-Hendriksen. “One of the major roadblocks for theme development is the lack of an official unified tool to start from. _s served that role for a while, but it is now poorly maintained, sluggish in development, and lagging significantly behind where standards and modern tooling is concerned. WordPress needs something similar to ‘create react app’ has had for a long time. WP Rig was created to serve as a base, or as inspiration, for such a project: provide an official starting theme and build process to give people a unified place to work from and a unified base to contribute back to and improve so the community can lift itself up together.”

image credit:  Sylwia Bartyzel

Beginning September 1, 2020, Apple’s Safari browser will no longer trust SSL/TLS certificates issued for longer than 398 days, which is the equivalent of one year plus the renewal grace period. Apple cited its “ongoing efforts to improve web security” in the announcement earlier this year. The change affects the full lineup of Apple platforms:

This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS. Additionally, this change will affect only TLS server certificates issued on or after September 1, 2020; any certificates issued prior to that date will not be affected by this change.

Apple will begin enforcing the change immediately, which means it will deny connections to TLS servers that don’t meet the new requirements. After Apple’s announcement, both Google and Mozilla contributors moved to propose their own implementations that cap certificate validity at 398 days.

All of the major certificate authorities are falling in line, changing their offerings to conform with the new one year limit. This includes CA market leader IdenTrust, which accounts for roughly 52% of SSL certificates. DigiCert, a CA that captures 20% of the market, published a dry note of compliance, emphasizing the burden it places on certificate users:

Why did Apple unilaterally decide to enforce a shorter certificate lifetime? Their spokesperson said it was to “protect users.” We know from prior CA/B Forum discussions that longer certificate lifetimes proved to be challenging in replacing certificates, in the case of a major security incident. Apple clearly wants to avoid an ecosystem that cannot quickly respond to major certificate-related threats. Short-lived certificates improve security because they reduce the window of exposure if a TLS certificate is compromised. They also help remediate normal operational churn within organizations by ensuring yearly updates to identity such as company names, addresses and active domains. As with any improvement, shortening of lifetimes should be balanced against the hardship required of certificate users to implement these changes.

The idea behind the change is that certificates with shorter life cycles are more secure, as compromised keys would expire on shorter timeframes. The new one-year expiration forces hosts and certificate providers to make automation a high priority. In fact, this is one of the reasons Let’s Encrypt’s free certificates already have a short 90-day life cycle. It was put in place years ago to encourage automation so that shorter lifetimes are no less convenient than longer ones.

Let’s Encrypt recommends subscribers renew every sixty days and may even consider recommending shorter lifetimes once automated renewal tools are more widely adopted. This may be happening sooner than anticipated now that Apple’s policy is forcing change across the industry.

Many WordPress users make use of Let’s Encrypt certificates using a plugin like WP Force SSL & HTTPS Redirect (100k+ active installs), SSL Zen (20k+ installs) or WP Encryption (20k+ installs). Some plugins have automatic renewal built in, but some offer it as part of a commercial upgrade. Others rely on hosts to perform renewals.

Although most website owners will not need to take action, the shorter certificate life cycle may can become a hassle without automated certificate management in place. It may also affect client billing with different options available from hosts and certificate authorities. If you manage websites for clients whose sites previously relied on certificates with longer life cycles, you will want to make sure to have some form of automated certificate management set up when the change goes into effect.

For months, I have eagerly awaited the official release of WordPress 5.5, an update that promised to put the long-awaited block patterns system into the hands of theme designers. I may sound like a broken record at this point, but patterns have the potential to revolutionize WordPress theme development, even more so than the upcoming full-site editing.

The feature should drastically change how developers create WordPress themes. If used to its full potential, theme authors can rid themselves of dozens of theme options and drop most of their page templates. They can focus less on programming and more on designing, which is what themes are really all about.

To understand why patterns are so revolutionary, you must understand the underlying issue that it solves for theme authors and, ultimately, end-users. Throughout all of WordPress’s theming history, there has been a single overarching issue that has caused untold numbers of issues. This is an issue that has been the root cause of multiple guidelines added to the WordPress.org theme review system.

This single issue can almost exclusively trace its roots back to the big question: how can theme authors build custom homepages and easily allow end-users to recreate them?

Whether it is a slider or columns of info boxes or a call-to-action section, WordPress has never truly provided a solution that theme authors could rely on. To be fair, many developers have built creative and unique systems around the limitations of the platform. However, those systems were specific to a single theme or a set of themes from a single company. There was no standard. There was nothing that would guide theme designers to simply design whatever interesting thing they had in their minds and allow users to simply fill in the content.

While I say that the homepage of the site is the underlying issue here, the problem is really extended to any page on the site. The homepage design is a bit like the theme author’s signature. It allows designers to showcase their talents and draw users in. And for over a decade, theme authors have tried a thousand different methods just to get this one page right.

Patterns are so much more. The system does not require that theme authors become PHP ninjas to piece together beautiful designs. It does not limit users to a theme options panel for building their homepage — they can build out any page on their site with the patterns their themes offer.

The big thing is that it renders the “how do I build a custom homepage” question moot. Theme authors never need to think about that question again, at least not in the way that they have in previous years. Theming is moving away from building designs on a page level and toward designing individual blocks and sections (patterns). The focus is much more atomic, which provides users with more flexibility and freedom.

Because I could not wait for weeks or months longer to see what theme authors built within this system, I wanted to take a peek at what the current themes in the official theme directory were doing. There was not a lot to look at, but at least some theme authors are willing to be the pioneers in this new era of theming.

Currently, the Block Editor Patterns feature filter for the directory is not working. Technically, theme authors are not allowed to add the block-patterns tag to their themes, but there is a patch available which should fix the issue soon.

Patterns So Far

Right now, the theme directory only has three themes with block patterns. It is not much to go on, but it is interesting to see what theme authors are building so far.

UXL Themes recently updated its Cordero theme with several blocks. One of the things I like about how Cordero added its patterns is that it created a custom “Cordero” block pattern category. Patterns can exist in multiple categories, but having all of the theme’s custom patterns consolidated to a single group made discovering them much easier. This is a practice that I would like to see more of going forward.

Cordero’s patterns are primarily geared toward the typical business layout. It includes a couple of hero-type patterns, some features/services boxes, and pricing tables.

Cordero theme block patterns.

The Inclusive theme by Themes Team representative Carolina Nymark has several patterns (it is also a solid theme if you’re in the market for a good accessibility-ready option). The most interesting patterns of this theme are its two-column patterns with sidebars. Nymark has essentially created the “body” of a page with patterns. One adds a sidebar on the left and the other pattern adds it to the right. Both patterns have a main column for adding custom content. The sidebar column is decorated with widget-type blocks by default.

Inclusive theme pattern with sidebar and content columns.

What makes these patterns unique is that they are almost like a stepping stone toward full-site editing — all that they are missing is a header and footer. Admittedly, I was unprepared for this sort of pattern and expected patterns to be used for smaller sections, but I am a fan of the experimentation in the Inclusive theme.

Nymark has two of the current three themes with block patterns in the directory. Her Deejay theme adds a single pattern, which allows the user to create a DJ profile section on their site. It combines columns, social icons, the latest posts list, a video embed, and more.

Deejay theme profile pattern.

Overall, I like the early exploration of this new feature. It is never easy being the first to try things out, so I applaud the theme authors for paving the way. We’re only a week into the WordPress 5.5 release, but I am excited to see more.

How Well Do Patterns Transfer Between Themes?

One of the promises of the block system is that it allows users to switch between themes and maintain their content. The idea is that each theme will style all the blocks in such a way that the front end output does not look broken.

While there is merely a small sample size of three themes, I did hit some content styling issues when switching between them.

Generally, the more complex a pattern and whether the pattern employs custom classes decides how well it would transfer from theme to theme. Images could present an interesting problem too if the user decides to not replace a pattern’s image with its own. Because the image would exist in the theme folder, if the theme is deactivated and uninstalled, it would no longer exist.

photo credit: Brodie Vissers

WordPress 5.5 has already been downloaded more than 4 million times after its release earlier this week, and it’s time to kick off work on 5.6. Josepha Haden will be leading the release alongside coordinator Dee Teal, with additional leads for Triage (Tonya Mork), Core Tech (Helen Hou-Sandì), Editor Tech (Isabel Brison), Design (Ellen Bauer and Tammie Lister), and several more women managing documentation, accessibility, marketing, testing, and other important aspects of the release. The full squad includes 46 women so far with a couple of roles left to be decided.

When Josepha Haden officially proposed the idea of having an all-women release squad, she emphasized that this doesn’t mean the release can only include contributions from women. In addition to the general objective of shipping a stable and enhanced version of the WordPress, Haden outlined a few more goals for this historic release:

My hope is that with a release squad comprised entirely of people who identify as women, we’ll be able to increase the number women who have that experience and (hopefully) become returning contributors to Core and elsewhere. This doesn’t mean the release will only contain contributions from women. And if our current squad training process is any indication, it also doesn’t mean that we’re asking a squad to show up and do this without support.

Francesca Marano, who worked as release co-lead for WordPress 5.3, published a post announcing the squad as well as the scope of the release. Two major items are already complete: conversion of the widget-editing areas and removal of support for PHP 5.6.x. The squad plans to deliver an impressive array of new features that are still in development:

• Navigation menus block in Core
• Automatic updates for major WordPress Core releases (opt-in)
• New features from the block editor upgrades.
• Widgets-editing and Customizer support in Core
• Default theme, including an FSE compatible version
• PHP 8 support
• Public beta of Full Site Editing

A recent tweet from a woman who works as an iOS developer at Quicken Loans, asked if there have ever been women in software development working in leadership roles. Although many projects and organizations have women in such roles for many years (as seen in the replies to the tweet), the question demonstrates why representation still matters. WordPress 5.6 is an opportunity to make many more women leaders visible for people who need to see others like themselves in leadership roles.

So far the community has been very supportive of the plan for an all-women release squad and is rallying around the idea. WordPress 5.6 is the last release planned for the year and is expected to land on December 8, 2020.

It is an age-old question. OK, well, it’s really a 10-year-old feature request, but that is age-old in software development years. Should WordPress have a local avatar system?

Let’s be honest. Most of us have kind of gritted our teeth and quietly — and sometimes not so quietly — lived with the Automattic-owned properties that are integrated directly with the core WordPress software. At least Akismet is a plugin and somewhat detached from the platform. But, avatars, a feature courtesy of Automattic’s Gravatar service, is baked deep into the platform. Users must disable avatars completely or opt into another plugin to distance themselves from it.

There are the obvious privacy concerns that some people have around uploading an image to the Gravatar service and creating an account with WordPress.com. Even aside from such concerns, regardless of whether they are warranted, new users who are unfamiliar with local avatar plugins are essentially guided to create an account with a third-party service to have one of the most basic features expected from a CMS.

Not all WordPress installs have access to Gravatar, such as within companies that use intranets. Some countries have the power to effectively block access to the service, as shown by the move China made in 2013 to block WordPress.com and Gravatar, leaving users to seek out alternatives.

The itch that many want to scratch is to simply remove Automattic-connected services from the core software. Gravatar’s inclusion in WordPress has hampered any chance of competing services gaining a foothold. To be fair, at the time of Gravatar’s initial inclusion in WordPress, there were few good options. It made sense to leverage a working solution that would get an avatar system rolling. And the notion of a globally-recognized avatar is noble — one service to control your avatar across the web. However, having that service under the control of a for-profit U.S. company will always be an issue that could potentially hold it back from being the service that the web truly needs. It will certainly always be a contentious issue in the WordPress community. Even those of us who love the software and services that Automattic offers can see the problem.

WordPress should be agnostic about what services it includes out of the box. Gravatar should be a separate plugin, even if it is bundled with core a la Akismet. Local avatars is not an insurmountable feature, and it might just be time to make the change.

While possible to build into core, it is not a simple matter of plugging in an image upload form on the user profile screen. The feature carries its own privacy concerns too. For example, uploading images currently requires certain permissions that would also provide the user with access to the entire media library. There is the question of how to deal with registered vs. non-registered users in such a system along with several other hurdles.

Recent chatter in the 10-year-old ticket and the #core-privacy and #core-media Slack channels have reignited the idea of local avatars. There is also an early spreadsheet on local avatar requirements and research.

Much of this discussion is amidst the backdrop of the WP Consent API proposal, which seeks to create a standardized method for core, plugins, and themes to obtain consent from users. Presumably, Gravatar usage would tie into this API somehow.

Matt Mullenweg, the co-founder of WordPress and CEO of Automattic, seems open to the discussion. “It’s exciting to see this older ticket picking up so much steam,” he said on the Trac ticket. However, he further pushed for a separate featured plugin that focused on broader privacy concerns.

In many ways, local avatars feel like the early days of the web in which users had to upload a custom avatar to every single website they joined. At times, it could be tedious. Gravatar solved this issue by creating a single service for people to bring their avatars along their journey across the net. However, we have seemingly come full circle in the last few years. With the passage of the European GDPR and other jurisdictions beginning to follow suit with similar privacy laws, it easy to see why there is renewed discussion around Gravatar in core.

We should have local avatars because it is the right thing to do. Provide a basic avatar upload system on the user profile screen. Beyond that, let users choose what they want by installing their preferred plugin without guiding them toward one particular service over another.

If nothing else, I’m excited about a wider discussion around local avatars in WordPress and welcome the possibility of such a featured explored via an officially-sanctioned plugin.

This was supposed to be the year that ushered in a revolution in how we work. Remote jobs would become a common practice, spurred on by the global COVID-19 pandemic. A time when everyone would start paying attention to those radical ideas from remote work evangelists such as Matt Mullenweg.

The question is whether this pandemic was the catalyst the world needed to reevaluate the workplace.

There is certainly a lot of good we can talk about. No hour-long commutes. Saved money by eating at home instead of takeout from the restaurant across the street. More flexible hours.

As a veteran and evangelist of the remote work movement, I have not dealt with many of the struggles that others have during this stretch. While I have had to adjust to the outside world a bit, for the most part, my day-to-day life has remained the same. I had the knowledge that colleagues, friends, and family were having some growing pains with the new reality. However, I never understood what they were going through.

Last week, I nearly reached my breaking point. It was one of those times where reality decided to check in. The beautiful veneer hanging over a decade of remote work was stripped away. It was a time where I truly understood what others had been going through during this worldwide period of struggle.

One of my housemates tested positive for COVID-19 a week earlier. He had a short battle with a fever a few days before, but that was the scope of sickness within the household. My other two housemates and I tested negative and have been doing fine to this point. As frightening as those few days were (Will my friend be OK? Am I going to get sick?), I was unprepared for what this change meant within our household.

That one little test upended our routines and took its toll on my work life.

It meant two weeks of continual interruptions from people who are not accustomed to being under quarantine. While everyone did their best, it was not an ideal situation. I could hunker down in my own space, but the routine that typically drives my life was shattered. For those of us routine-oriented people, even the smallest interruptions can feel like a freight train chugging by with the sole intent of ruining an otherwise peaceful day.

For most of my professional life, I have worked alone in quiet. I might put on some music or a podcast, mostly as a calming bit of background noise. However, I tend to enjoy being alone with my thoughts and the occasional interruption of a cat jumping in my lap for its daily petting.

The two-week disruption of my life, while unpleasant, was a mere blip in comparison to the struggle that many others have endured and overcome for the past five or six months. However, it has allowed me to become more empathetic when hearing others’ stories. From disruptions on Zoom meetings of children zipping through the house to the family dog begging for playtime in the middle of the day, work has taken on a new meaning for many. And, this is true for remote workers within the WordPress community.

The pandemic has certainly thrust companies and their employees into remote work. However, I question whether it was the push the world needed to reevaluate the workplace. It is not something that grew organically. It forced people into situations they were unprepared for. Some did not miss a beat. Others are still attempting to find balance.

Many of us with years of experience have run into issues. A large portion of the WordPress community works remotely. Some are new to it, and many who have years of experience are learning to cope with changes to their environment.

Mullenweg realizes this is not the best of times, even within an established distributed company such as Automattic. “I believe that if you do distributed work well, you’re a lot more productive,” he said in Corner Office interview for the New York Times. “But the pandemic has affected a lot of people’s lives. School is canceled. People are working from home that might not normally work from home. So we definitely have seen a hit to productivity, not to mention the stress, which has been even compounded by the social unrest.”

I am still an evangelist for remote work. Outside of potentially teaching schoolchildren once again (perhaps in the far, far away future), I can hardly imagine moving to an office away from home anytime soon. However, I can see how being propelled into an unfamiliar environment will not sit well with some. This experience in remote work may even turn away those who would have otherwise been comfortable had they been given the opportunity outside of the chaos of kids, spouses, housemates, and all the other distractions. That old, familiar cubicle may be enticing at this point.

I am happy that this pandemic will make for some converts to remote work but worry that others have not been given a fair look at the benefits that might exist under normal circumstances.

This post is in part sharing my struggles with remote work and part an open invitation for members of our community to talk about their experiences over the past several months. This is me checking in with you, our dear readers. How are you coping today?

For people who are struggling but are not comfortable discussing issues related to remote work openly in the comments, please check out Big Orange Heart, an organization dedicated to supporting the well-being of remote workers.

Now that WordPress 5.5 has shipped, block patterns are available in core for all users. If you have previously been relying on reusable blocks but prefer the flexibility of block patterns, you may want to convert these.

WordPress core developer Jean-Baptiste Audras has made this possible in the latest update of his Reusable Blocks Extended plugin. He posted a video demo of how the plugin converts reusable blocks to block patterns with one click.

What’s the difference between reusable blocks and block patterns?

Why might you want to convert your reusable blocks to block patterns? For users who are new to the concept, there are a few distinctions between these similar features.

Reusable blocks were designed to be a time-saving feature that allows users to save a block or group of blocks for use on other posts or pages. They can be edited but they have a certain distinction in that they are intended to look the same in all places they are used. Any changes made to a reusable block will apply to all instances of the block wherever it is used.

If a user wanted to make changes to a reusable block specific to one page, the process would involve clicking on the block’s properties and selecting “convert to regular block,” which would ensure that all edits would appear only on that specific instance of the block. It’s unlikely that most users would know how to do this without help, so this is one of the drawbacks of reusable blocks.

Block patterns are predefined block layouts that are designed to be changed. Once a pattern is inserted into the content, users can customize with their own text, images, alignments, colors, additional blocks, etc. The options are limitless and any changes made are not saved back to the original pattern. Block patterns provide a flexible starting point that gives users an idea of how blocks can be combined to make attractive layouts.

User-Created Patterns Are Coming Soon to the Block Pattern Builder Plugin

At the moment, users can create their own reusable blocks but not their own block patterns. Patterns have to be registered with code in order to appear in the pattern library. This is another reason that Audras’ one-click conversion is quite useful for users who are limited to capabilities offered in the editor’s current UI.

The ability to create block patterns inside the editor should be a feature in core. It would enable non-technical users to share their designs and creations in a more flexible format than reusable blocks provide. Until this feature is added to core – and it isn’t a guarantee- there is a plugin for that.

Justin Tadlock’s Block Pattern Builder plugin, which is available on WordPress.org, will soon be merging a pull request that adds the option to create block patterns inside the editor. It will work in a similar way to the process of adding reusable blocks. Now that block patterns are available in WordPress 5.5, this feature will be more useful to a wide range of users.

Audras’ Reusable Blocks Extended plugin, like many other amazing utilities for the editor, might be difficult to find unless you already know exactly what to search. Many times users are not even aware of the possibility of converting reusable blocks to patterns. This might also make a useful core feature but doesn’t seem likely to be a high priority at the moment. In the meantime, watch for more plugins to start extending block patterns to do interesting things now that they are available in core WordPress.

The world of open source tooling has expanded to welcome JSHint, as the project’s maintainers have finally completed the necessary work to adopt the MIT Expat license. Previously, the JavaScript linter’s code was partially published under the JSON license, with an additional seemingly innocuous clause that stated: “The Software shall be used for Good, not Evil.” This clause prevented it from being recognized by FSF as a free software license and similarly was not recognized as open source by the Open Source Initiative.

In an essay titled Watching the Ship Sink, JSHint co-maintainer Mike Pennisi describes how the license hurt the project. Despite having captured the distinction of being the most popular JavaScript linter in 2015, the tool has been brutally outpaced during the past five years by its contemporary, ESLint, largely due to the effects of having non-free licensing.

credit: Mike Pennisi

“Legally-conscious objectors aren’t betraying their own dastardly motivations; they’re refusing to enter into an ambiguous contract,” Pennisi said. “Put differently: they’re not saying, ‘I’m an evildoer,’ they’re saying, ‘I don’t understand what you want.’ This consideration disqualified JSHint from inclusion in all sorts of contexts.”

Licensing concerns prevented developers from the Debian and Fedora GNU/Linux distributions from including JSHint. Pennisi even dips into a bit of WordPress history, when he detailed how programming platforms that “repackaged” JSHint also reconsidered due to its additional clause.

“There was a time when the popular content management system WordPress repackaged JSHint in this way,” he said. “Once they learned of the JSON license, they replaced JSHint in a matter of weeks.” Pennisi referenced a ticket for WordPress 4.9 wherein JSHint was removed from core’s implementation of CodeMirror, as well as WordPress’ build tools.

“When a project like JSHint loses users, it also loses contributors,” Pennisi said. “This slows the addition of new features and the correction of bugs. Timeliness is important for these things, and people perceive delays very negatively. The best example of this comes from JSHint’s delayed support for async functions.”

JSHint had become what Pennisi described as a “bizarrely-encumbered JavaScript linter.” Unfortunately, the process of going open source after seven years was not as simple as submitting a pull request for a license change. In a series of essays, he unfolds the grueling process of requesting permission from all of the project’s 200+ contributors, only to end up receiving one refusal and some who weren’t available for contact. Ultimately, the JSHint team was forced to rewrite the source code but only for the parts that were contributed by the five people who had not permitted the license change.

At the beginning of August, JSHint updated to use the MIT Expat license in version 2.12.0 and is now GPL-compatible. Pennisi’s cautionary tale of what he called “the liberation of JSHint” is a fascinating read that details the struggle of overcoming the challenges of the project’s original license. The key takeaway from this story is that software creators should strongly consider the ramifications of licensing up front, even if a large community of users seems unimaginable at first. Open source licensing takes a project further than its creator could ever have brought it alone.

“For many people, licensing is an esoteric part of software development,” Pennisi said. “It’s a relatable opinion: the legal frameworks are intimidating, and most considerations can be addressed by simply defaulting to well-known free/open-source licenses.

“The trouble is that not all software is distributed under well-known free/open-source licenses. My hope is that the particulars of JSHint’s decay help folks understand why licensing matters.”

Over the weekend, David Gwyer announced a custom server-side render component for block plugins. The co-founder of WPGO Plugins primarily built his component to speed up the rendering process for dynamic blocks within his own plugins. However, he has now released this component for other block developers in the WordPress community.

Most blocks are static. Their output remains the same and has no need to change. However, some blocks are dynamic. Their output needs to change based on a variety of reasons, such as the context they are output in or other changes within the WordPress system. For example, the core Latest Posts block is dynamic because the posts that it displays change as new posts are written. If they were output as a static block, the end-user would need to update the block each time a new post was written. Therefore, dynamic blocks come in handy because they are rendered by the server in the editor and on the front end.

The problem with rendering from the server is that it can be slow, especially if the user is making several successive options changes to a particular block. With each change, the block must be re-rendered. The core experience with dynamic blocks has not been ideal.

Gwyer’s new component is available via GitHub. The project has little code, and its primary JavaScript file weighs in at just over 4kb (uncompressed). It introduces a new component, which works similarly to WordPress’s existing . Block developers should have little trouble switching to this version for a quick test.

He is currently using his component within the Flexible FAQs plugin. After running through a few tests, the plugin’s dynamic blocks feel much more responsive, almost to the point where there is little difference between it and a JavaScript-rendered static block.

component works when updating a block." class="wp-image-103253" />Live rendering when updating a dynamic block’s options in the editor.

He also has plans to use it within his Simple Sitemap plugin and any other future dynamic blocks. That is assuming WordPress does not improve its server-side rendering component in the meantime.

How the Component Works

Gwyer’s component is a fork of the core component, which he says works well aside from the point where it transitions between render states. His custom component seeks to rectify that issue. “The main additions were a new piece of state to track the previous block content to use as placeholder content, and a new component prop to handle the spinner location,” he said.

He laid out how both the core and his component works with the core component rendering as follows:

1. Render block.
2. Block attribute(s) updated.
3. Replace entire block content with spinner.
4. Render new block content.

His new component makes an important change that creates at least a perceived visual speed increase:

1. Render block.
2. Block attribute(s) updated.
3. Replace entire block content with placeholder content (current/previous content), plus spinner in the top right corner.
4. Render new block content.

“Because the block content is essentially left unaltered until the new content is ready to be rendered it looks a lot faster as well as smoother,” said Gwyer.

The real question is whether this fork should make its way into the Gutenberg project and eventually merged into WordPress. WordPress developer Ben Gillbanks thinks so and has created a new GitHub ticket with the request.

“I’d like to see it added to Gutenberg as it’s a much better rendering experience for dynamic blocks,” said Gwyer. “I’d happily liaise with the team if they’re are interested in including it in core.”

In the summer of 2019, I was asked to help out with a WordPress release. A few months before, the Core Team representatives reached out to other teams in an effort to increase the diversity of the release teams, and I started seriously considering it.

At the time, I was already heavily involved in the WordPress ecosystem and was in my second year as the WordPress Community and Partnership Manager at SiteGround, but I had no experience whatsoever on how WordPress gets done from a Core point of view. Still, when Josepha Haden, WordPress.org Executive Director, pinged me, I said yes without hesitation. And it proved one of the most challenging and rewarding experiences of my life. Here is how. 

Josepha and I walking around Vienna, WCEU 2016 – Photo by Luca Sartoni

An Accidental Contributor: My Path in Tech

From an early age, I seemed to be predestined to become a developer. My parents are programmers, they started in the sixties, and I got my first personal computer in 1982 when people in Italy didn’t really have an idea of what those were.

I followed after their work ethos and I thought that their job was fascinating, making a machine do what you want, but I was drawn to other career options. In fact, I didn’t really know what I wanted to do when I grew up, but computers and websites kept being a big part of my personal and professional life.

While back-end programming was never something that interested me, I found myself taking a class on web design in 1999, then signed up for a degree in Arts and Multimedia in 2004. I finally found WordPress in 2008 and started making a living off of it in 2010. 

Soon, I realized my true skill was helping clients who were coming to me with a request for a website to better focus on their “why” for the website and think about their business and marketing strategy before they hired me. I wrote books on business planning, productivity, and websites. I also started giving talks at WordCamps and other events to educate freelancers on those topics. 

In 2015, I randomly met some people who were involved in the WordPress community, which led me to start contributing too. I didn’t have development skills so I never thought I could contribute to OSS, but it turns out that was unnecessary. I met people who pointed me to the many different teams that make WordPress and started being active in Polyglots first and Community later.

My first WordCamp Talk: The Rebirth of the Italian Community, at WordCamp London 2016

I kept working on my business, but the more I contributed to WordPress, the more I wanted to find a way to help thousands of people at a time. My outreach efforts of giving talks, helping community organizers, and writing content needed to scale. 

This is where I met SiteGround. In the summer of 2017, they were looking for a Community Manager and despite not being one by trade I decided to apply and got the job. Joining the company allowed me to have sponsored time to contribute to WordPress. It also allowed me to tap into the collective knowledge of my colleagues when I start cooking up new ideas for the project.

So I said yes without hesitation, but the truth is that this yes was almost five years in the making. In addition, I felt that Josepha and SiteGround trusted me to do a good job. In return, I trusted the WordPress community to help me figure out all the things that I needed to learn.

How WordPress Gets Done

The other encouraging factor was that ever since WordPress 5.0, a release was no longer made by one person, as it used to be for years, or a person with a couple of deputies. Now there was a whole team at work, affectionately known as “the squad,” so there are many hands on deck.

A Lot of Communication

During a release cycle, there is a lot of communication. There are blog posts from different Make teams. At each stage of the release, there are blog posts in the News section of WordPress.org. There is constant chatter in the public Slack channel and there is a private one which is the safety net for the new people that initially might feel intimidated by asking questions in a large public channel. 

The Different Roles in the Release Squad

WordPress 5.3 had a release squad of 12 people and 654 contributors. WordPress 5.5 threw it out of the park with 805 contributors!

The thing that I love the most about this model for the release is the variety of roles that it includes. There are developers, designers, marketers, technical writers, and project managers. WordPress is not only made of code, and it’s great to see all these different skills coming together to contribute to its release. 

The role of the Release Coordinator (the one I covered for WordPress 5.3 and 5.4) and of the Triage PM (role that was covered by the excellent David Baumwald for 5.3, 5.4, and 5.5) is to try to keep an eye on all the moving parts. And I say try because it’s nearly impossible. This is why there are focus leads for the different parts that are getting worked on.

Matt Mullenweg is the project lead and has been the release lead since WordPress 5.0. He comes up with the high-level roadmap and the focus projects.  But beyond that, he is not involved with the day-to-day life of Core development. In over one year of being involved in Core releases, Matt asked only once to add a feature. 

I am annoyed when people think that everything that happens in WordPress is because Matt wants it that way. It diminishes the role of all the people who care about the project and take it upon themselves to move things forward, to shepherd issues, to champion tickets, and in general to commit to contribute to make WordPress better for everyone, no matter if they do it for one ticket or work on it full time. 

Component Maintainers and Core Committers

A group of people who are instrumental in shaping a release are the component maintainers. They are responsible to look after a certain component that makes up Core and see how tickets in that area are proceeding. They are the ones who can evaluate if a ticket is ready to be merged.

Once a ticket is deemed ready, Core Committers enter the scene. They do a final review of the ticket. They might request some changes, or make the changes themselves while committing. This is the thing that surprised me the most probably. I really didn’t think that a commit could take hours, but it definitely can. In the releases I coordinated, I definitely observed not a lot of engagement from maintainers and committers, and this is very demotivating for people working on tickets. Not everything can go into a release, even if the patch is ready, because there aren’t enough people to review, give feedback, and ultimately commit. With few resources, you have to make choices and those will not always align with each WordPress user or contributor preferences. 

This is probably one of the biggest challenges WordPress will have to tackle moving forward: How can we reactivate people who can give a big help?

The Release Party

Photo by Florian Ziegler

Despite these issues, things get done and when the release is ready, we celebrate with a party. I don’t know who started calling them Release Parties or when they started. What I know is that for 5.3 and 5.4, I hosted quite a few, and they were all a lot of fun. 

On the day of one of the steps of the release (it might be Betas, Release Candidates or General Release) the Core channel gets very active: a lot of people come online to see how the version of WordPress gets released. There are multiple steps and different people involved with different tasks. The release steps are documented in the Core handbook and are followed publicly so everyone can see them all. 

The biggest party is the general release day; there is one specific moment which is incredibly powerful. WordPress has a download counter, so before releasing the new version, the squad takes a screenshot of the previous one, we all say goodbye and welcome the new kid. Despite everything being virtual, this moment is almost tangible and will never cease to move me. We made WordPress, once again.

Screenshots of the WordPress counter seconds before WordPress 5.5 was released and two hours later.

12 Months as a Core Contributor

While I was writing this article, it occurred to me that I have been a Core contributor for a year now. I still have my full-time role at SiteGround, which at times I found hard to juggle, so I have to give my team credit for their support.

I still can’t write PHP and despise JavaScript deeply, but when I look back, I am incredibly proud of the changes that have happened in the past 12 months. I can not take credit for all of them, but I am happy I was able to be somehow part of them.

Release Schedule

One thing that a lot of contributors asked for was a mid-term schedule of releases, to better fit them around their work and personal calendar. Being the new kid can be hard because you don’t know the whole history and background of why things are done a certain way, but that is also a perk. You are free to restart conversations. After discussing it with the squad and other teams, it was clear to me that it was just a matter of “who is going to bring this up with Matt”. And so I did. A couple of days later a tentative release schedule until WordPress 6.0 was published on the Core blog, and we have been using it ever since.

Bigger Release Squad and Mentorship

The release squad is also getting bigger with every release. Many teams are involved in making it and affected by it. It’s important for all these teams to be represented in the process. In WordPress 5.5, there are several new roles, and in 5.6 there will be even more: Test, Documentation, Support are all vital components of what makes WordPress great, so having their feedback while the software is in active development is important.

And it’s important to have mentors. This is a major improvement that Josepha introduced in WordPress 5.3. The release squad is not only made of focus leads, but there is a growing group of mentors able to help new contributors learn the ropes. The idea is that those people will eventually become mentors and teach new people. This is another great way to have more and more people involved in Core, with different skills and backgrounds. 

And this brings me to the biggest change (and challenge) of all. WordPress 5.6, which is shaping up to be a massive release, will have a squad entirely made of women and people who identify as female. Like a lot of things in WordPress, it all started with a “Thinking out loud” moment and is now a reality. Work on this release will start very soon, and I am excited to be part of it as a mentor.

Fellow female contributors leading the Polyglots team at WordCamp Torino 2018. Picture by Gianni Vascellari

WordPress Needs Your Help

I wish I could say it is all unicorns and rainbows, but it’s not. The number of people actively involved in making this project a reality is still very small compared to the magnitude of its reach.

I am very much a doer, so I wish people took the time and energy they take into critiquing WordPress and turn it into active contribution time. Yes, sometimes it requires being very stubborn about a ticket and it requires to follow up on it relentlessly, but I still think it’s worth it.

Active participation also means leaving constructive feedback in tickets or offering to take notes during dev chat. That is the curse and the beauty of a massive project. There is always something to do!

In the last few years, I have also seen an increase in contribution from different kinds of companies. At SiteGround, for example, we mostly contributed to events and the community for years. We sponsored, and we volunteered, we were organizers and speakers. We worked a lot within the Spanish WordPress community to help it develop and grow, and now it’s one of the largest in the global community. In the last year, we have increased the hours we dedicate to more technical teams. I am still active in Core as a mentor and as the team representative. One of our WordPress engineers, Stanimir Stoyanov, is part of the Security team, and one of our JavaScript Engineers, Kiril Zhelyazkov, is now dedicating a couple of days per week to Gutenberg.

My colleague and Core and Security contributor, Stanimir Stoyanov

These topics align with our values, so it was a natural progression for us to become more involved.

Finally, I hope to see people get involved in a proposal I published a few days ago in the Core blog about end-to-end tests. Right now there is one, and I’m sure we can do better. Again, developers are not the only ones needed. Users are the rarest contributors and probably the ones the project needs the most to finally have some user testing in place. I am not a developer, and I’m happy that non-developers can make an impact. 

My Personal Concerns and Hopes for the Future of the Project

When I started contributing to Core, I started a note on my computer with some observations. Not having 17 years of experience in the project helps me see things without bias, and not being a developer helps me see the project more as a living, breathing body, instead of components or tickets. Allow me to share my concerns, hopes, and dreams for the future.

Component Maintainers and Core Committers: You Are Needed More Than Ever

At the time of writing this article, the project has about 60 committers and 60 component maintainers, with a lot of people pulling double, triple, and sometimes sextuple duties. But the reality is that in WordPress 5.4 and 5.5 hundreds of commits were made by Sergey Biryukov. I am incredibly grateful for Sergey’s work. At the same time, I feel like we are inadvertently building a bus factor into Core. The majority of the people with Core Commit access did not commit one ticket. Similarly, I reached out to all the component maintainers to hear about their plans for the upcoming releases and only about 50% of the components replied.

How do we make sure that the people who have the power, and thus the responsibility, to help with committing and shepherding tickets are involved? But also, how do we encourage people to step down and declare themselves inactive so new people can step up? 

My career spans over 25 years in different industries, and one thing remains the same: when people see there is someone else filling a role, they will be less motivated and sometimes even intimidated to step up. Scarcity not only drives purchases, it drives new engagement.

The Community Team, for example, maintains a list of deputies and their different statuses. I have been wondering if Core could do something similar so when new people want to step up they can see at a first glance which components are missing maintainers. People who complain about “The Core Developers” will not see them as a blob, but as individuals who at any point in time might be inactive for a period. When you see that there are actually only a few people actively reviewing and committing, you might be more prone to understand why not every ticket can make it to the finish line.

Documentation Is the Highest Form of Generosity

I say this every time I speak about contributing to OSS: documentation is frequently lacking. Oftentimes, what is there is outdated. 

How do we make sure that documentation is not an afterthought but is baked into the development process?

Handbook from it.wordpress.org – How to translate WordPress to Italian. Photo by Gianni Vascellari

There is a lot of work put into writing dev notes for the changes that affect development, but that is not the only documentation that is needed. Some of the processes described in the Core handbooks are outdated, some are missing because they live in experienced contributors’ minds.

As a big fan of Gutenberg and rich, engaging text, I wish our handbooks would fully leverage the power of the block editor and be more inviting. Right now they are a wall of text and whenever we tell people to look at the handbooks I feel my heart shrinking.

Possible solutions, which I am not sure are technically doable, but a girl can dream: sync with GitHub to solve at least the version control issue. Then recruit, recruit, recruit and work with Documentation, Meta, and Design to provide useful, engaging, readable, easy-to-scan handbooks.

Keep Track of the Moving Parts and Work as One

The other thing that I notice often is how teams, focuses, and components work in silos.

This is absolutely not done to be gatekeepers, it’s just how every team self-organized over the years.

We need to find a way to have a bird’s eye view of what is going into the next release and what are all the moving parts.

is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported Licen","focal_length":"23","iso":"3200","shutter_speed":"0.076923076923077","title":"","orientation":"0"}" data-image-title="People-at-Contributor-Day-WordCamp-Europe" data-image-description="" data-medium-file="https://wptavern.com/wp-content/uploads/2020/08/People-at-Contributor-Day-WordCamp-Europe-300x200.jpg" data-large-file="https://wptavern.com/wp-content/uploads/2020/08/People-at-Contributor-Day-WordCamp-Europe-500x333.jpg" loading="lazy" width="2000" height="1333" src="/wptavern/wp-content/uploads/2020/08/people-at-contributor-day-wordcamp-europe.jpg" alt="People sitting at round tables during a contributor day" class="wp-image-103206" srcset="https://wptavern.com/wp-content/uploads/2020/08/People-at-Contributor-Day-WordCamp-Europe.jpg 2000w, https://wptavern.com/wp-content/uploads/2020/08/People-at-Contributor-Day-WordCamp-Europe-300x200.jpg 300w, https://wptavern.com/wp-content/uploads/2020/08/People-at-Contributor-Day-WordCamp-Europe-500x333.jpg 500w, https://wptavern.com/wp-content/uploads/2020/08/People-at-Contributor-Day-WordCamp-Europe-768x512.jpg 768w, https://wptavern.com/wp-content/uploads/2020/08/People-at-Contributor-Day-WordCamp-Europe-1536x1024.jpg 1536w" sizes="(max-width: 2000px) 100vw, 2000px" />People Making WordPress at Contributor Day, WordCamp Europe 2015 – Photo by Florian Ziegler

Trac is very granular and you have a number of ready-made reports, you can filter by milestones and see how many tickets are in each component, but that is just part of the story.

Yes, I am talking about finding a way to manage the project as a whole and not as bits and bobs. 

Enter GitHub. At Some Point. 

This is not happening anytime soon, but I hope it will eventually happen. Move development and project management of WordPress to GitHub, like Gutenberg has been doing. 

I know that for many it will be an incentive to contribute to WordPress in a way that is more familiar. It will lower the bar to entrance, which is always welcome. With some handy tutorials, it will allow non-technical people to contribute to documentation, testing, and project management.

The Future is Bright

Despite all the issues, or maybe because of them, the future of WordPress is bright. 

I have been lurking around multiple teams in these years, and lately I notice more people coming on board, more people being involved in each release, more people stepping up in leadership roles in different teams. I have also noticed an increase in diversity, which is always a welcome change.

Bottom line: WordPress needs all of us to make it happen. I hope to see you on board!

With all of the advancements made in JavaScript and newer, shinier frameworks, it is sometimes easy to forget that WordPress still relies on the aging jQuery library. The same holds true for thousands of plugins and themes in the official WordPress directories.

For some, this may feel like a journey back to the mid-2000s, a time when JavaScript very much felt like the Wild West. jQuery solved many issues for a programming language that had not kept up with what developers needed to accomplish.

A ticket created by Aaron Jorbin four years ago to move WordPress to the latest 3.x branch of jQuery is finally coming to fruition. However, the WordPress development team will need to make this transition in stages, particularly after waiting for so long.

WordPress has fallen behind on keeping jQuery updated. For a platform that routinely suggests that users need to be running the latest and greatest version, it is odd that WordPress itself has not done the same with third-party code that it relies on. WordPress currently bundles jQuery version 1.12.4, a version of the library released in 2016. It is also a version that supports Internet Explorer 6, 7, and 8.

“Mostly because for the last couple of years the focus has shifted to other/more modern JavaScript libraries,” said WordPress lead developer Andrew Ozz on why the platform has fallen behind. “The number of JavaScript developers that contribute to core is limited, and there is a very high demand.”

In the long term, he said a future option might be to move the WordPress admin to native (vanilla) JavaScript completely, which is a sentiment shared in the comments on his announcement post to update the version of jQuery bundled with WordPress. “This would be great,” he said, “and at the same time, a very large effort.”

Far too many themes and plugins rely on this dated version of jQuery to move any faster. While plugins could choose to overwrite core WordPress’s bundled version of jQuery with the latest version, themes have had no such option. The official theme directory guidelines require themes to utilize the core-bundled scripts, including jQuery. There is a good reason for this: for the most part, it ensures compatibility with core and third-party plugins.

However, now it is time to move on.

What Developers and Users Need to Know

WordPress has a three-stage plan to bring jQuery up to date. The core team asks that theme and plugin developers begin testing their extensions with the Test jQuery Updates plugin. This will help them bring code up to date throughout this transitional period.

The first step in this process will be removing the jQuery Migrate 1.4.1 script from WordPress 5.5, which was released earlier today. This version of jQuery Migrate makes older code compatible and helps developers migrate to jQuery 1.9+.

This move will undoubtedly break some plugins and themes. The core team has made the Enable jQuery Migrate Helper plugin available for end-users. “It is intended to be run in production on sites that experience jQuery-related problems after updating to 5.5,” said Ozz. “It works by re-enabling jQuery Migrate and by showing the warnings about the use of outdated/deprecated jQuery functions to site admins.”

The long-term goal is to get developers to update their extensions. In the meantime, this plugin should ease some of the problems.

Ozz said the biggest thing developers need to do right now is to make sure they are testing their extensions against WordPress 5.5. “Ideally, paying more attention to any old jQuery-based scripts and confirming they still work as expected,” he continued. “In almost all cases, the fixes are trivial.”

Beyond WordPress 5.5, things will start to take shape. The tentative plan is to update to the latest version of jQuery and add the latest version of jQuery Migrate as part of the WordPress 5.6 release.

“Again, Migrate will be used to help in updating jQuery based scripts, and also as a backward-compatibility ‘fix’ while plugins and themes get updated,” said Ozz. “The version of Migrate in WordPress 5.6 will be different, as it will correspond to the latest jQuery version. It will serve the same purpose as when it was added for the first time, but now will help core, plugins, and themes get updated from jQuery 1.12.4 to 3.5.1 (or later).”

The third leg of the process will be to once again remove jQuery Migrate from WordPress. This change is tentatively planned for WordPress 5.7, which will not be released until 2021. The end goal is to remove the reliance on Migrate and ship the latest version of jQuery until someday — perhaps far into the future — there may no longer be a need for bundling it with WordPress at all.

“Following the best practices and the recommendations of the jQuery team, Migrate should be used as a helper tool, not as a permanent backward-compatibility solution,” said Ozz. “Ideally, WordPress will be able to do this.”

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

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

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

Block Directory Enables Block Discovery and Installation Inside the Editor

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

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

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

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

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

Other notable updates in WordPress 5.5 include the following:

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

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

Here it is! Named “Eckstine” in honor of Billy Eckstine, this latest and greatest version of WordPress is available for download or update in your dashboard.

To access a site hosted with WordPress.com or connected to WordPress.com through the Jetpack plugin, log in with your WordPress.com credentials. After clicking on the Login button, select Continue with WordPress.com.

You can also select the others options to Continue with Google or Continue with Apple if the email address linked to these services matches the email address of your WordPress.com account.

Next, enter the email address associated with your WordPress.com account and click next. From there you can either choose to receive a login link to be sent to your email address or click on the link to “enter your password instead” to use your password to log in.  If you select the option to receive a login link, you’ll be given the option to open Mail where you should have received a new email with a button to click to ‘Log in to the app’. This link expires in one hour and when clicked should redirect you to the app where you will see a list of your sites and have the option to either Connect another site or press ‘Done’ to start managing your WordPress.com connected sites.

See the login procedure below:

The Themes Team suspended Astra from the official theme directory just a few short weeks after it became the first non-default WordPress theme to surpass one million active installs. The reason: the theme was breaking the directory’s ban on affiliate links. The theme has since been reinstated. However, it has been delisted from the popular themes list.

After the Themes Team handed down an initial five-week suspension, the story continued to unfold through various channels over the weekend and into the start of the new week. Brainstorm Force, the company behind the theme, argued that it did not violate the affiliate link rule because the theme was simply filtering referral IDs of third-party plugins. The plugins were technically supplying the links. The company also asked for lenience because this was its first violation.

Since the initial discussion, the Themes Team has reinstated the theme while bumping it off the popular themes list. The goal is to make sure existing users still have access to updates while providing a method for dealing with guidelines violations, a method that does not go to the extreme of outright suspension. The team also added an additional week of punishment after finding a sixth affiliate-related violation missed in the initial review. Astra will now be delisted for a total of six weeks.

Astra is not the first suspension of a popular theme over the years. These high-profile suspensions can lead to the loss of thousands of dollars in revenue if the theme’s business model relies on traffic from WordPress.org. In 2017, a five-month suspension of the Zerif Lite theme left its creators with a decline of 63% in revenue. Zerif Lite’s user count was around one-third of Astra’s current total.

While it will take some time to see the results, being delisted will likely cut into Brainstorm Force’s revenue. The theme upsells a pro version of their theme. It is a common freemium model that many theme companies employ.

The WordPress.org theme review guidelines ban affiliate links. More precisely, the guideline is as follows:

Themes are not allowed to have affiliate URLs or links.

Technically, Brainstorm Force did not directly output affiliate links via its theme. Instead, the theme injected the company’s referral ID into affiliate links for third-party plugins when they were active on a user’s site. In and of itself, this type of injection is nothing nefarious. The plugins themselves allow for such filtering of their affiliate links, presumably to entice theme authors to make a few dollars by recommending and integrating with them.

As for the Astra theme, the question is whether it violated the affiliate guideline. When the rule was written, the Themes Team was most likely thinking about direct links within the theme and not a scenario where a theme was injecting a referral ID or filtering an existing link from a plugin.

According to the Themes Team, at least two of the affiliate IDs in Astra were for plugins that the theme recommended but did not actually integrate with or support in any way. In at least once instance, the theme automatically updated a database option for the Monster Insights plugin to add an affiliate ID — automatically updating any database option without user action is generally not allowed.

Regardless of individual opinions on the Theme Team’s complete ban of affiliate links, it is not a cut-and-dry situation of simply allowing or disallowing.

“It is also about needing to understand the legal impact of disclosures,” said Carolina Nymark, a team representative. “It is not something that the team can take responsibility for, nor look away if authors do not follow it.”

Astra’s Apology and Response

Sujay Pawar, a co-founder of Brainstorm Force, published an open apology on the Astra blog. However, this apology post created its own controversy within the community. The current post was not the first apology. Pawar changed his original post and removed some of the earlier promises he made to the community.

According to multiple sources within the community and a comment on the post, he had promised to dedicate 16 hours from one of the company’s senior developers to contribute work for the Themes Team. Along with this contribution, he promised to spend 5% of the company’s resources toward open source development and to donate to future WordCamps.

“These last few days have been very emotional for me and the entire team,” said Pawar. “I have never been in such a stressful situation in my life. As you can imagine, I wrote many versions of this apology and just wasn’t sure what was the best way to do it.”

For some people in the community, changing the post’s content seemed suspicious. He had changed it around the same time the theme was reinstated on WordPress.org. However, the issue was likely the result of bad timing. Pawar was forthcoming about having written the original post and later removing parts of it.

“My initial apology did include the specifics of how we are planning to increase our commitment to WordPress, but after more thought, I felt it wasn’t the right place to share that,” he said. “I don’t want our contributions to be overshadowed or tied back to a rule violation. We still plan to honor our commitment, and we will release those details in a dedicated post.”

Pawar has no hard feelings for the Themes Team. For him, it has been a high-stress weekend that he will no doubt recover from. He is attempting to rectify the situation the best he can.

“I have a lot of respect for all members of Themes Team,” he said. “They work tirelessly to move the WordPress ecosystem forward. I 100% believe that guidelines must be enforced because it’s the only way to ensure that WordPress keeps growing. As one of the most popular theme authors, it’s our goal to lead by setting a good example and work together with the TRT to set better standards.”

Long Term: Delisting Themes Instead of Suspending

The Themes Team does not have a lot of options when it comes to punitive measures for guideline violations. In a large part, this is the result of limitations of the software in use. The team simply needs better tools.

“The punitive measures the team has right now is suspend it or do nothing,” said William Patton, a Themes Team representative. “There is no in-between, and in a lot of cases, neither of those two options are ideal. From past experience, I have found that asking authors repeatedly for changes is either ineffective or they fix it but the behavior returns after a short time. Suspension has been quite effective in some cases but it is quite a lot of work for the team to manage and maintain lists or time frames of what happened when and to revisit after a given time.”

Patton said that the threat of suspension without action is ineffective. However, actually going through with suspending a theme often has implications for end-users. In some cases, there may be an urgent security update that users need to get, but the suspension system does not make that easy to manage.

There is now an open meta ticket to offer theme directory administrators the option to delist a theme. In effect, this would keep a theme such as Astra available in the directory if someone knows the direct URL. It would also allow the theme author to provide updates, such as security fixes, to users without direct approval from the Themes Team. However, the theme would not be available through the popular themes list or search.

This offers the team a less drastic option than a full-on suspension and has no negative drawbacks for existing theme users.

Currently, the team found what they described as a “hacky” method of essentially delisting Astra. Because the popular themes list algorithm uses the theme’s publication date to help determine a theme’s popularity, the team changed this date for the theme to push it down the popular list. It is not a perfect solution, but it provided a quick middle ground between doing nothing and suspension, at least until a more permanent solution is in place. It also gives them an early chance to test out the effects such a measure would have.

Punitive measures have always been a struggle for the team. On the one hand, they do not like to suspend themes for wrongdoing, regardless of whether such wrongdoing was intentional. On the other, they must attempt to provide a fair playing field for all theme authors. Threats of punishment for guideline violations ring hollow if there is no follow-through. It is not an easy position, and team members can quickly become victims of harassment or unwanted private messages from theme developers and outsiders.

“We had several occasions where theme authors would ‘follow us home’ with blame and different kinds of suggestions,” said Nymark.

One of the ways the Themes Team has been dealing with this is by using the relatively anonymous “@trtmessenger” account when suspending themes. This is the route the team took when handling the Astra theme suspension and followup decisions.

The team has dealt with attacks toward individual members over the years on various decisions it has made. In many cases, the representative who delivered a particular decision, regardless of their personal role in it, bared the brunt of the negative feedback. Far too often, it was a case of shooting the messenger, and the current reps have found a workable solution for this issue.

“This is an account that enables messages to be sent without one single person being held accountable for the message,” said Patton. “It is intended to prevent anyone from getting any negative feedback directly from a decision.”

In light of the recent conversations about the Unsplash plugin’s CDN, several extensions have popped up this week for disabling it. By default, the plugin serves images from the CDN but saves copies to the WordPress media library in case the plugin is disabled or removed. The plugin does not currently have an option to change this.

Disable Unsplash CDN is the first to be published to the WordPress.org directory for changing the plugin’s default behavior. There are no options or settings – activating it turns it on. Xaver Birsak, a prolific WordPress plugin author, created it to help users who may experience slower page speed caused by the Unsplash CDN.

“I’ve followed the release of the official Unsplash plugin as well the strange one-star rating from Matt Mullenweg which is think is not appropriate,” Birsak said. “The problem he mentioned was, in addition to the Unsplash license, the fact that images are being served from Unsplash (Imgix) servers. I don’t think that this is totally unnecessary from Unsplash as a CDN can serve images much quicker in most cases. For some users this is maybe not the case.”

Birsak was referencing Matt Mullenweg’s recent one-star review of the Unsplash plugin, which drew the ire of many plugin developers whose ability to monetize their products can hinge on getting decent reviews. The review called the plugin “sketchy” and called into question the practice of making the CDN the default:

It’s unclear why they want you to use their CDN and make that the default, it’s probably to support their new advertising business model and get analytics for it. Running a CDN is expensive, and if you’re not paying for it then you are the product. I would not be surprised if Unsplash hotlinked images broke at some point in the future.

If you want a CDN, you should run one for your entire site, not just certain images from a single source — in fact having multiple CDNs running at the same time could slow down your site because of the additional DNS lookups.

Birsak said he checked the plugin and found a simple solution for bypassing the hotlinking, which only requires a few lines of code.

“Since it’s so easy, and others may find it useful, I released this plugin,” Birsak said. “Nowadays with GDPR and the invalidation of the Privacy Shield people are more likely to be concerned about sending data to third party services. So disabling the CDN should at least be an option.”

WordPress developer Tom Nowell also created a quick plugin to disable Unsplash’s CDN, which is now available on GitHub.

“I don’t have qualms with Unsplash themselves but I did miss having the option to choose for myself,” Nowell said regarding the plugin’s CDN default. “Rather than argue to add it, I spent a little time and built the plugin, it’s only small so didn’t take much time. As for the CDN, it’s nice to save bandwidth, though for local development it’s always faster to switch it off.”

Unsplash Plugin Will Not Add an Option to Disable the CDN – Its API Guidelines Require Apps to Use It

The plugins that disable Unsplash’s CDN could immediately become obsolete if Unsplash decided to build in an option into the official plugin to do the same. The company has confirmed the team has no current plans to so.

“The CDN is a feature that dynamically serves the right size and format of image, and includes performance optimizations not available via additional plugins like WordPress.com’s Jetpack or most CDNs,” Unsplash co-founder Luke Chesser said. “We do this to improve the performance of the image loading and allow Unsplash contributors to count the number of times their images have been seen.”

In addition to sharing this data with contributing photographers, Unsplash advertisers also need this data to continue getting value from the new Unsplash for Brands business model.

The total monthly cost in 2019 for the company’s image hosting with Imgix was $42,408, which means Unsplash spends north of $500k per year to serve optimized images via its CDN. Chesser said the cost of the CDN is “very low relative to the number of requests and traffic it can serve,” given how optimized and performant the image serving infrastructure is. Last year Unsplash sent petabytes of data through Imgix’s CDN for 250 million variations of the library’s source images.

“We treat brands as contributors as they also share images on Unsplash,” Chesser said. “We report downloads and views back to them. So yes, the view and download counts do matter to our business from a monetary perspective, but to be clear, if you take away brands, we would still have this requirement as it’s central to growing the library and encouraging more contributors.”

Providing stats to brands undoubtedly helps pay the bills and keeps the lights on, so it is no wonder the requirement to use the CDN will remain in the WordPress plugin. In fact, this requirement was built into Unsplash’s API guidelines in 2018 and applies to all applications accessing the collection:

“All API uses must use the hotlinked image URLs returned by the API under the photo.urls  properties. This applies to all uses of the image and not just search results. “

In 2019, Unsplash received more traffic from its API partners than from the company’s own website and official apps. Any successful monetization strategy that hinges on advertising will need to deliver those stats and requiring applications use the CDN in order to use the API is one way to do that.

Matt Mullenweg recently asked what these API guidelines mean for existing WordPress plugins, like Instant Images, that serve Unsplash images without using the CDN. The plugin has more than 50,000 active installations.

“When we released the updated guidelines we applied them proactively to new apps and worked with developers on a case by case basis over a one year period to consider hotlinking and downloads for legacy apps,” Chesser said. “Instant Images was built before we made the update to the guidelines and so we exempted them long ago, along with a number of other legacy apps.”

Instant Images plugin developer Darren Cooney said he will not be adding an option to his plugin for turning on the CDN and declined to comment further on his reasons.

“I will say that I think the CDN should be opt-in and it should be more clear what happens on the Unsplash side when the CDN is in use,” Cooney said. “What is tracked, why it’s tracked and what benefit do added views provide the contributors.”

When asked whether Unsplash plans to update the plugin to deny API access to sites that have added a plugin to disable the CDN, Chesser said no. WordPress plugins weaponizing themselves against each other is not unheard of, although it is unusual and frowned upon.

“We don’t do things like that,” Chesser said. “I think anyone who knows our team and our community will know that we always try to take reasonable actions as we’re representing a lot of contributors and a large community. If a user wants to install a plugin to deactivate the CDN but still access the library, they can do that by all means, but we don’t want to build, promote, and support that functionality ourselves because it works against our community, our business, and our mission.”

The bottom line is Unsplash is a business, and a business needs to make money. Certainly a company doesn’t commission a WordPress plugin from a team of the caliber of XWP without hoping for a return on that kind of investment. The plugin’s setup process makes it effortless for users to connect to the Unsplash API, but there isn’t any transparency during this process regarding what data users are agreeing to send Unsplash. The plugin needs to be more forthcoming about the data the CDN collects on views and downloads. This would go a long way towards establishing more credibility with skeptics. Those who are wary of the requirement to use the CDN can use a plugin to disable it or install an alternative like Instant Images.

On Wednesday, the Gutenberg team pushed what was primarily minor enhancements and bug fixes to the WordPress platform’s primary project. Everyone is mostly gearing up for the WordPress 5.5 release, so we are not seeing any major features dropping at the moment. However, steady work continues on improving the Gutenberg plugin.

Gutenberg 8.7 contains over 30 bug fixes, in which nearly a third were accessibility-related changes. Around half of the new enhancements focused on updating block patterns.

Users can look forward to several minor enhancements that should improve the editor, such as the Buttons block getting a proper preview in the inserter. The monitoring solution behind auto-saving should also work more consistently with this update.

The biggest user-facing enhancement is the change in dealing with invalid blocks. The latest version of the plugin makes the attempt block recovery option the default. This change hides the resolve, convert to classic, and convert to HTML options under the sub-menu (ellipsis button). This is a nice touch and makes the most sense. Attempting to recover a block should generally be the first step when correcting invalid block output.

Block Pattern Updates

Updated block pattern designs.

I can now proceed to eat my earlier words of frustration with block patterns. Or, perhaps I can praise myself in some small way for pushing the Gutenberg team to up their game. I was unhappy with the abysmal designs that were originally going to ship with WordPress 5.5. The team has taken what was looking to be one of the most disappointing first outings for a feature and turned it into something the project can be proud of.

It did not take much. A photo here. A touch of pizazz there. The Don Quixote images and text bring a cohesive theme to the patterns, breathing a touch of life in an otherwise desolate and barren feature.

The “large header with a heading” pattern dropped the blinding background gradient and replaced it with an image. The “quote” pattern now has a face instead of an impersonal icon. Even the “two images side by side” pattern fits in thematically.

If anything, I am not a fan of the long pattern names. “Large header with a heading and a button” and “three columns of text with buttons” do not exactly roll off the tongue. Nor do they make it easy to write about them. I do not wish the pain of typing them out on any support volunteers.

At least we are working with a somewhat decent set of patterns going forward, and that is enough to be thankful for at this point. I will now await the first theme author to truly impress me with custom patterns.

Experimental Features Update

Site editor beta.

Much of the work for this release centered on the plugin’s experimental features. The bulk of it went toward post-related blocks. At this point, these features are so experimental that even experienced developers outside of the inner Gutenberg circle have trouble following the progress. It is nice to see the continual movement in this area. However, from a user viewpoint, it is not even ready for a quick look. Enable at your own risk. Wait until the product is a bit more polished.

I typically enable Gutenberg’s experimental features once a month or so. I want to keep up with the progress and not feel out of the loop. Such was the case over the past couple of days as I tinkered a bit more with the full-site editing and demo templates features. I am unsure what I was hoping for. Mostly, I wanted some indication of a bright future — one that I fully expect to be realized at some point. I wanted to be wowed.

I understand why the wow factor is not there. The feature is far from ready. More than that, I know that, as a developer, you have a vision of the finished product in your head, and as the UI is in flux, others cannot see that vision. It is a step-by-step process that you simply have to continue working through.

I am still of the belief that full-site editing will not be close to a viable feature until 2021. Even with all hands on deck, four months is too small of a window to make anything remotely competitive to existing solutions out there. When full-site editing does land in core WordPress, it needs to do so with a bang, not a whimper.

A short while ago, Justin Tadlock posted an article titled Are Plugin Authors to Blame for the Poor Admin Notices Experience?. If you haven’t already, I recommend reading his article. It describes in detail one question I’ve been pondering since I originally posted the WP Notify feature project proposal almost a year ago now: Will a new notification system for WordPress solve the notification spam, or just move it elsewhere?

The answer might not be as simple as we think.

I have been building, maintaining, and supporting a number of free, paid, and client plugins for the past five years. During that time I have also been an active contributor — as much as I possibly can outside of work and my personal life — to the WordPress open source project. Now that’s definitely a drop in the ocean compared to some folks, but whenever I see the mess that can occur when multiple plugins or themes register admin_notices on EVERY SINGLE ADMIN PAGE, it strengthens my resolve in the idea that WordPress needs a centrally managed notification system. 

If you read Justin’s article, or you are a plugin or theme developer yourself, you know that the notifications system (aka admin notices, a reference to the WordPress hook that prints these notices) in WordPress is limited at best. We need to be honest with ourselves, however, admin notices was not designed to function as a notification system. Admin notices should really only be used to display useful information to the user about state changes in the system. Messages like when a post has been updated or deleted, or a database upgrade is required. Short, useful, and more importantly, relevant.

As developers, we usually look for the root cause of a problem. And in the case of admin notices, the root cause is not the current notification system, or the fact that plugin developers use it for things other than, well, admin notices. The root cause is the fact that there has never existed a mechanism for notifications other than admin notices to be displayed to the user. This means that whenever a plugin developer has needed, or in fact wanted, to communicate with their users, via “in app messages,” admin notices has been the only way they can do so.

Want to let your users know about a new upgrade? Admin notice. Want to ask them to leave a review? Admin notice. Your premium license is about to expire! Admin notice. Hey, we’ve got a new sale on our premium products! Admin notice. It all soon adds up to an almighty mess.

And that’s the problem with a project like WP Notify. We’ve had admin notices, in its current iteration at least, since 2011. That means we have been using it for all our user facing messages now for nine years at least – nine years of plugin and theme developers using admin notices to send messages to users. 

If you have children, imagine telling your nine year old that the way they have been walking is wrong, and they now need to learn a completely new way of doing it. Good Luck!

So, as much as it pains me to admit it, WP Notify is not the silver bullet that will magically fix the problem at its core. As Matt Mullenweg pointed out in the comments on Justin’s article, “I don’t think a notification center is the solution to this problem. It may be useful for other reasons, but not that one.”

However, not having a specific solution for notifications other than those that are necessary, means that developers will keep on doing things the way they have always been. Enforcing new guidelines around the current functionality nine years later is going to be hard, especially since enforcing these guidelines will have to be done by a small group of volunteers, namely the theme and plugin review teams. 

By building WP Notify, we create a new and hopefully better way for plugin and theme developers to connect and communicate with their users. At the same time, we provide a tool by which we can more easily enforce any new guidelines. A guideline could be created for example, that unless your message is strictly within the realms of informing the user about state changes in the system, it needs to be displayed in the notifications center, and not as an admin notice.

So no, I don’t believe WP Notify will be a silver bullet solution. We’re not going to build it, ship it, and suddenly all the notification spam goes away the next day. That kind of change takes time.

But I do believe it’s a step in the right direction.

If you agree with me, why not join our merry band and help us build it. 

Automattic’s relaunch of P2 is now in Beta. This is the long-awaited update to the company’s internal collaboration software that is also used on WordPress.org and other self-hosted sites via a theme. For years, Automattic, which now counts more than 1,200 employees in 77 countries, has had P2 at the core of its written communication tools. It is used as a complement to Slack and video conferencing, providing a public collaboration space for conversations which might otherwise be hidden away in emails.

The older version of P2 functioned as a dependable workhorse with few changes over the years, but the beta introduces some marked improvements that make it more versatile than before. It is now seamlessly integrated with the block editor and includes a streamlined invitation system for onboarding new team members.

P2 has a fresh design that has come a long way since its roots as an evolution of the Prologue microblogging theme. Many things about WordPress have changed since P2’s first launch 11 years ago but threaded conversations have endured as a useful collaboration format. Mobile support is one of the things that has improved significantly. Users can get notifications via the web, email, and the WordPress mobile apps.

“It works on the WordPress apps perfectly but it’s handled as a normal WordPress site, without any P2 specific functionality,” Automattic’s P2 launch lead Jon Burke said. “P2 specific functionality and improvements are on the mobile app product roadmap. The browser version on the other hand has all the particularities that P2 has.”

The beta version of P2 is free and each instance comes with 3GB of storage space for images and files. Users can create as many as they like. The product is built on top of WordPress.com’s infrastructure but functions as a scaled back version of a blog – essentially a WordPress for teams.

Pricing for the commercial upgrade has not yet been determined, according to Burke, but the roadmap includes a hefty list of features.

“We’ll have integrations with third party services, project management features, more storage space, custom URLs, more customization options, etc,” Burke said. “We plan to introduce multi-site functionality, too, so an organization can create multiple P2s while sharing the same user base, have cross-posting, a common glossary, and other advanced features.”

With the diverse myriad of blocks pouring into the WordPress ecosystem, every P2 has the opportunity to be unique, depending on which features it introduces through the editor. Burke said Automattic plans to allow admins to extend their P2 instances with plugins in the enterprise version.

P2 Set to Roll Out on WordPress.com, Self-Hosted Version Coming “Eventually”

P2 is just now entering beta but many fans are already eagerly awaiting a self-hosted version. Burke said it is coming “eventually,” but the team hasn’t yet worked out how it will be structured. The project is not currently available on GitHub.

“With this launch version behind us the P2 team will turn to this but don’t yet have a time-line,” Burke said. “The team will need to now define how the backend admin will look.” The updated P2 is also coming to power conversations on WordPress.org further down the road.

“We don’t yet have a target date but it is on the product roadmap,” he said. “This P2 version has been more than a theme or plugin update – it’s really a product concept- so we can’t simply update the WordPress.org P2 theme; it requires additional progress.”

P2 seems like it would be a good fit for Automattic’s Happy Tools suite of products for distributed teams. A version of P2 with more features may roll out under this brand once the beta concludes.

“Given the sudden global shift to remote work we really wanted to get out a stable product as soon as we could,” Burke said. “That really made WordPress.com the most expedient pathway to get P2 into peoples’ hands.

“Now that we have launched this version, we will make decisions around where the next releases will live. P2 has been envisioned as being part of the Happy Tools suite. But we are going to learn from the early users on WordPress.com and prioritize the next steps. We know that some users will need a premium version on WordPress.com in order to secure a custom domain and other features so we will update that shortly.”

Iain Poulson announced that Plugin Rank is open to the public yesterday. It is a new service that allows plugin authors to track their rankings by keyword on the official WordPress plugin directory. The service is geared toward plugin authors with freemium offerings.

The tools were already in place for Poulson to build the service. He just needed to build his service on top of them. “Plugin Rank leverages the WordPress.org API to retrieve a set of plugins for a search term,” he said. “It’s the same API that WordPress uses when a user searches for a plugin inside their WordPress dashboard or when searching on the plugin directory.”

Poulson described how a user might search for a membership plugin by typing “membership” in the search box. The WordPress API returns a set of plugins that best match that term, based on an internal ranking algorithm. The Plugin Rank service uses this same, underlying technology.

“Plugin Rank will check the API daily to find the latest positions of the plugins for the keywords being tracked by Plugin Rank customers,” he said. “This data is then used to show position movement and charted to show an overall picture of how the plugins are ranking.”

Plugin dashboard screen.

The idea for the service was born from work he and others were doing at Delicious Brains, a WordPress development company, a few months ago. “We’d started to work on improving the copy in the WP Migrate DB plugin readme.txt files to rank higher in search results,” he said. “Brad Touesnard set up a Google sheet with all the keywords we wanted to rank for, a link to search the keyword on wordpress.org, and columns for each month. He started to record the position the plugin appears for each keyword every month. Or that was the idea, when we remembered!”

Poulson began using the same system for WP User Manager and Intagrate, two freemium plugins he had in the plugin directory. However, it did not take long to realize the futility of that system.

“The sheer manual nature of the task of setting up the sheet, monthly checking, and trying to remember to do it made me think there must be a better way,” he said. “So I started to work on an app to do it for me.”

Besides simply providing a particular plugin’s rank, Poulson said the service provides information that can help plugin developers raise their rankings in the search results.

Competitive analysis against other plugins.

“The competitor analysis in Plugin Rank gives you an insight into the top 50 plugins that rank for the keywords you care about,” said Poulson. “It gives you insights into what those plugins are doing that make them rank higher than you. Do they have a high amount of the keyword in their readme? Do they have it in their title or tags? Do they answer the bulk of their support requests? Do they have a large number of five-star ratings?”

A Premium Service with a Premium Price

Plugin Rank is the first service of its kind in the WordPress industry. Therefore, Poulson had to look outside of traditional WordPress channels to get a sense of how to price the new service.

“I looked at similar SEO tools for traditional search engines, like Ahrefs and SEMrush, and tried to base my pricing on how valuable it can be in relation to other marketing channels,” he said.

Only time and feedback will decide whether he found the sweet spot between offering a valuable service and what plugin developers are willing to fork over. The Starter tier allows plugin authors to track up to five keywords for a single plugin. It also includes email reports and competitor analysis. The $9 per month price tag is low enough for developers to dip their toes in and decide whether it is worth upgrading for tracking more keywords and plugins.

The $49 Plus plan allows up to five plugins and 50 keywords. It also includes tracking for multiple languages. The $119 Pro plan bumps the plugin count to 20 and keyword number to 500.

Right now, Plugin Rank is offering a 21-day free trial, which is a no-brainer for any freemium plugin author who might even be remotely interested in the service. I have no doubt I would sign up if I was still in the freemium plugin game.

“Most developers and companies will invest heavily and get good results from content marketing and SEO improvements, and their WordPress.org plugin listing will receive little attention,” said Poulson. “But for freemium plugins, it can be a huge channel for getting people using their plugin and buying the up-sells. So it’s priced with that in mind.”

The Future of the Service

The knowledge of where a plugin stands in the rankings and having the data readily available will undoubtedly help many plugin authors. However, knowledge is merely the beginning of ranking higher. For developers who are not well-versed in marketing and SEO, they will need to develop new skills to make full use of what they learn from the service.

Poulson seems interested in expanding the service beyond its initial goal of providing ranking data. Tutorials, videos, and other resources would be a nice value-add for those who buy into the service now.

“Plugin Rank’s primary functionality at the moment is monitoring and getting access to data,” he said, “but I’ve got features planned that focus on how to make improvements, as well as tutorial-style content on the Resources page.”

Immediately available is BuddyPress 6.2.0. This maintenance release:

• fixes 1 bug related to the 6.0.0 release,
• is preparing BuddyPress for WordPress 5.5.0,
• is a recommended upgrade for all BuddyPress installations.

For details on the changes, please read the 6.2.0 release notes.

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

Many thanks to 6.2.0 contributors 

hareesh-pillai, man4toman, dcavins, boonebgorges, imath

We're seeing the strain of isolation and 100% remote work without meetups, conferences, or other in-person opportunities to collaborate. In this episode of Post Status Draft, Cory and Brian discuss how to create healthy virtual work environments, including some tips for establishing better work days.

Or watch this episode on YouTube:

Sponsor: Pagely

Pagely offers best-in-class managed WordPress hosting, powered by Amazon's Cloud, the Internet’s most reliable infrastructure. Pagely helps big brands scale WordPress.Thank you to Pagely for being a Post Status partner!