WordPress.org

Make WordPress Core

Opened 13 days ago

Closed 8 days ago

#53324 closed defect (bug) (fixed)

New WordPress installations should have blocks in widget areas instead of widgets

Reported by: noisysocks Owned by: noisysocks
Milestone: 5.8 Priority: normal
Severity: normal Version: trunk
Component: Widgets Keywords: has-patch has-unit-tests
Focuses: Cc:

Description

When installing a new WordPress blog, the widget areas are initially populated with widgets instead of blocks. This means that a new user on a new WordPress installation will see the Legacy Widget block when browsing to the block editor via Appearance → Widgets.

We should replace these default widgets with their block counterparts.

To reproduce:

  1. Create a new WordPress site e.g. by using wp db reset and wp core install.
  2. Go to Appearance → Widgets.
  3. There are Legacy Widget blocks in the widget areas instead of blocks.

Change History (7)

#1 @noisysocks
13 days ago

  • Owner set to noisysocks
  • Status changed from new to accepted

This ticket was mentioned in PR #1331 on WordPress/wordpress-develop by noisysocks.


13 days ago

  • Keywords has-patch has-unit-tests added

Modifies wp_install_defaults() to add blocks to the site's widget areas instead of widgets in a new WordPress installation.

Trac ticket: https://core.trac.wordpress.org/ticket/53324

#3 @prbot
13 days ago

noisysocks commented on PR #1331:

The Twenty Twenty-one theme will need some styling adjustments to accomodate for the different markup.

#4 @prbot
13 days ago

jasmussen commented on PR #1331:

I could use some guidance from someone who knows all about the default themes. @jasmussen, maybe? 🙂

I _always_ appreciate a ping, thank you. In this case, I can only offer limited guidance:

  • A widget-heading class would probably be useful, but I imagine it might be onerous to add to the heading block just in this context, and if it's not easy, might not be worth it.
  • I think it's okay for themes to have to do a few updates here and there, and in this case I imagine there's a widget container they can target, i.e. .widgets h3 instead of h3.widget-heading, it shouldn't be a lot of work, and might be worth it for all the other changes blocks bring to widgets anyway.
  • Finally, the heading block comes with options which classic widget headings didn't. Specifically, you can choose your own heading level, which is an important accessibility consideration for some themes that might be using Widgets in a more primary fashion than others.
  • In addition to being able to set the correct heading level depending on your theme, the heading block comes with the ability to set the font size. That could potentially be a solution here, embracing one of the default smaller presets. I imagine that's why a widget-heading class existed in the first place — H2 might be the correct heading level semantically, but might have been visually too big for the design.

For some actual theme experts, you might want to ping @melchoyce and perhaps @maggiecabrera.

#5 @prbot
12 days ago

noisysocks commented on PR #1331:

Thanks for your useful comment, @jasmussen!

A widget-heading class would probably be useful, but I imagine it might be onerous to add to the heading block just in this context, and if it's not easy, might not be worth it.

Yeah. I think adding the widget-heading class is not the way to go. It will be confusing to users who insert a new Heading block in their widget area as the new Heading block that they add won't have the class and so will appear bigger.

Finally, the heading block comes with options which classic widget headings didn't. Specifically, you can choose your own heading level, which is an important accessibility consideration for some themes that might be using Widgets in a more primary fashion than others.

Great point! 🌈

In addition to being able to set the correct heading level depending on your theme, the heading block comes with the ability to set the font size. That could potentially be a solution here, embracing one of the default smaller presets. I imagine that's why a widget-heading class existed in the first place — H2 might be the correct heading level semantically, but might have been visually too big for the design.

This is a really good idea and not one I'd thought of. I tried it, but it doesn't work fully because we also want the heading to appear bold. We _could_ do this by adding <strong> to the Heading block but I fear that at this point we're having the default blocks assume too much about what everything should look like when really this is the theme's job.

I think it's okay for themes to have to do a few updates here and there, and in this case I imagine there's a widget container they can target, i.e. .widgets h3 instead of h3.widget-heading, it shouldn't be a lot of work, and might be worth it for all the other changes blocks bring to widgets anyway.

I think this is what we have to do! I've adjust the Twenty Twenty-one styles in 249e2d6. Happy to hear thoughts from everyone.

#6 @prbot
12 days ago

noisysocks commented on PR #1331:

Unfortunately this breaks just about every unit test we have 😛. I'll start fixing them on Monday.

#7 @noisysocks
8 days ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 51088:

Make new WordPress installations use blocks in widget areas instead of widgets

Modifies wp_install_defaults() so that when you install a new WordPress site you
have block in your widget areas, not widgets.

Fixes #53324.
Props isabel_brison, hellofromtonya, andraganescu.

Note: See TracTickets for help on using tickets.