fidzu : WordPress

For users of the Classic WordPress editor who often needed to insert special characters into their posts, life was once simple. Click the "Ω" button in the editor to open a modal with a list of characters not found on a standard keyboard. The user then only needed to click on the character they wanted to insert and go about the business of writing their post.

For users who made the move to the block editor and were accustomed to inserting special characters at the click of a button, life became more complicated. The answer to their woes was to first insert a Classic block and use its special character inserter, which kind of defeats the purpose of using the new and shiny block editor. Another option was to use the special character app/program packaged with their computer, which assumes all users know the keyboard shortcut for it or how to run the program.

By many accounts, this would be considered a standard feature for any text editor. When WordPress is at a stage of trying to sell a new editor, it should be prepared to include features that users of the old editor consider standard. The lack of a special-character inserter could have been written off as an oversight if people were not asking for it.

• Reimplement Character Map
• Just a Few More Text/Paragraph Formatting Choices?
• Add Special Character Menu
• Where Are the Special Characters?

People were asking for it.

Fortunately, the requests caught the attention of the 10up team. In September this year, they released the first version of their Insert Special Characters plugin. It has since gone through a couple of updates and works well across browsers.

The plugin is simple and does its job much better than the previous Classic editor inserter. Instead of just handling the basics, the team went above and beyond what was necessary to launch the plugin.

The plugin adds a new sub-menu item to the text toolbar titled "Ω Special Characters."

"Special Characters" rich text menu item.

After clicking the link to insert a special character, a modal box appears on the screen. The box provides hundreds of special characters to choose from. It sorts them under Miscellaneous, Math, Latin, and Arrow categories while providing a search filter to narrow down the list. The box can also be reached by typing ctrl/cmd + o on the keyboard.

Special characters insertion modal box.

Like many modals, the box pops up in a weird position from time to time, depending on where the insertion point is on the screen. Outside of that, I found no major problems with the plugin.

The plugin also provides a hook for other developers to manipulate the tabs and available characters in the modal.

This does beg the question of whether the feature should be implemented in the core block editor now. If the core team puts it in at this point, one would hope they would make it competitive with the plugin. Anything less would be a letdown.

13 Dec 2019 8:46pm GMT

WordPress 5.3.1 was released today with 46 bug fixes and enhancements. Changes include several accessibility improvements and four security vulnerability fixes. The update includes multiple changes to the default Twenty Twenty theme.

Version 5.3.1 is a security and maintenance release. All users are encouraged to update as soon as possible. For those with auto-updates enabled, updates are currently rolling out. All major branches of WordPress from version 3.7 through 5.3 received the new security fixes.

The following security issues were addressed:

• Users without the correct permission (capability) could make a post sticky via the REST API.
• An issue where cross-site scripting (XSS) could be stored in links.
• Hardening the wp_kses_bad_protocol() function so that it is aware of the named colon attribute.
• A stored XSS vulnerability using block editor content.

Most of the release focused on maintenance. Form fields and buttons now have the same height, which should result in a more consistent admin UI. This has long been an issue, but the accessibility changes in WordPress 5.3 highlighted the problem.

A bug with how permalinks were generated with the new Date/Time changes in WordPress 5.3 has been fixed. This left some sites using date-based URLs with incorrect post permalinks.

Other changes include removing support for the CollegeHumor oEmbed provider (the site is no longer available), updating the sodium_compat library, and making sure admin verification emails use the user's locale instead of the site's locale. For a full overview of all changes, visit the WordPress 5.3.1 release page.

Accessibility Improvements

"Coffee" color scheme with new button colors.

Some of the biggest accessibility changes fixed issues with the alternate admin color schemes available in WordPress. The accessibility improvements to buttons in WordPress 5.3 did not get carried over to most of the alternate schemes. Or, rather, those alternate color schemes were not taken into account when the changes went into effect. This left secondary button elements practically unreadable in some cases, which made accessibility worse.

Version 5.3.1 creates a unified design for secondary buttons for every color scheme. It also makes sure that the :active state for buttons are consistent.

Other improvements to accessibility include adding underlines to links on the Dashboard screen that were not clearly links by context, properly disabling nav menu forms when they should not be in use, and adding hover effects for links on the "About" admin screens.

Twenty Twenty Changes

Author bio option in the customizer.

The Twenty Twenty theme launched with JavaScript-based, smooth-scroll behavior for anchor links. This feature did not work correctly in all cases. It also broke anchor links to individual comments when paginated comments were enabled on a site.

Version 1.1 of Twenty Twenty includes CSS-based, smooth-scroll behavior. This greatly simplifies the code by using native behavior. It also works based on the user's reduced motion setting for their browser, which enhances accessibility for the theme.

The theme update comes packaged with a new option for showing or hiding the post author bio. The setting is available under the "Theme Options" section in the customizer. It is enabled by default and will show the author bio section at the end of every post across the site.

The Twenty Twenty update also includes several bug fixes, most of which were trivial issues.

13 Dec 2019 12:58am GMT

WordPress 5.3.1 is now available!

This security and maintenance release features 46 fixes and enhancements. Plus, it adds a number of security fixes-see the list below.

WordPress 5.3.1 is a short-cycle maintenance release. The next major release will be version 5.4.

You can download WordPress 5.3.1 by clicking the button at the top of this page, or visit your Dashboard → Updates and click Update Now.

If you have sites that support automatic background updates, they've already started the update process.

Security updates

Four security issues affect WordPress versions 5.3 and earlier; version 5.3.1 fixes them, so you'll want to upgrade. If you haven't yet updated to 5.3, there are also updated versions of 5.2 and earlier that fix the security issues.

• Props to Daniel Bachhuber for finding an issue where an unprivileged user could make a post sticky via the REST API.
• Props to Simon Scannell of RIPS Technologies for finding and disclosing an issue where cross-site scripting (XSS) could be stored in well-crafted links.
• Props to the WordPress.org Security Team for hardening wp_kses_bad_protocol() to ensure that it is aware of the named colon attribute.
• Props to Nguyen The Duc for discovering a stored XSS vulnerability using block editor content.

Maintenance updates

Here are a few of the highlights:

• Administration: improvements to admin form controls height and alignment standardization (see related dev note), dashboard widget links accessibility and alternate color scheme readability issues (see related dev note).
• Block editor: fix Edge scrolling issues and intermittent JavaScript issues.
• Bundled themes: add customizer option to show/hide author bio, replace JS based smooth scroll with CSS (see related dev note) and fix Instagram embed CSS.
• Date/time: improve non-GMT dates calculation, fix date format output in specific languages and make get_permalink() more resilient against PHP timezone changes.
• Embeds: remove CollegeHumor oEmbed provider as the service doesn't exist anymore.
• External libraries: update sodium_compat.
• Site health: allow the remind interval for the admin email verification to be filtered.
• Uploads: avoid thumbnails overwriting other uploads when filename matches, and exclude PNG images from scaling after upload.
• Users: ensure administration email verification uses the user's locale instead of the site locale.

