Add id's to fieldsets in wp-admin/profile.php

[Otto42]

Change this:

<fieldset>
<legend><?php _e('Update Your Password'); ?></legend>

to this:

<fieldset id='passwords'>
<legend><?php _e('Update Your Password'); ?></legend>

Reasoning: This would allow for a very simple plugin to do essentially the same thing that is given here:
​http://wordpress.com/blog/2007/06/07/how-strong-is-your-password/

All that would then be required of a plugin would be a hook to 'admin_head' to call wp_enqueue_script('jquery') and a hook to 'show_user_profile' to include the small amount of necessary html+javascript to do the password strength indicator.

Further suggestion: All fieldsets on profile.php should be given unique ID's.

[rob1n]

(In [5689]) Add ID's to profile edit form's fieldsets. fixes #4434

This is an attempt at a backport of ​https://github.com/WordPress/gutenberg/pull/44334

The main part of this change is adding a new CSS file and I'm not sure how to do this - I'm guessing this comes from the packages, rather than me adding it manually.

@ockham any insight would be appreciated.

This is an attempt at a backport of ​WordPress/gutenberg#44334

The main part of this change is adding a new CSS file and I'm not sure how to do this - I'm guessing this comes from the packages, rather than me adding it manually.

I think that's accurate; ​according to unpkg.com, the package currently contains files such as ​`common.css` or ​`theme.css` at root level, so I'd expect classic.css to show up there, too.

I'll be publishing a new round of npms for WP 6.1 Beta 2 later today, and since we've cherry-picked ​https://github.com/WordPress/gutenberg/pull/44334 to be included with it, we can check unpkg later to see if the file ended up there.

The ​path you're using to then locate the file in Core after a sync and build also matches where I'm seeing those other CSS files locally.

(To recap, we'll need to wait for packages to be published and synced before we can land this PR 😊 )

Published ​`@wordpress/block-library@7.14.3`. It has classic.css: ​https://unpkg.com/browse/@wordpress/block-library@7.14.3/build-style/classic.css.

Here's the sync PR: ​https://github.com/WordPress/wordpress-develop/pull/3342

I'll rebase so this will pick up classic.css, now that the ​sync PR has landed.

Some more detail from ​https://github.com/WordPress/gutenberg/pull/44334's paper trail:

​https://github.com/WordPress/gutenberg/pull/43981 has testing instructions:

## Testing Instructions

1. Switch to a classic theme that doesn't specify its own button styles (I'm using Canape)
2. Check that button look broken in trunk
3. Check out this PR
4. Check that buttons now look correct:

The styling was apparently originally removed by ​https://github.com/WordPress/gutenberg/pull/34180, which was ​merged into Gutenberg in June. This means that it likely made its way into Core with the ​first package sync for WP 6.1. Testing this now.

The styling was apparently originally removed by ​WordPress/gutenberg#34180, which was ​merged into Gutenberg in June. This means that it likely made its way into Core with the ​first package sync for WP 6.1. Testing this now.

Confirming:

| Before 3b63a75108b7f6d5e9112c556285ab1bc80ddbcf | At 3b63a75108b7f6d5e9112c556285ab1bc80ddbcf |

|

| | |

Merged into core in https://core.trac.wordpress.org/changeset/54358.