An updated Button component in WordPress 5.4

As the @wordpress/components package becomes the vehicle that implements more and more of the WordPress design system, and as that system matures, its components get more consistent and more coherent.

WordPress 5.4 adds a number of changes and enhancements to the Button component.

Button sizes

In keeping with the overall design direction of the project, the button default height is now 36px. So you no longer need to use the previous isLarge prop variation.

The Button still supports the isSmall variation.

import { Button } from '@wordpress/components';

const regularButton = <Button>My Button</Button>;
const smallButton = <Button isSmall>My Button</Button>;

To keep all the button variations consistent, their styles now declare specific heights.

If you’ve been relying on the previous buttons’ dynamic heights to make them adapt to their content, you’ll want to override the new fixed heights. Make sure you add the rule below:

height: auto;

Icon support

In previous versions, the components package offered a Button component for regular buttons and an IconButton for buttons with icons.

WordPress 5.4 merges those components. To show buttons with icons, pass an extra icon prop to the regular Button component. You can also mix text and icons.

import { Button } from '@wordpress/components';

const myIcon = (
  <svg xmlns="" viewport="0 0 20 20">
    <path r="M5 4l10 6-10 6V4z" />

const SimpleIconButton = <Button icon={ myIcon } label="Button label" />;

const IconAndTextButton = (
  <Button icon={ myIcon }>
    Button Text

Note: the IconButton is still available, but it’s officially deprecated.

Classname changes

In previous versions, icon buttons relied internally on the components-icon-button. With the merger of the Button and IconButton components, WordPress removes this class name and replaces it with .components-button.has-icon.

Recommendation: Don’t rely on any internal className a component might use. If you want to target a specific component, prefer adding your own className prop and use that instead.

Going further

Try out the Button component or the other wordpress/components. Check out the components Storybook.

#5-4, #block-editor, #components, #dev-notes

Devchat summary: November 27, 2019

The year is winding down!

@francina led the chat; @marybaum here taking notes on a holiday-travel schedule.

20 people announced their presence – of course somewhere around 30K are members, and we could ALL have been watching. The more the merrier!

The chat worked from this agenda.


Next minor: 5.3.1

The announcements were all about the next minor, WordPress 5.3.1.

@justinahinon and I (@marybaum) announced that he would move the Thursday bug scrub to Friday so folks in the US could join in without interrupting their Thanksgiving plans.

After some discussion, @azaozz suggested ad hoc bug scrubs every day until release on December 11. He got active emoji support from five people, and then @audrasjb volunteered to host a bug scrub every day this week (the week of December 2).

Highlighted Posts

@francina called the group’s attention to four conversations.

Got opinions? Especially if your feelings are strong, now’s the time to get over there and share your views:

  1. Recap from last week “Regular” chat (edited) 3:15 PM
  2. Recap from last week “After Hour” chat (edited) 3:15 PM
  3. Tons of good feedback about the 5.3 release (edited) 3:16 PM
  4. And tentative release for 2020-2021 (edited)

And you can always come to devchat, Wednesdays at 21:00 UTC. Find the agenda here, 24 hours in advance.

Calls from Component Maintainers

@francina opened the Call with this wide-ranging intro:

Do we have news from components? Do we have abandoned components that someone wants to adopt? (edited) 3:22 PM

Do we have components that are struggling with the amount of work and need more hands on deck? How can we come together as a community to recruit? (edited) 

See the discussion starting here.

What followed was a general clarification of the difference between a component and a focus, thanks to @sergeybiryukov, who linked to two posts that add some detail.

(I’m listing them in reverse order, so you can read from the general to the specific):

@isabel_brison‘s post introducing the idea of a focus versus a component.

And this post, introducing the Core-CSS group in Slack.

As that discussion ended, @isabel_brison offered to write a followup post, which you can find here.

What are our goals in publishing?

@francina handed the (virtual) mic to @joyously, whose comment on the agenda for this chat asked the group to address goals in publishing.

Essentially, @joyously reminded us that publishers – our users [and as I was trained to think of such folks ~30 years ago, our customers, both internal and external] create content that is going to go more places than just a browser: in emails, feed readers and more. And those environments vary radically in their support for CSS and JS.

In her words:

I am concerned that the trend is toward content that looks good only in a web browser (with JS and CSS) and not good anywhere else.


See the rest of the discussion in chat here.

A highlight: @francina linked to this post on Smashing Magazine, that looks at another facet of this issue.

And be on the lookout for more blog posts addressing the topic, so you can add your thoughts.

#components, #core-css, #devchat, #focuses

Component Maintainers in 5.3

On the heels of APAC Triage and Bug Scrub Sessions and Bug Scrub Schedule for 5.3, thanks @pento and @davidbaumwald, I’d like to propose something a little bit different.

The WordPress 5.3 release is shaping up to be substantial. There are tons of fixes and improvements in Gutenberg, for both users and developers. Even if 5.3 only included the Gutenberg update, it would have been a very nice, very desirable upgrade.

There is more to this release! Currently there are 632 tickets on the 5.3 milestone on Trac, both open and closed. A few smaller new features and user facing enhancements are in the works, and a lot of bugfixes and under-the-hood improvements are coming up or already done.

I’d like to propose that component maintainers take more “charge” of the tickets in their components. There is a general expectation that if you moved a ticket to a milestone you are the “lead” for that ticket and will see it through to completion, or move it to a future milestone if not feasible. But that shouldn’t stop component maintainers from helping to keep those tickets moving.

With the scheduled bug scrubs, and the per-component bug scrubs that usually happen at the components’ meetings, the 329 open tickets aren’t that big of a mountain. 

The 5.3 Challenge

During the next few weeks (by beta-1 scheduled for 23 September) join me in making sure all 5.3 tickets in our components will either be resolved or moved to a future milestone. And if there are any hurdles leave a comment on the ticket briefly outlining the difficulties and include a resolution timeline.

It would also be helpful if during this time all component maintainers do a short, concise update about their component on the weekly core dev chats. These updates would typically include the number of open 5.3 tickets and whether there are any difficulties with any of them. This will help people know where help is most needed, especially any newer contributors who are having trouble deciding where to spend their time.

Also, we have a Docs Wrangler for our release! After 5.3.0-beta-1 is out, it would be great if component maintainers review all changes to their component (if not already reviewed), then, if possible, help @justinahinon with writing or editing dev. notes. There are currently 301 fixes and enhancements committed to the 5.3 milestone and they will need documentation.

The proposed change for component maintainers is to act early, before beta-1, and to regularly make updates and bring any difficulties to the core dev chat.

#5-3, #bug-scrub, #components, #core

Dev Chat Summary: August 28th 2019

This post summarizes the weekly dev chat meeting from August 28th 2019 (agenda / Slack Archive).


@chanthaboune mentioned a Make/Core post about using SSL for auto-updates.

@francina mentioned the recently created WP-Notify working group. They had their first meeting and they have two weekly meeting so people from different timezones can attend. If you are interested, join #feature-notifications dedicated slack channel.

WP-Notify was also added to the features list page on Make/Core.

@francina also mentioned there is a new time slot for Core tickets/Gutenberg issues triage and bug-scrubs. If you are in the APAC timezone feel free to take part into the bug scrubs, they are great to get started in understanding how WordPress is made.

Upcoming Releases


5.2.3 RC 1 is available for testing.

Release lead @whyisjake mentioned they are skipping RC2 for 5.2.3 as there are no new commits since RC1 and no regression was reported against RC1. The final release is scheduled for this coming Wednesday.

Please continue testing, and provide feedback. If you are new to testing Core releases, there is a guide to get started. Getting involved in testing WordPress means you will be directly involved in raising the quality of the WordPress user experience.


@francina announced that @audrasjb is joining the Release Team as focus lead for the accessibility part.

@davidbaumwald ran the first bug scrub of the release cycle, focused on tickets that are milestoned for 5.3, but haven’t see any movement in some time.

@johnbillion: “We need more people attending bug scrubs and scrubbing bugs. Tell all your friends.”. @davidbaumwald added that’s being added for the 5.3 cycle to give props for those running scrubs.

If you want lead a scrub, please get in touch with @davidbaumwald and it will be added to the official schedule to spread the word.

@azaozz mentioned it would also be great if component maintainers could help triage their components.

@audrasjb mentioned the accessibility team will run two additional bug scrubs dedicated to 5.3.

@karmatosed mentioned the design team also runs weekly bug scrubs.

@davidbaumwald is maintaining the list of 5.3 bug scrubs. There was a discussion about having it as a sticky post to see if it helps to increase the number of people attending bug scrubs.

@karmatosed published a post concerning the design of WP core About Page. The post is to start a discussion about what could be easier about this screen. It has a few of the current problems around it and then leads into some potential ideas. Any input on this is welcome.

Call for component maintainers

As per today, there is 6 components without maintainer. Any interested contributors is welcome to help maintain components.

@justinahinon mentioned his interest for the Site Health component.

@francina asked if all the components who seem to have a maintainer really maintained.

@jeffpaul did one component maintainers audit this year and one last year, so the current listing is nearly almost folks who committed to maintaining as best they can.

#5-2-3, #5-3, #bug-scrub, #components, #feature-plugins

Call for Component Maintainers

WordPress is organized into 60 components. Each component can have more than one maintainer. A maintainer triages new tickets, looks after existing ones, spearheads or mentors tasks, pitches new ideas, curates roadmaps, and provides feedback to other contributors.

Pings/Trackbacks, Date/Time, Autosave, Quick/Bulk Edit, Export, Import, Mail, Permalinks, Rewrite Rules, Post Thumbnails, Menus, and Role/Capability are currently without a maintainer. Are you familiar with one of the components and want to help to maintain this component? Please comment below or ping @jorbin or @ocean90 on Slack if you’re interested.


The list of component maintainers is a living document. If you are no longer actively maintaining a component, please remove yourself or let us know so that the list can be as accurate as possible

#4-6, #components

Component Page Updates for 4.4

Now that 4.4 is underway, let’s update the component pages to reflect 4.4 activity. The Customize, Editor, and Press This pages serve as good templates, though they all need 4.4 updates. The component pages are targeted at beta testers. They should describe the component, list milestones (roadmap), and explain what needs testing and how to test it. Good component pages assist triage. For details, see the previous round of component page updates.

Also, if your component has a corresponding Slack chat, link to the component page from the chat’s channel topic. This assists using Slack in beta testing flows.

Component maintainers, here are your component pages…

Continue reading

#components, #maintainership

Proposed Trac component reorganization

Warning, this long. tl;dr: I propose a reorganization of our Trac components. 34 top-level components with two dozen subcomponents. New tree at the bottom. First, an overview of some of our problems.
Continue reading

#components, #trac

Continuing the Trac component re-organization with "focuses"

Based on triaging a few hundred tickets in the General and Multisite components, we’ve added five components:

  • Bootstrap/Load — applies to wp-settings.php, ms-load.php, load.php, ms-settings.php, etc.
  • Login and Registration — useful for multisite, but applies to single-site too
  • Options and Meta — option.php, meta.php, etc.
  • Script Loader — WP_Scripts, WP_Styles, and script-loader.php
  • Networks and Sites — multisite only

We also removed two components that (poorly) described the problem rather than the affected area of core. “Validation” ranged from from validation tickets to XHTML issues. HTML validation issues now belong in the affected component, like “Template” or “Administration.” “Warnings/Notices” contained tickets ranging from PHP warnings to providing feedback to users. The open tickets were moved to more appropriate components. Additionally, the remaining tickets in “AtomPub” were wontfixed and the component was removed.

A new concept: Focuses

We’ve also added seven new “focuses”ui, accessibility, javascript, docs, multisite, performance, and rtl. Focuses are about broad concepts and help break tickets down by specialties and skills, rather than functional areas of core. Multisite and RTL are widely general “modes” for WordPress, and each have contributors who focus strongly on those areas, but they are not well-contained “components” of core. Accessibility isn’t an area of core — it permates the entire user experience. A ticket about inline documentation should still receive the attention of developers for that area of core (say, comment.php), while those who focus on inline documentation should still be able to do so.

“Focuses” is a new field in Trac. They’re like tags, and more than one can be assigned to a ticket. It can be queried using custom queries. And they have their own reports which we hope to properly expose and make better really soon —

Guidelines to help with the transition

The corresponding components for the new focuses have been removed. The “ui-focus” keyword has also been converted over. Overall, we gained five components but lost eight.

This has the potential to be confusing at first and we’ll surely need to make some adjustments. Also, the component cleanup is not done yet — this is just the beginning. Here are some guidelines for how to use the new focuses.

  • The old RTL component — use the rtl focus and assign a relevant component. If it’s RTL issues with the media library, use the “Media” component. If it’s about the RTL build tools, then use the “Build Tools” component. If it’s more general, then use the “I18n” component.

  • The old Accessibility component — use the accessibility focus and assign a relevant component. For issues with the media library, use “Media.” For issues with activating a theme, use “Themes.”

  • The old Inline Docs component — use the docs focus and assign a relevant component. Hook documentation for user.php belongs in the “Users” component.

  • The old Multisite component — use the multisite focus and assign a relevant component. If it’s related to users, use “Users.” If it’s related to the loading process of multisite (choosing a site based on domain and path, etc.), use “Bootstrap/Load.” If it’s related to the installation process, use “Upgrade/Install.” network_admin_url() goes into the “Permalinks” component. get_site_option() is “Options and Meta.” The Network Admin still has its own component. (Choosing that component or “Networks and Sites” automatically assign the “multisite” focus for you.) @jeremyfelt recategorized about 110 tickets into about 15 different components.

  • The old Performance component — use the performance focus and assign a relevant component. Improving the performance of WP_Query belongs in “Query,” improving the performance of get_option() belongs in “Options and Meta,” etc.

  • The old Graphic Design component — use the ui focus and assign a relevant component. (This is probably going to be “Administration”, at least for now.)

  • The old ui-focus keyword — This has been removed. Simply use the ui focus.

  • The old JavaScript and UI components — these have not existed for some time. Use the corresponding focus and assign a relevant component.

We may add more focuses over time. For example, the “Text Changes” component would probably make a better focus, for our wordsmiths.

Any questions, suggestions, or comments?

This is a summary and addendum of one section of this Wednesday’s weekly developer meeting. Logs.

#components, #trac

It might be useful to create a …

It might be useful to create a “Text” component that people could use for reporting typos, suggesting text changes, etc. This would also automatically be a good starter component for people who need something super easy to learn how to submit a patch.