Wordpress News

WPTavern: FOSS Responders Group Brings Financial Help to Open Source Ecosystem Affected by COVID-19

Wordpress Planet - Fri, 05/01/2020 - 23:04

The pandemic has caused economic hardships and upheaval in nearly every industry. Open source communities and contributors have been affected in a myriad of ways – whether it’s a loss of donations, the burden of nonrefundable travel expenses for canceled conferences, or severely diminished business and fundraising opportunities.

FOSS Responders is a working group of volunteers that aims to future-proof the open source infrastructure we rely on by helping sustain those who maintain the software. The group’s website allows those in need to apply for emergency funds. FOSS Responders is raising money on Open Collective and 100% of donations go to open source technologists in need. So far the group has an estimated annual budget of $8,145.05. Open Collective is also waiving its platform fees on COVID-19 solidarity collectives until the end of June.

On May 22, FOSS Responders plans to host a virtual funding event to provide financial support for organizations affected by the profound economic disruptions caused by the pandemic. Organizers have a $5,000 goal for ticket revenue from general event ticket sales.

In addition to providing emergency funds, the FOSS Responders group is aiming to address non-financial needs. Open source projects that relied heavily on events for fundraising need help amplifying their projects and recruiting volunteers. FOSS Responders is also creating a Resource Center for projects to find tips and tricks on how to manage fully virtual community interactions and events. Anyone with a skill or service to volunteer can get in touch on the FOSS Responders website and the team will work as matchmakers to connect experts with projects that need help.

WPTavern: FOSS Responders Group Brings Financial Help to Open Source Ecosystem Affected by COVID-19

Wordpress Planet - Fri, 05/01/2020 - 23:04

The pandemic has caused economic hardships and upheaval in nearly every industry. Open source communities and contributors have been affected in a myriad of ways – whether it’s a loss of donations, the burden of nonrefundable travel expenses for canceled conferences, or severely diminished business and fundraising opportunities.

FOSS Responders is a working group of volunteers that aims to future-proof the open source infrastructure we rely on by helping sustain those who maintain the software. The group’s website allows those in need to apply for emergency funds. FOSS Responders is raising money on Open Collective and 100% of donations go to open source technologists in need. So far the group has an estimated annual budget of $8,145.05. Open Collective is also waiving its platform fees on COVID-19 solidarity collectives until the end of June.

On May 22, FOSS Responders plans to host a virtual funding event to provide financial support for organizations affected by the profound economic disruptions caused by the pandemic. Organizers have a $5,000 goal for ticket revenue from general event ticket sales.

In addition to providing emergency funds, the FOSS Responders group is aiming to address non-financial needs. Open source projects that relied heavily on events for fundraising need help amplifying their projects and recruiting volunteers. FOSS Responders is also creating a Resource Center for projects to find tips and tricks on how to manage fully virtual community interactions and events. Anyone with a skill or service to volunteer can get in touch on the FOSS Responders website and the team will work as matchmakers to connect experts with projects that need help.

WPTavern: Block Lab Team Joins WP Engine, Looks to the Future of Block Building

Wordpress Planet - Fri, 05/01/2020 - 17:16

The three-person Block Lab team of Luke Carbis, Ryan Kienstra, and Rob Stinson is joining WP Engine to work on the company’s block editor projects. WP Engine approached the team members after seeing how successful the Block Lab project had grown and made them an offer. The team will be able to continue building projects with solid financial backing.

Block Lab is a plugin that was created to allow other developers to build blocks without needing to wade through the depths of complex JavaScript programming. It is a way to get your feet wet in the block development pool without diving in head first. The plugin has built a solid reputation based on user reviews. Out of 39 submissions, it has received 38 five-star ratings.

“From the start, Block Lab has been our answer to the question of ‘how can I lower the barrier to entry for creating custom blocks,'” said Stinson. He said the plugin has done two important things for developers. It has given them an easy-to-use admin interface to work from and a simplified templating experience that is aligned with traditional workflows. “It’s helped folk who haven’t had the time to summit the JS-all-the-things mountain or simply provide those that are looking for a standardized system that does a lot of the heavy lifting for them.”

The Block Lab plugin is being phased out, but the team assures that the plugin’s current users will not be left in the dust. The plan is to continue supporting the plugin through bug and compatibility fixes for the next year. Pro users will also receive the same support until their license expires. In the long term outlook, the team plans to build a migration path to the new tools they will be building under the WP Engine banner.

Stinson said that the plugin should work well for a long time to come because it was built by Carbis and Kienstra, two of the best engineers he has worked with. However, he stresses that the work they will be doing with WP Engine will exceed anything they have done with Block Lab.

“We’ll be working on technology there that is focused on the Block Editor though, and a part of that will be taking what we’ve done with Block Lab and introducing the feature set to the WP Engine suite of products,” he said. “The alignment will be close and will offer existing Block Lab users an easy migration experience.”

While the Block Lab plugin will see an end, the features the team has worked on will live on in some form.

A New Beginning

Before taking on roles with WP Engine, each member of the Block Lab team was paying the bills through agency and freelance work. Block Lab was merely a side project they were handling in their free time, but it was slowly growing both in scale and financially.

“Getting to a place where we could give it full-time focus was easily two to three years away though,” said Stinson, “and we have always been incredibly conscious of the things we wanted to be doing with it and how much the time factor was a limitation. With WP Engine, we’re equipped to take the product vision we had for Block Lab and basically strap a rocket to it. Not only are we able to devote our full attention, but we also have the incredible support and resources of WP Engine behind us.”

Stinson is looking forward to the transition within the state of the current WordPress ecosystem. The team can walk into a fresh beginning with the full weight of a major company behind them. “Between the classic way of building with WordPress and this new block-first frontier, being set up right now to build and contribute is incredible!” he said.

The team had an existing roadmap and backlog of features they wanted to develop. However, with Block Lab being only a side project, it meant those features would have taken much longer to build. They can now pursue them full time.

“We saw what Block Lab has currently as a necessary baseline for a plugin that equipped folks to create custom blocks, but what we have planned and are dreaming about goes so much further,” said Stinson. “Joining WP Engine unleashes us to chase down that work faster and with more focus. Another really exciting piece of this is that with our focus we are better positioned to offer insights and contribution to the larger block editor project through core and community contributions.”

The team now has the opportunity to be a pioneer in the years to come. They have proved they can build a useful tool on top of the block editor. The next step is seeing where they take it and whether they can get more developers to join them into a world of building blocks.

“The shift in thinking around how a website is structured towards one that is powered by ‘blocks’ is a journey that the majority of the WP community is still on,” said Stinson. “A big part of my vision is having a larger portion of the community up to speed and onboard with this. With more people operating within that zone, more great work and tooling will be produced. By lowering the barrier to entry through Block Lab and what we have planned at WP Engine, it will help to get more people in that zone.”

WPTavern: Block Lab Team Joins WP Engine, Looks to the Future of Block Building

Wordpress Planet - Fri, 05/01/2020 - 17:16

The three-person Block Lab team of Luke Carbis, Ryan Kienstra, and Rob Stinson is joining WP Engine to work on the company’s block editor projects. WP Engine approached the team members after seeing how successful the Block Lab project had grown and made them an offer. The team will be able to continue building projects with solid financial backing.