For more information, browse the full list of changes on Trac or check out the version 5.3.1 HelpHub documentation page.

Thanks!

In addition to the security researchers mentioned above, thank you to everyone who contributed to WordPress 5.3.1:

123host, acosmin, Adam Silverstein, Albert Juhé Lluveras, Alex Concha, Alex Mills, Anantajit JG, Anders Norén, andraganescu, Andrea Fercia, Andrew Duthie, Andrew Ozz, Andrey "Rarst" Savchenko, aravindajith, archon810, Ate Up With Motor, Ayesh Karunaratne, Birgir Erlendsson (birgire), Boga86, Boone Gorges, Carolina Nymark, Chetan Prajapati, Csaba (LittleBigThings), Dademaru, Daniel Bachhuber, Daniele Scasciafratte, Daniel Richards, David Baumwald, David Herrera, Dion hulse, ehtis, Ella van Durpe, epiqueras, Fabian, Felix Arntz, flaviozavan, Garrett Hyder, Glenn, Grzegorz (Greg) Ziółkowski, Grzegorz.Janoszka, Hareesh Pillai, Ian Belanger, ispreview, Jake Spurlock, James Huff, James Koster, Jarret, Jasper van der Meer, Jb Audras, jeichorn, Jer Clarke, Jeremy Felt, Jip Moors, Joe Hoyle, John James Jacoby, Jonathan Desrosiers, Jonny Harris, Joost de Valk, Jorge Costa, Joy, Juliette Reinders Folmer, justdaiv, Kelly Dwan, Kharis Sulistiyono, Kite, kyliesabra, lisota, lukaswaudentio, Maciej Mackowiak, marcelo2605, Marius L. J., Mat Lipe, mayanksonawat, Mel Choyce-Dwan, Michael Arestad, miette49, Miguel Fonseca, mihdan, Mike Auteri, Mikko Saari, Milan Petrovic, Mukesh Panchal, NextScripts, Nick Daugherty, Niels Lange, noyle, Ov3rfly, Paragon Initiative Enterprises, Paul Biron, Peter Wilson, Rachel Peter, Riad Benguella, Ricard Torres, Roland Murg, Ryan McCue, Ryan Welcher, SamuelFernandez, sathyapulse, Scott Taylor, scvleon, Sergey Biryukov, sergiomdgomes, SGr33n, simonjanin, smerriman, steevithak, Stephen Bernhardt, Stephen Edgar, Steve Dufresne, Subrata Mal, Sultan Nasir Uddin, Sybre Waaijer, Tammie Lister, Tanvirul Haque, Tellyworth, timon33, Timothy Jacobs, Timothée Brosille, tmatsuur, Tung Du, Veminom, vortfu, waleedt93, williampatton, wpgurudev, and Zack Tollman.

13 Dec 2019 12:07am GMT

The past two weeks have been blazing fast for Gutenberg plugin development. A total of 161 pull requests (patches) were merged into version 7.1 of the plugin. Over 20 bugs were squashed while the team added several enhancements, which include better multi-block selection, a new welcome modal, and drag-and-drop featured images.

The team refactored several areas of the codebase to prepare for future changes and make it possible to use new hooks. API changes include a new custom select control, text highlight, and custom gradient picker components for developers to use in their plugins.

The release also featured a toolbar button for switching between "edit" and "select" mode. The select mode allows you to select blocks without opening the editing controls unless you click again within a block, which switches you back to editing mode. The only noticeable difference is that the editing controls do not appear while in select mode. Wondering when I will ever use this feature…

Welcome Guide Modal

New welcome guide modal for first-time users.

The new version of the plugin includes a pop-up welcome modal for first-time users. There are currently three panels with short introductions to what blocks are, how to use them, and getting to know the block library.

Ideally, the modal will link out to more extensive documentation in a future iteration. Right now, the information provided does not go into much detail. It feels like a message to say, "Hey, check out this shiny new thing." However, there needs to be more substance for it to be helpful for first-timers.

Improved Multi-block Selection

Selecting multiple blocks at once.

The block editor now incorporates a nicer native multi-block selection process. The first aspect of this change is to use the native selection color, which improves accessibility. It also uses native selection behavior when selecting multiple blocks.

The second part is important because it paves the way toward partial block selection in a future release. Currently, when selecting text across multiple blocks, the editor extends this out to select all text from the selected blocks. In the future, it should be possible to select only part of the text across multiple blocks. This would be consistent with normal text-based editors where users can select the last sentence from one paragraph and the first from the next, for example.

Selecting multiple blocks and pasting new content works correctly in 7.1. In the past, the rich text component handled pasting. This resulted in the blocks being split and the pasted content inserted between the split. The block editor now handles the pasting process. This allows users to completely replace multiple selected blocks with a paste.

Drag-and-Drop Featured Images

Dragging a featured image from the desktop.

Instead of clicking the featured image box to open the media modal, users can now save themselves a click. Just like dragging and dropping an image into the editor, the featured image box now accepts any image file dropped into it.

Table Captions

Adding a caption to the table block.

For those who have long waited for a true table <caption> implementation, keep on waiting.

A year-old ticket that was opened for a table caption feature was closed with a solution matching that of other blocks with captions (e.g., image, gallery). The pull request featured a lengthy discussion over the technical limitations of how to best handle the feature. Ultimately, the decision was to wrap tables in a <figure> element and add the caption via the <figcaption> tag.

While this may work for some who need to add a caption or summary below a table, it is not currently helping users who need captions in their normal spot at the top of a table.

In the long run, users who need to roll out advanced tables will likely need a table block plugin anyway. The Gutenberg and core WordPress implementation is limiting for anything beyond the most basic table output. Real captions would have been a nice touch though.

Alignment for the Navigation Block

Aligning navigation block items.

The Navigation block, which moved out of the experimental stage in version 7.0, has a new option for justifying the list items to the left, right, or center. This will be an important feature for full-site editing in the long term because users will want to set their nav menu perfectly.

This block will likely be in flux for a while. There are still major questions about how navigation will work on mobile, especially as we inch closer to full-site editing. Will core play a role in making mobile menus? Will themes be left to their own devices? Will themes offer multiple options based on screen size?

Moving Ahead with Templates and Full-Site Editing

Coming off the heels of a somewhat controversial documentation proposal for block-based themes, version 7.1 includes a new demo block template named index.html. It is a fallback template in cases where no templates are available. This is an early, experimental step toward making full-site editing a reality.

Theme developers who want to start looking at what block templates could look like, should view the demo index.html template.

Unfortunately, the release ZIP file available through the official plugin repository does not include the index.html template. It was excluded because of a bug in the build process. However, it may be packaged in a version 7.1.1 minor release. The file is correctly included for developers who clone from the Git repository.

The second step of this process was the addition of a Template Part block. The idea for this block is that it would be a placeholder to add to templates, which would output a template part on the front end.

11 Dec 2019 9:21pm GMT

