In order to help developers learn how to migrate from the classic editor to Gutenberg, Daniel Bachhuber has launched a Gutenberg Migration Guide. Bachhuber is seeking the community’s help in identifying and filling a database to document all of the ways the classic editor can be customized.
Take a look through the Gutenberg Migration Guide. For each action, filter, and so on, we’d like to document real-world examples of how they’ve been used. Then, for each of those real-world examples, identify how the feature might be replicated in Gutenberg.
He uses the media_buttons action as an example. This action is commonly used to add a button to the top of the editor. Developers can accomplish the same task in Gutenberg using the block inserter.
If you have any questions or suggestions, you’re encouraged to create a new issue on GitHub.
In this episode, John James Jacoby and I start the show with a shout out to WebDevStudios, a web development agency that’s celebrating its 10th year in business. We then cover what’s new in BuddyPress 3.0, why plugins hosted on WordPress.org can no longer claim legal compliance, and what to expect from 0.7 of the AMP for WordPress plugin. Last but not least, we share what’s new in Gutenberg 2.7 and explain why you shouldn’t edit content written in Gutenberg with the WordPress for iOS app just yet.
This release adds Native AMP support for all of the default widgets, embeds, and commenting. Notifications will be triggered for posts that contain content with validation errors or if you use a theme or plugin that adds invalid AMP markup.
While earlier versions of AMP displayed content in a way that was different from a site’s theme, 0.7 creates a native experience. For example, if you visit the AMP Conf WordPress Theme Demo site on an iPhone 7, the site looks exactly the same. As you can see in the image below, you can’t tell it’s running AMP.
Before 0.7 is officially released, the development team is asking for users to put 0.7 RC 1 through its paces and report issues on the project’s GitHub page. You can download the pre-release version here.
For more information on the AMP project, listen to episode 309 of WordPress Weekly where I interviewed Alberto Medina, Developer Advocate working with the Web Content Ecosystems Team at Google, and Weston Ruter, CTO of XWP. In this interview, we covered why the project was created, its future, and its potential impacts on the Open Web.
Delicious Brains have published the process they use for creating and releasing WordPress plugins. The post covers development, brainstorming, reviewing, testing, and wire frames. The team also describes the products and services they use and the roles they play within their projects. How is their process different or similar to yours?
When it comes to editing and crafting content on the go, the WordPress Mobile apps are a good choice. The question is, how does the editor in the iOS app interact with content written in Gutenberg? Let’s find out.
Quick Edits Turn Into Lengthy, Frustrating Fixes
For testing purposes, I used a simple scenario that many users may run into. I’ve written and published a post in Gutenberg using paragraph, unordered lists, and image blocks. I then used the WordPress for iOS mobile app to access the post, correct a typo, and save it. The goal is to see if content is effected by saving it in a different editor.
Here is what the content looks like written and published in Gutenberg.
Here is what the post looks like in the iOS app. It displays what appears to be Comment shortcodes at the beginning of each paragraph.
After correcting a typo and saving the changes, this is what happened to the post. As you can see, what was supposed to be a quick fix has turned into a lengthy process of fixing the entire article in Gutenberg.
All of the content runs together as one giant block. To say that this is frustrating is an understatement, especially if you’re on the road and don’t have access to a desktop or tablet that can load the WordPress backend.
Here is what the content looks like in Gutenberg after saving the edits in the iOS app. There are large gaps and a few of the blocks have warnings stating that they appear to have been modified externally.
Clicking the convert to block buttons turns the messages into blocks but it doesn’t return the formatting and in some cases, content goes missing. Before editing in the iOS app, this block contained a quote with a citation. Now it’s empty.
WordPress has post revisions so I was able to quickly restore the breaking changes introduced by the iOS app. But this user experience between Gutenberg and the WordPress for iOS app is a great example of how something so simple can easily turn into a perceived disaster by users and ultimately, tarnish the new editor’s reputation.
Searching the Gutenberg repository on Github for iOS produces some results, but none refer to the compatibility issues I experienced.
I found out the hard way and will not be making any more changes to posts written in Gutenberg in the iOS app until compatibility between both editors exists. I recommend you don’t as well unless you want to fix a lot more than a typo.
Gutenberg 2.7 is available for testing and not only does it refine the visuals around block controls, it adds the highly requested ability to edit permalinks.
A new pagination block is available that adds a page break, allowing users to break posts into multiple pages. The block is located in the Blocks – Layout Elements section.
There are a number of changes to the link insertion interface. Gutenberg 2.7 brings back the option to have links open in the same window.
When editing linked text, the Unlink icon now stays in the toolbar instead of displaying within the link options modal. When adding links, there’s a URL suggestion tool similar to what’s available in WordPress’ current editor.
What will be welcomed news to plugin developers, the PluginSidebar API is exposed and considered final. According to the pull request, this change does the following.
Refactors all the existing Sidebar components to share the same set components and removes duplicated custom CSS styles applied to <PluginSidebar />. There are no changes to the public API of <PublicSidebar /> component, other than it is going to be available under wp.editPost.PluginSidebar.
This release, like the others before it, has a changelog that’s a mile long. Please check out the release post for a detailed list of changes and links to issues on GitHub.
The handbook was created after the accessibility team repeatedly noticed the same accessibility issues cropping up and not having a central place to send people to learn about them.
The team is looking for people to review articles, discover resources to add to the handbook, and suggest topics to cover. If you’re interested in contributing, please join the #accessibility-docs channel on Slack where you can ask questions and learn more about the project.
Also, consider following WPAccessibility on Twitter to keep tabs on team projects and links to resources.
The BuddyPress development team has released Beta 2 of BuddyPress 3.0. BuddyPress 3.0 is a major release that contains some significant changes. A new template pack called Nouveau will replace the bp-legacy template packs introduced in BuddyPress 1.7.
BuddyPress 3.0 utilizes the Customizer by providing options to manipulate the Nouveau template pack or the site itself. For example, you can modify a user’s navigation options from the frontend. There’s also an option to adjust the number of columns for the Members loop.
Last week, I had the pleasure of joining Michael Fienen and Aaron Hill, hosts of the Drunken UX podcast, to discuss Gutenberg. We covered a lot of topics, including, why Gutenberg was created, our experiences, its timeline, pros, cons, resources, our biggest concerns, and what developers and freelancers need to know.
The show is one hour and thirty minutes in length. By the way, please don’t criticize my drink of choice.
The plugin review team has amended guideline number nine which states, developers and their plugins must not do anything illegal, dishonest, or morally offensive, to include the following statement:
Implying that a plugin can create, provide, automate, or guarantee legal compliance
Mika Epstein, a member of the WordPress.org plugin review team, says the change was made because plugins by themselves can not provide legal compliance.
Sadly, no plugin in and of itself can provide legal compliance. While a plugin can certainly assist in automating the steps on a compliance journey, or allow you to develop a workflow to solve the situation, they cannot protect a site administrator from mistakes or lack of compliance, nor can they protect site users from incorrect or incomplete legal compliance on the part of the web site.
Since sites can have any combination of WordPress plugins and themes activated, it’s nearly impossible for a single plugin to make sure they’re 100% legally compliant.
Plugin developers affected by this change will be contacted by the review team and be asked to change their titles, descriptions, plugin header images, and or the text within the readme.
Instead of claiming compliance, the team has published a frequently asked questions document that recommends plugin authors explain how the plugin will assist in compliance. If you have any questions, please leave a comment on the announcement post.
In this episode, John James Jacoby and I start the show by sharing our thoughts on Mark Zuckberberg’s congressional hearing. We then discuss what’s new in Gutenberg 2.6 and describe our user experience. We let you know what’s in WooCommerce 3.3.5 and discuss what the development team is doing to prepare for GDPR compliance.
The WordPress Theme Review team has implemented changes that simplify the process and places more responsibility onto theme authors. Theme reviewers now only need to check the following items to pass a theme.
Malicious or egregious stuff
Although the bar to pass a theme is significantly lower, theme authors are still expected to follow the required and recommended requirements listed in the theme handbook.
Moderators will check themes after they’ve gone live to make sure the author is following guidelines. If a moderator discovers any issues, a request will be made to the theme author to correct them. Failure to do so could lead to a temporary or permanent suspension.
Justin Tadlock clarified in the comments examples of egregious issues.
In the past two years, The Theme Review Team has battled the theme review queue with moderate success. In early 2017, the number of themes in the queue dropped below 200. Although there has been some work on automating the process, it’s largely reliant on humans.
Even though it hasn’t been updated in more than a year, theme authors are highly encouraged to use the Theme Check plugin before submitting themes for review.
With a simplified process to get a theme live, reviewers are hoping it will free them up to focus on larger projects.