Block Lab is a plugin that was created to allow other developers to build blocks without needing to wade through the depths of complex JavaScript programming. It is a way to get your feet wet in the block development pool without diving in head first. The plugin has built a solid reputation based on user reviews. Out of 39 submissions, it has received 38 five-star ratings.

“From the start, Block Lab has been our answer to the question of ‘how can I lower the barrier to entry for creating custom blocks,'” said Stinson. He said the plugin has done two important things for developers. It has given them an easy-to-use admin interface to work from and a simplified templating experience that is aligned with traditional workflows. “It’s helped folk who haven’t had the time to summit the JS-all-the-things mountain or simply provide those that are looking for a standardized system that does a lot of the heavy lifting for them.”

The Block Lab plugin is being phased out, but the team assures that the plugin’s current users will not be left in the dust. The plan is to continue supporting the plugin through bug and compatibility fixes for the next year. Pro users will also receive the same support until their license expires. In the long term outlook, the team plans to build a migration path to the new tools they will be building under the WP Engine banner.

Stinson said that the plugin should work well for a long time to come because it was built by Carbis and Kienstra, two of the best engineers he has worked with. However, he stresses that the work they will be doing with WP Engine will exceed anything they have done with Block Lab.

“We’ll be working on technology there that is focused on the Block Editor though, and a part of that will be taking what we’ve done with Block Lab and introducing the feature set to the WP Engine suite of products,” he said. “The alignment will be close and will offer existing Block Lab users an easy migration experience.”

While the Block Lab plugin will see an end, the features the team has worked on will live on in some form.

A New Beginning

Before taking on roles with WP Engine, each member of the Block Lab team was paying the bills through agency and freelance work. Block Lab was merely a side project they were handling in their free time, but it was slowly growing both in scale and financially.

“Getting to a place where we could give it full-time focus was easily two to three years away though,” said Stinson, “and we have always been incredibly conscious of the things we wanted to be doing with it and how much the time factor was a limitation. With WP Engine, we’re equipped to take the product vision we had for Block Lab and basically strap a rocket to it. Not only are we able to devote our full attention, but we also have the incredible support and resources of WP Engine behind us.”

Stinson is looking forward to the transition within the state of the current WordPress ecosystem. The team can walk into a fresh beginning with the full weight of a major company behind them. “Between the classic way of building with WordPress and this new block-first frontier, being set up right now to build and contribute is incredible!” he said.

The team had an existing roadmap and backlog of features they wanted to develop. However, with Block Lab being only a side project, it meant those features would have taken much longer to build. They can now pursue them full time.

“We saw what Block Lab has currently as a necessary baseline for a plugin that equipped folks to create custom blocks, but what we have planned and are dreaming about goes so much further,” said Stinson. “Joining WP Engine unleashes us to chase down that work faster and with more focus. Another really exciting piece of this is that with our focus we are better positioned to offer insights and contribution to the larger block editor project through core and community contributions.”

The team now has the opportunity to be a pioneer in the years to come. They have proved they can build a useful tool on top of the block editor. The next step is seeing where they take it and whether they can get more developers to join them into a world of building blocks.

“The shift in thinking around how a website is structured towards one that is powered by ‘blocks’ is a journey that the majority of the WP community is still on,” said Stinson. “A big part of my vision is having a larger portion of the community up to speed and onboard with this. With more people operating within that zone, more great work and tooling will be produced. By lowering the barrier to entry through Block Lab and what we have planned at WP Engine, it will help to get more people in that zone.”

WPTavern: Block Lab Team Joins WP Engine, Looks to the Future of Block Building

Wordpress Planet - Fri, 05/01/2020 - 17:16

The three-person Block Lab team of Luke Carbis, Ryan Kienstra, and Rob Stinson is joining WP Engine to work on the company’s block editor projects. WP Engine approached the team members after seeing how successful the Block Lab project had grown and made them an offer. The team will be able to continue building projects with solid financial backing.

Block Lab is a plugin that was created to allow other developers to build blocks without needing to wade through the depths of complex JavaScript programming. It is a way to get your feet wet in the block development pool without diving in head first. The plugin has built a solid reputation based on user reviews. Out of 39 submissions, it has received 38 five-star ratings.

“From the start, Block Lab has been our answer to the question of ‘how can I lower the barrier to entry for creating custom blocks,'” said Stinson. He said the plugin has done two important things for developers. It has given them an easy-to-use admin interface to work from and a simplified templating experience that is aligned with traditional workflows. “It’s helped folk who haven’t had the time to summit the JS-all-the-things mountain or simply provide those that are looking for a standardized system that does a lot of the heavy lifting for them.”

The Block Lab plugin is being phased out, but the team assures that the plugin’s current users will not be left in the dust. The plan is to continue supporting the plugin through bug and compatibility fixes for the next year. Pro users will also receive the same support until their license expires. In the long term outlook, the team plans to build a migration path to the new tools they will be building under the WP Engine banner.

Stinson said that the plugin should work well for a long time to come because it was built by Carbis and Kienstra, two of the best engineers he has worked with. However, he stresses that the work they will be doing with WP Engine will exceed anything they have done with Block Lab.

“We’ll be working on technology there that is focused on the Block Editor though, and a part of that will be taking what we’ve done with Block Lab and introducing the feature set to the WP Engine suite of products,” he said. “The alignment will be close and will offer existing Block Lab users an easy migration experience.”

While the Block Lab plugin will see an end, the features the team has worked on will live on in some form.

A New Beginning

Before taking on roles with WP Engine, each member of the Block Lab team was paying the bills through agency and freelance work. Block Lab was merely a side project they were handling in their free time, but it was slowly growing both in scale and financially.

“Getting to a place where we could give it full-time focus was easily two to three years away though,” said Stinson, “and we have always been incredibly conscious of the things we wanted to be doing with it and how much the time factor was a limitation. With WP Engine, we’re equipped to take the product vision we had for Block Lab and basically strap a rocket to it. Not only are we able to devote our full attention, but we also have the incredible support and resources of WP Engine behind us.”

Stinson is looking forward to the transition within the state of the current WordPress ecosystem. The team can walk into a fresh beginning with the full weight of a major company behind them. “Between the classic way of building with WordPress and this new block-first frontier, being set up right now to build and contribute is incredible!” he said.

The team had an existing roadmap and backlog of features they wanted to develop. However, with Block Lab being only a side project, it meant those features would have taken much longer to build. They can now pursue them full time.

“We saw what Block Lab has currently as a necessary baseline for a plugin that equipped folks to create custom blocks, but what we have planned and are dreaming about goes so much further,” said Stinson. “Joining WP Engine unleashes us to chase down that work faster and with more focus. Another really exciting piece of this is that with our focus we are better positioned to offer insights and contribution to the larger block editor project through core and community contributions.”

The team now has the opportunity to be a pioneer in the years to come. They have proved they can build a useful tool on top of the block editor. The next step is seeing where they take it and whether they can get more developers to join them into a world of building blocks.

