Alter how settings_errors are output in options.php

[griffinjt]

The *_settings_error(s) and settings_error functions are used mainly as part of the Settings API, but with the way that options.php currently handles the settings errors, it assumes that people will use this functionality exclusively with the Settings API. Notice options.php, starting at line 153:

	/**
	 * Handle settings errors and return to options page
	 */
	// If no settings errors were registered add a general 'updated' message.
	if ( !count( get_settings_errors() ) )
		add_settings_error('general', 'settings_updated', __('Settings saved.'), 'updated');
	set_transient('settings_errors', get_settings_errors(), 30);

This simply assumes that no other outside source has registered any sort of setting error other than the current options page. TwentyEleven does this, and so if any other source has registered any notices via these functions, the "Settings saved." message will not be output because the first bit of logic will fail. I don't think this assumption can (nor should) be warranted, so there needs to be another way to handle this so that themes like TwentyEleven who only call settings_errors at the top of their options page don't get unknowingly hijacked by other sources.

I always suggest registering your own errors at the end of the sanitization callback for your setting, and then output those specific errors within settings_errors to avoid any internal conflicts like this.

Just looking for some ways to approach this. :-)

[kobenland]

Related: #20833

[WraithKenny]

I think the trend is to discourage posting to the options.php. Options pages in themes and plugins can post to themselves, handle errors, do sanitation, etc. and do it much better by themselves.