Settings API notices/errors can get lost by checking for errors for a specific setting

[kobenland]

When using the Settings API, setting errors are saved in a transient to be available after redirection.

After the redirect, when a plugin now checks for errors:

<?php
//by checking
get_settings_errors( 'settings-name' );

// or displaying
settings_errors( 'settings-name' );

any existing errors retrieved from the transient gets lost, because they share the same variable and every error that does not match the requested setting gets unset.

This was introduced in [13177] (#11474).

Make sure errors from transient get added to the global variable and not unset when checking for an error of a specific setting. Also always return an array, as noted in the documentation.

1. Settings error is saved by the Settings API in the 'settings_error' transient.
2. On next page-load (redirected back to the original settings page) settings_errors() gets called, looking for errors to a specific setting.
3. Since $_GET['settings-updated' is set, the transient gets pulled into the temporary variable $settings_errors and then deleted (all other errors, previously added by add_settings_error(), also get merged into the $settings_errors variable)
4. Errors to a specific setting are requested, so $settings_errors get looped through, unsetting every error that does not belong to the requested setting. Including the ones from the transient.

Patch merges the errors into the global $wp_settings_errors variable, making them available through multiple calls to settings_errors().

Patch also returns only the requested errors, without unsetting all others.

In [21315]:

For get_settings_errors(), make sure errors from transient get added to the global variable and not unset when checking for an error of a specific setting. Also always return an array, as noted in the documentation. Props obenland. fixes #20833

21315.debug-cruft.patch​ removes debug cruft from [21315].

[21349]