“The shift in thinking around how a website is structured towards one that is powered by ‘blocks’ is a journey that the majority of the WP community is still on,” said Stinson. “A big part of my vision is having a larger portion of the community up to speed and onboard with this. With more people operating within that zone, more great work and tooling will be produced. By lowering the barrier to entry through Block Lab and what we have planned at WP Engine, it will help to get more people in that zone.”

WPTavern: WordCamp US 2020 Goes Online, Cancels In-Person Event

Wordpress Planet - Thu, 04/30/2020 - 22:49

WordCamp US 2020 organizers have cancelled the in-person event in favor of hosting it as an online-only conference. With more than a million confirmed coronavirus cases in the U.S. today, 63,000+ deaths, and 31 states set to partially reopen this weekend, the pandemic’s trajectory throughout the country has become increasingly uncertain.

Many statewide stay-at-home orders are expiring tomorrow, despite no state having met the federal guidelines for reopening. Some businesses are opting to reopen in a limited capacity, but the general populace is still wary of returning to their previous way of life. In the state of Missouri, where WordCamp US was to be hosted in 2020, there will be no limitations on social gatherings as of May 4, as long as individuals maintain social distancing. It’s not yet possible to predict what will be happening in the area in October or how it might impact an event with international attendees.

After organizers extended the WCUS speaker application deadline for another 1.5 months on April 17, it seemed the general disinclination towards traveling and gathering in large groups had already taken hold. Booking hotels and travel arrangements five months in advance is still too much of a gamble for speakers and attendees.

The WCUS organizing team emphasized the longterm health and safety of the WordPress community as their primary concern in today’s announcement about moving to an online-only event:

The WCUS organizing team has been working with WordCamp Central and local health authorities to try to make sense of the current COVID-19 pandemic and what it means for our event in St. Louis this October. Throughout this, we have held the longterm health and safety of the WordPress community as the highest priority of our event. To move forward in a way that honors what is best for our community – both locally and globally – we have made the hard choice to convert WordCamp US 2020 to an online only event. 

WCUS will still happen on the originally scheduled dates, October 27th – 29th. Organizers plan to run sessions, workshops, and a virtual Contributor Day, along with the annual State of the Word address from Matt Mullenweg. They are also putting together a hallway track, some form of swag, and creative ways for attendees to connect, which will be announced at a later date.

WCUS is now free for anyone who wants to attend. Without the necessity to rent a venue, provide lunches, and other physical aspects of the event, sponsorships are easily able to cover the cost of streaming to an unlimited number of attendees.

The call for speakers is open until May 31, 2020 at 11:59 pm CDT. WCUS is still accepting sponsorships and will be publishing a set of unique sponsorship packages for the virtual event. Organizers plan to put out a call for volunteers in the near future.

WordCamp US follows other major regional WordCamps in Asia and Europe that have canceled in-person events due to the pandemic. Several other upcoming WordCamps, including events in Spain, Kent, Denver, and Minneapolis / Saint Paul, have also announced that they are transitioning to online-only events.

WPTavern: WordCamp US 2020 Goes Online, Cancels In-Person Event

Wordpress Planet - Thu, 04/30/2020 - 22:49

WordCamp US 2020 organizers have cancelled the in-person event in favor of hosting it as an online-only conference. With more than a million confirmed coronavirus cases in the U.S. today, 63,000+ deaths, and 31 states set to partially reopen this weekend, the pandemic’s trajectory throughout the country has become increasingly uncertain.

Many statewide stay-at-home orders are expiring tomorrow, despite no state having met the federal guidelines for reopening. Some businesses are opting to reopen in a limited capacity, but the general populace is still wary of returning to their previous way of life. In the state of Missouri, where WordCamp US was to be hosted in 2020, there will be no limitations on social gatherings as of May 4, as long as individuals maintain social distancing. It’s not yet possible to predict what will be happening in the area in October or how it might impact an event with international attendees.

After organizers extended the WCUS speaker application deadline for another 1.5 months on April 17, it seemed the general disinclination towards traveling and gathering in large groups had already taken hold. Booking hotels and travel arrangements five months in advance is still too much of a gamble for speakers and attendees.

The WCUS organizing team emphasized the longterm health and safety of the WordPress community as their primary concern in today’s announcement about moving to an online-only event:

The WCUS organizing team has been working with WordCamp Central and local health authorities to try to make sense of the current COVID-19 pandemic and what it means for our event in St. Louis this October. Throughout this, we have held the longterm health and safety of the WordPress community as the highest priority of our event. To move forward in a way that honors what is best for our community – both locally and globally – we have made the hard choice to convert WordCamp US 2020 to an online only event. 

WCUS will still happen on the originally scheduled dates, October 27th – 29th. Organizers plan to run sessions, workshops, and a virtual Contributor Day, along with the annual State of the Word address from Matt Mullenweg. They are also putting together a hallway track, some form of swag, and creative ways for attendees to connect, which will be announced at a later date.

WCUS is now free for anyone who wants to attend. Without the necessity to rent a venue, provide lunches, and other physical aspects of the event, sponsorships are easily able to cover the cost of streaming to an unlimited number of attendees.

The call for speakers is open until May 31, 2020 at 11:59 pm CDT. WCUS is still accepting sponsorships and will be publishing a set of unique sponsorship packages for the virtual event. Organizers plan to put out a call for volunteers in the near future.

WordCamp US follows other major regional WordCamps in Asia and Europe that have canceled in-person events due to the pandemic. Several other upcoming WordCamps, including events in Spain, Kent, Denver, and Minneapolis / Saint Paul, have also announced that they are transitioning to online-only events.

WPTavern: WordCamp US 2020 Goes Online, Cancels In-Person Event

Wordpress Planet - Thu, 04/30/2020 - 22:49

WordCamp US 2020 organizers have cancelled the in-person event in favor of hosting it as an online-only conference. With more than a million confirmed coronavirus cases in the U.S. today, 63,000+ deaths, and 31 states set to partially reopen this weekend, the pandemic’s trajectory throughout the country has become increasingly uncertain.

Many statewide stay-at-home orders are expiring tomorrow, despite no state having met the federal guidelines for reopening. Some businesses are opting to reopen in a limited capacity, but the general populace is still wary of returning to their previous way of life. In the state of Missouri, where WordCamp US was to be hosted in 2020, there will be no limitations on social gatherings as of May 4, as long as individuals maintain social distancing. It’s not yet possible to predict what will be happening in the area in October or how it might impact an event with international attendees.

After organizers extended the WCUS speaker application deadline for another 1.5 months on April 17, it seemed the general disinclination towards traveling and gathering in large groups had already taken hold. Booking hotels and travel arrangements five months in advance is still too much of a gamble for speakers and attendees.

The WCUS organizing team emphasized the longterm health and safety of the WordPress community as their primary concern in today’s announcement about moving to an online-only event:

The WCUS organizing team has been working with WordCamp Central and local health authorities to try to make sense of the current COVID-19 pandemic and what it means for our event in St. Louis this October. Throughout this, we have held the longterm health and safety of the WordPress community as the highest priority of our event. To move forward in a way that honors what is best for our community – both locally and globally – we have made the hard choice to convert WordCamp US 2020 to an online only event. 