bbPress 2.6.3 fixes 9 issues reported by community members:

• Fixes a few typos and grammatical errors
• Bumps required WordPress versions to 5.3.0 (bbPress always only officially supports the latest WordPress version)
• Fixes the Forums widget displaying in the wrong order
• Fixes a JavaScript error with hierarchical replies

We're continuing to work on improving bbPress 2.6 while also deciding what exactly will make it into 2.7.

Expect for the next minor release (bbPress 2.6.4) to be released sometime before Christmas 2019.

10 Dec 2019 8:52pm GMT

Jeffrey Carandang, the creator behind the EditorsKit WordPress plugin, launched a new community site for sharing block designs and templates today. The ShareABlock website allows visitors to download block files directly from the site and import them into the block editor. Users can also sign up to share custom block designs and full-blown block templates. All downloads are available for free.

At the moment, there are 18 block designs available for download. There are two primary types of downloads: block patterns and block templates.

Patterns are smaller groupings of blocks to create a specific section for a page. These include designs such as various hero sections, pricing lists, and a call-to-action section.

Templates work the same way as patterns. However, they are larger sets of blocks designed to create an entire page. For example, one template allows users to import a full gallery portfolio page. Another creates an editable resume layout.

Other than Carandang, two other contributors have shared block designs. This number should rise as more people sign up and decide to share their creations. The registration process is open to anyone who wants to join. However, each contribution is subject to a review for quality assurance.

"One of my primary goals in creating [EditorsKit] is to help users get a little more comfortable with using the new WordPress Gutenberg block editor," described Carandang in the announcement post for ShareABlock. "The goal is to help users create Gutenberg blocks easily. With drag and drop import, layout and designs will be available in an instant."

Carandang feels confident that pre-configured block designs will help users learn how to use the block editor to create richer content. "Even if it's just a little help to make them comfortable with Gutenberg, it means a lot," he wrote.

He said the feedback from users has been positive thus far.

Importing the Fullscreen Profile Card block pattern.

Block designs downloaded from ShareABlock require the EditorsKit plugin, which is available for free in the WordPress plugin directory. This requirement is because WordPress does not currently have a native importer built into the block editor. In the future, this may change and the requirement could be lifted.

Version 1.7 of EditorsKit introduced the ability to import blocks by dragging and dropping a block .json file into the editor. The blocks available via ShareABlock work using this feature. After downloading a .json file from the site, users merely need to drag it into the editor. Users can also use the "Import" block available from EditorsKit to do the same.

Block Patterns and the Future

"The plan is to provide integration with Block Patterns, which is what the core devs are currently working on," said Carandang. "With this integration, the import process will be much easier."

Block patterns are a planned feature that is under active development in the Gutenberg plugin and will eventually make its way into core WordPress. Patterns are predefined sets of blocks. They will allow users to quickly create more advanced layouts while also teaching what specific blocks do. The idea is to have a set of patterns with common layouts that people see around the web.

Carandang said he is actively checking the progress of the Block Patterns feature. He is eager to see the feature to come to fruition, which carries with it the possibility of more widespread use of the blocks available from his new community.

10 Dec 2019 7:51pm GMT

Immediately available is BuddyPress 5.1.0. This maintenance release fixes 8 bugs related to the 5.0.0 release, and is a recommended upgrade for all BuddyPress installations.

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

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

Many thanks to 5.1.0 contributors

szepe.viktor, JarretC, Renato Alves (espellcaste), David Cavins (dcavins), Boone Gorges (boonebgorges), John James Jacoby (johnjamesjacoby) & Mathieu Viet (imath).

09 Dec 2019 9:45pm GMT

Josepha Haden, Executive Director of WordPress, published an update of WordPress' goals in 2019. The focus for WordPress over the past year has been on nine primary projects. Of the nine projects, WordPress only managed to ship two in 2019. This means that the focus in 2020 will be much the same as the community continues building on the progress it has made toward the existing projects.

Currently, there are three planned major releases for WordPress in 2020:

• Version 5.4 - March 2020
• Version 5.5 - August 2020
• Version 5.6 - December 2020

Each of those dates are subject to change. We should also get more specific dates as each release draws near. The various projects for 2020 should land in each release.

Matt Mullenweg, co-founder of WordPress, initially laid out the 2019 plans in his 2018 State of the Word address and listed the projects on the Make Core blog. The big takeaway is that 2019 was supposed to be the year that we got closer to full-site customization (Phase 2 of the Gutenberg project). While developers have made huge strides in making that a reality, much of the project is still in its infancy.

Projects That Shipped in 2019

All existing core WordPress widgets now exist as blocks. Rather than being limited to placing widgets where the theme decides, users can now put widgets in posts, pages, or any other content area via the block editor. As the project continues to move toward full-site editing, users will eventually have the ability to place these widgets and other blocks nearly anywhere.

The site health project was merged into core. It features a screen that provides information about the site's health to site owners. It also has a fatal-error detection script that emails site owners when plugin and theme issues are found.

Projects to Expect in 2020

Most of the remaining projects that did not quite make the cut for release in 2019 have still made progress during the year. The following is a breakdown of what projects to expect in the coming year.

Navigation Menu Block

Navigation block in the block editor.

Currently, the navigation block's target is to ship with WordPress 5.4. This is a likely reality because it is now out of the experimental stage and is available for beta testing in Gutenberg 7.0. The development team worked on this block for several releases and now have something stable enough for user testing.

This block is a major piece of the site-customization puzzle. In the long term, users will need an easy-to-use block for handling navigation menus across their site.

Custom Block-Aware Content Areas for Themes

Phase 1 of the Gutenberg project brought the block editor to post content. A large part of Phase 2 is breaking outside of post content and allowing users to add blocks in more areas. It is unclear exactly what that will look like in the long run. Themes should be able to register additional block-aware areas.

The target release for this feature is set to WordPress 5.5, but it is too early to guess whether that is a realistic target. It is a tough issue to solve because it will need to coincide with decisions on theme block templates, saving multiple entities, and full-site customization in general. It is not a feature that can be rushed because it will have far-reaching consequences to how WordPress works for years into the future.

Widget Areas to Support Blocks

Experimental widget areas feature in Gutenberg.

The current plan is to allow widget areas (sidebars) to support blocks alongside widgets. The Gutenberg plugin has an experimental widget areas option for enabling an early version of this feature, which has a target release of WordPress 5.5.

There are two aspects to making this feature a reality. The first is making it work on the widgets admin screen. The second is making it work in the customizer, an area where users can also manage widgets.

At the moment, it feels like the sidebar concept should be deprecated. The experimental feature works by allowing users to add blocks to a sidebar, which are converted into one big "block area" widget on output. If WordPress is "all in" on the block paradigm, energy would be better spent focusing on allowing themes to build custom block areas and letting the official Sidebar API die a slow death. Mixing an old concept with a new one feels clunky at best. It's time to move on and soft-deprecate sidebars and widgets until most themes no longer support them.

