Last Friday, Themes Team representative Carolina Nymark announced the Twenty Twenty-One Blocks theme project. It is a block-based version of the Twenty Twenty-One default theme that is shipping along with WordPress 5.6. It will work with the site editor available in the Gutenberg plugin. Developers will work on the two themes as separate projects.
The original plan was to explore support for full-site editing after the WordPress Beta 1 release for Twenty Twenty-One. Some had hoped that support would land in the theme itself. However, a second theme could be a better path in the long run.
As I wrote in my original coverage of Twenty Twenty-One, it did not seem likely that full-site editing would be far enough along in development for it to be a primary feature for the theme. Since the feature will not be in WordPress 5.6, it makes sense to develop for it outside of the primary theme for the time being.
“Twenty Twenty-One Blocks is an experimental theme created as an example to highlight what is possible with Full Site Editing,” wrote Nymark in the announcement. “The theme will need Gutenberg and the Full Site Editing experiment to be enabled. It will not be part of Core, but once complete it will be available in the theme directory.”
Currently, there are no plans to integrate the two themes down the road. They will be maintained as separate projects. This sounds like a smart strategy for this theme. It will allow developers to work on the Blocks theme as a separate entity in the coming months without having to worry about potential problems with merging.
I am excited about this project because it means we get a somewhat official, though not technically a default, theme that supports full-site editing. Otherwise, the community would have had to wait another year for the Twenty Twenty-Two theme, which will presumably be 100% built with blocks.
The Q theme by Ari Stathopoulos, a Themes Team representative, is a little farther along at the moment. It is a solid starting point and learning tool. However, there should be a theme project coming from core WordPress developers that is leading the way for other theme authors. There is a sense of trust, particularly for first-time theme authors, when picking apart an officially-supported theme that it is built to current standards. That is why Twenty Twenty-One Blocks is important.
Thus far, little work has gone into the theme, much of it coming from the original pull request to kick off development from Kjell Reigstad. The theme is currently stored in the WordPress Theme Experiments repository. Ideally, the team will split this theme into its own GitHub repository since it will be added to the theme directory and not merely an experiment.
For theme authors who want to cut their teeth on building block-based themes, this would be a good place to begin taking those initial steps. Or, it will at least be a good project to follow because this is as close to an “official” theme that supports full-site editing that we will see for a while.
At this point, the theme does not do a lot. It is minimal and nowhere near a block-based equivalent of Twenty Twenty-One. However, it works as well as most other themes supporting Gutenberg’s site editor.
For now, template parts do not seem to be working on the front end. However, template parts have been hit or miss in my tests for a while, sometimes seemingly working only by some randomly magical force that rears its head when I close in on the limits of my frustration — it will likely begin working immediately after publishing this post. That is often the nature of testing alpha-level software. Nevertheless, I am excited about following the development of this theme in the coming weeks and months.
This maintenance release fixes an issue introduced in WordPress 5.5.2 which makes it impossible to install WordPress on a brand new website that does not have a database connection configured. This release does not affect sites where a database connection is already configured, for example, via one-click installers or an existing wp-config.php file.
Earlier today — between approximately 15:30 and 16:00 UTC — the auto-update system for WordPress updated some sites from version 5.5.2 to version 5.5.3-alpha. This auto-update was due to an error in the Updates API caused by the 5.5.3 release preparations (see more here). The 5.5.3-alpha version at this point was functionally identical to 5.5.2 as no development work had been started on 5.5.3; however, the following changes may have been made to your site:
The default “Twenty” themes installed as part of the pre-release package.
The “Akismet” plugin installed as part of the pre-release package.
These themes and plugins were not activated and therefore remain non-functional unless you installed them previously. It is safe to delete these features should you prefer not to use them.
If you are not on 5.5.2, or have auto-updates for minor releases disabled, please manually update to the 5.5.3 version by downloading WordPress 5.5.3 or visiting Dashboard → Updates and click “Update Now.”
WordPress’ Core systems team had an eventful Friday when an error in the auto-update system caused sites to update to WordPress 5.5.3-alpha-49449, including live production sites with no auto-update constants defined.
Those who received an email about the update logged into their sites to see the message: “BETA TESTERS: This site is set up to install updates of future beta versions automatically.”
“It’s worth noting that there’s no functional difference between 5.5.2 and 5.5.3-alpha, so there’s no need to worry in that regard,” core committer John Blackbourn said.
Sites that were accidentally updated also installed all the default themes released over the last decade, as well as Akismet. Developers will need to manually delete the bundled themes that they don’t need.
In under an hour, all affected sites were automatically returned to 5.5.2, but the incident has eroded trust and damaged confidence in the auto-update system. Several commenting on the ticket asked how they can explicitly disable development updates.
“The worrying thing is that a single developer can do this, seemingly without any checking or confirmation by other developers,” UK-based developer Paul Stenning said. “This is a serious security concern as a rogue developer could push out malicious code in an update that nobody else checks.”
WordPress agency owner Rob Migchels, who had approximately 50 websites affected, tracked 18 minutes between the the trac ticket (#51679) and receiving the fix.
“The 5.5.3-alpha issue is a side effect of another issue that occurred on 5.5.2,” WordPress engineer and 5.6 Triage release lead Tonya Mork said. Jake Spurlock published an official statement regarding the incident as part of the 5.5.3 release notes:
“Earlier today — between approximately 15:30 and 16:00 UTC — the auto-update system for WordPress updated some sites from version 5.5.2 to version 5.5.3-alpha. This auto-update was due to an error in the Updates API caused by the 5.5.3 release preparations.”
Spurlock elaborated on the technical details in a separate post on the WordPress development blog:
While work was being done to prepare for WordPress 5.5.3, the release team attempted to make 5.5.2 unavailable for download on WordPress.org to limit the spread of the issue noted in the section above, as the error only affected fresh installations. This action resulted in some installations being updated to a pre-release “5.5.3-alpha” version.
In a situation like this, where users who haven’t elected to run their live sites on beta releases are getting a forced update, site owners might wonder whether this update is actually arriving from WordPress, or if the system has been hijacked.
Security researcher Slavco Mihajloski, who commented last week on the lack of transparency regarding how automatic updates are tested and performed, said this incident highlights the need for more openness surrounding the process.
“Why is transparency important? Because procedure will become public and when public, the community will be able to contribute in order to improve it,” Mihajloski said. “At the moment it is more than obvious that this process and the whole security at WP.dot org lacks QA and QC. Each task is left to an individual or closed group. Imagine the following: what if an automatic security update could be pushed only if: – X out of Y (where X < Y) authorities agree that update is fine – have a pilot update on let’s say 100 different servers (I hope .org could afford this) where regression tests will be fired against each one. The current problems would not occur.”
Automatic background updates for minor releases have saved developers thousands of hours in updating sites. A UI for allowing users to opt into automatic updates for major releases is on the roadmap for WordPress 5.6, expected in early December.
This particular accidental update has betrayed for many developers what was already a somewhat fragile trust in the auto-update system. It doesn’t shore up more confidence for selling the idea of core updates when 5.6 is released, but it doesn’t mean that auto-updates are not a good idea. WordPress.org will need to put better processes in place in order to win back users’ trust.
The incident affected more than 100 sites for WordPress agency owner Robert Staddon. He reports that they all displayed the “Update now” button with the confusing and incorrect text seen below. Staddon said the incident has not yet caused him to change his approach to allowing clients to receive auto-updates.
“I was very grateful for the extraordinarily fast response time to get the problem fixed,” Staddon said. “However, it did shake my confidence in the WordPress auto-update process. Considering the number of websites using WordPress, a mistake of this magnitude could end up having a rather catastrophic effect around the web. I would hope that the core team would be able to evaluate how this happened and consider putting some checks in place to make sure it doesn’t happen again.”
Over the last few years, Microsoft has tightly integrated OneDrive, its cloud storage service, into Windows. Using OneDrive used to be a cumbersome pain — now, OneDrive is built right into Windows, and can be used automatically.
As soon as you install OneDrive on a PC and set up your account, you should see OneDrive and all its subfolders in the File Explorer.
Here’s how to make sure OneDrive will appear.
How to add OneDrive to the File Explorer
To see your OneDrive files in the File Explorer, you need to link your computer to your OneDrive account.
1. Click the Start search box and type “OneDrive.” When OneDrive appears in the search results, click it.
2. Enter the email address that’s associated with your OneDrive account and click “Sign in,” and then enter your password. If you don’t have a OneDrive account, you’ll need to make one.
3. Follow the instructions to choose your OneDrive folder. If you’ve previously signed into OneDrive on this PC, you might have an existing OneDrive folder. In that case, you can click “Use this folder.”
When you’re done, your OneDrive files will appear in File Explorer. You can now move files in and out of OneDrive easily.