WCUS will still happen on the originally scheduled dates, October 27th – 29th. Organizers plan to run sessions, workshops, and a virtual Contributor Day, along with the annual State of the Word address from Matt Mullenweg. They are also putting together a hallway track, some form of swag, and creative ways for attendees to connect, which will be announced at a later date.

WCUS is now free for anyone who wants to attend. Without the necessity to rent a venue, provide lunches, and other physical aspects of the event, sponsorships are easily able to cover the cost of streaming to an unlimited number of attendees.

The call for speakers is open until May 31, 2020 at 11:59 pm CDT. WCUS is still accepting sponsorships and will be publishing a set of unique sponsorship packages for the virtual event. Organizers plan to put out a call for volunteers in the near future.

WordCamp US follows other major regional WordCamps in Asia and Europe that have canceled in-person events due to the pandemic. Several other upcoming WordCamps, including events in Spain, Kent, Denver, and Minneapolis / Saint Paul, have also announced that they are transitioning to online-only events.

WPTavern: WordCamp US 2020 Goes Online, Cancels In-Person Event

Wordpress Planet - Thu, 04/30/2020 - 22:49

WordCamp US 2020 organizers have cancelled the in-person event in favor of hosting it as an online-only conference. With more than a million confirmed coronavirus cases in the U.S. today, 63,000+ deaths, and 31 states set to partially reopen this weekend, the pandemic’s trajectory throughout the country has become increasingly uncertain.

Many statewide stay-at-home orders are expiring tomorrow, despite no state having met the federal guidelines for reopening. Some businesses are opting to reopen in a limited capacity, but the general populace is still wary of returning to their previous way of life. In the state of Missouri, where WordCamp US was to be hosted in 2020, there will be no limitations on social gatherings as of May 4, as long as individuals maintain social distancing. It’s not yet possible to predict what will be happening in the area in October or how it might impact an event with international attendees.

After organizers extended the WCUS speaker application deadline for another 1.5 months on April 17, it seemed the general disinclination towards traveling and gathering in large groups had already taken hold. Booking hotels and travel arrangements five months in advance is still too much of a gamble for speakers and attendees.

The WCUS organizing team emphasized the longterm health and safety of the WordPress community as their primary concern in today’s announcement about moving to an online-only event:

The WCUS organizing team has been working with WordCamp Central and local health authorities to try to make sense of the current COVID-19 pandemic and what it means for our event in St. Louis this October. Throughout this, we have held the longterm health and safety of the WordPress community as the highest priority of our event. To move forward in a way that honors what is best for our community – both locally and globally – we have made the hard choice to convert WordCamp US 2020 to an online only event. 

WCUS will still happen on the originally scheduled dates, October 27th – 29th. Organizers plan to run sessions, workshops, and a virtual Contributor Day, along with the annual State of the Word address from Matt Mullenweg. They are also putting together a hallway track, some form of swag, and creative ways for attendees to connect, which will be announced at a later date.

WCUS is now free for anyone who wants to attend. Without the necessity to rent a venue, provide lunches, and other physical aspects of the event, sponsorships are easily able to cover the cost of streaming to an unlimited number of attendees.

The call for speakers is open until May 31, 2020 at 11:59 pm CDT. WCUS is still accepting sponsorships and will be publishing a set of unique sponsorship packages for the virtual event. Organizers plan to put out a call for volunteers in the near future.

WordCamp US follows other major regional WordCamps in Asia and Europe that have canceled in-person events due to the pandemic. Several other upcoming WordCamps, including events in Spain, Kent, Denver, and Minneapolis / Saint Paul, have also announced that they are transitioning to online-only events.

WPTavern: Gutenberg 8.0 Merges Block and Pattern Inserter, Adds Inline Formats, and Updates Code Editor

Wordpress Planet - Thu, 04/30/2020 - 19:48

The team behind the Gutenberg plugin shipped version 8.0 yesterday. The update adds some nice user-facing changes, including a merged block and pattern inserter, new inline formatting options, and visual changes to the code editor. Over two dozen bug fixes were included in the release, along with several enhancements.

Designers on the project updated the welcome box illustrations to match the current UI. Because the welcome modal should already be dismissed for current users, only new users should see these changes.

For theme authors, the post title and placeholder paragraph text for the block appender will inherit body font styles. Previously, they had specific styles attached to them in the editor. The current downside is that the post title is not an <h1> element so it cannot automatically inherit styles for that element. However, that will change once the post title becomes a true block in the editor.

The editor also now clears centered blocks following a floated block. This is an opinionated design change, but it should not negatively affect most themes. However, theme authors should double-check their theme styles to be sure.

Updated Block and Pattern Inserter Patterns available in the inserter.

The development team added patterns to the existing inserter. Now, both blocks and patterns have an individual tab within a unified interface. This is yet another step in the evolution of the pattern system that should land in core WordPress this year.

Right now, the experience is a two-steps-forward-one-step-back deal. The inserter’s behavior has improved and it is great to see patterns merged into it. However, all blocks and patterns are within long lists that require scrolling to dig through. Block categories are no longer tabbed in version 8.0, which is a regression from previous versions. I am certain this will be resolved soon enough, but it is a little frustrating locating a block in the list at the moment.

Merging patterns into the inserter is an ongoing process. There is still a lot of work to do before the final product is polished and included in core WordPress.

The following are some key items that need to be addressed in upcoming versions of Gutenberg:

  • Patterns should be categorized the same as blocks.
  • The block search box should switch to a pattern search box when viewing patterns.
  • Pattern titles should be reintroduced in the interface (removed in 8.0).

Of course, there is a host of other minor and major issues the team will need to cover to nail down the user experience. For now, the interface for patterns continues to improve.

Subscript and Superscript Formats Adding superscript text to the editor.

Gutenberg developers added two new inline formatting options to the editor toolbar: subscript and superscript. These options allow users to add text such as X2 and X2. They work the same as bold, italic, inline code, and other options.

The two formatting options represent their respective inline HTML tags, <sub> for subscript and <sup> for superscript. With the addition of the elements, the toolbar now covers most of the widely-used inline HTML tags. The only other tags that are low on my wish list are <abbr>, <del>, and <ins>, but I could live with those remaining firmly in plugin territory.

Improved Code Editor Updated code-editing view.

The code editor received a much-needed overhaul in the 8.0 update. Everything from the post title to the content is set in a monospace font, and the width of the code editing box spans the editing area. It should be a welcome change for those who need to switch to code view once in a while.

The next step to polishing the code editor (and the HTML block) would be to add syntax highlighting. In the current version, the HTML output is plain text. Given the extra markup that the block editor produces, it can be a bit of a jumbled mess to wade through. Basic syntax highlighting would improve the experience several times over. There is a GitHub ticket for adding the feature, but it has not seen any movement in several months.

WPTavern: Gutenberg 8.0 Merges Block and Pattern Inserter, Adds Inline Formats, and Updates Code Editor

Wordpress Planet - Thu, 04/30/2020 - 19:48

