Support `warning` and `info` type notices in settings errors

[desrosj]

The add_settings_error() only supports error and updated admin notices. These should also be supported for scenarios where error or updated are not appropriate.

[desrosj]

44941.diff​ uses .settings-error.warning and .settings-error.info to add support for these. The updated and error notices are supported with the div.updated and div.error selectors, but adding div.warning and div.info to core would probably result in plugin and theme elements unintentionally being styled.

If the div selectors are preferred, that could maybe go into a major release if accompanied by a dev-note, but that doesn't address all backward compatibility concerns.

[javorszky]

This looks good! Tried with

add_settings_error( 'bulk_action', 'bulk_action', 'Error text', 'info' );

and

add_settings_error( 'bulk_action', 'bulk_action', 'Error text', 'warning' );

They look like this:

[karmatosed]

This was discussed in this week's triage meeting. Thank you for the work done here, looks great and removing feedback keyword.

[donmhico]

Removed the CSS part from 44941.diff and added the @since docs.

[donmhico]

In my patch 44941.2.diff, I removed the CSS part because notices should use the existing .notice-* styles. See #44640.

[donmhico]

Corrected @since to adhere to WPCS.

[SergeyBiryukov]

In 45814:

Administration: In add_settings_error(), add warning and info as possible values for message type.

Account for these new values in settings_errors(), resulting in notice-warning and notice-info CSS classes.

Map legacy error and updated CSS classes to notice-error and notice-success.

Props donmhico, toddhalfpenny, flixos90, desrosj, javorszky, SergeyBiryukov.
Fixes #44640, #44941.

[afercia]

Minor: worth noting the changes in [45814] break plugins that are (with good intent) passing a proper CSS class. For example, if a plugin passes notice-error, the CSS class printed out will now be notice-notice-error. Maybe worth considering a quick dev note. See also #44640.

Yes, the previous documentation mentioned Accepts 'error' or 'updated' but there was nothing in the code to prevent to pass arbitrary class names. Even in the new code there's nothing to prevent it.

Also, one could pass a string like the following:

error my-own-css-class hello world

and actually get the following (spaces are stripped out by sanitize_html_class()):

notice notice-errormy-own-css-classhelloworld settings-error is-dismissible

[SergeyBiryukov]

Replying to afercia:

Minor: worth noting the changes in [45814] break plugins that are (with good intent) passing a proper CSS class. For example, if a plugin passes notice-error, the CSS class printed out will now be notice-notice-error. Maybe worth considering a quick dev note. See also #44640.

Good catch, we should only add notice- if it doesn't already exist, and only to error, success, warning, info, not other random classes.

Also, one could pass a string like the following:

error my-own-css-class hello world

and actually get the following (spaces are stripped out by sanitize_html_class()):

notice notice-errormy-own-css-classhelloworld settings-error is-dismissible

I guess I was a bit overzealous with sanitize_html_class(), esc_attr() could be used instead.

Looks like this needs some more work, I don't think we should break backward compatibility here.

[SergeyBiryukov]

In 45873:

Administration: Adjust [45814] to address a backward compatibility issue for plugins passing multiple CSS classes to add_settings_error().

Only add the notice- prefix for error, success, warning, info CSS classes, keep other classes as is.

Add unit tests for settings_errors().

Props afercia, SergeyBiryukov.
Fixes #44941.

[donmhico]

Nice catch @afercia and thanks for the resolution @SergeyBiryukov.

[desrosj]

Mentioned in the Miscellaneous Developer Focused Changes dev note for 5.3: ​https://make.wordpress.org/core/2019/10/15/miscellaneous-developer-focused-changes-in-5-3/