id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
21211	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. :-) 


"	defect (bug)	new	normal	Awaiting Review	Administration	3.4.1	normal		2nd-opinion reporter-feedback