The team behind the Gutenberg plugin shipped version 8.0 yesterday. The update adds some nice user-facing changes, including a merged block and pattern inserter, new inline formatting options, and visual changes to the code editor. Over two dozen bug fixes were included in the release, along with several enhancements.

Designers on the project updated the welcome box illustrations to match the current UI. Because the welcome modal should already be dismissed for current users, only new users should see these changes.

For theme authors, the post title and placeholder paragraph text for the block appender will inherit body font styles. Previously, they had specific styles attached to them in the editor. The current downside is that the post title is not an <h1> element so it cannot automatically inherit styles for that element. However, that will change once the post title becomes a true block in the editor.

The editor also now clears centered blocks following a floated block. This is an opinionated design change, but it should not negatively affect most themes. However, theme authors should double-check their theme styles to be sure.

Updated Block and Pattern Inserter Patterns available in the inserter.

The development team added patterns to the existing inserter. Now, both blocks and patterns have an individual tab within a unified interface. This is yet another step in the evolution of the pattern system that should land in core WordPress this year.

Right now, the experience is a two-steps-forward-one-step-back deal. The inserter’s behavior has improved and it is great to see patterns merged into it. However, all blocks and patterns are within long lists that require scrolling to dig through. Block categories are no longer tabbed in version 8.0, which is a regression from previous versions. I am certain this will be resolved soon enough, but it is a little frustrating locating a block in the list at the moment.

Merging patterns into the inserter is an ongoing process. There is still a lot of work to do before the final product is polished and included in core WordPress.

The following are some key items that need to be addressed in upcoming versions of Gutenberg:

  • Patterns should be categorized the same as blocks.
  • The block search box should switch to a pattern search box when viewing patterns.
  • Pattern titles should be reintroduced in the interface (removed in 8.0).

Of course, there is a host of other minor and major issues the team will need to cover to nail down the user experience. For now, the interface for patterns continues to improve.

Subscript and Superscript Formats Adding superscript text to the editor.

Gutenberg developers added two new inline formatting options to the editor toolbar: subscript and superscript. These options allow users to add text such as X2 and X2. They work the same as bold, italic, inline code, and other options.

The two formatting options represent their respective inline HTML tags, <sub> for subscript and <sup> for superscript. With the addition of the elements, the toolbar now covers most of the widely-used inline HTML tags. The only other tags that are low on my wish list are <abbr>, <del>, and <ins>, but I could live with those remaining firmly in plugin territory.

Improved Code Editor Updated code-editing view.

The code editor received a much-needed overhaul in the 8.0 update. Everything from the post title to the content is set in a monospace font, and the width of the code editing box spans the editing area. It should be a welcome change for those who need to switch to code view once in a while.

The next step to polishing the code editor (and the HTML block) would be to add syntax highlighting. In the current version, the HTML output is plain text. Given the extra markup that the block editor produces, it can be a bit of a jumbled mess to wade through. Basic syntax highlighting would improve the experience several times over. There is a GitHub ticket for adding the feature, but it has not seen any movement in several months.

BuddyPress: BuddyPress 6.0.0 Release Candidate

Wordpress Planet - Thu, 04/30/2020 - 00:45

Hello BuddyPress community members!

The first release candidate for BuddyPress 6.0.0 is now available for a last round of testing!

This is an important milestone as we progress toward the BuddyPress 6.0.0 final release date. “Release Candidate” means that we think the new version is ready for release, but with more than 200,000 active installs, hundreds of BuddyPress plugins and Thousands of WordPress themes, it’s possible something was missed.

BuddPress 6.0.0 is slated for release on Thursday, May 14, but we need your help to get there—if you haven’t tried 6.0.0 yet, now is the time!

You can test the 6.0.0-RC pre-release in 4 ways :

A detailed changelog will be part of our official release note, but you can get a quick overview by reading the post about the 6.0.0 Beta1 release.

Plugin and Theme Developers

Please test your plugins and themes against BuddyPress 6.0.0. If you find compatibility problems, please be sure to post to this specific support topic so we can figure those out before the final release. We strongly advise you to have a look at the 6.0.0 development notes to figure out what to focus on during your testing.

Polyglots, we need you!

Do you speak a language other than English? Help us translate BuddyPress into many languages! This release also marks the string freeze point of the 6.0.0 release schedule. For your information, we are now using WP CLI to generate the buddypress.pot file and you’ll see we’ve paid attention to add translators comments to all the strings needing some.

If you think you’ve found a bug, please let us know reporting it on the support forums and/or on our development tracker.

Thanks in advance for giving the release candidate a test drive!

BuddyPress: BuddyPress 6.0.0 Release Candidate

Wordpress Planet - Thu, 04/30/2020 - 00:45

Hello BuddyPress community members!

The first release candidate for BuddyPress 6.0.0 is now available for a last round of testing!

This is an important milestone as we progress toward the BuddyPress 6.0.0 final release date. “Release Candidate” means that we think the new version is ready for release, but with more than 200,000 active installs, hundreds of BuddyPress plugins and Thousands of WordPress themes, it’s possible something was missed.

BuddPress 6.0.0 is slated for release on Thursday, May 14, but we need your help to get there—if you haven’t tried 6.0.0 yet, now is the time!

You can test the 6.0.0-RC pre-release in 4 ways :

A detailed changelog will be part of our official release note, but you can get a quick overview by reading the post about the 6.0.0 Beta1 release.

Plugin and Theme Developers

Please test your plugins and themes against BuddyPress 6.0.0. If you find compatibility problems, please be sure to post to this specific support topic so we can figure those out before the final release. We strongly advise you to have a look at the 6.0.0 development notes to figure out what to focus on during your testing.

Polyglots, we need you!

Do you speak a language other than English? Help us translate BuddyPress into many languages! This release also marks the string freeze point of the 6.0.0 release schedule. For your information, we are now using WP CLI to generate the buddypress.pot file and you’ll see we’ve paid attention to add translators comments to all the strings needing some.

If you think you’ve found a bug, please let us know reporting it on the support forums and/or on our development tracker.

Thanks in advance for giving the release candidate a test drive!

BuddyPress: BuddyPress 6.0.0 Release Candidate

Wordpress Planet - Thu, 04/30/2020 - 00:45

Hello BuddyPress community members!

The first release candidate for BuddyPress 6.0.0 is now available for a last round of testing!

This is an important milestone as we progress toward the BuddyPress 6.0.0 final release date. “Release Candidate” means that we think the new version is ready for release, but with more than 200,000 active installs, hundreds of BuddyPress plugins and Thousands of WordPress themes, it’s possible something was missed.

BuddPress 6.0.0 is slated for release on Thursday, May 14, but we need your help to get there—if you haven’t tried 6.0.0 yet, now is the time!

You can test the 6.0.0-RC pre-release in 4 ways :

A detailed changelog will be part of our official release note, but you can get a quick overview by reading the post about the 6.0.0 Beta1 release.

Plugin and Theme Developers

Please test your plugins and themes against BuddyPress 6.0.0. If you find compatibility problems, please be sure to post to this specific support topic so we can figure those out before the final release. We strongly advise you to have a look at the 6.0.0 development notes to figure out what to focus on during your testing.

Polyglots, we need you!