Block Directory Search and Install

Experimental block directory search in Gutenberg plugin.

Eventually, all WordPress users will be able to search for a block via the block inserter. If the block exists, they can insert it into the block area. If not, the inserter will allow users to discover new blocks from the block directory. The installation, activation, and insertion of the new block should be seamless.

The target release for this feature is set for WordPress 5.5, which should be possible (if not earlier) based on how well the feature currently works in the Gutenberg plugin. It is not perfect yet and has broken more than a few of my posts when working with installed blocks. There are still several open issues that need to be addressed.

Plugin authors who are looking to get ahead of the game can submit block plugins by following the block plugin guidelines.

Automatic Plugin, Theme, and Major Core Updates

After years of extensive testing and using automatic updates for minor WordPress releases, it feels like we should already have auto-updates on everything at this point. Having to keep up with plugin and theme updates can be a pain for some site owners. With enough plugins, it is not out of the realm of possibility to have one or more plugins to update daily.

Some hosting solutions and Jetpack have mitigated this issue for many users by offering automatic plugin updates, but this is a long overdue core feature that should be a high priority. No target release was given for auto-updates on themes/plugins or major core releases. Let's hope the feature does not get put on the back burner for another year.

Tackling Over 6,500 Trac Issues

With the Gutenberg plugin getting much of the attention these days, it is easy to forget that there are thousands of tickets awaiting patches, reviews, and decisions on Trac. I have long been a champion of using one major release of WordPress to simply fix existing bugs while adding no new features.

Jonathan Desrosiers has written an extensive post that covers much of the work the Triage Team has done earlier this year.

Triaging is not something that ever truly reaches a conclusion. It is an ongoing process that must continue throughout the life of a project. People who are interested in being involved with the Triage Team can find more information on the Triage Team announcement post.

09 Dec 2019 9:25pm GMT

I recently took part in DoSummitGood, an online conference for people and organizations working to Do Good in the WordPress community.

The organizers managed to get recordings of all the talks on YouTube the very next day, which is pretty impressive.

In this talk I tell a lot more about what was going on in my personal life while spinning up HeroPress, so I recommend checking it out even if you've already heard the story.

The post Video from DoSummitGood appeared first on HeroPress.

09 Dec 2019 4:13pm GMT

You've probably heard that WordPress is open-source software, and may know that it's created and run by volunteers. WordPress enthusiasts share many examples of how WordPress changed people's lives for the better. This monthly series shares some of those lesser-known, amazing stories.

Meet Jill Binder

Jill Binder never meant to become an activist. She insists it was an accident.

Despite that, Jill has led the Diversity Outreach Speaker Training working group in the WordPress Community team since 2017. This group is dedicated to increasing the number of women and other underrepresented groups who are stepping up to become speakers at WordPress Meetups, WordCamps, and events.

Jill's back story

Internship

Jill's WordPress story begins in 2011, in Vancouver, Canada. Jill secured an internship for her college program, working on a higher education website that was built in WordPress. As a thank you, her practicum advisor bought Jill a ticket to WordCamp Vancouver 2011: Developer's Edition. After that Jill began freelancing with WordPress as a Solopreneur.

First steps in the WordPress community

The following year her internship advisor, who had become a client, was creating the first ever BuddyCamp for BuddyPress. He asked Jill to be on his organizing team. At that event she also moderated a panel that had Matt Mullenweg on it. Then, Jill was invited to be on the core organizing team for WordCamp Vancouver.

Part of this role meant reviewing and selecting speakers. From 40 speaker applications that could be a fit the team had to pick only 14 to speak.

The diversity challenge when selecting speakers

For anyone who has organized a conference, you know that speaker selection is hard. Of the 40 applications, 7 were from women, and the lead organizer selected 6 of those to be included in the speaker line up.

At this point Jill wasn't aware that very few women apply to speak at tech conferences and suggested selection should be made on the best fit for the conference. The team shared that not only did they feel the pitches were good and fit the conference, but they also needed to be accepted or the Organizers would be criticized for a lack of diversity.

Selecting women for fear of criticism is embarrassing to admit, but that's how people felt in 2013.

By the time the event happened, though, the number of women speakers dropped to 4. And with an additional track being added, the number of speakers overall was up to 28. Only 1 speaker in 7 was a woman (or 14%) and attendees did ask questions and even blogged about the lack of representation.

What keeps women from applying?

Later that year at WordCamp San Francisco-the biggest WordCamp at the time (before there was a WordCamp US)-Jill took the opportunity to chat with other organizers about her experience. She found out that many organizers had trouble getting enough women to present.

Surprisingly Vancouver had a high number of women applicants in comparison to others, and the consensus was more would be accepted if only more would apply.

Jill decided that she needed to know why this was happening? Why weren't there more women applying? She started researching, reading, and talking to people.

Though this issue is complex, two things came up over and over:

• "What would I talk about?"
• "I'm not an expert on anything. I don't know enough about anything to give a talk on it."

A first workshop with encouraging results

Then Jill had an idea. She brought up the issue at an event and someone suggested that they should get women together in a room and brainstorm speaker topics.

So Jill became the lead of a small group creating a workshop in Vancouver: the talented Vanessa Chu, Kate Moore Hermes, and Mandi Wise. In one of the exercises that they created, participants were invited to brainstorm ideas-this proved that they had literally a hundred topic ideas and the biggest problem then became picking just one!

In the first workshop, they focussed on:

• Why it matters that women (added later: diverse groups) are in the front of the room
• The myths of what it takes to be the speaker at the front of the room (aka beating impostor syndrome)
• Different presentation formats, especially story-telling
• Finding and refining a topic
• Tips to become a better speaker
• Leveling up by speaking in front of the group throughout the afternoon

Vancouver Workshop 2014

Leading to workshops across North America and then the world

Other cities across North America heard about the workshop and started hosting them, adding their own material.

Many women who initially joined her workshop wanted help getting even better at public speaking. So Jill's Vancouver team added in some material created from the other cities and a bit more of their own. Such as:

• Coming up with a great title
• Writing a pitch that is more likely to get accepted
• Writing a bio
• Creating an outline

At WordCamp Vancouver 2014-only one year since Jill started-there were 50% women speakers and 3 times the number of women applicants! Not only that, but this WordCamp was a Developer's Edition, where it's more challenging to find women developers in general, let alone those who will step up to speak.

More work is needed!

Impressive as those results were, the reason Jill is so passionate about this work is because of what happened next:

• Some of the women who attended the workshop stepped up to be leaders in the community and created new content for other women.
• A handful of others became WordCamp organizers. One year Vancouver had an almost all-female organizing team - 5 out of 6!
• It also influenced local businesses. One local business owner loved what one of the women speakers said so much that he hired her immediately. She was the first woman developer on the team, and soon after she became the Senior Developer.

Diversity touches on many levels

Jill has seen time and again what happens when different people speak at the front of the room. More people feel welcome in the community. The speakers and the new community members bring new ideas and new passions that help to make the technology we are creating more inclusive. And together we generate new ideas that benefit everyone.