Do you speak a language other than English? Help us translate BuddyPress into many languages! This release also marks the string freeze point of the 6.0.0 release schedule. For your information, we are now using WP CLI to generate the buddypress.pot file and you’ll see we’ve paid attention to add translators comments to all the strings needing some.

If you think you’ve found a bug, please let us know reporting it on the support forums and/or on our development tracker.

Thanks in advance for giving the release candidate a test drive!

WPTavern: WordPress 5.4.1 Addresses 7 Security Issues and Fixes Several Bugs

Wordpress Planet - Wed, 04/29/2020 - 20:39

WordPress 5.4.1, a security and maintenance release, dropped today. The release addresses seven security issues, which were all responsibly disclosed to the WordPress security team. Core developers also included several fixes for code regressions in the previous version 5.4 release and ported bug fixes to the block editor from the Gutenberg plugin.

End-users with automatic updates enabled should begin seeing their sites updated shortly. Other users should update as soon as possible to make sure they are running a version of WordPress with the latest security fixes.

The WordPress support team has published the full release documentation for those who wish to view it.

Security fixes were added to every major version of WordPress from 5.4 back to 3.7. The following vulnerabilities were addressed:

  • Password reset tokens were not correctly invalidated.
  • Some private posts could be viewed without authentication.
  • Two cross-site scripting (XSS) vulnerabilities in the customizer.
  • XSS issue in the search block.
  • XSS issue in the WordPress object cache.
  • XSS issue with file uploads.
  • XSS issue in the block editor for WordPress 5.4 Release Candidates 1 and 2 (fixed in 5.4 RC5).
Block Editor Updates

Several fixes were high priority enough from the Gutenberg plugin to port to the WordPress 5.4.1 release. The biggest user-facing issues were a broken block duplication keyboard shortcut, misaligned buttons blocks, and odd scrolling behavior when attempting to edit text in a long block.

The following is a full list of the issues the development team addressed:

  • Fixed the Ctrl + Shift + D keyboard shortcut for duplicating a block, which no longer throws an error.
  • Adds correct margins when aligning the buttons block left or right.
  • Prevents the editor from scrolling to the top when clicking to edit a large block, such as a long list.
  • No longer hides the toolbar for plugins that have text inputs in the toolbar.
  • Stops a JavaScript crash with the latest posts block when an image has missing dimensions.
  • Escapes the HTML class for the RSS and search blocks to prevent malformed markup.

To review the code changes to the block editor in-depth, see the full ticket list.

Other Core WordPress Changes

Users who run their browsers in dark mode can rejoice if they also use the core WordPress favicon. The team introduced an updated favicon with a light background so that it no longer washes out. It is a minor fix but makes the famed WordPress logo look more professional.

The heading level, which was previously set to <h3>, has been bumped up one level on the WordPress admin freedoms screen (wp-admin/freedoms.php). This change provides the proper heading level and should help screen-reading users better navigate the page.

For users on the Edge or iOS Safari browsers who could not select files in the media library, it was due to a CSS issue that hid the input. This should no longer be an issue in the new update.

WordPress 5.4.1 addressed some regressions from the previous version. One revolves around posting by email when no post title was added. In that scenario, the email subject should have been used as the title, but this was broken by a code change in WordPress 5.4. For developers, the category_link and tag_link filter hooks were mistakenly deprecated previously and are now once again good to use without throwing a notice.

Plugin developers have a few bug fixes to look forward to. The WP_Site_Health object is now instantiated after the plugins_loaded and after_setup_theme hooks, which means they can perform necessary actions before the site health is checked. The deprecated wp_get_user_request_data() function is now correctly loaded on the front end, which was causing errors with plugins such as BuddyPress.

In a larger design change, plugin authors who add custom content to the privacy policy guide can use more HTML elements. In WordPress 5.4, the guide design was updated to add a white background behind the suggested text. However, the new code only applied to paragraphs. Now, the design supports tables, lists, and other elements that are commonly used. Unordered lists also have bullet points to distinguish them from paragraphs.

The development team fixed two issues with the REST API. The first corrected an issue with the get_item permissions check. The second fixed the _fields filtering. The core code now uses the rest_is_field_included() function to determine which fields to include to permit filtering by nested field properties.

WPTavern: WordPress 5.4.1 Addresses 7 Security Issues and Fixes Several Bugs

Wordpress Planet - Wed, 04/29/2020 - 20:39

WordPress 5.4.1, a security and maintenance release, dropped today. The release addresses seven security issues, which were all responsibly disclosed to the WordPress security team. Core developers also included several fixes for code regressions in the previous version 5.4 release and ported bug fixes to the block editor from the Gutenberg plugin.

End-users with automatic updates enabled should begin seeing their sites updated shortly. Other users should update as soon as possible to make sure they are running a version of WordPress with the latest security fixes.

The WordPress support team has published the full release documentation for those who wish to view it.

Security fixes were added to every major version of WordPress from 5.4 back to 3.7. The following vulnerabilities were addressed:

  • Password reset tokens were not correctly invalidated.
  • Some private posts could be viewed without authentication.
  • Two cross-site scripting (XSS) vulnerabilities in the customizer.
  • XSS issue in the search block.
  • XSS issue in the WordPress object cache.
  • XSS issue with file uploads.
  • XSS issue in the block editor for WordPress 5.4 Release Candidates 1 and 2 (fixed in 5.4 RC5).
Block Editor Updates

Several fixes were high priority enough from the Gutenberg plugin to port to the WordPress 5.4.1 release. The biggest user-facing issues were a broken block duplication keyboard shortcut, misaligned buttons blocks, and odd scrolling behavior when attempting to edit text in a long block.

The following is a full list of the issues the development team addressed:

  • Fixed the Ctrl + Shift + D keyboard shortcut for duplicating a block, which no longer throws an error.
  • Adds correct margins when aligning the buttons block left or right.
  • Prevents the editor from scrolling to the top when clicking to edit a large block, such as a long list.
  • No longer hides the toolbar for plugins that have text inputs in the toolbar.
  • Stops a JavaScript crash with the latest posts block when an image has missing dimensions.
  • Escapes the HTML class for the RSS and search blocks to prevent malformed markup.

To review the code changes to the block editor in-depth, see the full ticket list.

Other Core WordPress Changes

Users who run their browsers in dark mode can rejoice if they also use the core WordPress favicon. The team introduced an updated favicon with a light background so that it no longer washes out. It is a minor fix but makes the famed WordPress logo look more professional.

The heading level, which was previously set to <h3>, has been bumped up one level on the WordPress admin freedoms screen (wp-admin/freedoms.php). This change provides the proper heading level and should help screen-reading users better navigate the page.

For users on the Edge or iOS Safari browsers who could not select files in the media library, it was due to a CSS issue that hid the input. This should no longer be an issue in the new update.

WordPress 5.4.1 addressed some regressions from the previous version. One revolves around posting by email when no post title was added. In that scenario, the email subject should have been used as the title, but this was broken by a code change in WordPress 5.4. For developers, the category_link and tag_link filter hooks were mistakenly deprecated previously and are now once again good to use without throwing a notice.

Plugin developers have a few bug fixes to look forward to. The WP_Site_Health object is now instantiated after the plugins_loaded and after_setup_theme hooks, which means they can perform necessary actions before the site health is checked. The deprecated wp_get_user_request_data() function is now correctly loaded on the front end, which was causing errors with plugins such as BuddyPress.

In a larger design change, plugin authors who add custom content to the privacy policy guide can use more HTML elements. In WordPress 5.4, the guide design was updated to add a white background behind the suggested text. However, the new code only applied to paragraphs. Now, the design supports tables, lists, and other elements that are commonly used. Unordered lists also have bullet points to distinguish them from paragraphs.

The development team fixed two issues with the REST API. The first corrected an issue with the get_item permissions check. The second fixed the _fields filtering. The core code now uses the rest_is_field_included() function to determine which fields to include to permit filtering by nested field properties.

WPTavern: WordPress 5.4.1 Addresses 7 Security Issues and Fixes Several Bugs

Wordpress Planet - Wed, 04/29/2020 - 20:39

WordPress 5.4.1, a security and maintenance release, dropped today. The release addresses seven security issues, which were all responsibly disclosed to the WordPress security team. Core developers also included several fixes for code regressions in the previous version 5.4 release and ported bug fixes to the block editor from the Gutenberg plugin.

End-users with automatic updates enabled should begin seeing their sites updated shortly. Other users should update as soon as possible to make sure they are running a version of WordPress with the latest security fixes.

The WordPress support team has published the full release documentation for those who wish to view it.

Security fixes were added to every major version of WordPress from 5.4 back to 3.7. The following vulnerabilities were addressed:

  • Password reset tokens were not correctly invalidated.
  • Some private posts could be viewed without authentication.
  • Two cross-site scripting (XSS) vulnerabilities in the customizer.
  • XSS issue in the search block.
  • XSS issue in the WordPress object cache.
  • XSS issue with file uploads.
  • XSS issue in the block editor for WordPress 5.4 Release Candidates 1 and 2 (fixed in 5.4 RC5).
Block Editor Updates

Several fixes were high priority enough from the Gutenberg plugin to port to the WordPress 5.4.1 release. The biggest user-facing issues were a broken block duplication keyboard shortcut, misaligned buttons blocks, and odd scrolling behavior when attempting to edit text in a long block.

The following is a full list of the issues the development team addressed:

  • Fixed the Ctrl + Shift + D keyboard shortcut for duplicating a block, which no longer throws an error.
  • Adds correct margins when aligning the buttons block left or right.
  • Prevents the editor from scrolling to the top when clicking to edit a large block, such as a long list.
  • No longer hides the toolbar for plugins that have text inputs in the toolbar.
  • Stops a JavaScript crash with the latest posts block when an image has missing dimensions.
  • Escapes the HTML class for the RSS and search blocks to prevent malformed markup.

To review the code changes to the block editor in-depth, see the full ticket list.

Other Core WordPress Changes

Users who run their browsers in dark mode can rejoice if they also use the core WordPress favicon. The team introduced an updated favicon with a light background so that it no longer washes out. It is a minor fix but makes the famed WordPress logo look more professional.

The heading level, which was previously set to <h3>, has been bumped up one level on the WordPress admin freedoms screen (wp-admin/freedoms.php). This change provides the proper heading level and should help screen-reading users better navigate the page.

For users on the Edge or iOS Safari browsers who could not select files in the media library, it was due to a CSS issue that hid the input. This should no longer be an issue in the new update.

WordPress 5.4.1 addressed some regressions from the previous version. One revolves around posting by email when no post title was added. In that scenario, the email subject should have been used as the title, but this was broken by a code change in WordPress 5.4. For developers, the category_link and tag_link filter hooks were mistakenly deprecated previously and are now once again good to use without throwing a notice.

Plugin developers have a few bug fixes to look forward to. The WP_Site_Health object is now instantiated after the plugins_loaded and after_setup_theme hooks, which means they can perform necessary actions before the site health is checked. The deprecated wp_get_user_request_data() function is now correctly loaded on the front end, which was causing errors with plugins such as BuddyPress.

In a larger design change, plugin authors who add custom content to the privacy policy guide can use more HTML elements. In WordPress 5.4, the guide design was updated to add a white background behind the suggested text. However, the new code only applied to paragraphs. Now, the design supports tables, lists, and other elements that are commonly used. Unordered lists also have bullet points to distinguish them from paragraphs.

The development team fixed two issues with the REST API. The first corrected an issue with the get_item permissions check. The second fixed the _fields filtering. The core code now uses the rest_is_field_included() function to determine which fields to include to permit filtering by nested field properties.

WPTavern: WordPress 5.4.1 Addresses 7 Security Issues and Fixes Several Bugs

Wordpress Planet - Wed, 04/29/2020 - 20:39

WordPress 5.4.1, a security and maintenance release, dropped today. The release addresses seven security issues, which were all responsibly disclosed to the WordPress security team. Core developers also included several fixes for code regressions in the previous version 5.4 release and ported bug fixes to the block editor from the Gutenberg plugin.

End-users with automatic updates enabled should begin seeing their sites updated shortly. Other users should update as soon as possible to make sure they are running a version of WordPress with the latest security fixes.

The WordPress support team has published the full release documentation for those who wish to view it.

Security fixes were added to every major version of WordPress from 5.4 back to 3.7. The following vulnerabilities were addressed:

  • Password reset tokens were not correctly invalidated.
  • Some private posts could be viewed without authentication.
  • Two cross-site scripting (XSS) vulnerabilities in the customizer.
  • XSS issue in the search block.
  • XSS issue in the WordPress object cache.
  • XSS issue with file uploads.
  • XSS issue in the block editor for WordPress 5.4 Release Candidates 1 and 2 (fixed in 5.4 RC5).
Block Editor Updates

Several fixes were high priority enough from the Gutenberg plugin to port to the WordPress 5.4.1 release. The biggest user-facing issues were a broken block duplication keyboard shortcut, misaligned buttons blocks, and odd scrolling behavior when attempting to edit text in a long block.

The following is a full list of the issues the development team addressed:

  • Fixed the Ctrl + Shift + D keyboard shortcut for duplicating a block, which no longer throws an error.
  • Adds correct margins when aligning the buttons block left or right.
  • Prevents the editor from scrolling to the top when clicking to edit a large block, such as a long list.
  • No longer hides the toolbar for plugins that have text inputs in the toolbar.
  • Stops a JavaScript crash with the latest posts block when an image has missing dimensions.
  • Escapes the HTML class for the RSS and search blocks to prevent malformed markup.

To review the code changes to the block editor in-depth, see the full ticket list.

Other Core WordPress Changes

Users who run their browsers in dark mode can rejoice if they also use the core WordPress favicon. The team introduced an updated favicon with a light background so that it no longer washes out. It is a minor fix but makes the famed WordPress logo look more professional.

The heading level, which was previously set to <h3>, has been bumped up one level on the WordPress admin freedoms screen (wp-admin/freedoms.php). This change provides the proper heading level and should help screen-reading users better navigate the page.

For users on the Edge or iOS Safari browsers who could not select files in the media library, it was due to a CSS issue that hid the input. This should no longer be an issue in the new update.