This workshop was so successful, with typical results of going from 10% to 40-60% women speakers at WordCamps, that the WordPress Global Community Team asked Jill to promote it and train it for women and all diverse groups around the world. In late 2017, Jill started leading the Diverse Speaker Training group (#wpdiversity).

Dozens of community members across the world have now been trained to lead the workshop. With now dozens of workshops worldwide, for WordPress and other open source software projects as well, there is an increase in speaker diversity.

WordCamp US 2019

As a result of the success, Jill is now sponsored to continue the program. The first sponsor is Automattic. She's proud of how the diversity represented on the stage adds value not only to the brand but also in the long-term will lead to the creation of a better product. She's inspired by seeing the communities change as a result of the new voices and new ideas at the WordPress events.

Jill's leadership in the development and growth of the Diversity Outreach Speaker Training initiative has had a positive, measurable impact on WordPress community events worldwide. When WordPress events are more diverse, the WordPress project gets more diverse - which makes WordPress better for more people."

Andrea Middleton, Community organizer on the WordPress open source project

Resources:

• The Workshop: http://diversespeakers.info/
• More information: https://tiny.cc/wpdiversity
• How to build a diverse speaker roster
• Diversity Outreach Speaker Training Team

Contributors

Alison Rothwell (@wpfiddlybits), Yvette Sonneveld (@yvettesonneveld), Josepha Haden (@chanthaboune), Topher DeRosia (@topher1kenobe)

This post is based on an article originally published on HeroPress.com, a community initiative created by Topher DeRosia. HeroPress highlights people in the WordPress community who have overcome barriers and whose stories would otherwise go unheard.

Meet more WordPress community members over at HeroPress.com!

Correction: December 7, 2019
The original article mentioned the team Jill lead, but did not mention the team members who joined her. Those have been added. Apologies to Vanessa, Kate, and Mandi.

06 Dec 2019 11:27pm GMT

The team behind Zero BS CRM launched version 3.0 of their WordPress plugin today. This is the first major release since the plugin was acquired by Automattic in August. The updated plugin uses custom database tables, opens the plugin for more extensions, and has a more consistent UI than previous versions.

CRM is an acronym for "customer relationship management." CRM systems allow businesses to manage their customer relationships through an interface. How CRM systems work can vary greatly, depending on the software used. In general, the goal is to help manage contacts, sales, and productivity.

Zero BS CRM was co-created by Mike Stott and Woody Hayday. Despite a low number of plugin users (around 1,000 at acquisition), Automattic acquired the plugin based on the strength of the product. Currently, Stott and Hayday are the primary developers on the plugin and maintain more than 30 commercial extensions for it.

Many CRM solutions are SaaS products, such as Salesforce CRM and HubSpot CRM. "The main benefit of ZBS CRM over online SaaS type solutions is it sits in your WP admin dashboard, and you own your own data," said Stott.

Version 3.0 of the plugin improves in several key areas. One major change is the switch to custom database tables rather than pigeon-holing everything into a custom post type. This change should speed up accessing data such as contacts and transactions in large databases.

Users should benefit from a much improved and consistent UI from previous versions. Zero BS CRM does not strictly follow the core WordPress admin UI. "When looking at ZBS CRM and how to tie in all our menu items into the WordPress UI - it wasn't easy," said Stott. "We settled on using a UI framework with our own top menu, and a natural follow-on for that was to draw our list views using that same UI and button systems. Whether we move this back or not depends on feedback from our users - we get a lot of positive feedback on how easy it is to navigate around and wouldn't want to change something that's been getting good feedback."

Contact management screen in the Zero BS CRM plugin.

Moving to custom tables over custom post types has also helped improve elements of the UI. Stott said a huge advantage is not having third-party plugins accidentally adding themselves to the plugin's admin pages, such as having unnecessary SEO options on contact records.

Another big change in 3.0 was building out a more extendable foundation for the plugin. This will open up custom CRM objects in the future. For example, plugin users could manage resources such as "properties" or "campuses" along with customer contact data. This update creates more potential for industry-specific extensions.

"It really opens the door for more extendibility in the future," said Stott, "and through an improved API in 2020 will allow for us to do more work across platforms and open up our CRM tools to more people."

The Zero BS CRM plugin remains free and is available in the WordPress plugin repository. The primary source of income comes from its extension bundles, which are priced monthly and billed yearly. The website currently offers freelancer ($11/month), entrepreneur ($17/month), and elite ($30/month) pricing options. It also has a reseller plan available.

The Move to Automattic

When the plugin was first acquired, there was an initial idea to rebrand as "Jetpack CRM." However, they have maintained the Zero BS CRM branding with an acronym instead of the direct expletive for "BS." A rebrand may still be on the table in 2020 or beyond.

"We've been gathering user feedback and sentiment following the minor changes to ZBS CRM and the initial reactions if we were to rename as Jetpack CRM," said Stott. "Since the shorter name, there's been less objection or negative feelings, which puts less pressure on a big rebrand project, but it's certainly something we'll be coming back to."

Stott said the primary focus since the acquisition has been less on branding and more on delivering 3.0 to the existing customer base.

The acquisition by Automattic has helped with how their two-person team works. "The main thing is being able to lean on the amazing team and people throughout Automattic," said Stott. "In the past, we'd only have Woody and my input, now we can reach out to experts in design, marketing, plus much more, and bounce our ideas around a vast pool of experience."

He explained that the additional support resources of Automattic's Happiness Engineers means that he and his partner can focus more on engineering and growing the product and team.

The acquisition of Zero BS CRM came during a busy year for Automattic. With major moves such as acquiring Tumblr and the Salesforce investment, this small plugin has mostly flown under the radar in comparison. Stott and Hayday have big plans for 2020. They would like to grow the engineering team and explore bringing their tools to more WordPress.com users.

The plugin's growth has remained stable since the acquisition, according to Stott. "The announcement brought us some additional customers who saw the backing from Automattic as strong advocacy for the plugin over other solutions in the WordPress space, so they made the decision to join us," he said. The plugin has doubled its active install count and now serves over 2,000 users. The team expects to continue growing in the coming months.

06 Dec 2019 8:43pm GMT

As we quickly head into the final weeks of 2019, we also pass the first anniversary of WordPress 5.0 and, subsequently, Gutenberg coming headlong into our lives.

Love it or hate it, Gutenberg is here to stay. If you had asked my thoughts on it last December, I would have probably sided with a large portion of other WordPress users.

What are you doing?

WordPress is fine, leave it alone!

Stop forcing me to use this!

Here we are, twelve months later, and you know what? I LOVE IT. And, I am not alone.

When it comes to writing content, I cannot imagine using the Classic Editor anymore. Sure, for a few paragraphs, the Classic Editor is fine. However, when you need to make a 4,000+ word post, Gutenberg and the new block system make things a lot easier.

Yes, the UI is a struggle for someone brand new to WordPress. We have all heard the "Wait, I thought you said this was like Word?" line. A good onboarding process would tackle that going forward. For the rest of us, if you have not adopted Gutenberg yet, you should take another look at it.

The Need for a New Editor

Let's be honest. The Classic Editor was great for short posts, a couple of headlines and paragraphs, job done. But, how often were you going into the Text tab to remove an extra line break, fix a shortcode, or cut and paste a section to somewhere else in the post? At best, it was a struggle. Often, it was excruciating to get your post just right before publishing.

Not only will I not miss this, but I am pleased that new users will not be exposed to it anymore either.

Classic Editor - Text tab in action

When I first heard of Gutenberg - before it was released in WordPress 5.0 - I installed the plugin and was immediately confused and slightly bewildered at the options. I wondered how I would edit in the future.

I, among many others, probably gave out the same noises as when Facebook and Twitter reveal a huge overhaul of their UI, agreeing with everyone that things would never be the same again. This was a mistake. Of course, I was both right and wrong at the same time. I just didn't know it. Editing would not be the same again. Instead, it would be a lot better (with some adjustment).

I also know that many people will not agree with me and do not like the way Gutenberg looks or behaves to this day. But, if you give it some time and understand how it can make your life easier, it will do just that.

First, take the time to work out the difference between Blocks and Document. On the left you have all the blocks for your post or page, inserting them in merrily as you go. On the right, the Document panel controls everything else, handily changing when you need to fine-tune a block.

Gutenberg block editor in action

One of the most common complaints I have read is people struggling with the toolbar that appears as you hover over each block. There is a simple solution to this, and when it is enabled, the majority of people suddenly start to love it! Make sure you set the view to "Top Toolbar" in the Gutenberg options. Now you have a distraction and clutter-free editing environment to work with.

Gutenberg vs. Page Builders

Gutenberg is not a page builder, and it is a common argument thrown out by people on why they refuse to use it. They are right, it is not a replacement for the likes of Elementor or Beaver Builder. If you remove the comparison to page builders from your mind, you will find adapting to it is much easier.

My peers and I regularly chat about Gutenberg and agree it is already great for writing. The post creation process is a breath of fresh air. Others have great stories from their clients about being able to produce content and edit it with ease, and the number of editor-related support requests is down, which can only be a good thing.

However, many of us would not use it for designing pages. Instead, we still prefer to use one of the many page builders for that complete control.

Gutenberg Phase 2 will allow editing of the site to areas outside of the main content (e.g., headers, footers, sidebars) and will creep further into the page builder category, which means we will have a strange blend of Gutenberg and page builders living side by side on many sites soon.

Will it remove the complete need for themes? Who knows? I suspect we will have people further divided into opposing camps going forward, but what a great opportunity for us to collectively work on for a better overall experience in the end.

By the Numbers

Let us take a quick look at Gutenberg and its penetration to date.

Currently, 63.8% of all WordPress installs are running 5.x onward according to WordPress.org, which means Gutenberg is available natively on nearly two-thirds of all WordPress installs.

But, it is not all red roses when it comes to adoption.

The Classic Editor plugin has over 5 million active installs (and a rather biased 723 five-star reviews, such as "Keep this forever" and "Never going to give it up!"). It is also currently in the top five of the most popular plugins.

Is this the backlash against Gutenberg or incompatibility with older themes forcing users to use the Classic Editor for now? At a guess, a good majority is probably the latter combined with some diehards.

But, look at the graph below from the Classic Editor plugin page.

Growth is declining. That is not a movement of people who continue to install Classic Editor on new installs and refuse to adapt.

Classic Editor adoption will likely continue falling, and perhaps the original date of it being supported until 2022 isn't that far-fetched after all (note: they have said they will continue to support it longer if needed).

On the flip-side, the Gutenberg plugin has 200,000 active installs and a whopping two-thirds of reviews (2,003) are a paltry one star. However, many are merely unhelpful complaints (e.g., "This is junk" and "Destroy it"). They do not tell the true story to novices.

As you can see from the graph below for the Gutenberg plugin, active install growth is up and continues to climb. It is not at the same pace as the decline with the Classic Editor, but that is probably because it is bundled with WordPress now.

One thing people seem to forget is Gutenberg is a plugin in and of itself. It is updated frequently, whereas the majority of users only see changes to it when there is a WordPress core update.

If you can see past the fields of one-star reviews and install the plugin, you will be rewarded with more frequent updates to the experience.

For example, version 7.0 recently added in the Navigation block as stable, allowing users to quickly create a menu of links. Don't get me wrong; this does require theme integration for it to work, but you can get a better idea of where it is heading on a more frequent basis this way (7.0 is expected to ship with WordPress 5.4 in March/April 2020).

Block Party

Compatibility with Gutenberg continues at a quick pace. With over 21 pages of block-enabled plugins available on WordPress.org, pretty much all the popular plugins have solutions in place. A fair amount of plugin updates these days are also adding new and enhanced blocks as standard.

If those are not enough for you, we also now have a new breed of block-specific plugins. There is a growing trend of plugins devoted to purely enhancing the style and number of blocks you can add to your site.

Popular Gutenberg-focused plugins such as Stackable and EditorsKit add further styling and editing abilities, bringing you another step closer to full-page design and enhancing your content.

EditorsKit - a purely Gutenberg plugin.

Because no one knows how far Gutenberg will go and which toes it will step on, block plugins may have a fight on their hands in the future. At the pace they are being released and updated, it is a good sign of a committed global collective who not only believe in the future of blocks but is excited about it too.

What Does the Future Hold?

Gutenberg is here to stay, and I don't think any of us have ever denied that. It is probably not an issue for anyone who started using WordPress for the first time this year.

Thankfully, for those already deeply embedded in WordPress, things are getting easier (and I would say more enjoyable) with the growth of the new Gutenberg-specific plugins.

With the advent of platforms such as Wix and Squarespace, it was obvious that WordPress needed something to make it more user-friendly and Gutenberg is a solid attempt at that. It is still a bit rough around the edges, but the days we look back nostalgically at the Classic Editor are likely numbered.

How will it look at the end of 2020? Will you still be using the Classic Editor?

05 Dec 2019 5:49pm GMT

In a pull request on the Gutenberg repository yesterday, Riad Benguella created an initial document that outlines how block-based WordPress themes might work. While the document is merely a starting point for the conversation, it is a set of ideas that will likely forever reshape the WordPress landscape. It is paradigm-shifting.

For the first time, theme authors can glimpse what their future holds. Since the inception of Gutenberg, many have asked for more technical details. Particularly, they wanted to know whether themes would be reduced to a stylesheet or a stylesheet and a few PHP files. What would themes look like architecturally? Would themes exist at all?

The document, while open for changes, makes a strong case about the structure of themes going forward. It is clear that much forethought has gone into the proposal. It matches the direction of the experimental site-editing feature in Gutenberg that has already been set in motion. Even though it is subject to change, there seems to be a finality to the overarching idea. The writing has long been on the wall. Now everyone can see the wall. The missing piece is figuring out how to bring the idea to fruition.

What is Full Site Editing?

Before understanding how themes of the future might work, you must first understand the direction that Gutenberg is headed. The end goal for Gutenberg, and eventually WordPress, is for users to have the ability to customize every aspect of their site via the block system. Currently, the block system primarily handles editing post content.

To move to full-site editing, every piece of dynamic data about a site must be a block. For example, a site title block must exist as a placeholder for the site title. Users should be able to place it anywhere they desire to output the title, such as in the header.

This has left theme authors with a reasonable question: If users can move these blocks anywhere, where do themes fit into the picture?

It is easy to see how themes would become little more than a stylesheet that styles every WordPress block while also handling other necessary styles like typography and vertical rhythm. Even then, it makes one wonder if themes, at least in how we have come to know them, are necessary at all.

The Proposed Theme Structure

The proposed structure does not look much different from current WordPress themes. The big difference is that theme templates would become "block templates" and "block template parts." These templates would be HTML files rather than PHP files.

The following is where the structure currently stands.

theme
|__ style.css
|__ functions.php
|__ block-templates
    |__ index.html
    |__ single.html
    |__ archive.html
    |__ ...
|__ block-template-parts
    |__ header.html
    |__ footer.html
    |__ sidebar.html
    |__ ...

From a templating perspective, it appears relatively normal for a WordPress theme. The files simply have a different type and are organized in specific folders.

However, the difference is how the HTML templates would work. They would essentially become placeholders for blocks. Users would also have the ability to edit or completely overwrite individual templates via the WordPress admin. Because templates are made up of blocks, no code would be necessary on the user's part. They could simply point and click to insert or remove blocks with their mouse.

In other words, block templates within themes would be unique starting points for users to build their sites.

There are two noteworthy items about the proposed system: themes are still themes and end-users can become theme builders.

The Essence of a Theme Remains the Same

When you cut through everything else, WordPress themes have always been HTML and CSS. The PHP aspect of theming basically mixes PHP function calls (i.e., template tags) within some structured HTML markup. If you look at most themes going through the official WordPress theme directory, you will find that the underlying markup is mostly the same.

In the block template system, this idea doesn't change. If anything, it could simplify the role of theme author by creating a set of standard elements (blocks) that themes output. If done right, it also creates a standard for class names so that styles can easily be shared across themes and all sorts of similar goodies.

Anyone Can Build a Theme

The initial outline explains the potential of exporting themes:

Ultimately, any WordPress user with the correct capabilities (example: administrator WordPress role) will be able to access these templates in the WordPress admin, edit them in dedicated views and potentially export the templates as a theme.

This is where the proposed system could revolutionize website building. Those without the coding skills to create a WordPress theme today could have the tools to contribute something back tomorrow.

The idea aligns perfectly with the open-source ethos of WordPress. By giving everyone the ability to export their customizations, it provides an avenue for contributing that we have never had before for non-coders. A free directory of customized themes created by and for the community, anyone?

The Design Side of the Equation

Block templates are merely the HTML. Themes will need to stand apart with their CSS. However, there must be standardization to pull this off.

Designers will need to shift to a block-based approach when it comes to design. Some may already be familiar with various "component-based" systems, which would work much the same way. Rather than designing from the top-down, theme authors would approach design on a more atomic level by designing each block.

There are also many unanswered questions about how styles will eventually work. Currently, there is an open ticket for discussing a style system for blocks. Much of the discussion is around how to integrate a design system with themes.

Join the Discussion

It is important to point out that nothing about this proposal is set in stone. It is a high-level outline of what the future of themes could hold. However, now is time for input from the community, especially theme authors who may have felt a bit out of the loop in the past. Now is the time to make your voice heard and to contribute ideas to the discussion.

The WordPress theme review team also has an open discussion on the future of themes that goes along with this proposal and whether themes should start taking advantage of experimental Gutenberg features.

04 Dec 2019 8:56pm GMT

Screenshot of the Yoast Black Friday Ad

On November 28, millions of people awoke to a Black Friday ad on nearly every page of their WordPress admin, courtesy of the Yoast SEO plugin. That day also coincided with the U.S. Thanksgiving holiday, so it left freelancers and agencies scrambling to address a banner on their clients' sites on a day they likely planned to spend with family. The ad was not limited to users with administrative permissions either, so some site owners were troubled to find users with low-level permissions could see the ad in the WordPress admin.

The initial code for the banner was added on October 25, which made its way into version 12.4 of the Yoast SEO plugin. The code for the banner ad limited its output between November 28 and December 3 (Cyber Monday).

After blowback from users, the Yoast team published an updated version of the plugin without the banner. However, the initial damage was done. Users began immediately leaving poor reviews for the plugin. The 1-star reviews are still coming in, putting the number over 100 in the span of five days.

"That BlackFridayBanner was not the best idea," wrote Marieke van de Rakt, CEO of Yoast, on Twitter. "We're truly sorry for the annoyance and difficulties it may have caused. We did not think this through properly. If you want, you can update to a new version of our plugin without that banner."

The initial decision to place the ad was about growth for Yoast's premium products. The company has not grown as fast as expected over the past year explained van de Rakt. They had also seen other plugins use those types of ads, which was a part of the decision to run it.

"Let's be clear," said van de Rakt. "This was a mistake. We just didn't think this one through. It was incredibly stupid. So I can talk about why we made a decision, but I don't want that to be the explanation. The explanation is that we made a mistake."

The ad was an animated banner, and some users complained that it was difficult to dismiss. All notices in plugins available through the WordPress plugin directory must be dismissible. "That was a technical mistake," said van de Rakt of the issues with clicking the "x" icon for dismissal.

While the team had seen other plugins run similar ads in the past, van de Rakt explained that they didn't take into account how large of a user base Yoast SEO has in comparison to those plugins. "For so many users, we were the first plugin that done this," she said. "They never saw this before in their backend. And they freak out. This was a complete error of judgment."

Yoast plans to talk more with its plugin's users. Currently, the team is looking into creating a user-testing panel to prevent similar situations in the future.

"In hindsight, and that's what I feel most bad about, the banner did not fit our values," said van de Rakt. "These kinds of banners are not 'Yoast.' Perhaps, if we state more explicitly what we as Yoast find important and what fits Yoast and what doesn't, a mistake like this will be made less quickly."

Making Money with Freemium Products

Yoast is a large company within the WordPress space. It employs 90 people in its primary office in Wijchen, the Netherlands. It also has an additional 20 employees around the world. Running a successful business means paying everyone, contributing back to WordPress with its five-for-the-future work, and running charitable programs such as the Yoast Diversity Fund.

Currently, the Yoast SEO plugin has over 5 million active installs. According to van de Rakt, only around 2% of the plugin's users also use the company's premium products. Such a large plugin needs continuous funding to support and maintain.

Advertising a product or service in an internet culture that is seemingly averse to ads is not always easy. "It's rather hard to find ways to reach our audience, and we also have some principles on how (not) to do that," said van de Rakt. "We like to advertise in a straight-forward way. Tell people what they're buying. Ads are very annoying, but at least they are clear in what they're doing."

One issue that plugin companies run into is the lack of an official premium marketplace for WordPress. Currently, companies have to resort to in-admin advertising or similar tactics to push users on an upsell. Most of Yoast's premium products are sold through banners on the plugin's pages in the WordPress admin. Such practices do not always go over well with users, particularly when they are using a free product. One wrong step and it could spell disaster for future growth. Yoast is large enough to bounce back, but smaller companies may struggle more.

It is a tough balancing act between providing a valuable free product and making enough of a return to run a successful company. The Yoast team does not want to lock their popular SEO plugin completely behind a paywall. "Our mission is SEO for everyone," said van de Rakt. "We believe that every idea should have a fair chance in the search results. That means that also without any funds, people should be able to have a good working SEO plugin. Our free plugin is really important to us."

"I had a really bad weekend," said van de Rakt. "I am a people pleaser and I was terribly sad by what happened. But, the discussion about how to handle this is a good one."

Perhaps some good will come of this incident if there is an open dialogue. "These kinds of things sometimes lead to different 'rule-sets' or policies within WordPress," said van de Rakt. "Might even mean that there will be different and better ways for premium plugins to market their products."

03 Dec 2019 8:53pm GMT

Yesterday morning we've deployed the first stable version of the BP Beta Tester plugin on the WordPress.org plugins directory.​​

This plugin's goal is to make it easier to beta test our pre-releases. You just need to install and activate the plugin to be ready to try our beta and release candidate versions once we've announced them on this blog.​​
​
Beta testing BuddyPress is very important to make sure it behaves the right way for you and for the community. Although we, the BuddyPress Development Team, are regularly testing it, it's very challenging to test every possible configuration of WordPress and BuddyPress. That's why we absolutely need your help during these pre-release stages.​​

Making this plugin available was one of the means we thought about during our post 5.0.0 release development meeting to have more BuddyPress contributors.​​
​
Beta testing is actually a good way to start contributing, to anticipate and fix potential issues before you have the bad surprise to meet them once you're upgrading to a new stable version of the plugin.​​

NB: to beta test BuddyPress, we strongly advise you to have a local copy of your live site or a staging site : it's always safer than doing it on a production site.​​

During our next pre-release stages, when you will find something is going wrong during your beta tests, please think of warning us about it submitting a ticket on our Development Tracker or posting a new topic in our support forums.​​

Thanks in advance for your time and help <3

03 Dec 2019 12:27pm GMT

On November 27, Gutenberg 7.0 landed with several features, enhancements, and bug fixes. Most notably, the navigation block is now a stable feature. Theme authors can also start using block template parts and testing the post title and content blocks.

The update addressed several bugs with the block editor. It also introduced new developer features such as the card component and the ability to internationalize strings with safe HTML.

Gradient classes are now used for the cover block. Classes are a nicer solution than the inline styles used in earlier iterations. Note that gradients are still an experimental feature.

For developers, there is a new backward-compatibility document that outlines how the project preserves compatibility in its public APIs. This should be useful for all developers working on the project in the future.

Navigation Block Now Stable

Creating a nav menu with the navigation block.

The navigation block is now a stable feature and no longer considered experimental. The interface is much improved over earlier implementations. For quickly building a menu of links, it does the job. Users can manually type a link or search for an existing link for the site.

A user interface for nav menus in the block editor is no easy beast to tame. The Gutenberg team managed to fit in the most common features without making it feel confusing. For users, theme integration may be limited until their themes are updated with full support. The default Gutenberg design may not be ideal or work at all in the context of the active theme.

The navigation block also comes with both light and dark block styles. Theme authors can design these how they prefer, add additional styles, or remove the styles altogether. More than likely, theme authors will begin adding several variations to their themes as a selling point in the long run.

The Gutenberg team dropped the background color option from the navigation block. Instead, users are encouraged to place it within a group block and add a background to the group. It is possible to change the link text color directly within the navigation block.

Currently, there is no parity between normal nav menu HTML classes and navigation block classes. This could result in bulkier theme CSS, at least in the transition between how themes currently work and the full site-editing era. Inconsistent classes is an issue that should be handled with a design framework.

Post Title and Content Blocks Added

Customized post title block output.

As part of the experimental site-editing feature, Gutenberg has introduced the post title and post content blocks. These blocks act as placeholders and will output either the title or content. Both blocks are foundational elements for true full-site editing. Eventually, users will no longer be as limited to how their posts are output on the screen.

Currently, the post title block simply outputs the post title inside of <h1> tags. There are no classes for customizing the design. The other missing element at this point is the post byline or meta area that often accompanies the title. In the long run, Gutenberg needs to have a method of handling post header and footer areas.

The custom post header feature has plagued theme authors for years, long before Gutenberg was around. There are dozens or more implementations in the wild. Some of them work with the block editor. Others use custom post meta or the featured image. However, users are often left with sub-par implementations that don't always work in the context of a specific post.

One of the features I have wanted to implement within Gutenberg is the "hero" image with text set over the top. By using the built-in cover block and the post title block, I was able to accomplish this. However, it was still missing the post byline. Therefore, I put together a quick filter to output the post byline when the post title block is in use.

Any theme author who wants to test it out can modify the following code. I would not recommend this in production since this is an experimental feature, but it is good to start thinking ahead about possibilities.

add_filter( 'pre_render_block', function( $block_content, $block ) {

    if ( 'core/post-title' === $block['blockName'] ) {

        $post = gutenberg_get_post_from_context();

        if ( ! $post ) {
            return $block_content;
        }

        if ( 'post' === $post->post_type ) {

            $block_content = '<h1 class="entry__title">' . get_the_title( $post ) . '</h1>';

            $block_content .= sprintf(
                '<div class="entry__byline">%s &middot; %s &middot; %s</div>',
                get_the_author(),
                get_the_date(),
                get_the_term_list( $post->ID, 'category' )
            );
        }
      }

    return $block_content;

}, 10, 2 );

Block Template Parts for Themes

Gutenberg 6.9 introduced block templates that resolve from a theme's /block-templates folder as part of the site-building experiment. Version 7.0 takes that a step farther and introduces a block template parts system, which resolves from a theme's /block-template-parts directory.

This new system allows top-level templates to house smaller, reusable template parts. This is a rather standard method of template-part handling that has become a part of the normal theme-building experience.

It will be interesting to see how this works in the long run. WordPress' current template part system for theme authors (i.e., get_template_part()) is a bare-bones implementation with little flexibility for handling features like hierarchy and passing data. Thus far, the new feature seems to be a melding of blocks and old templating ideas, but it is too early in the process to see where it goes or whether theme authors will have to make customizations to bend the system to their will.

02 Dec 2019 7:22pm GMT