WordPress 5.4.1 addressed some regressions from the previous version. One revolves around posting by email when no post title was added. In that scenario, the email subject should have been used as the title, but this was broken by a code change in WordPress 5.4. For developers, the category_link and tag_link filter hooks were mistakenly deprecated previously and are now once again good to use without throwing a notice.

Plugin developers have a few bug fixes to look forward to. The WP_Site_Health object is now instantiated after the plugins_loaded and after_setup_theme hooks, which means they can perform necessary actions before the site health is checked. The deprecated wp_get_user_request_data() function is now correctly loaded on the front end, which was causing errors with plugins such as BuddyPress.

In a larger design change, plugin authors who add custom content to the privacy policy guide can use more HTML elements. In WordPress 5.4, the guide design was updated to add a white background behind the suggested text. However, the new code only applied to paragraphs. Now, the design supports tables, lists, and other elements that are commonly used. Unordered lists also have bullet points to distinguish them from paragraphs.

The development team fixed two issues with the REST API. The first corrected an issue with the get_item permissions check. The second fixed the _fields filtering. The core code now uses the rest_is_field_included() function to determine which fields to include to permit filtering by nested field properties.

WordPress.org blog: WordPress 5.4.1

Wordpress Planet - Wed, 04/29/2020 - 19:56

WordPress 5.4.1 is now available!

This security and maintenance release features 17 bug fixes in addition to 7 security fixes. Because this is a security release, it is recommended that you update your sites immediately. All versions since WordPress 3.7 have also been updated.

WordPress 5.4.1 is a short-cycle security and maintenance release. The next major release will be version 5.5.

You can download WordPress 5.4.1 by downloading from WordPress.org, 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

Seven security issues affect WordPress versions 5.4 and earlier. If you haven’t yet updated to 5.4, all WordPress versions since 3.7 have also been updated to fix the following security issues:

  • Props to Muaz Bin Abdus Sattar and Jannes who both independently reported an issue where password reset tokens were not properly invalidated
  • Props to ka1n4t for finding an issue where certain private posts can be viewed unauthenticated
  • Props to Evan Ricafort for discovering an XSS issue in the Customizer
  • Props to Ben Bidner from the WordPress Security Team who discovered an XSS issue in the search block
  • Props to Nick Daugherty from WordPress VIP / WordPress Security Team who discovered an XSS issue in wp-object-cache
  • Props to Ronnie Goodrich (Kahoots) and Jason Medeiros who independently reported an XSS issue in file uploads.
  • Props to Weston Ruter for fixing a stored XSS vulnerability in the WordPress customizer.
  • Additionally, an authenticated XSS issue in the block editor was discovered by Nguyen The Duc (ducnt) in WordPress 5.4 RC1 and RC2. It was fixed in 5.4 RC5. We wanted to be sure to give credit and thank them for all of their work in making WordPress more secure.

Thank you to all of the reporters for privately disclosing the vulnerabilities. This gave the security team time to fix the vulnerabilities before WordPress sites could be attacked.

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

In addition to the security researchers mentioned above, thank you to everyone who helped make WordPress 5.4.1 happen:

Alex Concha, Andrea Fercia, Andrew Duthie, Andrew Ozz, Andy Fragen, Andy Peatling, arnaudbroes, Chris Van Patten, Daniel Richards, DhrRob, Dono12, dudo, Ehtisham Siddiqui, Ella van Durpe, Garrett Hyder, Ian Belanger, Ipstenu (Mika Epstein), Jake Spurlock, Jb Audras, John Blackbourn, John James Jacoby, Jonathan Desrosiers, Jorge Costa, K. Adam White, Kelly Choyce-Dwan, MarkRH, mattyrob, Miguel Fonseca, Mohammad Jangda, Mukesh Panchal, Nick Daugherty, noahtallen, Paul Biron, Peter Westwood, Peter Wilson, pikamander2, r-a-y, Riad Benguella, Robert Anderson, Samuel Wood (Otto), Sergey Biryukov, Søren Brønsted, Stanimir Stoyanov, tellthemachines, Timothy Jacobs, Toro_Unit (Hiroshi Urabe), treecutter, and yohannp.

WordPress.org blog: WordPress 5.4.1

Wordpress Planet - Wed, 04/29/2020 - 19:56

WordPress 5.4.1 is now available!

This security and maintenance release features 17 bug fixes in addition to 7 security fixes. Because this is a security release, it is recommended that you update your sites immediately. All versions since WordPress 3.7 have also been updated.

WordPress 5.4.1 is a short-cycle security and maintenance release. The next major release will be version 5.5.

You can download WordPress 5.4.1 by downloading from WordPress.org, 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

Seven security issues affect WordPress versions 5.4 and earlier. If you haven’t yet updated to 5.4, all WordPress versions since 3.7 have also been updated to fix the following security issues:

  • Props to Muaz Bin Abdus Sattar and Jannes who both independently reported an issue where password reset tokens were not properly invalidated
  • Props to ka1n4t for finding an issue where certain private posts can be viewed unauthenticated
  • Props to Evan Ricafort for discovering an XSS issue in the Customizer
  • Props to Ben Bidner from the WordPress Security Team who discovered an XSS issue in the search block
  • Props to Nick Daugherty from WordPress VIP / WordPress Security Team who discovered an XSS issue in wp-object-cache
  • Props to Ronnie Goodrich (Kahoots) and Jason Medeiros who independently reported an XSS issue in file uploads.
  • Props to Weston Ruter for fixing a stored XSS vulnerability in the WordPress customizer.
  • Additionally, an authenticated XSS issue in the block editor was discovered by Nguyen The Duc (ducnt) in WordPress 5.4 RC1 and RC2. It was fixed in 5.4 RC5. We wanted to be sure to give credit and thank them for all of their work in making WordPress more secure.

Thank you to all of the reporters for privately disclosing the vulnerabilities. This gave the security team time to fix the vulnerabilities before WordPress sites could be attacked.

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

In addition to the security researchers mentioned above, thank you to everyone who helped make WordPress 5.4.1 happen:

Alex Concha, Andrea Fercia, Andrew Duthie, Andrew Ozz, Andy Fragen, Andy Peatling, arnaudbroes, Chris Van Patten, Daniel Richards, DhrRob, Dono12, dudo, Ehtisham Siddiqui, Ella van Durpe, Garrett Hyder, Ian Belanger, Ipstenu (Mika Epstein), Jake Spurlock, Jb Audras, John Blackbourn, John James Jacoby, Jonathan Desrosiers, Jorge Costa, K. Adam White, Kelly Choyce-Dwan, MarkRH, mattyrob, Miguel Fonseca, Mohammad Jangda, Mukesh Panchal, Nick Daugherty, noahtallen, Paul Biron, Peter Westwood, Peter Wilson, pikamander2, r-a-y, Riad Benguella, Robert Anderson, Samuel Wood (Otto), Sergey Biryukov, Søren Brønsted, Stanimir Stoyanov, tellthemachines, Timothy Jacobs, Toro_Unit (Hiroshi Urabe), treecutter, and yohannp.

Pages